Jersey
From APIDesign
| Line 1: | Line 1: | ||
| - | [http://jersey.dev.java.net/ Jersey], a [[wikipedia::Reference implementation (computing)|reference implementation]] of JAX-RS ([[wikipedia::Java Community Process|JSR]] 311), intended for building [[wikipedia::Representational State Transfer|RESTful]] [[wikipedia::Web service|Web service]]s. I | + | [http://jersey.dev.java.net/ Jersey], a [[wikipedia::Reference implementation (computing)|reference implementation]] of JAX-RS ([[wikipedia::Java Community Process|JSR]] 311), intended for building [[wikipedia::Representational State Transfer|RESTful]] [[wikipedia::Web service|Web service]]s. I was impressed by the framework and decided to build my project on it. Time has however come to ask whether it was a [[good]] choice. Is [[Jersey]] [[good technology]]? |
| + | |||
| + | == [[REST]] is Cool! == | ||
| + | |||
| + | There are three parts that make a technology [[good]]. Coolness being one of them. [[REST]] has been cool for few years. [[JAX-RS]] is cool as its [[Java]] realization. [[Jersey]] is the reference implementation of [[JAX-RS]]. All of this makes it very easy to choose [[Jersey]] as your technology (not counting the fact that most of the team that develops it sits one from above my office). | ||
| + | |||
| + | == No web.xml == | ||
| + | |||
| + | The other part of [[good technology]] is ''time to market''. [[Jersey]] delivers acceptable results in this respect as well. As being long time [[Java]] SE guys, I especially like the fact that [[Jersey]] can run outside of any web container like [[Tomcat]] or [[Glassfish]]. I am afraid of ''web.xml'' and disgusted when I have to touch it. With [[Jersey]] I could get my server up and running without paying attentiong only to what was important to me - the methods annotated with '''@GET''' and '''@POST'''. | ||
| + | |||
| + | [[Jersey]] also comes with a special testing framework which makes the process of testing [[REST]] application relatively easy. This is [[good]] for time to market as well, as these days people want to ensure the [[amoeba]] shape of they application with bunch of tests before they release. | ||
| + | |||
| + | ''Time to market'' is [[good]] with [[Jersey]]. | ||
| + | |||
| + | == No Server Side Push == | ||
| + | |||
| + | In 2009 I could confirm that I like the [[Jersey]] framework a lot. There was just one thing I was missing. As I am using [[Jersey]] to implement a board like game server, I'd like to notify the clients about changes made to the board as soon as they happen. I needed server side push like [[wikipedia:http://en.wikipedia.org/wiki/Comet_(programming)|Comet] computation model. | ||
| + | |||
| + | == Upgrade to 2.0 == | ||
| + | |||
| + | For two years I've been chating with the [[Jersey]] guys and got promise they will implement it. I was patient and the time has come. [[Jersey]] 2.0m3 was announced and it was the time to make the switch! But that has been the beggining of the nightmare! | ||
| + | |||
| + | === The Code === | ||
| + | |||
| + | |||
I've just got a little bit of time to migrate my project from [[Jersey]] 1.1 to 2.0. It is not easy at all! It is painful. For last two years, I've been waiting for support for asynchronous [[wikipedia::Representational State Transfer|REST]] communication (as I am trying to write a chess-like server). I've been waiting, waiting. The result? Complete disappointment. I've just tried to run my old code on [[Jersey]] 2.0 (without trying any new features), but it does not even compile! | I've just got a little bit of time to migrate my project from [[Jersey]] 1.1 to 2.0. It is not easy at all! It is painful. For last two years, I've been waiting for support for asynchronous [[wikipedia::Representational State Transfer|REST]] communication (as I am trying to write a chess-like server). I've been waiting, waiting. The result? Complete disappointment. I've just tried to run my old code on [[Jersey]] 2.0 (without trying any new features), but it does not even compile! | ||
The guys that produce [[Jersey]] as sitting a floor up from my office, for two years I've been asking them for asynchronous support and waiting (instead of switching to alternative implementations of [[wikipedia::Java Community Process|JSR]] 311 - - as [[wikipedia::Java Community Process|JSR]] 311 is one of the specifications with most implementations). What I got for being a loyal user? I got a [[Big Bang]] rewrite. Imports changed, code changed, some classes are missing, concepts are different. Well, being treated this way, I have little intention to upgrade. Why should I spend time upgrading to [[Jersey]] 2.0, when it seems as much work as switch to XYZ (which had asynchronous support for ages)? | The guys that produce [[Jersey]] as sitting a floor up from my office, for two years I've been asking them for asynchronous support and waiting (instead of switching to alternative implementations of [[wikipedia::Java Community Process|JSR]] 311 - - as [[wikipedia::Java Community Process|JSR]] 311 is one of the specifications with most implementations). What I got for being a loyal user? I got a [[Big Bang]] rewrite. Imports changed, code changed, some classes are missing, concepts are different. Well, being treated this way, I have little intention to upgrade. Why should I spend time upgrading to [[Jersey]] 2.0, when it seems as much work as switch to XYZ (which had asynchronous support for ages)? | ||
| + | |||
| + | === The Test Framework === | ||
| + | |||
| + | |||
| + | == [[Big Bang]] == | ||
Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want the [[Jersey]] team to write a compatibility bridge to guarantee I can just change the [[Jersey]] version and everything will continue to work. I am afraid I am not going to get any support like that. In such case, farewell, as I bet on [[Good|bad horse]]. Projects that don't preserve investments of their users should be damned. | Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want the [[Jersey]] team to write a compatibility bridge to guarantee I can just change the [[Jersey]] version and everything will continue to work. I am afraid I am not going to get any support like that. In such case, farewell, as I bet on [[Good|bad horse]]. Projects that don't preserve investments of their users should be damned. | ||
| + | |||
| + | [[Category:APIDesignPatterns:Anti]] | ||
Revision as of 10:27, 22 April 2012
Jersey, a reference implementation of JAX-RS (JSR 311), intended for building RESTful Web services. I was impressed by the framework and decided to build my project on it. Time has however come to ask whether it was a good choice. Is Jersey good technology?
Contents |
REST is Cool!
There are three parts that make a technology good. Coolness being one of them. REST has been cool for few years. JAX-RS is cool as its Java realization. Jersey is the reference implementation of JAX-RS. All of this makes it very easy to choose Jersey as your technology (not counting the fact that most of the team that develops it sits one from above my office).
No web.xml
The other part of good technology is time to market. Jersey delivers acceptable results in this respect as well. As being long time Java SE guys, I especially like the fact that Jersey can run outside of any web container like Tomcat or Glassfish. I am afraid of web.xml and disgusted when I have to touch it. With Jersey I could get my server up and running without paying attentiong only to what was important to me - the methods annotated with @GET and @POST.
Jersey also comes with a special testing framework which makes the process of testing REST application relatively easy. This is good for time to market as well, as these days people want to ensure the amoeba shape of they application with bunch of tests before they release.
Time to market is good with Jersey.
No Server Side Push
In 2009 I could confirm that I like the Jersey framework a lot. There was just one thing I was missing. As I am using Jersey to implement a board like game server, I'd like to notify the clients about changes made to the board as soon as they happen. I needed server side push like [[wikipedia:http://en.wikipedia.org/wiki/Comet_(programming)|Comet] computation model.
Upgrade to 2.0
For two years I've been chating with the Jersey guys and got promise they will implement it. I was patient and the time has come. Jersey 2.0m3 was announced and it was the time to make the switch! But that has been the beggining of the nightmare!
The Code
I've just got a little bit of time to migrate my project from Jersey 1.1 to 2.0. It is not easy at all! It is painful. For last two years, I've been waiting for support for asynchronous REST communication (as I am trying to write a chess-like server). I've been waiting, waiting. The result? Complete disappointment. I've just tried to run my old code on Jersey 2.0 (without trying any new features), but it does not even compile!
The guys that produce Jersey as sitting a floor up from my office, for two years I've been asking them for asynchronous support and waiting (instead of switching to alternative implementations of JSR 311 - - as JSR 311 is one of the specifications with most implementations). What I got for being a loyal user? I got a Big Bang rewrite. Imports changed, code changed, some classes are missing, concepts are different. Well, being treated this way, I have little intention to upgrade. Why should I spend time upgrading to Jersey 2.0, when it seems as much work as switch to XYZ (which had asynchronous support for ages)?
The Test Framework
Big Bang
Looks like some people really believe that Big Bang is natural part of software developement. Well, I don't. I want the Jersey team to write a compatibility bridge to guarantee I can just change the Jersey version and everything will continue to work. I am afraid I am not going to get any support like that. In such case, farewell, as I bet on bad horse. Projects that don't preserve investments of their users should be damned.
Follow
