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

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.
Effectively there's no new JVM instructions, and generics
(pseudo-templates) could have been beneficial to the development as a
help against common programming errors, or kludgy programming technics
like typecasts, that we suffer in Java 1.4.

The Java 1.5 compiler should have had flags so that is would compile
all Java 1.5 source language features targetting the Java 1.4 JVM. But
if we target Java 1.4 VM, we also loose the new language features.

Targetting Java 1.5 should have just meant that annotations would have
been included in the compiled classes, and that template types would
have had their own new type signature.

Apparently, Sun has decided to deprecate later the previous class
format in favor of a new updated one that won't load on previous
versions of Java, based on the assumptions that almost all VM
implementations will be updated to support the new class format. This
will be true for Windows, Linux, and soon for MacOSX, but there will be
some time before J2EE servers get the update.

This means that many common libraries and tools will continue to be
developed so that they can continue to run on J2EE environments (such
as WSAD, Struts, Oracle AS...) that are not as easy to update as
standalone J2SE (and J2ME) environments.

May be someone will develop a compiler that will accept the new Java
1.5 syntax targetting Java 1.3 and 1.4 VMs. May be these alternate
compilers already exist. But the standard Sun JDK still does not
support this option.

It would have been good to have generics, enums, and autoboxing for
developing Limewire... Will that be in the new update of Eclipse (which
has its own excellent Java compiler that really outperforms the Sun JDK
compiler)?

I note that during the development and discussions of new Java 1.5
language features, in the JCP process, experimentation of these
features was possible using the Java 1.4 and Java 1.3 VMs... (only
annotations were not supported within class files, but emulation was
possible by storing them externally in additional meta-data files, and
by emulating the new Reflection features with a custom class loader
that loads these meta-data files. Of course, embedded annotations
within the same class file is faster, and improves applications that
use Reflection to load classes dynamically based on annotation
meta-data).

I hope that Sun will be able to develop new language features highly
demanded now like multiple return values, or enhanced auto-boxing, but
I'm not sure that the new Java 1.5 class format (and the JVM 1.5 class
loader and verifier) will be compatible with those additions. So most
of these additions will need to wait for a long time the design of Java
6 (not expected to come before 4 or 5 years if the class file format
needs to be changed again...).

I don't understand why Sun took this slow path, when the .Net is
pressing all UML developers to abandon Java (there are already things
in UML that can't be emulated correctly and completely in Java/JVM, a
problem that C#/.Net and C-C++/native-assembly do not have): where are
for example events, event notifiers, event handlers, properties,
getters/setters? The way they are emulated in Java is not completely
satisfying and not completely errorprone or typesafe (type-safety and
more generally the need for developers to create programs that will not
experiment bugs only found at run-time, is now a very serious concern,
for security)

What is saving Java for now, is its performances and (temporarily) a
better secured sandbox, and the huge existing developements that have
been done in application servers. But as .Net comes now to Unix and
Linux, this is a serious concern, notably because Microsoft has not
renounced to make a compliant JVM that could run within .Net to press
developers to come to .Net with ease (Microsoft does not need to
support the Java language itself with a compiler, but it can still
demonstrate that its .Net platform can be used to run Java
applications)

It's also notable that .Net supports a virtual machine that can
completely emulate what a classical native processor architecture
supports, and this effectively allows using other languages than C#
(Microsoft promotes VisualBasic, but there also exists now Perl,
Python, Pascal, soon Delphi too, Ada, and I think that .Net will be
able to support C and C++ with the ANSI standard, or even Cobol and
Fortran, making .Net a future platform of choice to port many legacy
applications to application servers and n-tiers environments...)



	

	
		
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