Java SDK 1.5 'Tiger' Beta Finally Released

kingkola writes "Finally, after about two years of development, the Beta for Java SDK 1.5, aka Tiger, has been released. Features added in this edition include generics support, autoboxing of primitives, syntactic sugar for loops, enumerated types, variable arguments, sharing of memory between multiple VMs and a bunch of other bugfixes, enchancements, etc."

Comments

For more information check out theserverside.com

[alenm]

Link to discussion on TheServerSide.com

Re:Too little, too late

[sporty]

generics support

C# innovated this, and already has this in the spec

C++ had this way before. Next...

autoboxing of primitives

C# innovated this, already implemented years ago

Ruby.. next...

syntactic sugar for loops

"foreach": C# innovated and already has this, implemented years ago

Perl...

enumerated types

Java didn't have this before? LOL

No, and not always very useful. It's just neat.

and a bunch of other bugfixes, enchancements

Bugfixes in a language? WTF?

In the VM or in the java support classes library, i.e. j2ee.jar

Re:Too little, too late

[LordK2002]

C# did not "innovate" any of these. It might well have implemented them before Java, but most of them were available in various programming languages long before C# arrived on the scene.

Code Examples

[Dreamland]

Here's a very nice PDF giving actual code examples of the new language features:


http://www.javasig.com/Archive/lectures/JavaSIG- Ti ger.pdf

Re:About time too

[severoon]

This is one of the most misunderstood aspects of the C# vs Java debate.

If you write code in Java, you can run the same compiled class files on any platform. In C#, any code you write MUST run on a Windows-supported platform under Windows, but because every .NET language compiles to the CLA (Common Language Architecture), they are all translated into a single, compatible language before going to bytecode. Meaning, you can interoperate between any .NET language, have C# functions call a C++ function (assuming C++ is a .NET supported language now or someday) and just have it work...no CORBA, no distributed programming, etc. Furthermore, the CLA common language provides stuff like garbage collection so you can neglect free() and delete() in C++ and not worry about memory leaks (just don't compile that code with a non-.NET C++ compiler). The grand vision here is that everyone using .NET is locked into the .NET framework running on a Windows platform. There's nothing open about that.

sev

Re:IPv6 for windows finally

[Anonymous Coward]

Why finally? For Java to support IPv6 on Windows, MSFT had to support it first and that didn't happen until Windows XP SP1.
Now that being said, the really cool part about Java supporting IPv6 on windows is that it actually makes it much, much easier for developers to add support for IPv6 on Windows. You see, Microsoft didn't provide a dual stack implementation which means an IPv6 socket can not talk to an IPv4 host. It's stupid and contrary to what the RFCs strongly recommend. So if you're a .Net developer and want to support IPv6, you're in trouble as you have to rewrite your application to handle both kind of sockets, not too hard for client side, much more of a pain on the server side.
Now, with Java, none of that, a Socket is a Socket and that's it. To make it better, chances are your Java application doesn't need to be modified, or even recompiled! Imagine that: your application was already IPv6 enabled and you didn't know it.

About polymorphidm snd subtyping

[fab13n]

Let's state that A <: B means "A is a subtype of B". Now the question is "What do I need as conditions on As and Bs to get A<As> <: B<Bs>". The answer is:

• If one can only read values of type C with A methods, then the relation is covariant, i.e. to get A<As> <: B<Bs> we need As <: Bs.
• If one can only WRITE values of type C with A methods (e.g. pass them as function parameters), then the relation is contravariant, i.e. to get A<As> <: B<Bs> we need Bs <: As. Counter-example:

  Int &lt;: Float
  
  Array&lt;Float&gt; a0= new Array&lt;Float&gt;();
  a0.[0] = 3.14159;
  Array&lt;Int&gt; a1 = a0; // would be legal if the type was covariant
  Int x = a1[0]; // Oops, I've put a float in an int.
  // I shouldn't be allowed to do that without an explicit cast.

• If parameters of such types can be both read and written, then you need both As <: Bs and Bs <: As, i.e. As == Bs. That's what happens with java. If you want your structures to be covariant, you have to forbid their modification (here, forbid to change the cells' contents).

If in some exceptionnal cases you want to enforce subtyping, it's up to you to use casts. But you cannot assume a bogus subtyping relationship without noticing it, therefore the type system did its job.

Re:an annoying quirk

[derkaas]

You can, however, make use of wildcards to define a covariant inhertiance relationship between ArrayList<Number> and ArrayList<Integer>. We can reconstruct your example to create this relationship:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<? extends Number> t = s; //compiles

Check out this paper for information about this other kinds of variance available in Tiger.