classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: JDK 1.5 support?


From: Andrew John Hughes
Subject: RE: JDK 1.5 support?
Date: Thu, 01 Jul 2004 15:08:17 +0100

On Wed, 2004-06-30 at 23:28, David Holmes wrote:
> Andrew Hughes wrote:
> > The hardest thing would seem to be the generics (Java's templates -- is
> > it or me or does it seem strange that Java 1.5/5.0 is basically bringing
> > back in lots of C++ features, mainly as a result of C# having them?).
> 
> It's you :) Java has had generics on the cards for a long time - too long,
> but that's another story - since before C# existed. C# didn't define
> generics initially either - have they added it yet? Java Generics is nothing
> like C++ templates except for the <> syntax. You could say that a key goal
> for Java generics was to NOT provide something like C++ templates. :)
> 
From what I was reading recently, the new C# has generics.  I wasn't
aware how different generics were from templates -- I suppose that's
what comes from rushing in before I know better.  Templates are a pain,
so hopefully generics will be better.
As far as actually using Java goes, the re-appearance of enums will be
the nicest addition, mainly because the lack of them has been a pain
since I started using Java, and had to emulate them with constants. 
Boxing/unboxing will also be nice to avoid the use of the wrapper
classes, but I'll think we'll see side effects with the same thing going
on behind the scenes.  Most of these things are partly a result of C#, I
think, because its had these since word go.  I never understand why
enums weren't carried across, anyway.
> > Generics are added to a lot of the core classes, notably java.util's
> > collections.  Would adding this mean that compilers and code would need
> > to be 1.5 ready?
> 
> In principle because generics are based on type erasure, they are primarily
> a compile-time concept. So code that uses generics that is compiled with a
> 1.5 compiler may be runnable on a non-1.5 JVM. That said, some of the
> information is stored in the extensions to the class file format for
> run-time introspection (don't know the details of what you can and can't do
> here). So compiling with generics tends to produce class files that won't be
> understood by non-1.5 supporting VM's. I suspect you would need a compiler
> that knows how to compile generics whilst producing a non-1.5 specific class
> file.
> 
I think there are a few issues here.  If Classpath starts using
generics, compilers will need to support generics as they are prevalent
in some of the most basic classes.  This has already been noted.  What
is probably a more long term effect (and one I imagine Sun has already
considered at great length) is that this is likely to break both binary
and source compatibility, something which hasn't happened as far as I
recall, in Java's history.  Even the old AWT event model was maintained
from 1.0 to 1.1.  Later releases have added more and more code to the
library (Swing, better 2D graphics and printing, XML, SSL, etc.), making
more and more code for us to rewrite.  However, I think the only
language addition has been the 1.4 assert facility (which personally
I've never even used).  How will pre-1.5 code work with generics, etc? 
From flicking through the docs for 1.5 beta 2, enums are also being used
in the core classes, so I imagine some methods will return them
(Thread's state is now done this way).  It will be interested to see
what breaks.  This is also a issue for Classpath, of course, because
most of the library is more complex stuff building on top of these
things.
> David Holmes
> 
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
-- 
Andrew :-)
 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
 
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.
 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]