Slashdot Mirror
Java SE 6 Released
twofish writes "Sun has announced the availability of Java
Standard Edition 6 final release. JSE6 now has dynamic language support.
It comes pre-delivered with Netscape's Rhino, a Javascript engine, and the scripting
project's home page documents many other available scripting languages,
including awk, Jelly, Pnuts, Python, Ruby, and Scheme. In addition a lot of
work has been done on the libraries and run-time compiler. The JIT has been
improved, with better runtime analysis of program characteristics, giving notable
performance improvements. Other improvements include better desktop support, improvements
in Swing look and feel, Windows Vista support, and better diagnostic support
(For example, profilers and debuggers can now attach to a running JVM without
specifically using a debugging-capable configuration. For example, if a problem
is found at run-time for a production server, a debugger can attach to it without
restarting the server).
Sun is also offering sixty days of free developer support for JSE 6 through
their Developer Services program."
And here I am in the middle of studying for the Java 5 certification exam while my workplace runs 1.42 and J2EE 1.3.
Reviewing just the first hour of video games.
Kudos on the new release. I'm running Vista, so the support will be nice.
But as a user, it always amazes me how hard it is to navigate Java's downloads. Assuming non-techies know that "Java Runtime Environment" is what they need to run Java apps, you still have to dig past a JDK and NetBeans link to get to it. I tried walking a relative through downloading the JRE a week ago and it took way longer than it should have.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
You can finally have apps that look alot more like win32 or gnome apps without using swt or some other less standard api. Also this release uses some Apple technology with their jdk by offering dynamic class loading. Startups should be alot faster. This and java7 which is already in development should be really exciting. Sun has been putting out alot of java releases recently due to .NET and competition is good.
http://saveie6.com/
The scripting support is specified at JSR 223.
Here are some additional new features:
BTW, why isn't this on the front page? All the fussing about the possible new license was there but not the product publishment itself.
Congratulations to all the hard working people at Sun, and those outside who contributed (I'm one of them).
I tend to get +5 for these kind of posts, so this time I'll post anonymously to prevent karma wh:
As usual, InfoQ has a nice writeup with good links.
Sun has a confusing number of portal sites for news and communities, but the two most lively ones are probably java.net and Planet JDK.
Remember that Java 6 is not GPL, the decision to go GPL came too late in the development phase, only JDK7 is GPL. But you can get JDK6 and JDK7 is under the Research Licence from Subversion, a good blog with info about how and where is here.
OpenJDK project
Hotspot
Early 2007 we should see the class libs as well
See also here
"Q:
When will you finish open sourcing the JDK? What is the timeline?
A:
We expect to release a fully buildable JDK based almost completely on open-sourced code in the first half of 2007"
Some help on getting you back in the saddle with the new features:
1.5 features in a nutshell
What's the best way to get back into using Java? I took a couple of programming classes when it was still Java 1.3/1.4 a few years ago and totally missed the jump to Java 5/6.
I actually enjoyed the Head First Java book from O'Reilly, though I'll probably get mocked for it here.... I admit, it can feel a bit "kiddie" to have a lot of pictures, do puzzles and so on, but involving the right half of your brain makes stuff stick better, and for me, makes it fun and fast to learn. Second edition has some Java5 stuff in it.
If that style of learning is not for you, or if you are too advanced for that level, the Java Tutorial was pretty recently updated with new trails for Java 5 and Java 6, so you should find an appropriate level for you quickly. Also Java 5 Developer's Notebook is a neat guide.
Being bitter is drinking poison and hoping someone else will die
Please note that it is no longer "J2SE", it's just Java SE. (As per the URL you pasted in your post.)
Sadly the marketroids still insist on calling it Java SE 6 and not Java SE 1.6 (which it is), but at least today we're better off than with Tiger, which was Java 2 SE 5 (aka 1.5)
You know, every time a java story appears here this line gets trotted out, but I'm really not sure that it's anywhere near as valid as it once might have been. From what I understand Sun have made a lot of efforts in the last few releases (1.3+) to speed up swing. I've written quite a few java applications in the last couple of years, all swing based, and none of them has caused me to have any concerns over the speed of the GUI toolkit.
Sure swing still has some other issues issues (eg proper native look and feel), but I'm sure that a lot of the complaints people have about the toolkit's speed are either very old prejudices or stem from poor coding within the application rather than from swing itself.
It's not J2SE anymore. Now it's just Java SE. (Although we still have the 5 (but really 1.5), 6 (but really 1.6) silliness, but it's a step in the right direction.
Java GUIs have traditionally been 'slow' because they are double-buffered by default, and as a consequence they redraw completely before displaying. Hardware simply wasn't fast enough to do this gracefully -- it's only recently that most gnome/kde applications and some xp ones are expected to be double-buffered.
The double-buffering also lead to lots of inefficient widget redrawing, like for a while each widget was cleared with the bg color before being redrawn even if it then say put an image say over its whole area.
The other major slowdown was because Java's graphics were much more advanced than necessary, for example lines of width != 1 with end and joint caps, antialiasing, clipping regions (instead of boxes), custom renderers, etc. This made it difficult to integrate with the simple hardware acceleration at the time. Native apps had jaggy lines and solid colors as the main features.
More information can be found at Chris Campbell's blog, but yes, graphics are much faster in JDK 6 especially with the OpenGL pipeline turned on, although they were hardly "slow" in JDK 5. Also, the JIT compiler has been largely reworked to improve codegen (especially with -server flag specified).
Another common complaint about Java UIs is that the dynamic loading/binding/compiling/optimizing makes things slow the first time anything is done, a little less slow the second time, then reasonably zippy from then on. So the longer you work in a Java app, the faster it gets. In any case, I code in Java IDEs all day long and they don't seem any slower than native apps.
E pluribus unum
Agile Spaceport - You will never find a more wretched hive of scrum and villainy. We must be cautious.
I'm sure that it is. Java's backwards compatibility has always been pretty spectacular. They've got millions of lines of unit-test code that they test new releases against, in addition to major applications which get explicit testing. JBoss is about as major an application as you'll find.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Java 6 has made great strides in many areas, including speed, Swing LAF, etc. It now uses GTK theme engines (works with all themes) to allow swing apps to look more like GTK apps. The imitation is still very imperfect, but it's much improved over the old, crappy, Metal look. I believe generics have been improved some in 6, and I think, if I recall correctly, 6 marks the beginning of non-backwards compatible changes to the JVM itself to pave the way for a lot of exciting new features in Java 7, the most notable will the inclusion (finally) of delegates, making GUI event programming a lot cleaner. It's possible that with Java 7 finally on feature parity with .NET, someone could write a .NET to JVM translator, such as the reverse of ikvm, to allow C# code to be executed on a clean, GPLd Java stack. I still prefer C# to Java at this point, and it would be nice to have the difference between the two stacks (technologically anyway) be insignificant, hopefully helping developers who would choose .NET choose the now safer Java alternative. .NET really did get a jump on Java technologically up until now. It's better in several ways including the generics model, delegates, and being able to support a number of languages including python (jpython for JVM seems to be stalled). Java 7 will start to change all that. Sun's really proved they are listening to the community. Either that or .NET really got them scared.
If you have an OpenGL capable gfx card you should enable the OpenGL rending pipe for your Swing applications with this
java -Dsun.java2d.opengl=true *javaprogram*
It is disabled by default for compatability reasons, but all java programs should really make two launchers so users can choose.
The OpenGL path should be a lot faster now, since it has been refactored to use only a single thread to ship commands to the gfx card, which is the same technique that most 3d games uses.
It should be noticable.
If Sun say they are going to do it, they are going to do it, problems or not. Their statement that they are doing this is hardly "meaningless".
They are "meaningless" in that nothing changes for users until they actually deliver.
And that interpretation is already assuming that they are actually being honest and that no problems crop up. Given what happened with Java standardization and the tricks they have been playing with Solaris, Sun has little credibility when it comes to open source.
Nice (or not so nice) try of trolling FUD but the link works fine.
"I think this line is mostly filler"
- 206 - Core 2 Duo E6600 (2.4GHz)/DDR2@667Mhz/Linux 2.6.18.3 #5 SMP/Sun JDK 1.6.0-rc-b104
- 223 - Opteron 275 2.2GHz/Linux 2.6.11.12-grsec/Sun JDK 1.6.0-beta-b59g
- 349 - Pentium M 730 (1.6Ghz)/DDR2@400Mhz/Linux 2.6.15-cK1/Sun JDK 1.6.0-beta-b59g
- 401 - Core 2 Duo E6600 (2.4GHz)/DDR2@667Mhz/Linux 2.6.18.3 #5 SMP/Sun JDK 1.5.0_05-b05
- 408 - Opteron 275 2.2GHz/Linux 2.6.11.12-grsec/Sun JDK 1.5.0_01-b08
- 415 - Opteron 250 2.4GHz (dual)/Linux 2.6.8/Sun JDK 1.5.0-b63
- 596 - Pentium M 730 (1.6Ghz)/DDR2@400Mhz/Linux 2.6.15-cK1/Sun JDK 1.5.0_06-b05
Full results table."Man in the Moon and other weird things" - wfmh.org.pl/thorgal/Moon/
What you say about double buffering is incorrect. Double buffering means that the components are first drawn into an off screen graphics context (simply put an "image") that is not displayed. After all components have been drawn off screen the result is displayed on the screen in one fast operation. The effect (and the reason why double buffering is used) is that users never see an incompletely drawn display.
The only performance difference to unbuffered drawing comes from increased memory usage and the displaying of that "image". Double buffering does not require any more steps during component drawing than unbuffered display. The useless clearing you talk about can be resolved by setting component opaqueness to correct value.
Antti S. Brax - Old school - http://www.iki.fi/asb/