By all appearances, the initial release of Mac OS X Leopard will not include Java 6. Java 5 will still be there and include all of the 64-bit goodness that we’ve been reading about. Considering that Java 6 is not listed as one of the 300+ new features it’s a good indicator that it won’t be there. I’ve also received a few good comments which strongly indicate that Java 5 is the JVM that ships with Leopard. There maybe a separate Java 6 download later in life, but Apple being who they are don’t have much to offer on the subject. * sigh *. Looks like I’ll be saving my $129 for a while along with the rest of the folks who do Java development on a Mac.

Even though Java is not listed as one of the 300+ new features, Java is listed as one of the “Key Technologies” listed under the tech specs for Leopard. Additionally, the development tools section also states that Leopard will include:

“Complete Java JDK, including javac, javadoc, ANT, and Maen tools “

Whatever “Maen” is 🙂 Technically speaking, Java isn’t “new” even though Java 6 is a very big improvement over previous releases. I guess saying that they now have Ruby on Rails in every copy will sell more copies than saying that after 13 months, we finally have Java 6. Since Apple apparently removed the year-old developer preview of Java 6, I’m gonna go with Java 6 is finally going to appear in Mac OS X.

But seriously Apple, you need to do a better job at communicating with the development community on topics like this. We love your OS. We love your hardware. We hate the fact that the Java community was left in the dark as to what the state of Java was going to be in OS X Leopard. The Ruby folks seemed to have an awful lot of details around what was going to be included in 10.5. Whatever. I’ll still get my copy on the 27th at 10am.

So Apple has put out a page highlighting the 300+ new features Leopard will have. As I scan through this page, one word I’m particularly keen on is only mentioned once. That word is Java. It is only mentioned in DTrace section where it talks about how DTrace can monitor Java code. So we know Java is there, we also know it’s been tweaked for DTrace. We also know that Java on Leopard will be 64-bit. And we also know that Apple has been working on a Java 6 implementation for some time now.

So why isn’t Java a feature that’s listed? Honestly, this is primary reason for me to be purchasing Leopard in the first place. This is a pretty significant feature for me and many other folks who went out and got a MacBook Pro to do Java development on. These games that Apple is playing with the Java camp is certainly getting old!

As I’m reevaluating and retooling RESTEasy, I’m thinking about what it is going to take to reach 1.0. At a high-level, RESTEasy will provide:

• A Server side API as a JAX-RS Implementation
• A Client API similar to what I described in this post.
• A set of common code that is shared between client and server.

As for features, here’s the run down:

• A complete JAX-RS implementation
• Use EJB 3 Session beans as a RESTful end point
• Use EJB 3 Message-Driven beans as a RESTful end point
• Support for JPA and Hibernate
• Integrated GZip encoding
• An integrated HTTP proxy for Flex applications (to get around this issue)

These are the basics for the 1.0 release. Right now, I’m starting to get the code in back inline with JSR-311. If there’s something you want to see in 1.0, please let me know.

Bill Burke has just posted a bunch of really great feedback on the latest draft of the JAX-RS spec. If you haven’t had a chance to look at the spec, head over here. One thing that JSR-311 had initially chosen not to do was to define a client API. There has a been some grumblings about the lack of a client API in the spec. After readings Bill’s post, I’m starting to think there is a need for a client API in the spec.

There are a few reasons why a client API could make sense:

• You can reuse the same collection of EntityProviders on the client. They are already handle request/response anyway, so it’s a natural choice.
• Some of the annotations are applicable to client applications
• Utility classes like URIBuilder are useful to both sides of the API.

One of design decisions I made with RESTEasy was to separate the framework into three parts:

• A Client API
• A Service API (soon to be implementing JSR-311)
• And a collection of common code that is shared between both client and server

The RESTEasy common library handles thing like EntityProviders(aka RepresentationHandlers in the old RESTEasy), Header and Request info, and some other common utility classes.

