git.net

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

Re: Java 11 Compatibility Problem


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