Sun has released a new version of the Generics EA package. They have dropped variant type parameters, and added support for wildcard and bounded wildcard type
parameters. The varargs syntax has also been made more readable. Also supported are: Enumerations, Autoboxing, enhanced for loops and Static Imports.

Go to the Sun Generics Site

Here's a list of changes from the CHANGES file:

Version 2.2

Changes are primarily bug fixes and stabilization of the compiler. The previous (2_1) release was internal only.

We now require using a 1.4.2 bootstrap VM. It might work with 1.4.1, but I won't support that anymore.

Version 2.1 [was an internal release only]

We have dropped variant type parameters from the prototype. Based on feedback received, we believe this syntax is simply to difficult. We are not putting anything like variant arrays into the language in Tiger. Instead, we are simply disallowing all of the constructs
involving arrays that are not sound. Consequently, we have removed from the prototype download the documents describing variance, and the compiler no longer supports it. We continue to investigate alternatives that would allow arrays to be used with generic classes
for some future release.

This version contains support for wildcard and bounded wildcard type parameters, a feature of the draft JSR14 spec that has previously been missing from the prototype. This lets you use more concise signatures for many generic methods.

The method:

<T extends E> void addAll(Collection<T> c);

is now written:

void addAll(Collection<? extends E> c);

using an "extends bounded wildcard".

and:

the method:

<T> void shuffle(List<T> l);
is now:

void shuffle(List<?> l);

using an "unbounded wildcard".

There are occasional situations that can be expressed using wildcards that were previously inexpressible. See, for example, the classes in java.lang.ref.

We hope you find wildcards more readable than variance. The syntax for wildcard types is due to Neal Gafter, Gilad Bracha, Lars Bak, and Bob Deen.

The syntax for varargs has changed slightly to improve readability.

The new syntax is due to James Gosling:

void printf(String fmt, Object... args);

Within this method, the "args" variable is of type Object[].

Boxing and unboxing conversions are currently only implemented as argument conversions. It is almost certain that this is not what the JSR 201 expert group will specify. When we have more guidance from JSR 201, we will update the prototype.

What do you think of these changes?

Hi all,

I think that dropping variant type parameters is a good move, because of the low value/complexity ratio.

Also, new wildcard syntax is much more readable to me.

MC

Good news. The variant type syntax was incredibly ugly and confusing. I sent an email specifically on this.

Does anyone know if autoboxing will become a default feature behavior? I'm concerned about the overhead this will add to numerically intensive applications. This has been noted as a performance issue in C#.

>

How would auto-boxing change anything, performance related, from the situation we got today?

Maybe java will be harder to understand for newbies (starting to become as messy as C# IMNSHO) and that I regret - but performance will be the same for equivalent code!

The only difference will be that instead of writing
list.add(new Integer(5));
which anyone can understand
you write
list.add(5);
and get the same effect - just that it's now not as clear if the "list" is a Integer list or an int list (jakarta(?) collections comes to mind)...

I.e. no difference to performance - just comprehension of code a first sight is harmed (and this is probably something you'll eventually get used to - just as polymorphism etc etc).

Boxing DOES indeed affect performance.
Even MSFT mentions this. Here are a few links ...

http://www.geocities.com/csharpfaq/box.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp03152001.asp
http://www.codeguru.com/cpp_managed/KateGManaged.html
http://www.c-sharpcorner.com/Code/2002/April/BoxNUnboxSSF.asp
http://www.c-sharpcorner.com/Code/2003/April/IterationsInNet.asp
http://www.dotnet247.com/247reference/a.aspx?u=http://www.c-sharpcorner.com/Code/2002/Mar/BoxingPerformanceIssuesOnCollections.asp

I'm concerned about how a Java Boxing implementation could
potentially impact intensive financial computations. It all
depends on how Sun chooses to implement this feature. If it
is something I can avoid at run-time, I'm happy. Otherwise,
I'll look to drop Java for something else.

K

As far as I know, boxing happens only when you need to treat that primitive as an object. If you treat it as a primitive, boxing is not needed and boxing will not happen. I don't know any C#/Java implementation details, but that's suposed to be the main advantage (apart from ease of usage) that boxing/unboxing has over wrapper classes.

Stern

Folks I think we are looking at autoboxing from the wrong angle. I believe it will be comparable in performance to the current situation were we have to explicitly create the object. Java collections still hold Objects not primitive types, so even though we do not type it in our code object creation still happens.

The only danger I see here is that in the past this was explicit, so now we can sneakily create objects and perhaps affect performance. However this is minor programming is an mental task we can never remove thinking from the process.

In .NET versions with generics, accessing collections typically doesn't involve boxing. This is because the runtime understands about generics and instantiates generic classes as necessary.

but if you look more clearly on the design of c# generics you see that this only performs with the current implementation of .NET: Ahead time compiliation.

if you dynamic compile the code, like the java hotspot compiler does, this sort of generics comes at severe performance problems!

why: the clr generics are kind of asterixes in the bytecode, so the compiler would have to look at the asterixes at runtime and resolve that - just imagine what that does to performance.

It could also be a security whole? - Since various checking mechanisms wouldn't work on that special bytecode type. In the CLR this kind of generic mechanism is more easily implemented since almost all operations are not typed, opposed to the java case.

After reading various papers about generic support, I come to like the current situation. I am hoping that object inlining and things like that could eventually optimize the primitive wrapper instances, they are immutable anyway, away.

On the other hand I am fond of the idea Mr. Bacon has developed in his Kava paper, where you build up your primitives out of simple enums.

I would not recommend using normal Collections autoboxed or not when you require good performance. Use of appropriate primitive type tailored Collections such as the fastutil package can boost performance and decrease memory usage. If you have computationally intensive code you should have a look at this (or one of the number of other similar open source packages available).

Al

I believe you still don't understand boxing...

Please re-read my post and then try again :)

I was hoping at some point they would add some version of the Metadata JSR-175 to the compiler.

Sam

I liked the covariant type support, but I understand why Sun decided to drop it. While it's very nice for object-oriented enthusiasts, most developers, especially newbies, would probably be comfused by it.
I do hope that covariant types or something similar would be included in future releases, perhaps after it has been more thoroughly studied.

As for autoboxing, I think that it is performed only at the compiler level. The early access implementation only includes a compiler, so I can't see how the autoboxing can cause any performance issues at runtime - it is the same runtime as you are using now. The way I read the spec, boxing and unboxing are performed by the compiler in certain types of conversions (e.g. assignment conversion). Code that does not use autoboxing should not be affected by it.


Gal

> certain types of conversions (e.g. assignment conversion). Code that does not
> use autoboxing should not be affected by it.
>

I think the concern is that autoboxing in Java will be so seemless that you don't know when you're using it. In C++, it's possible to overload the auto-cast operator and the copy constructor, so that conversion happens seemlessly. This can (and often does) result in a large number of temporary objects being created and destroyed without the user even knowing what's happening. Of course, it's very easy to design classes and use these classes effectively if you're a moderately above-average C++ programmer. But since (by definition), at least 50% of programmers are below average and you often have to maintain or extend their code, your code will likely end up paying (in performance and unexpected side effects).

Personally, I think that Java autoboxing strikes the right balance. It's limitted enough to avoid most of the unintentional temporary object creation in C++, yet useful enough so that basic types can appear to look like they are part of the class system instead of being a performance hack.