git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java 11 Compatibility Problem


Equinox JarProcessor [1] seems to use pack200 CLI.

1.
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/plain/bundles/org.eclipse.equinox.p2.jarprocessor/src/org/eclipse/internal/provisional/equinox/p2/jarprocessor/JarProcessor.java

Gintas

On Thu, 11 Oct 2018 at 17:00, Nicolas Lalevée <nicolas.lalevee@xxxxxxxxxx>
wrote:

> To be complete on this subject, the pack200 algorithm has been implemented
> to be able to resolve artifacts in an Eclipse updatesite. I don’t know how
> nowadays artifacts are packaged on a « p2 repository », but some
> documentation still exists and doesn’t contain any warnings:
>
> https://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Pack200_Optimization
>
> Nicolas
>
>
>
> > Le 10 oct. 2018 à 14:04, Jaikiran Pai <jaikiran@xxxxxxxxxx> a écrit :
> >
> > Hi Jan,
> >
> > For end users (of Ivy), the place where pack200 packaging becomes
> > visible is when they reference it in their dependencies as noted in our
> > doc[1]. So IMO, I think we should probably add a note/warning within our
> > documentation than a runtime log/warn message. But I still think, it's a
> > bit too early to do that. Maybe we should wait a few more releases of
> > Java and see if any alternatives show up?
> >
> > [1]
> >
> https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging
> >
> > -Jaikiran
> > On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote:
> >> If I understand Dragans point right, the warning comes when analyzing
> the code.
> >> Not just running Ivy.
> >> So the normal user won't see the warning. Maybe we should implement a
> warning?
> >>
> >> Jan
> >>
> >>> -----Ursprüngliche Nachricht-----
> >>> Von: Jaikiran Pai [mailto:jaikiran@xxxxxxxxxx]
> >>> Gesendet: Mittwoch, 10. Oktober 2018 07:08
> >>> An: dev@xxxxxxxxxxxxxx
> >>> Betreff: Re: Java 11 Compatibility Problem
> >>>
> >>> I agree with Stefan, at the moment I recommend ignoring those warnings.
> >>> There isn't anything else we can do (other than removing support for
> >>> pack200, which isn't a good option).
> >>>
> >>> -Jaikiran
> >>>
> >>>
> >>> On 10/10/18 9:56 AM, Stefan Bodewig wrote:
> >>>> Hi Krzysztof
> >>>>
> >>>> I'm not actively working on Ivy so take my response with a grain of
> >>>> salt.
> >>>>
> >>>> On 2018-10-09, Dragan, Krzysztof wrote:
> >>>>
> >>>>> Hi,
> >>>>> scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on
> >>>>> jdk11 I noticed two problems with this jar.
> >>>>> These two methods using internal jdk marked for removal and will be
> >>> deleted:
> >>>>>  * class org/apache/ivy/util/FileUtil uses deprecated class
> >>>>>    java/util/jar/Pack200$Unpacker (forRemoval=true)
> >>>>>  * class org/apache/ivy/util/FileUtil uses deprecated class
> >>>>>    java/util/jar/Pack200 (forRemoval=true)
> >>>> For background see https://openjdk.java.net/jeps/336
> >>>>
> >>>> The Java community has decided to eventually remove support for the
> >>>> pack200 format, but it still is there in Java11. Right now this is
> >>>> only a warning, it will only become a real problem once the classes
> >>>> actually get removed. They do not offer any alternative
> >>> implementation
> >>>> right now, and may never do (unlike the JAXB case, which is available
> >>>> as an external library now).
> >>>>
> >>>> I am aware of an alternative based on the former Apache Harmony code
> >>>> in https://github.com/pfirmstone/pack200 but am unsure about its
> >>> state
> >>>> - both technically and legally - I very vaguely recall the Pack200
> >>>> spec was encumbered with Oracle patents but may be totally wrong.
> >>>>
> >>>> In Ivy's case the only save option right now was to remove support
> >>> for
> >>>> pack200 archives and break existing setups that consume such archives
> >>>> which seems to be excessive just in order to get rid of a warning.
> >>>>
> >>>> If yu ask me I'd recommend to live with the warning for now and wait
> >>>> for an alternative to the class library's pack200 classes to become
> >>>> available - which hopefully happens before the Java version removing
> >>>> support gets released.
> >>>>
> >>>> Stefan
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx For additional
> >>>> commands, e-mail: dev-help@xxxxxxxxxxxxxx
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx For additional
> >>> commands, e-mail: dev-help@xxxxxxxxxxxxxx
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx
>
>