warprulz (03 Jan, 2007 06:09):
Why Java 6? Why not just jump to Java 7? I'm not sure how feasible it is to skip any version as the build process seems to bootstrap the previous version. I wonder if this could be circumvented by using the class files from the Windows or Linux distributions?The reason I suggest version 7 is that porting will take time. By the time porting is completed 7 will either be early in its release or sometime thereafter or maybe some subsequent Java release.
An argument against version 6 is the distribution licensing. I don't think any of us have deep enough pockets for Sun. What is the distribution licensing for version 7?
Sun owns the trademark only --after the company released the code under the GNU licensing scheme. Hence, as long as the OS/2 port is not called Java, the only limit for the OS/2 port seems to be willingness by OS/2ers to commit to "get their hands dirty" without pay. The Free Software Foundation already had done so by naming their Java implementation "GNU Classpath."
The following is taken from: http://www.artima.com/forums/flat.jsp?forum=276&thread=184631
"According to Tim Bray, Sun's director of Web technologies, open-sourcing the implementation has nothing to do with the specifications upon which those implementations are built. And for any implementation to be able to use Java trademarks, including the Java name, or call itself compatible with a JSR, it has to pass the appropriate Technology Compatibility Kit test suite. Those TCKs, and their associated specifications, are developed through the Java Community Process, or JCP."
Hence, the licensing fees are to be paid to Sun only if the potential OS/2 port is to be "official Java" by passing Sun's compatibility te$t. That is irrelevant in our case since we would be extremely satisfied if the actual port is done --we can name our implementation OS/2eClasspath (or to a lesser degree due to the addition of more proprietary names that could bring trade mark issues in case of a dispute) OS/2eCSpath or whatever. The only care that we should take is in adhering to the standard specification so as not to experience compatibility issues.
warprulz (03 Jan, 2007 06:09):
And there is the decision for compilers. GCC with GNUMake (assuming it has been ported to OS/2) with additions for OS/2 compilation in the makefiles would be the quickest result. OpenWatcom (my choice
) would require a complete makefile rewrite much like when GoldenCode Development did for Java 1.4.1 on VisualAge C++ 3.6 and NMake.
Selecting a compiler with the most compatibility with Linux will make any borrowed open source implementations (the agnostic part of Java) compile under OS/2 with less pain than with other alternative. Thus, either the old (EMX based) and or the newer GCC seem to be the most viable alternatives for the long run since we do not have an abundance of developers' time to tweak the quirks of their tools.
warprulz (03 Jan, 2007 06:09):
I would join this project as soon as Leonardo and I and if anyone else joins to get Eclipse 3.1 ported to OS/2. I have a nasy bug to try to squash with the window procedure.
Have you considered the SWT to Swing alternative to execute SWT applications mapped to SWING project? That might provide a faster (although potentially slower performance due to the extra mapping) way to have Eclipse (and other SWT apps) performing on OS/2.
The only problem is that SWTSwing is based on Java 5 and spits out some (older) inconsistencies of Golden Code Development's 1.4.1_7. Taking those (inconsistencies) as a hint, it appears that quite possibly (a hacker, as oppossed to a conservative, always tries) the OS/2 native compilation of a few methods/implementations/classes from GNU's Classpath might make possible a little hack on 1.4.1_7 to be compatible with 1.5.
If the latter is achieved, the newer versions of Eclipse will be executing on the OS/2 platform.
My take on the issue, needless to say, 