was planning to give it a try in ~3 weeks (travelling soon so will not have a lot of hack time) and then try to get xbeam-asm-6 out. Issue today is we dont support any lib using mjar releases - even on a java 8 VM - including log4j since we scan all .class and sometimes it contains java 9 code we cant read.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-09-28 9:42 GMT+02:00 Mark Struberg <[email protected]>: > +1 but a bit short on time right now. > > Might be able to help in a few weeks. > > LieGrue, > strub > > > Am 27.09.2017 um 16:53 schrieb Romain Manni-Bucau <[email protected] > >: > > > > Hi guys, > > > > how do we want to handle multi release jars? > > > > concretely we need to: > > > > 1. check it is activated in the manifest.mf > > 2. if 1 is "true" then check META-INF/versions/<x>/<fqn>.class exists > and read it instead of <fqn>.class > > > > This logic is not hard by itself but has some implication in term of > perf since for *each* class we can end up doing this validation. > > > > Do we want to do it the other way? read it all, put the > META-INF/versions/<current> in another bucket and merge it after. My > assumption is META-INF/versions/* will be way smaller than the opposite so > we would just go through the archive once avoiding all the double checks > and just have an iteration over a small set of classes during the merge > phase at the end. > > > > wdyt? > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > >
