Java Today |
 |
Method Handles in a Nutshell
"One of the biggest puzzles for dynamic language implementors on the JVM, and therefore for the JSR 292 (invokedynamic) Expert Group, is how to represent bits of code as small but composible units of behavior. The JVM makes it easy to compose objects according to fixed APIs, but it is surprisingly hard to do this from the back end of a compiler, when (potentially) each call site is a little different from its neighbors, and none of them match some fixed API." John Rose takes a swing at addressing this problem through a new design for "method handles", which he details in the blog Method Handles in a Nutshell.
Kinds of Compatibility: Source, Binary, and Behavioral
What does it mean for changes to be "backwards compatible" with previous versions of Java? Joe Darcy clarifies common misperceptions in the blog Kinds of Compatibility: Source, Binary, and Behavioral. "When evolving the JDK, compatibility concerns are taken very seriously. However, different standards are applied to evolving various aspects of the platform. From a certain point of view, it is true that any observable difference could potentially cause some unknown application to break. [...] Since not making any changes at all is clearly not viable for evolving the platform, changes need to be evaluated against and managed according to a variety of compatibility contracts."
Working with jMaki Events
The latest SDN Enterprise Tech Tips looks at Working with jMaki Events. Author Carla Mott writes, "the following tip expands the discussion of the event mechanism in jMaki. You'll learn more about the concepts that underlie the jMaki event mechanism and how to take advantage of it to easily interact with widgets. "
Weblogs |
 |
Anti-Social Networking
We all have light bulb moments from time to time, ideas for new software which scream "code me". Google's new App Engine promises to get your ideas up and running without the traditional hassle, leaving you to focus on your code... but are there consequences further down the line? —
Simon Morris
Loading data into jMaki widgets
I've gotten a few questions about how to get datainto jMaki widgets. This blogs describes the different ways in jMaki to load data into widgets. —
Carla Mott
Object Only Programming (and Modelling) Considered Silly
Every so often I come across a blog entry that makes my own attempts to put my thoughts in writing seem pathetically inadequate. Stevey's Blog Rant: Execution in the Kingdom of Nouns is one such entry. —
John Reynolds
Forums |
 |
Re: Logging in Java ME
JSR 47 is the logging API but unfortunately it never got much traction in Java ME land. You're right that there are a few open source packages available but I have not yet tried them. Do you need to log during development? If yes, then with many devices System.out goes to the console on the PC or into a file on the device and you can use that. If you are looking for logging functionality once your app is deployed to users then your choices for persistent storage is RMS or PIM files. In both cases you'll need to implement caching and LRU policies to minimize the activity on the persistent store as some devices are very slow in accessing flash storage. —
Generate one physical wsdl file for a web service
The JAX-RPC used to generate only one physical WSDL file for a web service but JAX-WS generates multiple files (wsdl and xsd) for one web service. Though segregating different types of the stuff in different files looks logical but if one needs to distribute the WSDL then it is quite inconvenient to handle them. Is there anyway to instruct JAX-WS to generate only one file? —
Need authoritative answer on whether JAX-WS client objects are thread-safe
We need to know whether the service objects generated by wsimport (JAX-WS RI 2.0.1 and later versions), as well as the port objects returned by the getPort() methods of those service objects are thread-safe. The spec appears to be ambiguous on this and forum posts for other JAX-WS implementations appear to indicate that these objects are not thread-safe for some implementations (e.g. Axis 2, CXF). In our performance tests with JAX-WS RI 2.0.1 and 2.1.3, the overhead of the Service.getPort() method is very heavy with average response times of 400-1000 ms. In order to achieve acceptable performance, we would need to cache and share port objects across threads. In order to do this, we need to know whether these objects are thread-safe. If we cannot do this, we may be forced to look at using an alternative web service stack. —
java.net RSS Feeds
