Moderator (MDR): MDR-lisa

Guest Speaker (SPK): SPK-Ray Gans, SPK-Roger, and SPK-James

MDR-lisa: Hi, everyone. I'm Lisa Stapleton, editorial director of the JDC, and my guests today are here to talk about the 100% Pure Java^TM program at JavaSoft^TM. My guests are Roger Hayes, Ray Gans, and James Leonard of Sun Microsystems Inc. They'll talk about the program, as well as how developers can get in on it.

rickl: There is currenly no abstraction to a system's native preference storage, such as Window's Registry. How can we be 100% "pure" without that? Or am I wrong and there is a way to achieve this currently?

SPK-Ray Gans: There is currently no platform-independent way to handle native preference storage (e.g., Window's Registry). This is something that we are aware of, but we have no 100% pure solution at this time.

SPK-Roger: The closest 100% Pure Java solution is properties, but that has the handicap of not interfacing with the platform's native preference storage (xrdb, .rc files, preference files, Registry, etc.)

jff: For the uninitiated, how about a general overview of what's involved in becoming 100% pure. For example, what are the costs involved for certification?

SPK-Roger: Purity has two aspects: programming and publicity. To get the right to use the (coveted) brand, you have to put your program through the certification process—this involves demonstrating to a third-party test agency (KeyLabs) that your program really is 100% Pure Java. More information on the criteria for purity, and the testing we do to check for it will be forthcoming I'm sure.

The certification cost is $1000, which pays for KeyLabs' labor.

tbednarz: With the 1.5 release of its Macintosh Runtime for Java, Apple has introduced a series of "com.apple.*" classes that provide added value to Java applications running on a MacOS platform, and are allegedly benign on other non-Apple VMs. What are the ramifications of including these classes in a Java application (and providing comparable functionality for Unix and Win32) for 100% Pure Java certification?

SPK-Ray Gans: Any non-JDK^TM core dependencies are by definition not pure and not platform-portable, unless those classes themselves are 100% pure and distributed with the app. In addition, we look for common behavior across platforms, so in this case, while the behavior may be benign on other platforms—it will be different, and therefore not pure.

SPK-James: I'd like to add to that by saying that platform-specific scripts to do install are allowed by the program, as long as the runtime code isn't modified in any way. When a 100% Pure Java install-solution becomes available, we may change this.

egagnon: I am a big fan of the 100% Pure Java initiative. It is the only way to write really cross-platform code.

SPK-Roger: As far as I know, you have to call System.exit() to make that command-line program exit. That's why exit() is not prohibited in a pure program; the Cookbook has some words of advice about being careful that the effective behavior is what you intend.

SPK-James: Part two of your question is about a free-ware version of the certification process. To begin with, you can get all of the documentation and the JavaPureCheck^TM utility for free from the SunTest web site (www.suntest.com/100percent), if you haven't already. However, in order to keep the meaning of the logo consistent, we feel it is necessary to have a third-party perform the testing, and this costs money. The fee is not a royalty payment for the logo, it is the cost of the service KeyLabs provides that results in your customers (paying or non-paying) having more confidence in your solution.

egagnon: OK, let's rephrase question #1. Why does the AWT create a nondeamon thread? Isn't that a problem for pure Java?

SPK-Roger: Any problem with the AWT definition is a problem for 100% Pure Java, because that's the definition we work from. I suspect this is a bug in a particular implementation, and should be tracked and fixed as such. As James said, one of the benefits of 100% Pure Java is that it puts pressure on the platform and all of its implementations to converge.

Fdeza: I have a multimedia Java application (not an applet) which can play sound only through the sun.audio undocumented internal package—thus, it is not pure. When will the JRE (Java Runtime Environment) offer a public API to play sounds in an application (not applet) context?

SPK-Ray Gans: We are aware of this deficiency and we are working to improve it in the future. Stay tuned....

JWBito: I would like to deliver 100% Pure Java applications, but the inability to manipulate the current working directory in JDK 1.1.3 makes this impossible for me. This is significant because I want the user to be able to start native applications that are downloaded using my application. If I had JRE support for changing the working directory (or setting it in Runtime.exec()), I would be able to ship the base application with only JRE and JARs. As it stands, I must include platform-specific code (scripts) just to set the working directory.

(There was also a related problem on Windows where the FileDialog would change the process-working directory, rendering any relative File objects useless.)

I think it would be bad to allow the working directory to be changed on the fly. Will Runtime.exec() allow new processes to be created with a specified working directory?

SPK-Roger: I think the best way to proceed on this is to go ahead and submit the program for certification. That will get it into the process; then the Variance Council can either suggest a workaround, or file a "request for enhancement" to get the required functionality into the Core API.

SPK-James: By the way, this is a very important component of this program. It allows you, the developer, to tell JavaSoft where the platform needs improvement.

glen_s: Will a program that requires a serial port ever be 100% pure?

SPK-Ray Gans: I don't know. We need to have a platform-independent way to do it.

jff: egagnon is not alone. I've also wondered about a nonKeyLabs certification process. $1000 is pretty cheap for commercial-level software, but not for free software/shareware.

How about a separate logo for 100% JavaPureCheck with the limitation that if you use the logo, the user of the software must also be able to run JavaPureCheck on the code (p-code)? Thus, there are no KeyLabs labor costs to cover, the user can check the author's claim, and there's more 100% Java.

SPK-James: I am aware there is a lot of demand for this, and the solution you propose is being seriously considered. We need to be careful that we don't dilute the formal certification process. Multiple logos results in lots of confusion for customers.

hhroark: How do the Java programmer/developer certifications fit into the 100% Pure Java initiative?

SPK-Ray Gans: They don't. 100% Pure Java is an initiative to encourage developers to write platform-portable code. The Java programmer/developer certifications do not mandate 100% pure.

chonok: We have a class library that has already been certified as 100% Pure Java. :-) We now plan to release three applets, built using only this class library. As the library has had all of its methods covered, do we need to have each of the applets recertified? (A bit expensive in time and money)

