Eclipse-based Applications Don’t Play Well With Mac OS X Leopard

This weekend I decided to give Leopard a shot and so far, so good. However, if you’re an Eclipse fan you will be disappointed. I should also add folks who use ANY Eclipse-based product including Flex Builder 3 Beta 2 and apparently Zend Neon as well, according to the commenter’s over at The Job of Flex blog. The long of the short is that anytime you try and use the Open Resource dialog and make your selection an hit “Ok”, Eclipse will crash.

Since Eclipse uses it’s own SWT, it’s hard to say if this is an Apple issue or an Eclipse issue. Seeing as how, Swing applications seem to be much more stable and perform better, I’m thinking this is an Eclipse bug. Even though Mac OS X is still a minority platform for the Eclipse group, it’s issues like this back up my prior assertion regarding SWT vs. Swing. But with all of that said, I have filed 2 bugs: one for the Eclipse IDE here and another for Flex Builder here. If you’re having the same issues I am experiencing, please vote for these bugs. In the meantime, I’m giving the latest Netbeans RC 2 a good hard look. So far, I’m very impressed with how it runs under Leopard.

Eclipse-based Applications Don’t Play Well With Mac OS X Leopard

URI vs. URL: What’s the Difference?

Updated (1/18/2011) : Because there’s still a lot of confusion, I’ve created a third post that attempts to resolve a lot of the questions from the comments on the last two posts. The new post is here.

Updated (8/27/2009): I’ve created another post that attempts to make the distinctions a bit more clear. The new post is here.

What is the difference between a URL and URI and why does it matter? This topic is confusing to some (myself included) and I thought I’d share my understanding of the two concepts. I’m hoping this post will give you a better understanding about how the two differ and why it matters to some.

Note: The goal of this post is to simplify the distinction between URI and URI. If you feel that in the summarization process something was lost, or it’s simply just correct, please post a comment and the information will be corrected. I only ask for any comments/criticism to be constructive.

Update: Thanks some constructive, and not-so constructive, feedback from some readers I have updated this post to correct many of my own misunderstandings. Of which, there were many.

URI

A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource. The fact that a URI can identify a resources by both name and location has lead to a lot of the confusion in my opionion. A URI has two specializations known as URL and URN.

URN

A URI identifies a resource by name in a given namespace but not define how the resource maybe obtained. This type of URI is called a URN. You may see URNs used in XML Schema documents to define a namespace, usually using a syntax such as:

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="urn:example"

Here the targetNamespace use a URN. It defines an identifier to the namespace, but it does not define a location.

URL

A URL is a specialization of URI that defines the network location of a specific resource. Unlike a URN, the URL defines how the resource can be obtained. We use URLs every day in the form of http://damnhandy.com, etc. But a URL doesn’t have to be an HTTP URL, it can be ftp://damnhandy.com, smb://damnhandy.com, etc.

The Difference Between Them

So what is the difference between URI and URL? It’s not as clear cut as I would like, but here’s my stab at it:

A URI is an identifier for some resource, but a URL gives you specific information as to obtain that resource. A URI is a URL and as one commenter pointed out, it is now considered incorrect to use URL when describing applications. Generally, if the URL describes both the location and name of a resource, the term to use is URI. Since this is generally the case most of us encounter everyday, URI is the correct term.

URI vs. URL: What’s the Difference?

Not enough is RESTful in RestFaces

I just came across a quick article on The Server Side about a JSF framework called RESTFaces. My initial reaction was “oh cool, a JSF framework that might adhere to RESTful principals.” Sadly, there isn’t much more than HTTP GET support that is “RESTful” about RESTFaces. RESTFaces touts itself as being a

RESTfaces for JavaServerâ„¢ Faces Technology make it possible to write bookmarkable pages using JavaServerâ„¢ Faces.

In a nut shell: RESTFaces allows you to invoke actions via HTTP GET as opposed to just POST actions. JBoss Seam has a similar feature and their docs describes it as a means of making RESTFul applications that can be bookmarked. To be fair, Seam does not claim to be a full-on REST framework. Now I am a huge fan of JBoss Seam, so I don’t mean to come off as pooh-poohing that effort. But I wonder, is just providing GET support enough enough to be considered RESTful? At a low level, probably yes. But there could be so much more.

This could all change as the specifications for JSF and Web Beans matures. JSR-311 is a thriving work in progress and JSR-314 is also still getting ramped up as well. As these spec mature, some nice integration points might be:

Support for URI templates.

JSR-311 is currently defining support for this, but if this were integrated into JSF URIs would not be just bookmarkable, but also human readable. For example, instead of:

http://somehost/blog/entry.action?id=1234

You could have something a bit cleaner

http://somehost/blog/entries/1234

Your entry ID is now a component of the URI, which makes it a lot easier on the eyes. If you ever have had to deal with marketing applications, you can appreciate the value of this.

Support for multiple representations via HTTP Content Negotiation

Again this is something that JSR-311 is defining, but if this is integrated into JSF, or Web Beans for that matter, it would allow a single URI to deliver different media types. Using the example above, the same URI:

http://somehost/blog/entries/1234

Could deliver the content as a PDF, or an HTML format that is more suitable for a mobile device and the decision is made by the framework. The user would not have to execute a specific URL for each type:

http://somehost/blog/entries/1234.html
http://somehost/blog/entries/1234.pdf
http://somehost/blog/entries/1234.wml

Or worse:

http://somehost/blog/entry.action?id=1234&type=application/pdf
http://somehost/blog/entry.action?id=1234&type=text/html

Through content negotiation, the user just needs the URI and the application will take care of delivering the proper response. If you’re looking for an example of a present day implementation, look no further than Apache HTTPD. JBoss Seam already supports a number of ways to generate other media types such as PDF, charts and graphs, and other, so I think they’re in a great position to deliver this kind of functionality. On the plus side, at least these two frameworks do allow one to use HTTP GET which is a big help.

Not enough is RESTful in RestFaces

Java 6 WILL NOT be Included in Mac OS X Leopard

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.

Java 6 WILL NOT be Included in Mac OS X Leopard

Some Mac OS X Leopard Java Details

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.

Some Mac OS X Leopard Java Details

No Mention of Java 6 on Leopard Features Page

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!

No Mention of Java 6 on Leopard Features Page

Goals for RESTEasy 1.0

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.

Goals for RESTEasy 1.0

Some thoughts on a JAX-RS client API

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.

Some thoughts on a JAX-RS client API