I would only support the current version: 2.x. Gary
On Wed, May 15, 2013 at 2:00 PM, Nick Williams < nicho...@nicholaswilliams.net> wrote: > Guys, > > Background: Since I'm the lead developer on a Jackson Mapper module ( > https://github.com/FasterXML/jackson-datatype-jsr310), I'm actively > involved on their development mailing list. > > Jackson 1.9 is, well, old. Specifically, 1.9.0 is two years old. 1.9 is > the last minor version of the 1.x family. There will continue to be bug > fixe releases—for now—about every 4-6 months. The last patch release was in > January. > > Jackson 2.x is the current version with rapid release periods. 2.0 Is > about a year old, 2.1 was released in October and 2.2 was released last > month. Only major bugs will be fixed in 1.9.x. Minor bug fixes and all new > features will go in 2.x. > > Jackson 1.x and 2.x use different Java packages. This has both advantages > and disadvantages. One advantage is that frameworks and libraries, like > Spring Framework, can easily support both versions because they can coexist > on the same class path during compilation and testing. One disadvantage is > that if some library is using 1.x and some other library is using 2.x and > you create an application that depends on both libraries, you'll have to > pull BOTH versions of Jackson on to your class path. Ugh. > > Log4j 2 is "brand new" (it's not even released yet). Typically, I would > argue that new projects should not use old versions of their dependencies. > In Log4j 2's case, I tend to lean the same direction. It doesn't seem wise > to tie ourselves to Jackson 1.x so late in its life when Jackson 2.x is > already mature and Log4j 2 isn't even released yet. As a Java 8, Spring 4, > Jackson 2 user, I know I wouldn't love having to also have Jackson 1 on my > class path (if I were using JSON configuration). > > I would suggest that we should either support both or we should only > support 2.x, but only supporting 1.x feels wrong to me. > > Supporting both wouldn't be a major challenge. The way Spring does it is > to have two Jackson* classes and Jackson2* classes with identical APIs. > Depending on which version you are already using, you use the appropriate > class. In this case, I would approach it like this: > > - Rename JSONConfiguration to Jackson1JSONConfiguration, and (using > CheckStyle's import control) ensure that only this class imports Jackson 1.x > - Create a similar class named Jackson2JSONConfiguration, and ensure that > only this class imports Jackson 2.x > - Alter JSONConfigurationFactory to detect which version is on the class > path and return the appropriate JSON configuration, preferring 2.x if both > are on the class path > > Thoughts? > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
