Skip to main content

Piece by Piece

Posted by editor on July 20, 2005 at 7:24 AM PDT

The building blocks of Mustang

First off, your eyes / glasses / contact lenses are not fooling you: the colors on have changed. The new look is meant to help distinguish as an independent site, which it is, as well as be attractive in its own right. Let us know what you think in the talkbacks below.

Mustang isn't due until the third quarter of next year, but it's decision time for what's going into this next rev of the Java Standard Edition. Surely everyone has his or her own set of longed-for JSR's (oh, wherefore art thou, JSR 80: Java USB API?), while keeping in mind the point, often made on the forums, that Java SE is already very big and adding more API's to it has a significant cost.

Today's big news from the JDK Community is that the set of component JSR's to appear in Java SE 6 (Mustang) has been selected. They're listed in Mark Reinhold's weblog entry Mustang Component JSR's, which has links to each of the JSR's selected by the expert group, along with a brief discussion of how this list differs from early proposals. These changes show why some web services API's made the cut, and the Smart Card I/O API (JSR 268) didn't.

Also in Projects and
Slides are now available (in PDF) for presentations offered at the Jini(TM) Technology: An SOA Delivering Java Dynamic Networking event, co-sponsored by Sun and the NYJavaSIG. Topics include Jini marketing, JavaSpaces, the Jini Community, and Jini as an SOA architecture.

In today's Weblogs.
David Herron talks about
Accessibility for test automation:
"I've spent more than a few brain cycles thinking about GUI test automation. It's been so much that at times I've been worried about my sanity - how many people do you know daydream about the minute details of GUI interactions, looking for ways to drive the interaction by a program?"

Vikram Goyal blogs on MIDP + DoJa = Mojo for Sun?: "NTT DoCoMo and Sun combine to update NTT's DoJa Java platform. Why, you may ask. Why not upgrade DoJa to MIDP 2.0 instead, rather than creating a separate breed of the J2ME platform?

Figuring out Native XML support in Dolphin is the topic of Kirill Grouchnikov's latest blog entry: "One of the big changes tentatively proposed for Dolphin is native XML support in the language. What do we have now, what can we expect and what would you like to see?"

In Also in
Java Today
JUnit is great, but it has its limits for distributed programming. Specifically, it's meant to run in one JVM on one machine--not the best thing for verifying behavior of complex systems on multiple machines, or for automating testing across several platforms. However, the Pisces project improves this situation by creating a distributed environment for JUnit testing. In Taking JUnit Out of the Box, Amir Shevat introduces Pisces and shows how to put it to work for you.

"Read almost any software developer journal or website and we're told that responsible developers write test cases. If those developers are Java developers then, most likely, they use JUnit for those test cases. JUnit is probably the oldest and certainly the most popular Java-based testing framework around. However, other frameworks have been built to address various faults and deficiencies with JUnit." Justin Lee's Test Framework Comparison introduces and analyzes the strengths and weaknesses of JUnit 3.x, JTiger, and TestNG.

In today's Forums,
laurapiersol makes the case Re: Multiple return values:
"Multiple return values are a great feature that really could and should be added to Java. All this talk on how its "not object oriented" and "just return a Point class where needed" definitely doesn't match my programming experience. Multiple values ARE and MUST BE returned by functions that perform multiple calculations in the same formula. No way to change the math so its just a fact. If you accept the FACT that certain formulas calculate multiple results then the only question is how to return the multiple results."

Support for named code blocks is an idea advocated by euxx:
"This would allow to access information about method slicing in the runtime or after compilation. From a bytecode point of view, this can actually be implemented as a new attribute that would have values for start and end offsets within the method bytecode (similar to try/catch) and also value for the block annotation."

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The building blocks of Mustang