Re: ant git commit: bz-62952 Make AntClassLoader multi-release jar aware when it deals with java.util.jar.JarFile
[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
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
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