Skip to main content


Posted by editor on May 17, 2007 at 7:19 AM PDT

Speaking up about JavaOne

Truth be told, it would be easy to fill the front page every day this week with JavaOne-related blogs and feedback; there's been some, but I've wanted to move on with new topics.

Still, I did happen across one blog I wanted to mention just in this editor's blog, and that's Charlie Collins' JavaOne wrap up on, a site he runs with GWT in Practice co-author Robert Cooper. Along with a gratuitous plug for my Glossitope plug-in (thanks!), he has pretty much the same impression of the variant quality of sessions as a lot of people have been expressing (though he may be the only one claiming that the Google-led sessions tend to be a cut above the rest), and says that the best part about the conference may be the ability to meet people you know only from their IM's and svn commit log messages. And he really nails a very common complaint regarding the management and movement of people between sessions:

The facility (Moscone), rooms, technical services, meals and so on were ultimately fine - but the coordination of getting people to places was s----y. The lines were really long, and they made you leave the room and line back up for the next session even if your next session was in the SAME room (sure they need you to sign in again, but just put a little badge reader IN the room, etc). Adding to the annoyance of the long lines was the fact that the lines were not maintained in any fashion - they would open up one line and wind people down hallways, and then when the room opened they would screw those who had been waiting by opening another door and letting other people walk right in (ending up with two lines, rather than just funneling the one line into two doors). Also the on site staff was very gruff. On several occasions they literally yelled at "all you people" for standing in the back of the room to catch a session and they generally barked orders about - overall pretty rude.

The whole thing with the advance reservations and the card readers came up a few years ago as a way of managing access to popular sessions, making people sign up in advance for the sessions they really care about. The motivation is good, but maybe it's time to ask if this system is really working or if it's time for a rethink. Coming out of one session in the Esplanade building, I saw the line for the next sessions there went all the way down the Esplanade, down some steps, past the bookstore and almost to the games area. A little further and they'd have had to either queue people up outside or down the steps.

As for other things Charlie thinks JavaOne should try to improve next year is the highly variant quality of the wi-fi access, as well as the scarcity of power strips to recharge laptops. The Community Corner's hang space had a much-used power strip between the sofas, and I'm thinking next year, we might want to put strips under the rows of chairs in the mini-talk audience, so attendees can recharge for 20 minutes while listening to speakers.

And what did you think? What would you like to see done differently at JavaOne 2008? We'll probably have another forum next year like the Planning JavaOne 2007 discussion we ran earlier this year, but until then, you could always leave your comments here...

In our Feature Article, Régis Medina and Pascal Pratmarty introduce
UISpec4J: Java GUI Testing Made Simple:
GUI's are notoriously difficult to test, and the robot-based approach to automated testing makes agile development difficult, as you need finished GUIs before you can test. The UISpec4J project takes a different approach, and in this article Régis and Pascal show how it works.

In Java Today,
a detailed new article on TheServerSide offers The Working Developer's Guide To Java Bytecode. Noting all the changes in the Java programming environment -- new languages atop the JVM, features like generics, etc. -- Ted Neward notes "one thing that hasn't changed, however, is the basic fact that all of these languages, despite all their interesting features or capabilities, eventually end up in the lingua franca of the Java Virtual Machine, the JVM bytecode set. In this article, we're going to examine the JVM bytecode set, disassemble some code to see how it works, and play with some tools that allow us to manipulate bytecode directly."

Artima's Frank Sommers asks What Are Your Java ME Pain Points, Really? "A billion Java-enabled devices in use, and the many more non-PC devices through which billions of people will experience the Internet, represent a potentially big opportunity for developers. Yet, relatively few developers work on Java ME applications today. What makes it hard to develop for mobile Java devices?"

At JavaOne, Sun Microsystems unveiled a new consumer-oriented product line called JavaFX, which among other things has a new language for interactive user interfaces (JavaFX Script). Sound a little like Flash? That's the idea, says Sun CTO of Software Bob Brewin, and a new streamlined runtime system will help make it a reality. In ZDNet's Sun CTO promises Flash-like experience from JavaFX and new runtime, Ed Burnette talks with Bob about how all this will work together to improve the experience for the user and developer.

Today's Forums start off with two messages about finding and fighting memory leaks. In
Re: Memory management on "real-world" J2ME devices, Stefan Haustein points out device-specific leaks that ME developers have to deal with:
"I think for pure Java objects, this is not an issue, but some devices are really messed up concerning freeing system resources. For instance, on a 6680, you will run into an OutOfMemoryException after creating a certain amount of Canvas objects, although they are no longer referenced anywhere (even when calling GC manually). I would not recommend pooling StringBuffers or similar, though."

On the SE side, kirillcool offers advice for tracking down these problems in
Re: Memory leak question.
"I'd say that a frame or even a text field will take much more than 24 bytes - or is it supposed to be 24KB? Any decent profiler can take a snapshot of the heap, filter out objects that can be garbage collected and then show paths to the GC roots. Then, you can see who exactly is holding a strong reference to that frame that can not be garbage collected. It might be some UI delegate tracking something in a static map, or some other internal Swing class doing something it's not supposed to."

trouby wonders about a persistent timer feature in

Re: EJB3 Timers:
"I was wondering, is there any way to stop the persistency of the timers? Sometimes it is critical that timeouts will be done by a constant intervals, and if there was some failures, when server is up again, all 'missed' timeouts being executed one after another, and in some situations it might be very risky."