8. Blackdown Java Development and Platform Porting

This section answers a few questions about development and Blackdown Java. First, it discusses using Blackdown Java to develop applications. Then it addresses the development of Blackdown ports themselves. It also describes how you can take advantage of the work the Blackdown team is doing, and how you can contribute yourself.

8.1 Development with Blackdown Java

This far from comprehensive section includes discussion of full-blown development with Blackdown Java in the Linux environment.

Last update:

$Id: java-development.sgml,v 1.3 1999/12/31 08:36:18 stevemw Exp $

How can I learn more about developing Java on Linux?

One of the best ways to get started is by participating on the Java Linux mailing list. If you have access to Linux, you can at least experiment with Java.

Nathan Meyers <nmeyers@javalinux.net> has written Java Programming for Linux, published by Macmillan Computer Publishing; its ISBN number is 1571691669. See http://www.javalinux.net/ for more information.

How do I compile native C or C++ code for interfaces?

See section Compiling Library Code for JNI.

8.2 Java Code Examples

This section has pointers to a few code examples we're adding in support of this document. Feel free to contribute suggestions.

Last update:

$Id: examples.sgml,v 1.2 2000/01/11 06:50:21 stevemw Exp $

Where can I find some example Java code to get started?

There isn't much documentation yet, nor are there many examples, but please take a look in this directory: http://www.blackdown.org/java-linux/docs/faq/examples/.

8.3 Java Licensing and the Open Source Community

A discussion of licensing issues with respect to developing Java on Linux. This section also addressess some of the questions those who are interested in contributing to JVM development may have with respect to licensing. None of this is legal advice!

Last update:

$Id: licensing.sgml,v 1.15 2000/01/24 08:36:39 stevemw Exp $

What issues are relevant to understanding Java licensing?

As a user, you're subject to the same licensing restrictions with Blackdown Java as you would be with Sun's Java binaries on Solaris or Win32. It's as simple as that. Pointers to the relevant Sun licensing README files are given below. In other words, you may copy Blackdown JDK binaries over the network from Blackdown mirrors.

As a developer, you unfortunately may not redistribute the Blackdown JDK on CDROM without permission from Sun. Sun has suddenly become very clear about this. Commercial Linux distribution vendors such as Red Hat must work with Sun directly to secure such rights.

The JRE (Java runtime environment) may be embedded and redistributed in your application.

J2SE (Java 2 "standard edition") source is available strictly through Sun to those willing to agree to a license containing certain intellectual property restrictions. Your strict source differences ("patches") may be exchanged freely and openly so long as they only address the porting of the code from one platform to another.

Blackdown is required to test its "full releases" of Java against a Sun-supplied test suite (see section Java Compatibility Kit). If they don't pass, then they must be clearly labeled as "release candidates."

(This topic is briefly introduced in section Under what license is Blackdown Java available?.)

Links to Java Binary Licenses

Below are links the the various license-related documents Blackdown has distributed on behalf of Sun with recent builds of each platform:

• JDK 1.02 http://www.blackdown.org/java-linux/docs/faq/README/1.0/COPYRIGHT, Known as the JDK BCL 9-6-96, or Java Developer's Kit Version 1.0.2 Binary Code License.
• JDK 1.1.8 http://www.blackdown.org/java-linux/docs/faq/README/1.1/LICENSE, or simply the Binary Code License Agreement.
• JDK 1.2.2 http://www.blackdown.org/java-linux/docs/faq/README/1.2/LICENSE, likewise called the Binary Code License Agreement.

Licensing for Java Source

Community access to Java product source has had an inconsistent history. Sun is pursuing a new path with important aspects of its intellectual property licensing known as "Community Source." This is a clear compromise between simply giving away source code (the files from which a set of executables like the Java platform is built) and never sharing it with the world.

This document can't explain everything you may want to know about licensing and development, but it can give a synopsis of the four most important issues to you as a developer or interested user.

