Posted by editor
on July 31, 2008 at 6:30 AM PDT
JavaFX SDK is ready for its close-up... also:
Java Today: JavaFX SDK debuts and JSR 277 versioning debate
Feature Article: Return-Type-Based Method Overloading in Java
Weblogs: Young developer learning path, developing MEP connectors, and deploying non-Maven jars to java.net m2 repositor
Forums: LWUIT combo box rendering bug, thread safety in SwingWorkers, and JAI on 64-bit x86
JavaFX SDK is ready for its close-up
The JavaFX SDK is available for download from JavaFX.com . Download options include NetBeans 6.1 with JavaFX for developers, and Project Nile , a suite of tools and plugins for Adobe Photoshop CS3 and Adobe Illustrator CS3 for designers. An overview of the technology is also available from updated pages at http://java.sun.com/javafx/ and the OpenJFX Community on java.net. Finally, Josh Marinacci is blogging about JavaFX on a new JavaFX Blog . In his first entry, Start Your Engines , he promises:
Over the next few months you're going to see more blogs from me and other JavaFX developers, showing off tricks and waxing philosophic about graphical interfaces. And don't just think it's all eye candy. We've got lot's of nutritional value here too. This is just the beginning of a great new platform for rich applications.
Also Java Today , debate has once again arisen in the community around JSR 277 , which is a proposed dynamic module system for Java 7. The flashpoint of the debate this time around is the version numbering system that is planned for JSR 277 Java Modules (JAMs). In the round-up article JSR 277 Debate Renews Around Versioning , InfoQ examines the discussions and arguments to understand more about the current state of JSR 277 and its acceptance by the community.
Overloaded method names must differ by parameter count and type and not return type, right? Wrong! The VM knows the return type of all methods and with a little bytecode engineering, you can have methods that differ only by return type. In our Feature Article , Return-Type-Based Method Overloading in Java , Vinit Joglekar shows you how it's done.
Today's Weblogs begin with Dana Nourie explaining the Young Developer Learning Path . "This article describes the tools you can use to learn Java programming. You decide which tool to start with based on what you currently know."
In Developing MEP Connectors - Part 1 , Santiago Pericas-Geertsen writes, "developing an application using the Sun Java Mobile Enterprise Platform (MEP) requires writing two components: a sync client application that runs on the mobile device and an enterprise connector that enables the MEP gateway to access the back-end system where the data is located. Ryan has already provided an intro on the architecture and features of the client SDK, so in this blog entry I'll introduce the Enterprise Connector Business Object (ECBO) API which is part of the server SDK and can be used to write enterprise connectors."
Finally, Kohsuke Kawaguchi describes
Deploying non-Maven jars to java.net m2 repository .
"Maven users often have to push 3rd party jars to the Maven repository. Here is how you can do this easily."
In today's Forums ,
venu19 reports an LWUIT Rendering bug when Combo box is opened . "Noticed a bug with ComboBox. It only occurs when the combobox(should be a big list so when box is selected the opened box height should be bigger then the screen) is the last component on the screen and when selected, box opens at the top of the actual combo box and then notice the starting element in the box is off the screen some where at the top and the last element is at the top of actual box. So, its missing scrolling functionality and looks like the rendering y position is calculated as openboxY = actualBoxY - openBoxHeight(sum of height of all the elements in the combobox). so, openboxY being negative value when openBoxHeight is greater then actualBoxY."
kicks off a discussion on
Thread safety in SwingWorkers (take care they're not magic)
"What bothers me is the worker and it's fields are created on the EDT, doInBackground() on some other thread has access to the fields then done() is back on the EDT accesing the same fields. So this isn't really thread safe? I should either have thread safe collections, add synchronised accessors, or make them atomics, or have that complicated return object (not boolean which is pointless in this example). Alternately is it possibly OK to access those fields after the Future.get() in the done() method? shouldn't their values be visible by then?"
mboet is interested in
64-bit Linux JAI native libs on Intel 64-bit machine (Xeon) .
"Has anyone tried to run JAI with the 64-bit native libraries for Linux on a machine with Intel 64bit processor? In particular, I am interested whether anyone has experiences in successfully running the (natively-accelerated) JAI for the linux-amd64 platform on Intel Xeon processors. From the name of the downloadable package linux-amd64 it is not clear if it was only compiled for AMD processors, or whether it also works for AMD-64 compatible ones (like the Intel Xeon)."
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
JavaFX SDK is ready for its close-up