RESTEasy 1.0 Beta 5 Released

1 Comment

Customer bug fixes and new features in this release. We’ve implemented some JSON support after some users requested this feature. Using the Jettison Framework, you can use JAXB annotated classes and marshal them to and from JSON. A pretty cool framework and easily integrated into RESTEasy JAX-RS. The RESTEasy JAX-RS documentation has also been updated to reflect changes and functionality updates.

Please see our main project page to learn how to download, post questions, etc.

Release Notes – Resteasy – Version Beta 5

Bug

  • [RESTEASY-47] – Autoscan thinks a Subresource is a root resource, result is error
  • [RESTEASY-50] – Client framework throws exception if anything other than OK is returned as a response code
  • [RESTEASY-53] – DELETE/POST with no entity returns 200 should return 204 (NO_CONTENT)

Feature Request

  • [RESTEASY-52] – JSON/JAXB and raw JSON @Provider support
  • [RESTEASY-54] – ClientResponse object for ClientFramework
  • [RESTEASY-55] – Allow return of Response.Status in client proxy framework
  • [RESTEASY-56] – Allow turning off of default built-in @Provider classes

Task

  • [RESTEASY-49] – Support ExceptionHandlers
  • [RESTEASY-57] – resteasy.providers should not turn off builtin

Speaking Thursday, June 12th NEJUG: REST and JAX-RS

Leave a comment

I’ll be speaking this Thursday, June 12th at the Boston area JUG (NEJUG) at the Sun campus in Burlington at 6:00 pm. My talk will be on on REST and how the new JAX-RS specification makes it easier for you to write RESTFul Web Services in Java. Please stop by, at least to say hi. Hecklers welcome too!

JAX-RS passes public review ballot unanimously

Leave a comment

I guess nobody has a problem with JAX-RS on the JCP EC.  Sweet!  🙂  It really is a good spec.  Kudos to Marc Hadley for putting together such a good spec and managing the JSR so professionally.

Resteasy JAX-RS Beta 4 Released

1 Comment

I’m trying to release much earlier and more often. This release brings RESTEasy JAX-RS up to the current public draft of JAX-RS, JSR-311, minus a few methods that are being debated upon within specification. I didn’t want to implement something where the behavior is going to change. The RESTEasy JAX-RS documentation has also been updated to reflect changes and functionality updates.

Please see our main project page to learn how to download, post questions, etc.

Release Notes – Resteasy – Version Beta4

Bug

  • [RESTEASY-28] – if a class or super class is annotated, then ignore any interface’s annotations
  • [RESTEASY-34] – Locator method and resource method with same URI does not dispatch
  • [RESTEASY-45] – You should be able to use multiple path params per uri segment
  • [RESTEASY-46] – Subresource class annotated via its interface does not work

Task

  • [RESTEASY-3] – Implement UriInfo.getAncestorResources and UriInfo.getAncestorResourcesURIs
  • [RESTEASY-7] – Implement MessageBodyWorkers
  • [RESTEASY-21] – Support for @Path.encoded
  • [RESTEASY-22] – CacheControl marshalling/delegate
  • [RESTEASY-30] – Implement encoding in UriBuilder
  • [RESTEASY-32] – Implement @Encoded support
  • [RESTEASY-35] – Support for javax.security annotations
  • [RESTEASY-37] – Update API to Public Draft
  • [RESTEASY-38] – Implement UriBuilder.extension()
  • [RESTEASY-41] – Implement Httpheaders.getAcceptableLanguages() and getRequestHeader()
  • [RESTEASY-42] – Support for MediaType and Language file suffix extension mappings
  • [RESTEASY-43] – Test servlet init-param parsing of map extensions
  • [RESTEASY-44] – Support for ApplicationConfig

Resteasy JAX-RS Beta 3 Released

1 Comment

This is the thrid release of JBoss’s JSR-311, JAX-RS, Restful Web Services implementation. Nothing special in this release, just a lot of bug fixes the community found as well as more spec-feature complete. We have some more things coming down the pipe in the next month, so stay tuned!