What Bill suggested was to have the ability to place annotations on interface classes. This is what the current implementation of RESTEasy does with EJB3-based Resources. The cool thing that Bill is suggesting is that it would be then possible for the client API to do something like:

@Stateless
public class PeopleResourceBean {	
    public Person getPersonById(int id) {...}

}

Also note how the JAX-RS annotation don”t litter your bean class? 🙂 You can then annotate your local interface such that:

@Local
@UriTemplate("/people")
public class PeopleResource { 
  @UriTemplate("{id}")
  @HttpMethod("GET")
  public Person getPersonById(@UriParam("id") int id);
}

Then finally, you’re client code could do something like:

public class PeopleServiceClient {	

@HttpResourceRef("http://somehost.com") PeopleResource peopleResource;

public Person getPersonById(int id) {
 	return peopleResource.getPersonById(id);
}

}

The client side framework would the take care of implementing the business of connecting to the remote service. The @HttpResourceRef is just an idea at this point, but this will provide a means to define the root location of the service. Once the interface is injected, it reads the @UriTemplate annotations to access the resource.

I’m starting to think this could be a pretty cool thing to have in the spec, or at the very least in RESTEasy 1.0.

I’ve found myself enjoying working with Adobe Flex. Flex does a lot of things really well, except its support of the HTTP protocol. Here’s a few things folks don’t know about the Flash Players HTTP support:

• It only support GET and POST methods. In order to use other methods such as DELETE and PUT, you have to the proxy service in Live Cycle Data Services. Lame!
• The Flash Player can’t read entity responses if a service returns a response code higher than 200. The LDS proxy gets around this limitation by forcing the response to a 200 status and returning the fault entity. Without LDS, there’s no way to get the response entity. Still lame.
• You are extremely limited to the number of header values you can set. The following header values cannot be used by the URLRequestHeader class: Accept-Charset, Accept-Encoding, Accept-Ranges, Age, Allow, Allowed, Connection, Content-Length, Content-Location, Content-Range, Date, Delete, ETag, Expect, Get, Host, Keep-Alive, Last-Modified, Location, Max-Forwards, Options, Post, Proxy-Authenticate, Proxy-Authorization, Public, Put, Range, Referer, Retry-After, Server, TE, Trace, Trailer, Transfer-Encoding, Upgrade, URI, User-Agent, Vary, Via, Warning, WWW-Authenticate, x-flash-version.

These features are extremely limiting for an RIA platform. It’s not always easy to try an sell RIA solution that is based on a platform crippled by limited networking support. I sincerely hope that future incarnations can get around these issues by providing a real HTTP implementation.

Lately I’ve been trying to figure some figure out some new ways to define declarative security constraints to web resources. Here’s the a use case that popped into my head a while back: suppose you have a service to access a persons information on a social networking site such as:

http://mysocialnetwork.foo/people/12345

This service offers two levels of membership: free and paid subscriptions. The free model only allows the caller to access a limited subset of information about user 12345, but a paid subscriber would have access to the complete record. So same URI, but a different resource depending on the authorization credentials of the caller.

Declarative security in the servlet API only allows you apply constraints to a single URI. So with the servelt API, you’d have to create to separate URIs in order to separate the functionality for free and paid users. By creating multiple URIs for different service tiers, the user would have to change the the URIs in their calling code if they upgraded from a free to paid subscriber.

To get around this, I’m thinking that a web resource could leverage the security annotations from JSR-250 so that you could write a PersonResource like so:

@UriTemplate("/people")
class PeopleResource {

