Does any existing linux-java group working on porting the complete API from SUN? The question I have is always down to what standard can we counting on. If you pick out the "Good" API from SUN and will that still being too "Large" for us to bite it off. I have a couple different VMs, different version of VM install for the competability issue, I do want to see free java able to provide a standard ( along with sun or not, we need one ) API for developer to use or even port from office sun API. Where to start? Alex
Rick Lutowski wrote: >Jim Pick wrote: > > >>Because the set of Java APIs is so large, trying to develop a set of >>class libraries that works as a drop in replacement for Sun's libraries >>is a very large task. In reality, it's going to be a long time before >>the free java class library projects manage to reimplement 100% of the >>Java2 API, and it's a moving target. >>... >>I think part of the problem is that there isn't enough granularity in >>Sun's Java specifications to make it easy for free software JVM/class >>library implementors to implement the whole thing (eg. "J2SE or J2EE"). >>Sun has broken the API up a bit for J2ME applications >> >> > > >By following several guidelines based on historical and pragmatic >considerations, the problem of implementing the huge numbers of >APIs can be made more manageable. Here are the guidelines. > >1. Develop and release APIs in historical progression. >2. Drop all Sun-deprecated classes and methods; conform only to the > latest non-deprecated version of an API spec >3. Focus on J2SE first, and J2EE/J2ME later > >This leads to the following "priority roadmap" (lower number >is higher priority): > > Priority Roadmap >JDK J2SE J2EE J2ME >1.0.2 1 n/a n/a >1.1.8 2 n/a n/a >1.2.2 3 6 9 >1.3.1 4 7 10 >1.4.x 5 8 11 > >For example, highest priority would be all API names that appeared in >1.0.2 (which is no longer a moving target), but IMPLEMENTED USING THE >1.4.x VERSION OF THOSE SPECS. Thus, event handling would use the 1.1, >not the deprecated 1.0, event model. Classes like Vector, which changed >in their implementation from 1.0.2 to 1.4, would be implemented using >the 1.2 Collections approach. For the 1.0.2 equivalent functionality >release, only Vector and the Collections interfaces directly supporting >it would be implemented, not the entire Collections package. Thus, >what is being implemented is always the latest version of the Sun spec, >but with priorities set by historical evolution. > >There are many practical reasons for the 3 guidelines and the resulting >priority roadmap. I will not waste space listing them here because they >become obvious on reflection. > > > > >>If we introduce software into Debian that runs on one implementation >>(eg. Kaffe), but not on another (eg. gcj), then we are introducing >>breakage. What do we do in that case? Do we hold back software unless >>it runs on all the JVMs/class libraries in Debian? Or do we introduce >>the software as soon as it runs on just one JVM in Debian (and breaks on >>all the others). >> >> > >Subset the 1.4.x (or latest version) JCK tests according to the above >priority roadmap. Require an implementation to pass its "level" of JCK >(e.g., the 1.0.2 test subset for a 1.0.2-equivalent implementation) >before admitting it into debian. Sun will not grant certification for >anything that does not pass all JCK tests, but the immediate goal here >is not certification but interoperability at a given "JCK equivalent >capability" level. The JCK tests can be highly useful for this. If >interoperability problems are found among (for example) different >1.0.2 implementations that all pass the 1.0.2 -level subset of the >1.4.x JCK, then develop additional "GNU-JCK" supplemental tests to >verify conformance of the implementations in the problem areas and >require implementations to pass these additional tests as well before >admitting them into debian. > > > > >>I think it would be incredibly useful if we, as the free software >>community, came up with our own set of specs for Java, documenting and >>advocating which APIs we feel are appropriate to use (based on the >>availability of free software implementations). >> >> > >When it comes to Sun-defined functionality (API, tool, etc) the Sun >specs and conformance tests should be followed rigorously so that a >1.4.x (or latest version) can be certified by Sun when it finally is >available. This will make it interoperable with non-free >implementations >to the extent Sun requires it to be. > >However, Sun does not preclude creating additional packages outside the >java.*, javax.*, org.omg.* etc trees released with the standard JDK. >For example, applications and tools such as IDEs do it all the time. >Hence, it would also be possible to include a gnu.lang along with the >standard java.lang package. gnu.lang might include things like the >Measured Units Conversion Package at >http://www.jreality.com/downloads.html >and other functionality that will likely never be included in Sun's >APIs. >These 'gnu' APIs would have to carry a LGPL-like license that permits >their use in non-free environments as well as free environments so >(1) code that uses them can be transported, and (2) users of Sun and >other non-free implementations would also be able to use them. This >would avoid any basis for Sun saying they illegally "extend" Java >They would just be additional APIs that ANYONE else could also use. >These APIs would come with "GNU-JCK" tests to verify conformance of >implementations that support them (including non-free implementations, >who then would have to be "certified" by the free community for >conformance!) > >This approach would allow the free community to develop their own >_supplemental_ set of API specs for Java, effectively an alternative to >the JCP, without in any way compromising the portability of Sun-standard >Java code to free environments, or visa versa. > >Rick > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
