Posted by editor
on February 4, 2009 at 8:12 AM PST
JCP special election nominations... also:
Java Today:JSP special election to fill ME seat, XWiki/GlassFish webinar, and Grizzly 1.9.5
Weblogs: Java SE 6u12, WADL update, and M3DD thanks and followup
Forum posts: Using OSGi in phoneME Advanced, thread pool for GlassFish TimerServicer timeouts, and JXTA design legacies
JCP special election nominations
The JCP has announced the beginning of the special election to fill a vacated seat on the Mobile Edition JCP Executive Committee:
The nomination phase will continue until 17 February 2009. This Micro Edition EC seat is for a term ending in December 2010, and will fill Intel's vacated seat on the Java ME EC.
If you are a JCP member, you can nominate your candidate by sending an email to
This is your opportunity to get involved. Check this link for a description of EC duties.
Please contact the PMO with any questions concerning nomination preparation. As in the annual EC Elections, these will be self-nominations, open to JCP program members only. Click here if you would like to join the JCP program.
The election will take place between February 24 and March 9. Good luck to all the would-be nominees.
Also in Java Today ,
The Aquarium announces a Feb 5th Webinar - XWiki and GlassFish : "This week's webinar is the first of a new, occasional,
GlassFish Partner Series. This week's webinar is on Thursday, Feb 5th, 11 am PT. Vincent Massol will provide an overview of XWiki , the java-based, OpenSource Wiki and collaboration platform. XWiki is supported on GlassFish and is used in curriki and in the new (in progress) OpenSolaris.org Site . I've asked Vincent to also include a comparison with Atlassian Confluence, as that's what it is currently being used in Wikis.Sun.Com . Time permitting we will also discuss Vincent's experience embedding GFv3 into XWiki, and Alexis would join us for that segment."
Project Grizzly , the NIO-powered server framework, has just released version 1.9.5. Jean-Francois Arcand summarizes the major improvements in a new blog , which include a concurrent CometHandler , a reflector CometHandler ,. an improved GrizzlyWebServer , an improved Java API , performance improvements, an OSGi bundle , and more (see the complete issue list ).
Osvaldo Pinali Doederlein takes a look at the the 6u12 update in today's Weblogs . In
Sun JDK 6u12 released, good for both Swing and JavaFX , he writes, "whether you are a Swing diehard or a JavaFX enthusiast, Sun's latest JRE is yet another important improvement for client-side Java."
Marc Hadley introduces a Draft WADL Update . "Its been just over two years since the last version of WADL was published and, in the intervening time, a number of issues have accumulated. I've held off making regular updates for reasons of stability but I think there's sufficient backlog now to require a new version."
Finally, wrapping up this year's conference, Terrence Barr posts a
M3DD: Thanks & follow-up . "I'm just coming up for air again ... M3DD took all my attention for the past three weeks and after it was done I had a bunch of things to follow-up on, sift through hundreds of piled-up emails, and finally take two days off for a desperately-needed break. Late, but anyway, I wanted to share a brief follow-up on M3DD:"
In today's Forums ,
jjjaime reports success Using OSGi in phoneME Advanced . "We have successfully deployed an OSGi r4 framework on top of phoneME Advance in a Windows Mobile device. WeÂ´ve tested 2 different OSGi frameworks: Equinox and Knopflerfish, over a phoneMe Advanced Personal Profile. We found critical problems with Equinox (probably phoneME bugs) but Knopflerfish worked perfectly."
Dobes Vandermeer wonders about
Thread Pool for the TimerServicer timeout actions? "Is there any way to control the number of thread spawned by the TimerService to process timeouts? Browsing the source code it *looks* like the TimerService always uses the default ThreadPool but I could be wrong. I'd like to limit the number of threads used to deliver timeouts to a particular bean to a more reasonable number - say 5 - instead of having it share the 200 threads in thread-pool-1 because otherwise I'll use up all the threads and all the database connections available."
turbogeek rues some of JXTA's design decisions in
Re: Relay per groups or per network? . "Here is the bottom line. I have said this many times. Jxta is not currently built to be efficient. It is unreliable despite the fact that it could be reliable. It seems to only have had one goal, at least from the original designer's point of view, is to be self healing and limit two way communications because it is not always possible. Sadly the idea that self-healing is more important than 'unreliable' and 'non-optimized' are perfectly acceptable when you think that way. In reality these are both possible, just harder and do require a little more bandwidth. Sadly the lack of reliability and optimal performance is the leading reason why Jxta is not as as popular as it could be."
Current and upcoming Java
Registered users can submit event listings for the
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
Archives and Subscriptions: This blog is delivered weekdays as
Today RSS feed . Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the
JCP special election nominations