Our organization needs to use these jars "as-is", due to legal obligations (modifying or rebuilding them at our site may extend the liability or support of these external libraries to customers, etc..among others). The overall system that deal with Java dictates that libraries use packages explicitly with no duplicate classes. Since it never was an issue, make files and other build systems simply spit these jars out as "non-standard and inadmissible". Even if we modify one area of the build, down the line, some other build system or a patch-application system utilizing this component will break. Although, not every product uses it, the Build and release in this environment deals with 243 Enterprise-capacity software systems all part of a single Suite of Products (in Java). But, that is the only option we have at this time with these Jackson Jars and have started looking into that route. That just delays our uptake of these external libraries. Appreciate all the suggestions.
On Wednesday, January 29, 2020 at 2:11:39 PM UTC-8, Tatu Saloranta wrote: > > On Wed, Jan 29, 2020 at 10:45 AM Ron Karim (Oracle Corp.) < > [email protected] <javascript:>> wrote: > >> Thanks for the quick response. For a large enterprise organization like >> ours, modifying central builds and making changes to them require all sorts >> of complexities, which we may have to bite the bullet and do. But the fact >> that we are getting security issues every few months is getting a lot of >> attention from our release areas as well. >> >> Since we need this particular set of jars (jackson_databin, jackson_core, >> jackson_annotations) for a JDK 7 Runtime environment (all components in >> this massive behemoth are still using JDK 7 and will be for quite >> sometime), couple of questions as we prepare a case for uptake of jackson >> 2.10.2 : >> >> - What version of the JDK are used to build these jars, (*if a JDK 9 >> compiler is used, then we won't be able to use them in a JDK 7 runtime >> environment, correct *?) >> > > JDK 8 used, since at this point it this almost impossible to publish > anything to Sonatype OSS repository with JDK 7 or earlier (I do not > remember exact timeline when this changed; I used JDK 7 for releases until > that point -- but I think this was in late 2018 or so). > > JDK 9 or later will not be used for building Jackson 2.x. > (getting JDK 7 itself is getting challenging, and CI systems like Travis > seem to have dropped supported too) > > Maven builds specify Java source and target versions of 1.7 (for JDK 7), > with exception of `jackson-annotations` and `jackson-core` that have target > of 1.6 (for JDK 6). So resulting bytecode should still be compatible with > earlier JVMs. > > module-info.class is included starting with Jackson 2.10. > > >> - If these libraries were tested for a Java 7 runtime, how did you build >> those particular libraries that were tested for the JDK 7 runtime ? >> > > No full or automated testing is done on JDK 7 any more. Effort is made to > avoid using any JDK classes or methods past JDK 7, but this is not very > robust as JDK 8 needs to be used for build process itself. > > We rely on user community to report issues with JDK 7 (or, for > streaming/jackson-core, for JDK 6), not having resources to do testing with > it. > > >> >> Thanks for all the advice and guidance. >> >> > I hope this helps. > > -+ Tatu +- > > >> >> On Tuesday, January 28, 2020 at 8:18:01 PM UTC-8, Tatu Saloranta wrote: >>> >>> On Tue, Jan 28, 2020 at 2:39 PM Ron Karim (Oracle Corp.) < >>> [email protected]> wrote: >>> >>>> Thanks for the quick response, the module_info.class is stored in a >>>> common location when we create a patch for cutomers with all 3 jars in the >>>> same "jackson-updated-security patch", here is an example error from our >>>> system: >>>> >>>> ERROR: Different size module-info.class duplicated in archives: >>>> fnd/java/3rdparty/stdalone/jackson_annotations.zip (120.0.12020000.7), >>>> fnd/java/3rdparty/stdalone/jackson_databind.zip (120.0.12020000.7), >>>> fnd/java/3rdparty/stdalone/jackson_core.zip (120.0.12020000.7) >>>> java/3rdparty/stdalone/jackson_core.zip >>>> >>>> One option that we re thinking is maybe create 3 separate patches, but >>>> that will cause an error when the patches are applied in the same customer >>>> location. >>>> >>> >>> That sounds like something where filtering out of these class >>> descriptors would probably make sense. There are other artifacts that I >>> have heard can cause issues with packaging -- META-INF/LICENSE, for >>> example, is exists in all jars. >>> I am guessing that tools in question predate Java 9, but there hopefully >>> is some setting to specify file(s) to ignore? >>> >>> Otherwise, pre-processing jars to drop module-info.class would serve the >>> same purpose. >>> This class obviously has no value on Java 7/8 platform. >>> >>> -+ Tatu +- >>> >>> >>>> >>>> >>>> >>>> On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle >>>> Corp.) wrote: >>>>> >>>>> As we are upgrading jackson modules to version 2.10.2, we are using >>>>> jackson_core, jackson_databind and jackson_annotations (all versions >>>>> 2.10.2), >>>>> Each of these jars have a module_info.class that seems to be different >>>>> in each jar. Hence we cannot use these 3 jars in our systems. >>>>> >>>>> Should we be using the same 2.10.2 version for jackson_core and ja >>>>> kson_annotations too ? Along with the jackson_databind 2.10.2 ? >>>>> >>>>> Or is there another resolution to dealiing with the module_info.class >>>>> in each of these jars ? >>>>> >>>>> Appreciate your help. >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "jackson-user" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "jackson-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/094d430e-1c9f-47ed-8a18-5f3c13a31c48%40googlegroups.com.
