Re: [gui-dev] Sun Java 1.5 Update 1, no more a beta!

 --- zbalevsky <[email protected]> a écrit : 
> Philippe Verdy wrote:
> 
> >Sam Berlin <[email protected]> a écrit : 
> >  
> >
> >>The most prominent features of 1.5 are changes in the language
> spec,
> >>such as the addition of templates, autoboxing of native types,
> enums,
> >>etc... 
> >>we can't make use of those until a version of 1.5 is available on
> all
> >>OS's, so that everyone can continue to compile LimeWire.
> >>    
> >>
> >
> >What is unfortunate is that most of the additions in the Java 1.5
> >language could have been retrofitted to work with the Java 1.4 VM.
> >
> Wasn't that done because of the jvm class-sharing?  Afaik only 1.5 
> bytecode can be shared between jvms.
> 
> If 1.5-compiled desktop applications become widespread, we could
> provide 
> a version of limewire with 1.5 bytecode.  Some things like the xerces
> 
> libraries are probably shared by 90% of java apps out there :)  Then 
> again, there are probably many small desktop software vendors
> thinking 
> "if Limewire starts offering 1.5 version, we'll start offering one
> too" 
> so its a chicken-and-egg situation :-/

Why not? It's your decision at Limewire to know if a version compiled
for Java 1.5 should be released. But this will require users to select
the target Java VM, something they probably don't know exactly when
they just have installed Java using the automatic installer on the Sun
website...

For now the good point is that the LimeWire installer has been reduced
in size, and I don't expect that the downloaded installer will contain
both versions of Limewire, and of its libraries like Xerces...

In my opinion, code sharing did not require a new class format. The new
format was needed because class files now contain more type identifiers
(for generics in class member signatures) and compiled annotations:
this would have shocked the Java 1.4 classloader in its verifier. So
classes need to be marked specially, so that new class vtables can
contain more fields.

This is not caused by new language features: Java 1.5 just defines a
more strict verifier, and changes the way Reflection will work (there
are also additional methods and private fields in the Class class, and
generics or autoboxing also change the rules for matching classes and
for implementing typesafe typecasts at run-time).

But this could have been retrofitted in Java 1.4 without the additional
strict rules (for example "List" is now a template, and an alias for
"List<? extends Object>" but also for "List<int>" autoboxed as
"List<Integer>". So the compiler could have been strict exactly like in
Java 1.5, without being so strict at run-time for introspection and
typecasts).

This approach is also used in other existing extensions of the Java
language, by alternate compilers still targetting the 1.4 JVM.

For example, there does exist some alternate experimental Java
compilers that support "const" references in method parameters... they
work by compiling not only 1.4-compatible classes but also by building
an additional dictionnary of class meta-data, in a special build
directory, this really helps developing with stricter UML rules, and
helps the developer finding bugs in the source that would be difficult
to track without this language extension; however const-strictness is
not enforced in the generated application and in Reflection at
run-time, unless the runt-time code uses a custom extension of
Reflection and of the class-loader at run-time, to take extended
meta-data into account).



	
	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev