classpath
[Top][All Lists]
Advanced

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

Re: Generics branch status?


From: Ewout Prangsma
Subject: Re: Generics branch status?
Date: Fri, 15 Apr 2005 10:08:32 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi all,

In JNode we're now using parts of the generics branch (e.g. for java.util) and it seems to work just fine.

Great work!

For an listing of the status of the new 5.0 features that we now support in JNode, see http://jnode.sourceforge.net/portal/node/623.

Ewout

Ewout Prangsma wrote:

Hi Andrew and others,

Thanks for the comments.
The reason for my question is that in JNode, we have made the switch to require 5.0 for our build process and we want to make the JNode VM more and more 5.0 "compatible". The new LDC already works and I want to start adding the 5.0 features. Enum's seems to work now, but things like annotations, generic collections are not yet there. For this I need some classes from the generics branch.

Ewout


On Wed, 2005-04-13 at 11:38 +0200, Michael Koch wrote:
On Wed, Apr 13, 2005 at 10:55:14AM +0200, Ewout Prangsma wrote:
Hi all,

What is the current status of the generics branch?

Not really usable yet.



Depends what you want to be use it for; I'd not be as pessimistic as to
say it's unusable.  I currently use it in place of Classpath in a lot of
places; they're fairly interchangeable, they pass the same Mauve tests
it seems and, with the generics branch, I can compile code using
parameterised lists (e.g. List<String>).  For this setup, you need ecj
(the Eclipse compiler), the generics branch and the latest version of
jamvm (1.3) which supports the new ldc construct.  Hopefully, we'll have
another capable compiler in the form of gcjx sometime soon.

I'd be interested to know if there are specific uses of the language
features you're interested in.  Remember that this is not a 1.5 branch,
but a branch for code which requires the new language features, those
being:

* parameterised types (generics)
* enumerations
* annotations
* syntactic sugar such as var args method(String...) and for..each

All of these collapse to the original bytecode format, leaving the only
runtime support to be reflection-based via flags in the class file.  You
will found however that 1.5 class files use StringBuilder instead of
StringBuffer; this behaviour is supported by both HEAD and the generics
branch.

Any 1.5 methods that don't use these features should be directed at HEAD
(although priority there is still on 1.4).  However, in this vein, I
would be interested to know what the list at large thinks of perhaps
using the generics branch for wider 1.5 testing, especially if this is
something people begin to request.  I'm thinking it might be a nice
testbed for things like Doug's concurrency stuff...

Are bugfixes in the HEAD branch also included in the generics branch?

Yes, Andrew merges both branches on a regular basis.



Seconded.  I usually merge them at the weekend (or a period when commit
activity is low), although I avoided this weekend due to some build
problems with HEAD.

Michael
------------------------------------------------------------------------

_______________________________________________
Classpath mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/classpath




_______________________________________________
Classpath mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/classpath





reply via email to

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