Posted by editor on November 13, 2008 at 7:28 AM PST
Picking up discarded objects and putting them back in the toy box... also:
Java Today: New GC for JDK 7, Tomcat and GlassFish survey, and OSGi in the Enterprise
Forum Posts: New applet lifecycle, problem with applet in new plug-in, inplace execution in CLDCHi and BD-J color fidelity on real devices
Picking up discarded objects and putting them back in the toy box
So, here's an amusing analogy for you, from Danny Coward, Sun's Chief Architect for Client Software:
Like using the living room as the
kids play area, tidying up, or
collection, is an integral part of life in the JVM. Except that the kids are applications and the toys on the floor the objects
they create. But unlike in your living room, these kids
sleep, are always playing with something, will
they have to wait while you tidy up, and will get seriously,
seriously mad if they lose a toy. So how can you organize the mess they
make without disrupting the game ?
Well, I suppose one answer would be to use Real-Time Java, but all that does is to make the timing of the cleanups predictable, potentially at the expense of performance (i.e., how many toys you get to play with in a given timeframe). But we can do better than that, right? Danny continues:
The HotSpot team has been quietly working on a new algorithm, called
First, for tidying up the memory space in the JVM while the kids
are playing, as a
for the existing parallel and concurrnet mark sweep collectors. By
dividing the living rooms into equal squares, it turns out that for
most games, many of the squares contain unused toys that can be safely
This approach could have some interesting consequences. Being scheduled, it's highly predictable, and by dividing the work up, it's highly parallel, and thus well-suited to multi-core. Sound good? Well, you can try it. As Danny reveals in Java VM: Trying a new Garbage Collector for JDK 7, this garbage collector has already been added to the latest build of JDK 7.
Also in Java Today,
Eduardo Pelegri-Llopart announces that Sun has launched a Tomcat and GlassFish Survey. "We are conducting a survey
on developers, ISV, etc, that are using Tomcat and are considering GlassFish.
We want to find out what features are used and which migration approach would be preferred.
If you want to help us, please participate in the survey.
"With the recent announcement of GlassFish v3 "Prelude", Sun's OSGi-based Java EE 6 server, the use of OSGi across the enterprise has grown to encompass almost all of the back-end servers." In the InfoQ article OSGi in the Enterprise, Alex Blewitt looks at how OSGi usage is growing in open-source projects, webapp and back-end systems, and OSGi's longer-term prospects in the enterprise.
New Java plug-in concerns top today's Forums, with leathrum reporting of an Applet not compatible with new plugin. "I have an applet which works fine with the plugin version 1.6.0_10 in classic mode, but not in next-generation mode. The page is written in XHTML, using
Meanwhile, kbr sets the record straight on the modern applet life-cycle in the follow-up Re: Dragable applets -- you screwed that up too... "The current applet lifecycle behavior is as intended. When applets were first introduced in HotJava, multiple calls to start/stop were allowed, and the applet instance would be cached between visits to the same web page. This behavior was changed several releases ago to no longer cache applet instances by default. This means that you will get calls to init / start upon visiting a page with an applet, and stop / destroy upon leaving the page. It is possible to request the previous lifecycle behavior, but I strongly recommend against it, even though the implementation of this functionality works well in the new Java Plug-In. Google for "legacy lifecycle" There are no explicit events in the current browser plugin specifications for minimizing the browser window or switching to a different tab. This makes implementing calling stop() / start() upon these events basically impossible."
ankitmittal000 has some questions about the potential benefits of Inplace execution in CLDCHi. "I am working on Inplace execution feature given by SUN in CLDC Hot spot Implementaion. I want to know how much performance can be increased by using inplace execution for the midlet to be run on the device. I have converted the midlet jar file into application image (bun) but not able to know whether I have got any significant improvement or not. Can anybody tell me that how can inplace execution improve the performance and it will affect which part? Is there any way to know how much performance has been increased like some benchmark midlet for InPlace Execution feature."
Finally, Bill Foote updates the state of Blu-Ray Disc Java specs and realities in Re: [BD-J-DEV] Issue with remote colored buttons. "I should mention that sample code 19.2 might be a bit overkill, since subsequent to the book's publication, the BDA added a requirement that the HAVi API return exact color values. The whole fuzzy match on hue isn't necessary for players that obey the enhanced spec. That said, I'd want to do extensive player testing before counting on that spec requirement having been implemented everywhere that matters; all things considered, it's probably worth it to be conservative, and add the tiny bit of code for the fuzzy match."
Varun Nischal reports on his integration of Ant, Hudson and Glassfish. "Blogging after a long time, I have learn something interesting and would like to share with you all. Its all about automating builds and continuous integration!"