SPK-James: You do have to recertify these applets. KeyLabs does have bundle pricing, and they are willing to work with developers to make it economical.

Fdeza: I have two questions:
1.) When will there be a dynamic counterpart to JavaPureCheck? I mean something which checks classes loaded through Class.ForName().
2.) When will JavaPureCheck detect hardcoded strings?

SPK-Roger: 1.) It would not be appropriate to make JavaPureCheck part of the class loader, as JavaPureCheck is only the first step in a process requiring human intelligence.
2.) We have discussed some sort of internationalization check. It does not belong as part of 100% Pure Java certification—maybe we can figure out another way to deliver that value.

jff: As a follow up to chonok's question, I would assume that recertification is necessary for future releases of a product. Are there any special provisions for "patch" releases (in case a bug is released :)? Is this another area where KeyLabs might try to make it economical?

SPK-James: Good question. You only have to recertify releases that include new features or functionality. Bug fixes or maintenance releases don't need to be recertified by KeyLabs.

SPK-Roger: Here are the five rules of "purity":

1. No native methods
2. No external dependencies, aside from Core API
3. No use of internals of a particular implementation
4. No "tunnel" methods
5. No platform-specific hardcoded constants

Everyone understand? Anyone disagree? Anyone care to propose another rule?

SPK-Ray Gans: Is anyone out there using Microsoft's AFC?

JoeSam: I have a comment and a question. Our friend who asked the question regarding System.exit() was led on that path due to the Cookbook, which lists the use of System.exit() as a pitfall. Because of that, many hundreds of dollars in our time were wasted, because I and others tried to help him. I would hope that the documentation writer, the project lead, and their editors would work diligently towards ensuring that requirements are clear. My question is: We may work at being 100% pure, but what guarantees do we have that the various VM providers will give the same results? Is there a certification program for them?

SPK-Roger: I apologize for any unclarity in the Cookbook; I tried to make it clear, in the introduction and body, that the pitfalls are "Hints and Tips," and that the exact rules for certification are given in the appendix. Those criteria are also printed out by the self-documenting feature of JavaPureCheck. How can I make this more clear?

SPK-Ray Gans: Java Compatibility is a VM certification process that all vendors must pass before shipping their VM as "Java Compatible." Java compatibility (as I'm sure you are aware) can never be perfect, since there are thousands of possible tests, and while we try to cover most of them, some do get missed.

We are working hard to improve the JCK (Java Compatibility Kit) that VM vendors use to validate their VMs. As we find problems and holes, we include them in the next release of the JCK. If you find problems in a particular VM, please alert the vendor so they can fix it.

JWBito: The question posed by Fdeza leads me to wonder: What proscriptions are there (if any) against the use of dynamic loading (Class.forName()), or installing specialized a Class Loader or Security Manager?

Would the Certification Lab be allowed to charge differently, if the package never made use of these dynamic features? That is, is it possible to determine that an applcation (applet) can be fully analyzed statically, and thus would require less effort for certification? Maybe this is a way to allow for a low-cost logo?

SPK-Roger: Class.forName is only one area where a static check cannot tell the whole story. There are many others. Static analysis of Java programs, while much easier than programs in other languages, can never tell the whole story. In fact, many of the portability problems caught during certification are caught during the install check. I don't think we could ever certify a program without a dynamic check.

jff: Where is the "Core API" defined? A previous question seemed to make reference to "JavaSoft" libraries that were not 100% pure. So "Core API" means JDK, JFC, JDBC....? Where is the list of "Core API" packages kept?

SPK-James: The Core API is defined at http://java.sun.com/products/api-overview/.

JoeSam: In this particular case, one could have noted that this applied only to applets and was necessary in an application. Generally a lot of peer review is an author's only hope.

SPK-Roger: As the Cookbook says, System.exit is also problematic on a Macintosh, for example, where all the windows tend to disappear. Thanks for your contribution to the continuing improvement; the review list for the Cookbook is the longest I've ever had for any publication, including refereed journals.

glen_s: About Microsoft's AFC, I believe it has to be downloaded from Microsoft (it's not distributable with your application). But I think the code is pure Java. If you did use AFC, would your application be certifiable, even though you don't distribute this one library?

SPK-Roger: The rule that applies is: your program must be self-contained, relying only on the Java Core API. So if AFC is indeed 100% Pure, and you can bundle it with your application, then it meets the rules for 100% Pure Java. We encourage library vendors to certify their libraries as 100% Pure—this makes it much easier for developers to use those libraries to build a 100% Pure Java program. I hope Microsoft will certify AFC as 100% Pure Java. (I have no idea whether or not it's pure.)

uomini: I just joined in, and had asked the following question in another JDC forum, but had never gotten an answer. My question is: What is Sun going to do about either moving the sun.net classes into java.net, or creating functionally duplicate classes in java.net? My app makes use of the sun.net classes, and I'm kind of annoyed that such apps are not considered 100% pure, inasmuch as I had never been told this earlier.

SPK-Ray Gans: There may be some relief to your issues in the next release of the JDK, However, it would be helpful if you could tell us what classes you want migrated. Please do this through: http://java.sun.com/cgi-bin/bugreport.cgi.

SPK-James: I guess that is all the time we have. Thanks for joining us, we appreciate this opportunity to chat with you. We invite you to download the Cookbook, Cert Guide, and JavaPureCheck from www.suntest.com/100percent and to register your programs for certification at www.keylabs.com/100percent. Be sure to join the Java Live discussion forum next week for Q & A with James Gosling!