The Java desktop team at Sun has not been very active in the blogosphere as of late, providing only a few hints of what will be added to the 6.0 update N. The biggest pieces available so far in the (not so) weekly drops were the Nimbus look-and-feel and Direct3D-accelerated pipeline for Windows. Not much else has been officially confirmed, with hints being dropped on media support and importing artwork from Adobe tools.

Sun has put a significant amount of effort into open-sourcing the JDK (OpenJDK project) and proclaiming that anybody can chip in and contribute to the project. Sadly, the current state of affairs is not quite so close to what the marketing / evangelizing would lead you to believe. One of the biggest obstacles for the community is the planning / scoping process for both 6.0 update N (which is not part of OpenJDK if i understand correctly) and 7.0. Sure, one can always pick the low-hanging fruit from the bug parade, but what about people who want to work on new features (in JDK in general and in desktop in particular)? Why would anyone want to start working on adding a new feature in his private Mercurial forest (or whatever it’s called) when he can’t be sure that the same feature is not being worked on by the core team?

This brings me to pretty much the only “peephole” into what is going on during the development cycle – the much-maligned bug parade. Thanks to the comments on Ben’s blog entry, i’ve found two quite interesting entries:

6656651 – The Java 2D LCD glyph rasterisation is not the same as that of the customer Cleartype rasteriser. Some of the resulting differences are observable on Vista and XP in applications which utilise the Windows L&F. [Evaluation] This can be fixed by asking GDI to perform the rasterisation of glyphs, then caching these glyphs in the same way as now. This avoids disruption to the various 2D rendering pipelines, particularly its hardware acceleration architecture. This has been verified with software and D3D and OpenGL pipelines, and with SwingSet and Font2DTest. […]

6655001 -When window translucency is enabled for windows with accelerated surfaces the tranlucency doesn’t work well on Windows systems prior to Windows Vista: there are artifacts when a window is dragged away, and it doesn’t appear transparent. Shaped windows work fine. […]

Am i dreaming? Is the first one talking about native font rasterization? Is the second one talking about shaped and translucent top-level windows? Now if only 6633275 hasn’t been marked as private (transparency, transparency, transparency)…