Links to where to download, post user questions, and our documentation are all available on our WIKI.

Release Notes – Resteasy – Version Beta3

Bug

  • [RESTEASY-25] – mime property types ignored when matching resource methods to requests
  • [RESTEASY-26] – MessageBodyWriter matching should use the entity class, not the method’s reflected return type.
  • [RESTEASY-27] – Resource Locators should be dynamically processed

Task

  • [RESTEASY-6] – Implement all methods with decode parameter within UriInfo
  • [RESTEASY-20] – Suport for @Path.limited

Resteasy JAX-RS 1.0 Beta 2 Released!

2 Comments

I finally got around to creating a new release for the next rev of our JAX-RS, Java RESTful Web Services, implementation. This release targets the 0.7 release of the JAX-RS specification. There’s a still a few features I haven’t implemented yet, but hope to get them out soon as the spec starts to solidify. Especially new in this release is a new embeddable container so you can run things within junit tests, or just serve up a small restful web service from your classpath. We’ve been using this embeddable container to unit test our implementation and finally made it available to the masses.

Check out our project page or download the new release.

Release Notes – Resteasy – Version Beta2

Bug

  • [RESTEASY-1] – DefaultPlainText.MessageBodyWriter should not write anything (arrays especially)
  • [RESTEASY-2] – If Response has set Content-Type, then that content type should be used
  • [RESTEASY-9] – Subresources erroneously considered as root resources
  • [RESTEASY-17] – Spec mandates supporting MultivaluedMap for form-urlencoded media types
  • [RESTEASY-18] – @QueryParam should not return x-www-form-urlencoded parameters
  • [RESTEASY-24] – WebApplicationException and http status codes

Feature Request

Task

  • [RESTEASY-4] – Implement variants
  • [RESTEASY-13] – Support @Context field injection
  • [RESTEASY-14] – Support @Context injeciton of HttpServletRequest/Response
  • [RESTEASY-16] – Support injection of javax.ws.rs.core.SecurityContext
  • [RESTEASY-19] – Support for StreamingOutput
  • [RESTEASY-23] – Integration test for SecurityContext

Reliable concurrent initialization

Leave a comment

I recently ran into the situation where I wanted to do lazy, on-demand, initialization of a registry. In previous applications, I would just use get()/put() from java.util.ConcurrentHashMap because I didn’t care if something was created more than once accidentally as it would eventually, and quickly, sort itself out and all I’d lose is a tiny garbage collection. Unfortunately, in my current project, a registry entry cannot be allocated twice as two different versions of it might be used concurrently and each registry entry holds and maintains state. These resources need to be individually unique. Thankfully, java.util.ConcurrentHashMap has a nice method called putIfAbsent(). This method does the atomic equivalent of:

if (!map.containsKey(key)) {
   return map.put(key, value);
} else {
   return map.get(key);
}

So, what I can do is do a mini double check. When I lookup at entry, if it doesn’t exist, allocate a temporty version of it and call putIfAbsent.

public V get(K key) {
   V value = concurrentMap.get(key);
   if (value != null) return value;

   value = new Value(...);
   V tmp = concurrentMap.putIfAbsent(value);
   if (tmp == null) {
      return value;
   } else {
      value.cleanup();
      return tmp;
   }
}

If putIfAbsent returns null, then I know nobody has created a version concurrently.  If it doesn’t return null, then I know somebody has initialized this entry concurrently.  In that case, I cleanup the created value, and return the one already in the registry.  This looks a lot like the double-check-nono, but it actually isn’t as ConcurrentHashMap performs the putIfAbsent atomically.

Resteasy Project: JAX-RS Restful Web Services implementation

12 Comments

I’m pleased to announce the first beta release of the JBoss Resteasy JAX-RS implementation!

