Moazam Rajas Sun hosted weblog garbage collection II

Here are some of the photos I took while attending both JavaOne and WWDC today.


Misha Dmitriev giving a demo of the JFluid profiling/monitoring tool. It looks like this tool might be worked into the Sun Java IDE soon.


The Project Looking Glass booth drew big crowds and tons of questions. Absolutely amazing demo.


Over at the WWDC side of the party, we were introduced to the new Apple LCD displays. You see that small 15"-17" looking LCD display towards the back? That's a 20" LCD! The new 30" LCD simply dwarfs everything in its presence!!


Welcome to the year 2020. Un-Believable. Apple really has the Bentley Arnage of computer and display setups.


Afterwards, at about 7:30pm Jonathan Schwartz showed up to the JavaOne Blogger Meetup, which probably surprised quite a few people. Jonathan is the President and Chief Operating Officer here at Sun Microsystems. Oh, and he made it official today, he has his own weblog.

I'd really like to thank the folks at Atlassian for setting up the evening event over at The Thirsty Bear, and special thanks go out to Tim Bray and Simon Phipps since I heard they were picking up the tab for the night!

As Calvin Austin mentioned, J2SE 1.5.0 is now known as J2SE 5.0. J2EE will be J2EE 5.0. I'm in the middle about this, but still not 100% sure what I think of the namechange.

JavaOne is pretty packed, it was very interesting watching the horde descend upon the pavilion floor when the clock struck 11. I went over to WWDC, my first visit ever, the pavilion is pretty small compared to JavaOne.

I need to figure out how to steal one of the huge BEA beanbags without anyone noticing.

ObJVMInternalsEntry> The Sun folks (Misha Dmitriev) were showing off JFluid and the built in Java Performance Console tool which will be bundled with J2SE 5.0.

I just got off a 6am con-call with a customer having some problems with Java 2D/Swing performance on multiple monitor systems. Unfortunately we don't have any sort of test case so we're shooting slightly in the dark for now. A quick search for Java 2D optimization and runtime flags brings up some interesting stuff.

From the 1.4.2 Release Notes:

One example of a known problem is that using Direct3D on some small subset of Windows 2000 systems has been known to cause a system crash. You can also try launching your application with the following command-line flag set:

-Dsun.java2d.d3d=false
This forcibly disables our use of Direct3D and avoids any Direct3D-specific problems.
You can also try the following flag:

-Dsun.java2d.ddoffscreen=false
This flag disables our use of DirectDraw and Direct3D for offscreen images (such as the Swing back buffer).
If problems persists, try launching the application with this flag:

-Dsun.java2d.noddraw=true
This flag disables our use of DirectDraw and Direct3D completely and thus avoids any problems you may be seeing associated with our use of those APIs and their respective drivers on your system.
For more information about performance-related flags, see Flags for Controlling Performance and Quality, a section in the High Performance Graphics white paper (also available in PDF format).

* Drawing many simple primitives to an accelerated offscreen surface may result in a JRE crash and corruption of the underlying graphics subsystem due to leakage of GDI resources. This problem is being tracked as bug 4766813. The workaround is to turn off offscreen acceleration:
-Dsun.java2d.ddoffscreen=false


And from the Graphics Performance Improvements white paper:

# -Dsun.java2d.noddraw=true
Setting this flag to true turns off DirectDraw usage, which sometimes helps to get rid of a lot of rendering problems on Win32.

# -Dsun.java2d.ddoffscreen=false
Setting this flag to false turns off DirectDraw offscreen surfaces acceleration by forcing all createVolatileImage calls to become createImage calls, and disables hidden acceleration performed on surfaces created with createImage.

# -Dsun.java2d.ddscale=true
Setting this flag to true enables hardware-accelerated scaling. Hardware scaling is disabled by default to avoid rendering artifacts in existing applications. These rendering artifacts are caused by possible inconsistencies between the scale method that the software scaling operation uses (nearest neighbor) and the different scale methods that video cards use. Certain events that occur while an application is running might cause a scaled image to be rendered partially with hardware scaling operations and partially with software scaling operations, resulting in an inconsistent appearance. For now, you can enable acceleration by setting the ddscale flag to true.