Related link: http://www.javalobby.com/nl/archive/jlnews_20040217o.html
I am not usually a big advocate of ‘link only’ blogs (particularly between article/blog based sites) but this article piqued my interest enough to want to get as many people as possible to read and understand another perspective on the whole ‘Sun, Java and Open Source’ debate that’s been rolling around for some time now.
The article covers the largely pragmatic (hey, we’re developers, this tends to be how we think!) approach to the discussion offered by Rick Ross, the editor of JavaLobby.
I can understand both perspectives on the issue but I have to be honest as a developer myself that Rick’s arguments really hit a chord with me. Whilst Eric Raymond’s open letter to Sun typified the ethical, social, and basically inherent patchiness of Sun’s approach to Java and open source; Rick’s article really raises the impact of the issue on concerns such as java job security and selling your java based products.
This is an important ongoing debate for the Java community as a whole and should therefore be of interest and closely followed by everyone that relies on Java for their wages, myself definitely included.
Your opinions on this are welcome on the JavaLobby page for the original article and here as well.
Just the Java J2ME,J2SE,J2EE Libraries
It would benefit the entire Java based industy, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libaries and Java to bytecode compilers.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of vendors were using the same core libaries.
To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
Contributions to the core standard would be required to licensed under the same open source license. The existing JCP standard body could decide what becomes part of the Open Java Core.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
Just the Java J2ME,J2SE,J2EE Libraries
Couldn't agree more. The OpenOffice.org model seems to work well for Sun so that seems a natural way to go to get things opened up. I get the feeling that that is Eric Raymonds point of view too, his argument appears to be that Sun are doing it right in other areas and that if they could just be consistent and do the same for Java then people would be happier.
The question of loosening the proprietary strangehold on the Java brand as presented by Rick is another issue. This aspect is a harder sell to the Sun management but is interesting nonetheless.
Just the Java J2ME,J2SE,J2EE Libraries
I have to strongly disagree here.
It would seriously HARM the entire Java industry to have the core libraries open for everyone to change to their liking.
It would create a plethora of incompatible versions running rampant around the world making it impossible to write applications for general distribution.
Is your app compatible with java.util.Collection version 1.2.3.2.53.2.5.3.3a6 pre3 beta4?
How is that any different than the situation today?
Did you not bother to read the third paragraph of my post at all?
To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references..
You asked:"Is your app compatible with java.util.Collection version 1.2.3.2.53.2.5.3.3a6 pre3 beta4?"
How is that any different than the situation today?
At the moment most major Java deployments are based on the 1.2 - 1.3/2.0 J2SE/J2EE standards. Instances of the 1.2 to 1.4.x JVMs and runtimes are often running found side by side on many servers. Admittedly, Java is by far the easiest non-vendor specific enviroment for porting to more uptodate releases, BUT, there is also a plethora of vendor specific frameworks and XML to webserver handling approachs.
Most vendors use and promote their own approachs and IBMs, BEA, Oracle and Sun implentations remain unsynchronized when it comes to the release of their repective implementation of each new standard.
Under an open source license, with standard preserving clauses as I suggested, it would be easier for vendors to endusers to backport new standards to the current 1.4 generation of the JVMs. With more synchronized adoption by the vendors, it would be actually easier for developers to predict what version most of the end user are going to be using. You can code to the current and upcoming standards without having to wiat for the end user to catch up.