RE: generic type support

[Andrew Haley <aph at redhat dot com>]

=?iso-8859-1?Q?=D8yvind=5FHarboe?= writes:
 > > Teaching gcj to invisibly run jikes and then read the 
 > > resulting bytecode would be an interesting project.
 > 
 > My main concern about GCJ doing source compilation is that it
 > is going to be "outflanked", i.e. it is a lot of work to create
 > an up to date frontend.

I doubt it.  The Java programming langauge has changed very little
over time.  We have some changes looming now, that's true.  The
question is when a new front end needs to be ready.
 
 > It is easier for GCJ to keep up with "only" changes to the bytecode
 > standard.

Yes, but we optimize better from source and we remove one unnecessary
compilation step.  Also, the debugging information in byte compiled
files isn't so very good -- you lose full pathnames for example.

 > On the horizon:
 > 
 > - Generics
 > - AspectJ
 > - Other?
 > 
 > I'm not clear on what the design goals for GCJ is, but my vote is
 > for deployment: Java could get a bigger bite out of the desktop, if
 > applications didn't have to drag along the JRE with all its
 > hickups.

You can't do anything about that because of the way the language is
defined.  There always must be a runtime environment, because it's
part of the specification.

 > Painless JRE deployment is still a couple of years off.
 > 
 > I support side by side installation of my program using GCJ(unzip
 > old and new version to two seperate directories, done!).
 > The only safe way I have found to deploy my app is to include the
 > JRE in each side-by-side installation(using e.g. InstallAnywhere).
 > 
 > Performance as a design goal for GCJ?
 > 
 > Development efforts aside, I believe that a JIT compiler could 
 > be made to outdo any source level static compiler. 

Because?  I know that the IBM JIT performance is very good, but I
think gcj can do even better.

Andrew.