• SCSL, or Sun Community source License. Sun is distributing source for many (but not all) of its Java products, including the core JVM. Selling products based on changes you make to the code is something you'll have to work out with Sun with branding and distribution licensing. Blackdown works closely with Sun to ensure that it stays within guidelines, among which include the restriction that it can only distribute patches (diff'erences). You must get the code from Sun directly.
• Burgeoning Java APIs. Although the core of the Java product has been available in source form to the Blackdown community of software developers from early on in its history, the ever-growing number of Java APIs often take longer to go into source availability. Some may never go into community source release.
• NDAs. Blackdown developers have historically needed to sign non-disclosure agreements with Sun, and are now forbidden to participate directly in the two most-commonly known cleanroom open-source JVM efforts, Japhar ( http://www.japhar.org/) and Kaffe ( http://www.kaffe.org/).
• JCK (Java Compatibility Kit). In order to release a build of Java and call it "ready for production," one must test it thoroughly with Sun's Java Compatibility Toolkit, or JCK. Because this suite is closely knit with Sun's partner development process, and is presumably a part of its current revenue stream plans for Java, obtaining access to has been difficult. Read more about the JCK in section Java Compatibility Toolkit. Blackdown has found this toolkit to be essential for porting JDK 1.2 partly because of its increased complexity.

Licensing Comparisons

• SCSL. Read more about the changing horizon of Sun's engagement with the open source community at http://www.sun.com/software/communitysource/.
• LGPL, what Japhar uses. See http://www.fsf.org/copyleft/lesser.html for information about the "GNU Lesser General Public License."
• GPL, and Kaffe's perspective. See http://www.kaffe.org/FAQ.html for information.
• Other such licenses are available at: http://www.opensource.org/licenses/.

Blackdown's Position on Sun's Community Source Policies

Blackdown developers have worked with Sun through each major version of the Java product family, and have appreciated its historic willingness to share source with certain interested developers. We hope Sun's recent attempt to formalize a community source process will prove successful for J2SE (Java 2, standard edition), Sun's commercial partners, and communities like Blackdown. After years of effort to secure a formal code codevelopment relationship, Blackdown is now ready to help Sun and Inprise reach out a world of developers wanting to contribute to the Java platform. However, there remain issues that Blackdown has always struggled with Sun to resolve:

• Help for developing a consistent policy for recruiting new Blackdown developers. Currently, we are unclear how to add new developers to the CVS repository access list, an essential step in bringing in new people. With all the new code to port and maintain, Sun surely knows this is critical.
• Java compatibility kit (JCK) access and updates. The JCK is essential for port development, yet Sun has been reluctant to share it consistently with all Blackdown developers.
• Access to highly current defect information. Blackdown is never sure when it is fighting a defect that Sun has already solved in a different way.
• A standardized method of obtaining recent product changes from Sun and its partners. A shared CVS repository between Sun and Blackdown would be ideal, but daily differences could also be exchanged.
• Standardized codevelopment procedures. In general, a commitment on Sun's part to build standard policies with respect to community source concerns rather that falling back on the heroics of individual managers like Steve Byrne and Calvin Austin.

If Sun could address these issues, we believe it would usher in a new era of productivity among open source developers wanting to help Java succeed.

Please see section Statement of Purpose for the Blackdown Project for a formalized explanation of Blackdown's philosophy about participation with the commercial software world.

Where can I find Sun's Community Source Agreement?

For the most recent set of instructions, which apparently allow you to obtain the source for J2SE (Java 2 Standard Edition), see http://www.sun.com/software/communitysource/java2/.

In the past, you first you had to read, sign, and (historically) FAX in an agreement with Sun. The agreement could be found at http://www.javasoft.com/nav/business/source_form.html.

8.4 Compiling Blackdown Java from Source

Here are some answers to questions about Java platform source code, compiling, and contributing fixes.

Last update:

$Id: source.sgml,v 1.8 2000/01/11 06:50:23 stevemw Exp $

Can I build Java myself?

Building the JDK on Linux with patches supplied by the Blackdown project is fairly straightforward. We encourage you to read http://www.blackdown.org/java-linux/docs/faq/README/1.2/README.linux.src from the patched source distribution if you plan to undertake this project.

Could you give me a pointer to Sun's licensing agreements?

Please see section Where can I find Sun's Community Source Agreement?.

How do I build Blackdown JDK 1.2 now that I have the source?

Read Juergen Kreileder's instructions in your binary distribution. It can be found online here: http://www.blackdown.org/java-linux/docs/faq/README/1.2/README.linux.src.

What about Motif? Don't I need that?

You can build the JDK against Lesstif, the Hungry Programmers' GNU copylefted implementation of the Motif API. For more information, visit their website at http://www.lesstif.org. Make sure you get the "current" distribution. They are very responsive to accurate bug and problem reports.

On the other hand, a number of Motif developer library vendors exist for Linux systems. I recommend you read the Motif comp.windows.x.motif news group FAQ. You can find it here: http://www.rahul.net/kenton/faqs/mfaq_index.html.

What version of Motif is the Blackdown team using?

Thanks to Jim Burmeister at Metro Link, the Blackdown team is currently using metromotif-2.1.10-4. See http://www.metrolink.com/motif/index.html for more information.

When I build and install 1.1, I get unsatisfied link errors at runtime!

For JDK 1.1.x, make sure you're building all the targets Steve Byrne suggests in http://www.blackdown.org/java-linux/docs/faq/README/1.1/README.linux.src. Here's an example:

make DESTDIR="$ALT_JAVAHOME/jdk116v2b" RELEASE="MY-JDK1.1.6-V2B" \
        appletviewer jre_only 2>&1 | tee MakeOut-V2B1-BUILD-01

Note: you ought to have ALT_BOOTDIR set to a running JDK 1.1, and I build with CLASSPATH and JAVA_HOME unset.

Can I try builds of the latest JDK port in development?

Please stay tuned to the mailing list for announcements.

What about the JCK?

See section What does Blackdown use to test Java's adherence to Sun's standards? for more information.

How can I contribute to Blackdown Java development efforts?

If you're not already contributing good bug-reports, patches, or documentation, those are places to get started. If you want to join the developer team, please indicate your interests, relevant experience, and a couple of professional references to Karl Asha <karl@blackdown.org>, the list administrator.

In addition to programming in C, Java, Motif, X11R6, using GDB, and the occasional kernel diving, you'll need to understand CVS, the GNU concurrent versioning system maintained by Cyclic Software http://www.cyclic.com/. A good place to learn about it is Karl Fogel's Open Source Development with CVS book published by Coriolis; its ISBN number is 1-57610-490-7, and you can find much of it freely online at http://cvsbook.red-bean.com/.

What is a source patch?

A source "patch" is generated by the diff(1) program by comparing the contents of one file (or sets of files, including whole directory trees) with another and producing a set of differences suitible for the patch(1) utility. When Blackdown has released a set of patches for a given Sun source release, you can build what Blackdown is shipping on your own Linux system by applying the patch set to your Sun source base. Due to time constraints and the occasional issue with Sun, Blackdown can't always issue diffs with every binary release. However, it is one of Blackdown's goals to deliver source differences as often as possible.

For more http://www.gnu.org/software/libc/libc.html.

8.5 Java Compatibility Kit

Discussion of Sun's JCK, a Java platform testing suite.

Last update:

$Id: jck.sgml,v 1.7 2000/01/05 18:35:31 srh Exp $

What does Blackdown use to test Java's adherence to Sun's standards?

With the advent of Java 2.0, Blackdown is using the JCK, a large suite of tests including a harness. Before Blackdown can stop calling a build a "release candidate" and call it "Java," it must pass the test. This test suite is sometimes referred to as the Java Conformance Toolkit, but glossary calls it the Java Compatibility Kit.

Currently, sun's JIT code is one of the areas that requires careful scrutiny during a release.

Blackdown continues to work with Sun to obtain the latest copies of this code, but it requires tremendous effort to stay synchronized with new tests continually pouring into Sun's internal version.

Does any build of Blackdown Java 2 pass the JCK?

For the latest, please visit http://www.blackdown.org/java-linux/jdk1.2-status/jck-status.html.

Will Sun make the JCK more accessible?

Blackdown developers are working with Sun and Inprise to resolve the issues surrounding community source for Java products such as the JCK. We assume Sun will deal with this on a case by case basis. At this time, Sun developers working on the Jini connection API (a distributed computing platform) have had stronger ties to the open source movement than most other APIs. See http://www.jini.org/ for more detail.

Is there any online documentation for the JCK?

See section The Latest Blackdown JCK Notes below.

The FAQ needs more answers about the JCK, but for now, here are some links:

• Carla Schroer's 1998 Java One presentation: http://java.sun.com/javaone/javaone98/sessions/T203/
• A chat session about the test kit: http://developer.java.sun.com/developer/community/chat/JavaLive/1997/jl0218.html
• Carla Schroer's 1997 Java One presentation: http://java.sun.com/javaone/sessions/slides/TT28/startit.html; a transcript of her talk is provided by the Irish Java User's group: http://sunsite.compapp.dcu.ie/IJUG/javaone/transcripts/compatibility.html;

The Latest Blackdown JCK Notes

Scott Hutinger <srh@www.mprojects.wiu.edu> has been working with the JCK and has contributed this information on December 29th, 1999 in hopes that it will be helpful for new users getting started with the JCK:

• Always make sure classes.zip is unzipped.
• Always make sure (when using slave) that classes and javatest.jar are in the $CLASSPATH correctly when using the map file and -mapArg. Note: the mapped files is only needed when doing slave/master via NFS.
• Only about 20 failures from these two items not being in the class path for compiler tests.
• Fonts and the JCK documentation Note that '-' are removed; on most releases, i.e. -DDISPLAY is DDISPLAY=, or -mapArgs = mapArgs due to font issues.
• Don't use file.txt (.txt) for the ftp file:
  1. Set in the file: lib/javasoft-x.jte.
  2. Set ftpURL=ftp://someplace/somefile.txt
  3. This will cause a failure, use //someplace/someothertype (i.e. .gif).
  4. Use something like .gif, as .txt will be plain/text, and the JCK thinks it should be html/text or something like that.
• Bad setup for java-compiler (solaris), use share ..... root=myclientslave.edu ..... unless the Solaris machine is setup well, the slave needs root access. This is mainly for *-compiler-* tests. As the gui will show unexpected failure from the compiler (bad access rights), although it's not stated.
• Native threads took around 23 hours to run the java-compiler tests; Green threads on the slave took about 8 hours?!
• The intial tests are not in the compiler.jtp file, although if failures exist, just stick in the correct javasoft.sqe.javatest.selection.initialFiles= setting.
• At that point the complete tests don't need to be run, just the failure portions to narrow down what needs to be fixed or changed.
• JNI and the JCK (JCK-runtime-vm-x) build in tests/vm/jni/build.
• Using ssh to ssh localhost for getting the display set correctly will make some of the URL type tests fail.