[xbean] mjars handling

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[xbean] mjars handling

Romain Manni-Bucau
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 BlogGithub | LinkedIn | JavaEE Factory
Reply | Threaded
Open this post in threaded view
|

Re: [xbean] mjars handling

Mark Struberg
+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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [xbean] mjars handling

Romain Manni-Bucau
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 |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-09-28 9:42 GMT+02:00 Mark Struberg <[hidden email]>:
+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 <[hidden email]>:
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: [xbean] mjars handling

Romain Manni-Bucau
Hi guys,

pushed some work in this area, it is far to be perfect, here are the
small issues (but I think it is already a step forward):

- at the moment we will only handle mjar alternative classes if there
is a main class (without a version), we can need to add support for
"versioned only" classes - don't think it is used yet
- we rely on a classloader by design so it means in the archive we
have to assume the classloader handles mjar release or add a
parameter/flag for that we surely don't want. Since we cant really wap
the loader to make it supporting it since we would split scanning and
runtime (where we never see the classloader) I think it is "ok" even
if not perfect

I just added a test for jarfile and we need to cover way more this
code but wanted to let you know it is started :)


Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-09-28 9:50 GMT+02:00 Romain Manni-Bucau <[hidden email]>:

> 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 |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
> 2017-09-28 9:42 GMT+02:00 Mark Struberg <[hidden email]>:
>>
>> +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
>> > <[hidden email]>:
>> >
>> > 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
>>
>