   @UriTemplate("{id}")
   @RolesAllowed({"paidSubscriber"})
   @SecureTransport
   PersonResource getPaidPersonResource (@UriParam("id) String id) {
     return PaidPersonResource(id);
   }

   @UriTemplate("{id}")
   @RolesAllowed({"basic"})
   PersonResource getCheapSkatePersonResource( UriParam("id) String id) {
     return CheapSkatePersonResource (id);
   }
}

In this instance, the framework would invoke the method that the user is authorized for. If the user was a paid subscriber, they’d invoke the resource method that returns a PaidPersonResource. Additionally, because the PaidPersonResource may contain sensitive information, it must be accessed over SSL. The @SecureTransport annotation will redirect the caller to the same URI, but using a secure port.

Of course, if declarative security isn’t you cup of tea, then you can alway manage it yourself:

@UriTemplate("/people")
class PeopleResource {

   @HttpContext SecurityContext securityContext;

   @UriTemplate("{id}")
   PersonResource getPerson(@UriParam("id) String id) {
     if (securityContext.isUserInRole("paidSubscriber")) {
       if(securityContext.isTransportSecure()) {
          return PaidPersonResource(id);
       }else {
          //-- Handle your else condition
       }

     } else {
       return FreePersonResource(id);
     }
   }
}

Since JSR-311 is not exclusive to a servlet container, the SecurityContext would be a generalized injectable interface that provides access to security related information. This would make access to security details consistent across implementations regardless of whether or not you’re using a servlet container or not.

Please keep in mind that this is just an idea that I’m throwing around and it’s nothing official yet.

It’s been a while since my last post and even longer since I blogged about RESTEasy. Or better yet, since I committed a change to the RESTEasy code base. This might have lead some to believe that RESTEasy has been abandoned and will cease to exist. Since I have been getting inquiries from friends as to what is going on with RESTEasy, I figured I should probably make a post about. So while the project is not being abandoned, the core API is definitely being rethought.

I have been doing some work on JSR-311 which is a JSR that will help formalize how to create a RESTful web service in Java. The ideas in RESTEasy and JSR-311 were similar, but the implementations are completely different. With that said, it didn’t make much sense to proceed down the path I was going and so I had decided to temporarily suspend development on RESTEasy until JSR-311 is closer to finalization.

I’ll be posting a few more ideas over the next few months, but development of RESTEasy probably won’t pick up again until late November-ish. So not dead, just on hold for a few.

A lot of people have been giving a lot of oooh’s and aaah’s to Microsofts still beta/alpha Silverlight’s HD video features. While HD video in Silverlight is cool and all, it was only a matter of time before Adobe offered up their HD offering. According to News.com, an upcoming Flash player update code named “Moviestar” will bring high-definition video along with H.264 compression as well as HE-AAC version 2 audio.

The new Flash player will offer hardware-accelerated, full-screen video playback. Additionally, it wouldn’t be much of a stretch for Adobe to take advantage of the hardware-based H.264 decoder in the iPhone. If that’s the case, then one could argue that this is the Flash update that Apple will include in the next iPhone update.

This update is important to Adobe in their effort against Silverlight. Unlike Silverlight which only supports Windows Media specific codecs, Adobe have chosen an industry standard approach. And to date, Adobe’s cross-platform track record has been extremely good when compared to MS. Granted, Linux support still needs a little more work, but Flash 9 has been leaps and bounds better than before. So now with HD video and industry standard compression, what makes Silverlight anymore compelling than Flash?

After parking my car in the garage this morning, I walked down stairs to the train platform to see it full of people waiting for a train that wasn’t there. It was now 8:26 and the 8:25 was no where in sight. Annoyed as why the train wasn’t here, I pulled out my Q to see if Internet Exploder Mobile could render the Massachusetts Bay Transportation Authority’s web site so I could check the service alerts.

Much to my amazement and delight, the MBTA now offers a mobile version (at the same URL) which is very usable on a mobile device. In addition to that, they’ve organized the content in such a way that it’s more useful for a mobile user. For example, The first item on the home page is “service alerts.” Minor, yes, but extremely useful. The content is nicely organized and easy to navigate on a mobile device.

The only complaint I have so far is that I can’t personalize it like I can the main site. Having MyMBTA available on the mobile home page would be even more useful. At any rate, it nice to see increased fares actually doing something useful. Now if only they’d put WiFi on the commuter rails.