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

[jlusk4]

The Java language, VM, libraries and protocols (RMI, J2EE) are all fully spec'd out. There are *no* proprietary pieces the implementation of which is forbidden by Sun. 3rd parties can implement to their heart's content.

On the other hand, MS always, always, always seems to take care to leave some proprietary poison pill in their work, so you can implement 99% of their offering, but w/out the last 1%, your offering is worth substantially less (if anything at all).

MS-Kerberos is my favorite example: all these bytes are yours, except these two over here. Touch them not.

I think Mono is another case in point: it's an implementation of C# and the VM (yes?) but the .NET libs are off-limits, are they not?

(Consider me trolled. Oh well, it's been a while since I've bitten any hooks.)

John.

Re:"generics"

[oops]

Are we talking about the same thing ? What's safer ? A Java collection that takes *any* object without type-checking, or one that's restricted to a particular type/subtype ? I know which one I'd take.

The compiler performs at 30% of it's former speed ? Not with the 1.5 beta release. Or the pre-release available last month. Or the generics add-in from last year. Have you tried these ?

Finally I've worked in the finance sector for the last 10 years. Nowhere are templates forbidden as suggested above. I'm desperate for these to be widely used to give the run-time object-typing security that Java has lacked in its collections. This is a huge gain in my book.

Re:Benchmarks

[SashaM]

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Re:"generics"

[fab13n]

Is it a troll?

Generic is good, if you're smart enough to use them correctly. Let's take the List example.

The type checking is much weaker thus introducing new potential holes for error to slip through.

Plain wrong. With the current list, if you've got a list of Foobar, then each time you want to extract a Foobar from the list, you have to fool the type system with a (Foobar) cast. If what you extracted was not a Foobar, then you get a runtime error (which is exactly what a type system's supposed to avoid). Symmetrically, if you try to put an integer in a list of widgets, the compiler won't notice. These issues are adressed by polymorphic type systems.

You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.

Wrong again: basically, a type is the statically verifyable part of the assumptions you make about a value. Maybe you're confused with dependant type systems, that allow to parameterize a type by a value (e.g. an array by its size), and is indeed often undecidable.

The reusabilty "argument" is rubbish

It wasn't for OO, and it is even more false about generics. Obviously quick and dirty code written by coder with low to average skills is not reusable, because writing reusable code asks a lot of smartness, and smartness can not be provided by a compiler. OTOH, STL in C++ are highly reusable, but very few coders are able to produce a code of such a quality, and noboby knows a way to fix that human issue. Reusability is about few code, written by few wizards, and used by many average coders.

The above mentioned problems create new security holes.

I'd be glad to see any concrete example backing this assertion. Actually, the evilest type system feature is the cast, and genericity is the way to get rid of most of them.

Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance. More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible.

Is this a random association of "sounds-good" term you've seen in a theoretical paper, or some very old and approximative quotes from a lecture during which you played Tetris on your phone?

Turing completeness doesn't lead to "slow downs", it immediately causes complete undecidability. The whole point of a type system IS to be decidable, hence not Turing complete, as opposed to the values. Moreover, templates keep the language in the "context free grammar" category. Last but not least, correctness checking is not related to grammars: grammar is just about parsing.

In old languages like Lisps the use of generics is usually strongly discouraged [...]

You know why it's discouraged? because it doesn't exist! List is dynamically typed, so templates don't make much sens. I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammer in unskilled hand.

I've really seldom seen such an accumulation of BS in a single post.

Re:Why?

[iapetus]

Um. That link shows Java as having 11132 projects - the highest number except for C++ (12686) and C (12706). Given Java's big uptake in commercial development and the fact that it hasn't been around and mature for as long as C/C++ (how far back do Sourceforge projects go) I'd say you've not really done much to disprove his claim. Java is certainly one of the most popular languages out there today, and might even be at the top of the heap.

Of course, I understand that Britney Spears is rather popular too...

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:Someone please make a debian package!

[tyrione]

Why are you stuck on that?

I'm running 1.4.2_03 update 3 on Debian Sid.

Download the Linux.bin self-extracting file. and install as root where you want it to be installed.

First do a chmod 777 on the .bin file as noted by Sun. It will extract a structure as 1.4.2_03/ I don't like that so I just moved it to 1.4.2/

$mv j2sdk1.4.2_03/ j2sdk1.4.2/

Set the pathways for your .profile. and root's as well, and every user who needs access to the tools.

Here are my settings:

#Java SDK 1.4.2 SDK Path Settings JAVA_HOME=/usr/local/SunJava/j2sdk1.4.2/

add JAVA_HOME to your export PATH list.

Your choice of where you want your install directory is your choice. I made everything from Sun under SunJava.

Now as root run update-alternatives. (Man page for more info about the following).

$update-alternatives --install /usr/local/bin/java java /pathToYourJ2SDK/bin/java 100

Repeat for javah, javac, jdb, javap, jarsigner, java-rmi-cgi keytool, etc underneath the Sun /bin directory.

Then run update-alternatives --all to make sure it has Sun's sdk 1.4.2 set.

Run update-alternatives --config java

$update-alternatives --config java

Make sure its set.

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.