Showing messages 1 through 1 of 1.

• How is that any different than the situation today?
  2004-02-20 19:10:17  nzheretic [View]
  
  
  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.