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."
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.
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.
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.