After about 4 months of on and off development, I finally have a working version of the new JSR-311, JAX-RS specification. For those of you who don’t know, JSR-311 is a RESTFul Web Services implementation for Java and is slated to be included within Java EE 6. The spec is still a bit of a moving target, but its still pretty useful. Let me know what you think!

Features:

  • JAX-RS implementation (almost full, still have a few minor things here and there)
  • Portable to any app-server/Tomcat that runs on JDK 5 or higher
  • EJB 3.0 and Spring integration
  • Client framework to make writing HTTP clients easy (JAX-RS only define server bindings)

Where can I find out more?

All information, including where to download it, is available on our Resteasy WIKI.

Anti-IDE Myths

10 Comments

Well, if you were wondering who my evangelist colleague was in my “Dynamic Languages: Rationalizations and Myths” blog, wonder no more. Please go read Steve Vinoski’s comments, they are a good read. One of my major points against dynamic languages was the inability for an IDE to provide reliable refactoring for them. Steve attacked this with a considerable amount of drivel. Here’s some good blurbs:

“The contrived Ruby example that Bill uses to “prove” [that dynamic languages can’t do reliable refactoring] is, well, contrived. Why would anyone write code like that or suddenly get the urge to rename init to init2? I’m no Ruby expert, but I’d probably rename the method and then stick a method_missing in there to catch any call instances I might have missed with my editor. “

Contrived my ass…Like I said in my previous blog. I write sucky code. I am constantly renaming methods, extracting methods, combining methods, renaming classes, deleting unneeded methods, fields, classes all the time. I never get things right the 1st time and rarely get them right the nth time. Steve, 99% of us are not the uber programmer you are. And, what Steve? Am I going to have to do a constant edit/test/edit/test continuously until I get my edits right? Sounds a lot less productive than having the IDE automatically and reliably do it for you with one click. Again Steve, I used to be in your world. Not as long as you, but still a considerable amount of time.

“I asked him if these magical modern IDEs that raise productivity and eliminate common errors also eliminate defects caused by missing or misunderstood requirements, missed use cases, or just plain ol’ bad programming. Again, no answer. The reason I asked this is that those are the bad bugs; syntactical errors are really the least of your worries. Even if the IDE spits out common idiom/pattern skeletons for you, it’s still quite possible to screw up the code logic, and neither the IDE nor the compiler is going to prevent that.”

Nice strawman Steve. When did I ever say or infer this? How is implementing in a dynamic language going to “eliminate defects caused by missing or misunderstood requirements”? It sure is going to be a hell of a lot easier to refactor your codebase to fix these problems, but eliminate? So Steve, are what you really saying is “IDE’s are not going to eliminate your bugs or poor design”? Thanks for stating the obvious. What I keep telling you is that I’m going to be 10 times more productive with a statically typed IDE when I try to fix these poor designs and logic.

“Considering how old Java is, it’s obvious that it’s taken quite a bit of time to get these IDEs to where they are today. I asked Bill if everyone should have to wait a long time, on the order of 10-15 years, before an IDE truly becomes valuable for a given language. No answer. Personally, I’d rather stick to my emacs and UNIX tools, with their infinite applicability and flexibility that can be used for development in pretty much any language, than wait around for someone else to give me a far less functional IDE that barely addresses only one language. But then again, if one language is all you got, then I guess you have no choice.”

Reality: One, I don’t remember him asking me this. Two, I think that IDEs (at least Intellij) are so well designed now that they can easily support a variety of languages fairly quickly. Add to this fact that their APIs are open (not OSS, but open) and have a great community. For instance, on a quick search I found plugins for Ruby, Python, AspectJ, XML, XML Schema, and Scala. The interesting thing about Intellij, is that it also has support for frameworks. For example, it has syntax checking and code completion for embedded Hibernate/JPA QL. Refactoring integration between Spring, JavaEE and Java. I haven’t looked at their RoR support, but I bet it is awesome. I continually find it AMAZING how these guys bang things out. They are either an army of people (doubtful) or just have an incredibly architected product (probable).

