On Fri, Jan 31, 2020 at 11:36 AM Ron Karim (Oracle Corp.) <ron.ka...@gmail.com> wrote: > > 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.
This is a good example why it would be really good to get early feedback on release candidate versions: changes can still be made, and in some cases inclusion could be deferred -- although with inclusion of module-info, only by some amount. In this specific case, for example, if it was known there are actual problems, I might have considered that 2.10.0 would not yet include module-info just because the important security aspects of 2.10 are worth getting out. And module-info could have followed in 2.11 which is due out soon now. But since module-info is included and probably used by many already (for those running on JDK 11 and later it can be very useful in trimming down full deployables), it really can not be removed from 2.10 patch versions. The idea of using different "flavors" of Jars (with Maven... classifier? or was it qualifier?), this is something we have considered for certain things, but at the end of the day complexity in build system, for users and so on really is something that does not seem worth the hassle. Handling releases, development across 2 dozen different projects is heavy enough burden as is. So it is unlikely we'd go that route here or in general. And finally, use of multi-release jars would be likely to cause as many issues as it might solve (based on commentary I have seen), regarding pre-java9 platforms. I am not even sure if module-info could live under sub-directories. If module-info is completely unacceptable, Jackson versions up to 2.9.x will not include it, so that may still be an option. Security aspects wrt CVE notices (... but not really _security problems_ actually) can be tricky as we still need to file CVEs for all theoretical problems. But at the same time we will keep on releasing micro-patches addressing those: 2.9.x branch will live as long as necessary. I hope this further clarifies the situation, -+ Tatu +- > 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.) >> <ron....@gmail.com> 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.) >>>> <ron....@gmail.com> 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 jackso...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com. >>> >>> -- >>> 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 jackso...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com. > > -- > 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 jackson-user+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/094d430e-1c9f-47ed-8a18-5f3c13a31c48%40googlegroups.com. -- 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 jackson-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAL4a10gGCoFHWzDaibNAK_e-bq7R2oHa%3D-As8phT4wtS4s_vTg%40mail.gmail.com.
