peter.firmstone at zeus.net.au
Fri Mar 26 23:44:29 UTC 2021
It would have been nice if the interfaces for packing and unpacking
remained in the jdk, and only the implementation removed, this would
make it a lot easier for others to package it separately.
On 27/03/2021 12:14 am, Eric Bresie wrote:
> It is Apache Netbeans which is on the list.
> The IDE/Platform is updated/updating to newer Java it’s how to handle the legacy plug-ins that I’m concerned about
> Its the independent plugins which leverages pack 200 / unpack during plug-in install.
> Presently there is issue (1) in work for this but it didn’t seem clear to me at first why it didn’t handle the use case of unpacking existing pack200 in a newer JDK environment but I’m guessing one of the pack200 forks may be the way forward.
> (1) https://issues.apache.org/jira/browse/NETBEANS-2842?jql=text%20~%20%22pack200%22%20and%20project%20%3D%20NetBeans%20
> From: Alex Buckley <alex.buckley at oracle.com>
> Sent: Tuesday, March 23, 2021 12:26:08 PM
> To: Eric Bresie <ebresie at gmail.com>; jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
> Subject: Re: Unpack200 alternatives
> On 3/23/2021 5:41 AM, Eric Bresie wrote:
>> ... With the frequency of releases, that doesn’t guarantee that
>> projects will be able to migrate immediately. Migrating between JDK
>> various [presumably you meant "variations"?] on a massive project is
>> not necessarily an easy task nor is it potentially feasible when
>> working with volunteer effort ...
> Is your "massive project" listed at
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach ?
> Can you share some of the problems migrating from JDK N to JDK N+1? We
> understand that JDK 8 to 9 (or straight to 11) can be tough, but
> migrating from JDK 15 to 16 should be straightforward.
0498 286 363
Zeus Project Services Pty Ltd.
More information about the jdk-dev