Main Menu

Old and Wise

Jini continues to be adored by a small crowd that "gets it", and ignored by many people who seem determined to reinvent about half of it (and not well). So let's reset for a minute: Jini is not about networking your refrigerator and your toaster oven. Just thought that needed to be restated, because so much of the initial Jini hype was about small devices that Jini ended up not running on anyways.

I first used Jini as a proof-of-concept for a project at a video networking company, where we were planning to put our servers on customers' LANs and allow them to move video around the network. Some of our machines would be able to dub this video to tape. But... which machines? Where were they? How could they be found? What could they do? How would you know if they were already busy? Some of the engineers and management were perfectly happy to solve most of these questions with configuration files: you put a box on your network, you get to edit a config file on the server, in whatever format we feel like supporting. So there's a maintenance to-do. And be sure you never lose the config file, or you have to re-write it. And, oh by the way, the typical broadcast engineer is not necessarily a competent network admin, so it probably wasn't smart to assume that the customer really could maintain this file. Multiply times hundreds of sites and it sounded like a support nightmare.

This is what got me interested in Jini. I thought we could have our VTR boxes announce themselves on the network as a "service", and then the rest of our software would discover these services and use them. It would eliminate the maintenance hassles and isolate the customer from being responsible for networking issues that they neither understood nor cared about. We whipped up a proof-of-concept in a couple of weeks, and, like a lot of quick-and-dirty demos, most of the code ended up eventually going into production.

The point of this: Jini has had a fabulously underappreciated history in the enterprise, and as people talk about software as service, they should look back at how Jini phrases the questions and offers some very robust answers.

Jini's SOA strengths are highlighted in the JavaPro article Jini at Your Service, featured in today's Projects and
Communities section. In it, Alex Krapf writes:
"What most people didn't realize during the initial launch of Jini was that it also provided a gorgeous framework for building service-oriented applications. The failure to notice this important capability is easily understood: the term service-oriented architecture (SOA) had not even been invented yet."

Also in Projects and Communities, the JavaTools Community Newsletter #64 is out. This edition discusses ideas for creating short videos of projects to be shown at the JavaOne 2006 Community Corner. It also welcomes two new projects to the community and links to a tip for creating Ant build files from Eclipse project configurations. Previous newsletters are available from the JavaTools Community newsletters archive.

The latest java.net poll asks "What do you think of the WebWork / Struts merger?" Cast your vote on the front page, then visit the results page for results and discussion.

In today's Forums,alanstange offers some answersRe: Trig performance:
"Give the mustang builds a try. Many of the Math.* routines have been 'intrinsified' for extra performance. Please try it and post the numbers comparing the 3 systems (1.5, C++ and 1.6). There's not a lot you can do in the 1.5 world. The issue is that the Java FP operations are defined to behave in a certain way. C/C++ programs can violate IEEE754 FP semantics in small ways which Java can't."

The Beyond Java discussion notes the conclusion of Chapter 6: Ruby in the Rough, and whether Java isCollapsing under the weight of abstraction?:
"My playtime in Ruby makes another, more powerful idea, clearer. As we stretch Java in increasingly unnatural directions, there's a cost. AOP and dependency injection are near-trivial exercises in Ruby, but they force Java developers to learn new programming models, deal with XML, and introduce increasingly complex syntax. With each new metaprogramming concept that we bake into Java, it's looking more and more like all of that complexity is trying to drive us somewhere. The net effect is to push Java further and further into the enterprise niche, and make it less and less accessible to the average Joe. Contrast that situation with Ruby, where dependency injection and AOP don't consume your focus; you're free to apply those ideas in spots right where you need them."

In Also in
Java Today,
"EJB persistence has long been criticized for its complex development model and for poor performance of entity beans. It's pretty much accepted as fact that if entity beans (especially container-managed persistence entity beans, or CMPs) are going to be used in an application, performance will suffer. This is not true." In the dev2dev feature article, Peak Performance Tuning of CMP 2.0 Entity Beans in WebLogic Server 8.1 and 9.0, Dmitri Maximovich reveals concurrency and caching strategies you can use to improve the performance of CMP beans.

Still waiting to move to J2SE 5.0? James Gosling thinks you should make the switch. In the interview Migrating to Tiger: James Gosling and Mark Reinhold on Java 2 Platform, Standard Edition 5.0, he says "People always fear new releases. But in the Tiger release, we performed rigorous testing in long alpha and beta cycles of a large variety of giant outside applications that we took in house, working directly with outsiders." He goes on to discuss criticisms of generics and autoboxing. Finally, Gosling defers to J2SE chief engineer Mark Reinhold regarding Tiger startup speed and a few other questions.

Santiago Pericas-Geertsen sizes up DOM vs. JAXB Performance in today's Weblogs:
"A key design decision when creating an application that has to process large amounts of XML data is whether to use an API that supports random access or not. APIs that only offer sequential access to the XML data (i.e., the XML infoset) are referred to as "streaming APIs". If an application does require random access to the infoset, two of the most popular options are the use of a DOM API (such as W3C DOM API) or a binding API (such as JAXB). In this blog, I'll kick the tires of the latest DOM implementation from Xerces as well as the latest JAXB 2.0 RI. So how do they stack up?"

Registered users can submit news items for the
href="http://today.java.net/today/news/">java.net News Page using our news submission
form. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the
href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net News RSS
feed.

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
site.

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 java.net it will be
archived along with other past issues in the
href="http://today.java.net/today/archive/">java.net Archive.