“I asked Bill if he’s ever considered that Java IDEs are the way they are due to issues with the Java language itself that must be compensated for. Consider its verbosity, for example, which is why IDEs spit out those skeletons.”

Reality: Let me go through the list of Code Gen and Refactoring items and see what is not useful in, let’s say, Ruby. There are 30 refactorings in IntelliJ + Java. Only 8 out of 30 are NOT useful to Ruby. For the “Generate..” code generation tab. 2 out of 5 are not useful for Ruby. I think the “Surround With..” tab is useful. The thing is, out of these 35 things, I *DO* use one of them *at least* every 10 minutes. This is of course assuming you believe that the unuseful things are because Ruby is a better language (I don’t beyond the closure stuff). I will admit that only 5 of the refactorings require a statically typed language to be *reliable*, but, at least for me, I do use these particular ones very very often, especially after the first prototype. (rename, move, safe delete, change method signature, inline). At least with Intellij, parameter types are also extremely useful with code completion. Good code is self documenting and with IDE code completion, I don’t have to look at a manual or source code comments to find out how to execute a method on an object. BTW Steve, what “skeletons” are you talking about? MDA bullshit? Or the crap I rarely use?

“Saying that “my buddy Jason was on a team that had to put type names in their Python function names” is certainly not even close to being solid evidence of your claim, Bill.”

Steve, I think Jason’s experience was a relevant experience.  I wrote about it because  I thought Jason’s experience was the funniest story I’ve heard. It sure isn’t the only horror story people have had with lack of static typing.

Other dynamic language propaganda

4 Comments

One of the commenters of my last blog reminded me of yet another myth:

If you learned to code in the XXX dynamic language way you’d need to rely a lot less on your IDE.

And Joe Johnson wasn’t the first to say that to me.  🙂  Another tactic I can’t stand with the zealots in the dynamic language community (and any other religious communities I might add.)  Attack your criticizer’s insecurities.  This comment translates to, “Java has made you a sucky programmer, if you program in Ruby, you will no longer be a sucky programmer” Or, simply:  “Ruby will make you an UBER programmer”  or, even simpler “You are a sinner, you must be saved”.  This is an awesome way to promote your language.  Why?  Well, because most of us programmers are geeks.  We were laughed at in school for wanting to spend our free time copying game code from magazines.  Even beat up.  So, we are inherently insecure and eager to be accepted by any crowd.

The problem with this argument is, for me personally, what happens when I switch to Ruby and miss the productivity I had with my Java IDE?  Does this mean I’m a horrible programmer and still a loser?  You readers know how insecure I am.  So, I just can’t switch to Ruby.  When I fail at becoming the uber programmer I always wanted to be after switching to Ruby, my insecurities and closet-Rod-Johnson-loving, fragile ego will just shatter me and I will end up  crying myself to sleep every night.  Sorry no thanks.  I already had enough heartache watching the biggest choke in NFL history yesterday.  I can’t take anymore.  The reality is that I know I am a horrible programmer and switching to Ruby won’t change that fact.  At least if I stay with Java, others will have the tools to productively clean up the messes I leave behind.

Ruby jobs have grown 500%!

Many are still scared by the dot.com bubble burst.  Many were laid off at least once.  So, its only natural to prey on these types of insecurities as well.  The reality is, if you read the fine print, Ruby is still only a tiny percentage of the Java market.  Even if it continues at this growth rate it will be at least 3 years before it overtakes Java.  Which is fine for me as, about that time, I have to start looking for another job as, obviously, SpringSource will have put JBoss out of business by then.  I’m fine with that.  3 years is enough time for me to collect the rest of my stock and get my wife back to work to take care of my ultimately unemployed ass.

The non-programmers of the world need a simple language to code in

Beautiful!  You mean my 94 year old grandma can help me code?  The problem with this is that this leaves a huge mess to clean up after the fact.  That’s great for the $100-200/hour consultant out there cuz they can bill thousands of hours.  Sucks for the company paying the bills.

Older Entries Newer Entries