Skip to main content

It's Not So Hard

Posted by editor on February 15, 2007 at 8:05 AM PST


Do framework developers need to give it a REST?

JDK 7 is turning into one of the best-debated releases of Java. We've already started vigorous discussions about closures, properties, and the modularization of Java, now get ready for the debate over the REST API.

The newly-unveiled JSR-311 proposes a Java API for "RESTful" web services. "This JSR will aim to provide a high level easy-to use API for developers to write RESTful web services independent of the underlying technology and will allow these services to run on top of the Java EE or the Java SE platforms. [...] The goal of this JSR is to provide an easy to use, declarative style of programming using annotations for developers to write REST-ful Web Services and also enable low level access in cases where needed by the application."

The question that's being raised immediately is whether REST needs its own Java API. A book editor I was IM'ing with this morning was surprised by JSR-311, saying in effect, "what do you mean you can't do REST in Java, I just signed a book on it." Author and developer Elliotte Rusty Harold goes further in yesterday's Café Au Lait news, questioning the motives and mindset behind JSR-311:

A major selling point of REST is that it's simple. It doesn't require big, complicated frameworks with seven levels of indirection to solve simple problems. However there are some companies (Sun being one of them) that can't imagine regular, ordinary developers building systems without using some ultra-complex framework they've designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don't actually need to do at all.

Marc Hadley takes on some of the concerns in his blog
JSR 311: Java API for RESTful Web Services, denying that the JSR presumes that developers are incompetent:

This one seems to come from this sentence in the JSR submission: "Correct implementation requires a high level of HTTP knowledge on the developer's part." OK, perhaps this wasn't put very well, but the plan is to offer default implementations of things like content negotiation and precondition support to save developers having to implement those things themselves (unless they really want to).

So what do you think? Does Java SE need an API for RESTful web services? Take a look at the discussion out there and jump in. The best way to make sure JDK 7 gets done right is if developers get involved early.


Also in Java Today,

the Java Desktop Community recently featured Stopwatch as its "Project of the Day". "Stopwatch is a platform independent timesheet recording application that may be used to track the time you spend on clients, projects and tasks. You can also generate reports from your timesheets by using one of the predefined templates, or from one you create yourself. "

Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé recently updated their Closures for the Java Programming Language proposal to version 0.5. The new revision changes terminology to clarify the difference between a closure literal and the result of evaluating it, corrected an example, further specified throws type parameters, added support for control abstractions that act as loops, and more. An introduction to closures, along with all the previous versions of the proposal, are available at the javac.info site.


In today's Weblogs, James Gosling reports on real-world Java use in
HBO: visiting another great customer:
"One of the best parts of my job is going on customer visits. Yesterday I got to visit the folks that run HBO&Cinemax. No, not the CEO and a pile of executives: the folks who make the bits flow. The server and storage farms, the transcoding arrays, the video stream construction and the satellite uplinks. It's all in an impressive 5 9's reliability site on Long Island. Redundant everything. Big power supplies. There are big bags of Java code in the control system."

Would you believe
The Web as a Database? David Van Couvering writes,
"Alex Iskold over at O'Reilly sees Yahoo! Pipes as a model for doing databases over the web. I agree that this looks like a very compelling approach, but I have some concerns about scale."


In our Feature Article,
Tom Gibara takes a look at
Tackling Java Performance Problems with Janino.
The Janino library takes a very different approach to performance, allowing you to dynamically compile your most-used expressions. Tom introduces Janino and makes some remarkable claims about its capabilities.


In today's Forums,
Daniel Adelhardt offers some helpful links in
Re: JCA adapter and load balancing.
"GlassFish V2 will support Loadbalancing and Failover on EJBs as well. See the specs for GF V2 IIOP Failover, and the in memory state replication for HTTP Sessions and statefull session beans."

hinkmond would like you to take a poll to assess the demand for comliance-testing tools, in
Re: Did Sun opesource JavaCheck:
"Steve More asked about the JavaCheck tool. I need to collect some data from the community on how useful it would be to other developers. Please take 5 seconds to take this quick poll (Log in using your java.net userid), Thanks!"

Arnold Burian needs help with a
JavaHelp localization issue:
"We have translated our JavaHelp to Japanese successfully, but the JavaHelp browser's toolbar tool tips still show up in English. The tabbed pane icon headers' tool tips are translated just fine, but not the toolbar icons above them (Previous Page, Next Page, Print and Page Setup). Any idea why this is happening? We are using JavaHelp 2.0_02 and it appears that Japanese is one of the included supported languages for the JH browser (includes a Constants_ja.class)"


Current and upcoming Java
Events
:

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.

Do framework developers need to give it a REST?