LWN.net Logo

Sun Announces Java Platform Standard Edition 6

Sun Microsystems, Inc. has announced the availability of Java Platform Standard Edition 6 (Java SE 6). "The Java SE 6 release is the result of over two years of industry-wide development involving open review, weekly builds and extensive collaboration between Sun engineers and over 330 external developers. Developers interested in getting started immediately with the Java SE 6 release can leverage the new NetBeans(TM) Integrated Development Environment (IDE) 5.5, which fully supports all the latest features of the Java SE 6 platform."
(Log in to post comments)

Sun Announces Java Platform Standard Edition 6

Posted Dec 11, 2006 19:42 UTC (Mon) by Tara_Li (subscriber, #26706) [Link]

Is this now under the GPL? I'm kind of surprised they'd bother dropping a new version, while they're notably in the process of working out what license they want to release under. Perhaps, with the MS/Novell Fiasco, they want to use GPL3, and figure they have enough time until it comes out to get a Java SE 7 ready?

Sun Announces Java Platform Standard Edition 6

Posted Dec 11, 2006 19:45 UTC (Mon) by tomsi (subscriber, #2306) [Link]

This version has been long in planning - the first I ead of it was about 18 months ago.

I guess the GPL version will be based on this ocdebase, but if it will be GPL2 or 3, I don't know.

Tom

Sun Announces Java Platform Standard Edition 6

Posted Dec 11, 2006 20:58 UTC (Mon) by coriordan (guest, #7544) [Link]

This release is distributed as proprietary software.

When they free java, they can, if they want, release the exact same version but as free software.

Sun Announces Java Platform Standard Edition 6

Posted Dec 11, 2006 21:09 UTC (Mon) by sab39 (guest, #2185) [Link]

This version is still proprietary. GPL code has been released for parts of what will eventually become JDK7 (notably the compiler, the VM itself and some Micro edition stuff, and notably NOT the class libraries yet) already at http://openjdk.dev.java.net/. The remainder is expected around March 2007.

They have picked a license - they had to, having already released some of the code, of course - and it's GPL2, with the class libraries going to be under GPL2+"Classpath Exception" (which essentially results in something very similar to the LGPL but with some obscure differences in some embedded scenarios). They picked the license to match what the GNU Classpath project was using, which was a *fantastic* decision for the entire Free Java community (if you scroll down far enough you can probably still find the giddy reactions on http://planet.classpath.org).

I've heard rumors that once the freeing of the JDK7 code is complete, they'll consider going back and freeing JDK6 retroactively, but nothing concrete on that score just yet.

It makes sense that they wouldn't hold up their existing release schedule for the open sourcing to be complete - many of their customers don't care about free software and they're not going to be too thrilled to hear that they have to wait an extra 4 months for the new version while licensing issues get worked out.

And as I understand it they will indeed continue to release the same code under a proprietary license for the benefit of people who are afraid to touch GPL code.

Sun Announces Java Platform Standard Edition 6

Posted Dec 12, 2006 1:43 UTC (Tue) by bk (guest, #25617) [Link]

And as I understand it they will indeed continue to release the same code under a proprietary license for the benefit of people who are afraid to touch GPL code.

So in essence that will make code sharing one-way only: Sun JDK -> GNU Classpath, since Sun cannot release code they don't own copyright to under a proprietary license. Sun JDK development will not benefit very much from an open development environment.

Operator overloading?

Posted Dec 11, 2006 23:36 UTC (Mon) by djabsolut (guest, #12799) [Link]

The Java SE 6 release is the result of over two years of industry-wide development involving ... extensive collaboration between Sun engineers and over 330 external developers

Does this release include the ability to overload operators, ala C++? Writing scientific applications (e.g. involving linear algebra, matrix handling, converting Matlab code, etc) is fairly painful without them.

Say A, B, C, and D are matrices. Currently, a simple expression like D = A*B+C would be implemented along the following lines in Java: D = mat_add(mat_mul(A,B),C). Imagine the unreadability for a more complex expression.

Operator overloading?

Posted Dec 12, 2006 0:04 UTC (Tue) by tomsi (subscriber, #2306) [Link]

Unfortunately, no.

Nothing fancy in the language department.

In addtion to operator overloading, I miss the oppertunity to create properties as easy as Delphi and C#.

Tom

Operator overloading?

Posted Dec 12, 2006 3:17 UTC (Tue) by mcculls (guest, #34229) [Link]

Actually if A, B, C and D are matrix objects you could write:

D = A.mul(B).add(C); // D = A*B+C

however, it's harder to spot precedence problems than with operators. For example:

C.add(A).mul(B) != A.mul(B).add(C) // (C+A)*B != A*B+C

but then again, assumptions about operators can lead to misunderstandings, ie. with matrices:

A * B != B * A

Operator overloading?

Posted Dec 12, 2006 4:21 UTC (Tue) by djabsolut (guest, #12799) [Link]

D = A.mul(B).add(C); // D = A*B+C

Yes, one can use this form, but this is still not a replacement for being able to implement linear algebra based algorithms in a readable fashion.

What was the original reason for not allowing operator overloading ? It seems rather shortsighted not to include such functionality (given that there is a rudimentary form of it for strings).

Operator overloading?

Posted Dec 12, 2006 7:38 UTC (Tue) by mcculls (guest, #34229) [Link]

I wasn't party to the original decision, but there's been a RFE discussion running since 2003 which captures a lot of the pros and cons at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4905919 (has the very helpful evaluation of "I have always objected to this, but I'll leave it so people can vote" from an anonymous Sun employee!)

BTW, it is possible to overload operators in some of the scripting languages built on top of the JVM, such as Groovy.

Operator overloading?

Posted Dec 12, 2006 10:40 UTC (Tue) by eru (subscriber, #2753) [Link]

I wasn't party to the original decision, but there's been a RFE discussion running since 2003 which captures a lot of the pros and cons at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4905919

From one of the comments there: Operator overloading is one of the most vile, confusing, and consistently mis-used facilities of C++. It is a maintenance nightmare.. Nice to see other people feel about this issue the same way I do. Allowing operator overloading is just like promoting the use of one-character function names, with the added confusion of allowing multiple definitions for each one-character name...

One could make the case for allowing it for extending arithmetic operators to handle new types (like the matrix example). That would be a good use for the feature. The problem is that a programming language cannot enforce any sane rules for this and for example prevent a "+" symbol for getting defined to do something totally unrelated to its original meaning.

Operator overloading?

Posted Dec 12, 2006 11:45 UTC (Tue) by nix (subscriber, #2304) [Link]

But an incompetent or evil programmer can *already* write functions called write_data() that read it, or add_numbers() that also has heaps of unexpected side effects.

It is wise to take *some* note of the effect of your language on newbies, or you end up with a language hideously hard to learn (like, well, C++). But banning features because they *might* be misused is foolish. *Any* feature can be misused.

(Far more pernicious a C++ fault is the *interaction* of operator overloading with exception handling, where you can never really tell where the hell an exception might propagate up from, because even the most innocent -> or + might throw who knows what exceptions. This is a fault which Java is mostly immune to because of checked exceptions. It would mostly be immune even if operator overloading existed.)

The one operator overload I really, really wish Java had was C++'s somewhat peculiarly-named operator()(), which lets you call an instance variable as if it were a function (whereupon operator() gets called instead). So you've gained, in effect, instanced functions with state, far nicer than mere nested functions.

Operator overloading?

Posted Dec 12, 2006 12:18 UTC (Tue) by eru (subscriber, #2753) [Link]

But an incompetent or evil programmer can *already* write functions called write_data() that read it, or add_numbers() that also has heaps of unexpected side effects.

Sure, but at least you can fix such programs by the replace-string operation of your favourite text editor. That would be totally hopeless if the name is "+" instead of add_numbers().

It is wise to take *some* note of the effect of your language on newbies, or you end up with a language hideously hard to learn (like, well, C++). But banning features because they *might* be misused is foolish. *Any* feature can be misused.

But if a feature has only a few reasonable uses (and lots of dark ones), it should not be included. I'm sure someone could come up with a good use for even the COMEFROM statement ( http://www.fortran.com/come_from.html), but I don't think it would be a good argument for including it in Java...

Operator overloading?

Posted Dec 12, 2006 17:15 UTC (Tue) by tjc (guest, #137) [Link]

But banning features because they *might* be misused is foolish.
Well, I guess this depends on where you're coming from.

People who write a lot of new code and leave it behind for others to fix and maintain tend to like expressive languages with a lot of features.

On the other hand, people who spend a lot of time fixing and maintaining other people's code tend to notice that there are a lot more bad programmers out there than good, and useful features are more often than not misused.

Operator overloading?

Posted Dec 12, 2006 18:06 UTC (Tue) by stevenj (guest, #421) [Link]

I much prefer languages like Caml that simply allow you to define new infix operators. This gives you the power of operator overloading without the obscurity.

Not that numerical linear algebra is necessarily the best poster-child for operator overloading. When dealing with large matrices, for performance reasons you often want to carefully structure your code to correspond to the available underlying BLAS and LAPACK primitives, and to minimize the number of temporary matrices that need to be allocated. This is much more difficult to do if the primitives are hidden inside overloaded operators. (Yes, I know about expression templates etc.)

Not "Java 2 Platform"?

Posted Dec 12, 2006 0:39 UTC (Tue) by proski (subscriber, #104) [Link]

It looks like Sun dropped "2" from the language version. The previous version of Java Platform was "Java(TM) 2 Platform, Standard Edition". It looks like Sun doesn't try to pretend any longer that it can singlehandedly assign version numbers to the Java programming language (as opposed to it's implementations).

If that's true, I appreciate Sun's humility.

Not "Java 2 Platform"?

Posted Dec 12, 2006 1:53 UTC (Tue) by nlucas (subscriber, #33793) [Link]

It's more easy to believe they finally understood how bad that decision was. Most non-techie people can maybe understand a version number, but not two version numbers on the same product name (hell, it took me a long time before I understood what that 2 was).

In a related note, Microsoft also backed from using .NET on every new product name (even when no .net framework was involved) because the confusion among marketing people and users was worse than the advantages.

Not "Java 2 Platform"?

Posted Dec 12, 2006 21:38 UTC (Tue) by sjj (guest, #2020) [Link]

Core 2 Duo anyone? What's wrong with these people?

Not "Java 2 Platform"?

Posted Dec 12, 2006 23:08 UTC (Tue) by proski (subscriber, #104) [Link]

The funniest thing is that "Core 2 Duo" has two cores. It's akin calling Boeing 747 "Engine 4 Quadro" :)

Not "Java 2 Platform"?

Posted Dec 13, 2006 23:27 UTC (Wed) by jonabbey (subscriber, #2736) [Link]

There was actually a real reason why Sun had the whole 'Java 2 Standard Edition, Version 1.4' nonsense for so long.

Back in the 90's, the contract that Sun entered into with Microsoft surfaced on the net. It had terms that required Microsoft to pick up any features that were added into Java during the 1.x sequence.

When it came time for Java 1.2, Sun realised that they had already advanced the platform enough to deserve a major number release (and if you look at the difference between JDK 1.1 and JDK 1.2, you can't deny that), but their leverage to force Microsoft to pick up the new features vanished if they called it Java 2.0.

The whole 'Java 2 Standard Edition, version such and so' was a dodge to keep Microsoft on the hook to accept their new features.

When that contract ended (in most unfriendly fashion), the need was no longer there, and they went with Java 5, 6, etc., for the marketing.

Not "Java 2 Platform"?

Posted Dec 12, 2006 5:25 UTC (Tue) by iabervon (subscriber, #722) [Link]

Sun does singlehandedly assign version numbers to the Java programming language. They publish the language specification. I think the reason the "2" is gone is that they released JLS 3, but they released JDK 5 with the wrong platform version (JDK 4 got described in an amendment to JLS 2, but JDK 5 wasn't going to work that way), so the platform version was clearly meaningless. They've just been discarding meaningless digits from their names, and any number that didn't change between JDKs 4 and 5 was clearly meaningless. I still think it was supposed to be called JavaZ JDKl (to sound more trendy in the late 90s, of course), and the marketting folks couldn't read the font.

Sun Announces Java Platform Standard Edition 6

Posted Dec 12, 2006 2:48 UTC (Tue) by beoba (guest, #16942) [Link]

Is this one both 1.6 and 6?

Hooray marketing team!

Sun Announces Java Platform Standard Edition 6

Posted Dec 12, 2006 17:00 UTC (Tue) by proski (subscriber, #104) [Link]

It looks like the 1.x number has been greatly deemphasized in this release.

Sun Announces Java Platform Standard Edition 6

Posted Dec 12, 2006 21:40 UTC (Tue) by sjj (guest, #2020) [Link]

Heh, it's just a Sun tradition, like SunOS/Solaris version numbers.

Sun Announces Java Platform Standard Edition 6

Posted Dec 13, 2006 12:58 UTC (Wed) by k8to (subscriber, #15413) [Link]

Stupidly allowing marketing to run roughshod over common sense? Is that the tradition you were speaking of? In the general case it seems to be a "tradition" in the entire industry, but Sun seems to be the "market leader" for this property manifested in version numbers.

Sun Announces Java Platform Standard Edition 6

Posted Dec 13, 2006 17:42 UTC (Wed) by amarjan (subscriber, #25108) [Link]

Intel is hotly contesting this leadership with their Pentium M-based Core Duo and "Core architecture"-based Core 2 Duo.

Sun Announces Java Platform Standard Edition 6

Posted Dec 13, 2006 14:09 UTC (Wed) by james (subscriber, #1325) [Link]

Perhaps it's time to drop the leading "2." from Linux kernel numbers, given the way they're tending towards 2.6.26.5-rc3-mm2...

Sun Announces Java Platform Standard Edition 6

Posted Dec 13, 2006 16:29 UTC (Wed) by bronson (subscriber, #4806) [Link]

Well, in this case the leading 2 does mean something: it's the userspace ABI version. When Linux 3.0.0 is released, you will know that Linus's aggressive backwards compatibility guarantees have been abandoned and Linux 2.X program binaries will not work on Linux 3.X.

Not that anybody foresees this happening any time in the next decade...

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds