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
