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
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
