Re: ant git commit: bz-62952 Make AntClassLoader multi-release jar aware when it deals with java.util.jar.JarFile

2018-12-12 Thread Stefan Bodewig
[sorry for the delay, am pretty much swamped right now, I know this
makes dialogue difficult]

On 2018-12-09, Jaikiran Pai wrote:

> On 09/12/18 3:18 PM, Stefan Bodewig wrote:
>> On 2018-12-05,  wrote:

>>> Repository: ant
>>> Updated Branches:
>>>   refs/heads/master ac46ff190 -> 593aff2d2

>>> bz-62952 Make AntClassLoader multi-release jar aware when it deals with 
>>> java.util.jar.JarFile

>> An alternative approach to using reflection when creating the JarFile
>> instance would be to create different AntClassLoader instances. We did
>> so for Java 2.x and Java 5.x respectively when the baselines were 1.1 or
>> anything lower than 1.5.

> I did check it out before going with this approach. I decided to go with
> this approach because at this point, for just this change, this looked a
> bit more simpler than having to introduce the new classloader which then
> would have to use the new Java 9 JarFile API at compile time and would
> involve build file updates.

Good. It's not been my intention to push you in any direction, just
wanted to mention the alternative that we've used in the past. If you've
been aware of it and decided against it for good reasons that is
fine. Applying YAGNI and taking a more invasive approach once it is
called for but not right now is fine with me.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Re: ant git commit: bz-62952 Make AntClassLoader multi-release jar aware when it deals with java.util.jar.JarFile

2018-12-09 Thread Jaikiran Pai
Hi Stefan,


On 09/12/18 3:18 PM, Stefan Bodewig wrote:
> On 2018-12-05,  wrote:
>
>> Repository: ant
>> Updated Branches:
>>   refs/heads/master ac46ff190 -> 593aff2d2
>
>> bz-62952 Make AntClassLoader multi-release jar aware when it deals with 
>> java.util.jar.JarFile
> An alternative approach to using reflection when creating the JarFile
> instance would be to create different AntClassLoader instances. We did
> so for Java 2.x and Java 5.x respectively when the baselines were 1.1 or
> anything lower than 1.5.
>
> https://github.com/apache/ant/commit/17527b6490851a728623c1dcbf5078cc63a982dd
> is the commit where I reverted the logic for the Java5 specific
> classloader after Java5 became the baseline.

I did check it out before going with this approach. I decided to go with
this approach because at this point, for just this change, this looked a
bit more simpler than having to introduce the new classloader which then
would have to use the new Java 9 JarFile API at compile time and would
involve build file updates.
>
> I'm not sure it makes any difference right now but can imagine the
> classloader will have to learn some additional tricks for module support
> in the future.

Agreed, I haven't yet checked what more will be expected of classloader
post Java 9 but if it looks like better approach to lay the ground work
and create a new classloader instead of this reflection approach, I am
open to it.

-Jaikiran


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Re: ant git commit: bz-62952 Make AntClassLoader multi-release jar aware when it deals with java.util.jar.JarFile

2018-12-09 Thread Stefan Bodewig
On 2018-12-05,  wrote:

> Repository: ant
> Updated Branches:
>   refs/heads/master ac46ff190 -> 593aff2d2


> bz-62952 Make AntClassLoader multi-release jar aware when it deals with 
> java.util.jar.JarFile

An alternative approach to using reflection when creating the JarFile
instance would be to create different AntClassLoader instances. We did
so for Java 2.x and Java 5.x respectively when the baselines were 1.1 or
anything lower than 1.5.

https://github.com/apache/ant/commit/17527b6490851a728623c1dcbf5078cc63a982dd
is the commit where I reverted the logic for the Java5 specific
classloader after Java5 became the baseline.

I'm not sure it makes any difference right now but can imagine the
classloader will have to learn some additional tricks for module support
in the future.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org