Now it is 2017 and [[I]] needed [[REST]] again. My obvious choice was [[Jersey]]. This time [[I]] started with version 2.3 and my [[JerseyInjection|experience]] is much better. Thus read the rest of this page as a view of a poor user who had to survive [[Big Band]] upgrade from version 1.x to 2.x once, but otherwise is [[JerseyInjection|relatively happy]] [[Jersey]] user.

Now it is 2017 and [[I]] needed [[REST]] again. My obvious choice was [[Jersey]]. This time [[I]] started with version 2.3 and my [[JerseyInjection|experience]] is much better. Thus read the rest of this page as a view of a poor user who had to survive [[Big Bang]] upgrade from version 1.x to 2.x once, but otherwise is [[JerseyInjection|relatively happy]] [[Jersey]] user.

== [[REST]] is Cool! ==

== [[REST]] is Cool! ==

[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 [[REST]]ful [[wikipedia::Web service|Web service]]s. I was impressed by the framework and decided to build my project on it in 2009. Now it is 2012 and time has come to ask whether it was a [[good]] choice. Is [[Jersey]] a [[good technology]]?

[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 [[REST]]ful [[wikipedia::Web service|Web service]]s. I was impressed by the framework and decided to build my project on it in 2009. Now it is 2012 and time has come to ask whether it was a [[good]] choice. Is [[Jersey]] a [[good technology]]?

== [[REST]] is Cool! ==

== [[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 a base technology (not counting the fact that most of the team that develops it sits one floor above my office).

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 a base technology (not counting the fact that most of the team that develops it sits one floor above my office).

== No web.xml ==

== No web.xml ==

== Suggestions? ==

== Suggestions? ==

<comments/>

<comments/>

[[Category:APIDesignPatterns:Anti]]

[[Category:APIDesignPatterns:Anti]]

== [[Big Bang]] ==

== [[Big Bang]] ==

Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want to reuse libraries that lower ''total cost of ownership''. I am too old to rewrite my code again and again every few years.

Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want to reuse libraries that lower ''total cost of ownership''. I am too old to rewrite my code again and again every few years.

Breaking all the tests is even worse. It is a clear message: start from scratch! And now tell me, why should I (when starting from scratch) trust such project once again? I've already learned my lesson by betting on [[good|dead horse]]. I know the project does not care about ''total cost of ownership'' of its users.

Breaking all the tests is even worse. It is a clear message: start from scratch! And now tell me, why should I (when starting from scratch) trust such project once again? I've already learned my lesson by betting on [[good|dead horse]]. I know the project does not care about ''total cost of ownership'' of its users.

Is not it the right time to switch to competition?

If [[Jersey]] '''2.0 final''' continues the trend, is not it the right time to switch to competition?

== Suggestions? ==

== Suggestions? ==

== Upgrade to 2.0 ==

== Upgrade to 2.0 ==

I was patient and my time has come. [[Jersey]] 2.0m3 was announced with support for '''@Suspend''' and it was the time to make the switch! But that has been the beginning of the nightmare! Since then it is hard to say anything [[good]] about [[Jersey]]. As the library user I feel disappointed and betrayed.

I was patient and my time has come. [[Jersey]] 2.0m3 was announced with support for '''@Suspend''' and it was

the time to make the switch!

 

I understand that '''m3''' is just a milestone and things can be improved before final '''2.0''' release is out. As such following critique may be premature. Should however the upgrading experience stay the same in '''final 2.0''', following is what I'd have to say:

 

After trying to migrate from ''1.6'' version to ''2.0m3'' it is hard to say much [[good]] about [[Jersey]]. As the library user I feel disappointed and betrayed.

=== The Code ===

=== The Code ===

== [[Big Bang]] ==

== [[Big Bang]] ==

Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want to reuse libraries that lower ''total cost of ownership''.

Looks like some people really believe that [[Big Bang]] is natural part of software developement. Well, I don't. I want to reuse libraries that lower ''total cost of ownership''. I am too old to rewrite my code again and again every few years.

Asking me to fix imports just because the team has joined another organization or to fix code because some concept ''polished and improved'' is only punishing me for trusting the project at all.

Asking me to fix imports just because the team has joined another organization or to fix code because some concept ''polished and improved'' is only punishing me for trusting the project at all.

Methods are returning different parameters (like ''configure()'') and it is not easy to find a replacement. Some methods don't even exists (for example ''resource()'') and the original return type is not even in the [[API]]! As a result my tests are full of errors and I don't have a slightest idea how to fix them.

Methods are returning different parameters (like ''configure()'') and it is not easy to find a replacement. Some methods don't even exists (for example ''resource()'') and the original return type is not even in the [[API]]! As a result my tests are full of errors and I don't have a slightest idea how to fix them.

In many projects tests are the glue that holds the whole project together. They contain the knowledge what the project should do. I no longer have it, as during last two years I was doing something else (yes, I am [[clueless]]), but that is the primary reason I write tests: to let them remember instead of me!

In many projects tests are the glue that holds the whole project together. They contain the knowledge what the project should do. Without them the project shakes like [[amoeba]]. I no longer remember what exactly the code should do, during last two years I was doing something else (moreover I admit, I am [[clueless]]), but that is the primary reason I write tests: to let them remember instead of me!

If you say that I have to rewrite all my tests before I can switch to [[Jersey]] 2.0, it is like suggesting me to start from scratch!

If you say that I have to rewrite all my tests before I can switch to [[Jersey]] 2.0, it is like suggesting me to start from scratch!

Methods are returning different parameters (like ''configure()'') and it is not easy to find a replacement. Some methods don't even exists (for example ''resource()'') and the original return type is not even in the [[API]]! As a result my tests are full of errors and I don't have a slightest idea how to fix them.

Methods are returning different parameters (like ''configure()'') and it is not easy to find a replacement. Some methods don't even exists (for example ''resource()'') and the original return type is not even in the [[API]]! As a result my tests are full of errors and I don't have a slightest idea how to fix them.

C'mon [[Jersey]] developers, in many projects tests are the glue that holds the whole project together. They contain the knowledge what the project should do. I no longer have it, as during last two years I was doing something else (yes, I am [[clueless]]), but that is the primary reason I write tests: to let them remember instead of me!

In many projects tests are the glue that holds the whole project together. They contain the knowledge what the project should do. I no longer have it, as during last two years I was doing something else (yes, I am [[clueless]]), but that is the primary reason I write tests: to let them remember instead of me!

If you say that I have to rewrite all my tests before I can switch to [[Jersey]] 2.0, it is like suggesting me to start from scratch!

If you say that I have to rewrite all my tests before I can switch to [[Jersey]] 2.0, it is like suggesting me to start from scratch!

</source>

</source>

I am not sure if this the right replacement (see below), but it is the simplest code I could find that promises to do the same as the original one. But the primary question remains: Why I need to change my code at all!?

I am not sure if the above is the right replacement (see next section), but it is the simplest code I could find that promises to do the same as the original one. But the primary question remains: Why I need to change my code at all!?

Some people believe that when doing [[Big Bang]] rewrite, it is better to do it as big as possible. Cleaning up names of classes and changing calling flow for sake of something. I can't find anyting [[good]] on such approach. It hurts ''total cost of ownership'' and clearly shows that the library authors don't care about users of previous version of their library.

Some people believe that when doing [[Big Bang]] rewrite, it is better to do it as big as possible. Cleaning up names of classes and changing calling flow for sake of something. I can't find anyting [[good]] on such approach. It hurts ''total cost of ownership'' and clearly shows that the library authors don't care about users of previous version of their library.