Le 04/01/2020 à 12:19, Stefan Bodewig a écrit :
>> FYI I plan to fork the JDK pack200 implementation into a standalone
>> project. I've reserved the 'pack200' group on GitHub for this. The code
>> isn't published yet
>
> https://github.com/pack200/pack200 looks pretty public to me :-)
I've
On 2020-01-05, Gary Gregory wrote:
> Is Pack200 100% Java? Even if not, I think it would be neat to bring it in
> from Apache Harmony as a new module.
What Emmanuel says.
> I think we should consider converting compress into a multi-module
> project and avoid hard dependencies. For folks who
Phone, top post, sorry. Yes you can build on J8 and test on J14 using a
Maven toochain. But it might be easier to use GitHub actions and Travis to
do it all on one at a time and all Java versions.
Gary
On Sun, Jan 5, 2020, 09:04 Emmanuel Bourg wrote:
> Le 05/01/2020 à 14:09, Gary Gregory a
Le 05/01/2020 à 14:09, Gary Gregory a écrit :
> Is Pack200 100% Java?
In OpenJDK the pack200 encoder is 100% Java, and there are two decoder
implementations in Java and in C. The native decoder is 5 times faster
than the Java one.
> I think it would be neat to bring it in from Apache Harmony
Is Pack200 100% Java? Even if not, I think it would be neat to bring it in
from Apache Harmony as a new module. I think we should consider converting
compress into a multi-module project and avoid hard dependencies. For folks
who want everything, we can create a BOM POM.
For the test, the
On 2020-01-04, Gary Gregory wrote:
> Java has a service leader mechanism for that. No sense in duplicating it.
Compress already supports that, and IIRC you've added that yourself :-)
Stefan
-
To unsubscribe, e-mail:
Java has a service leader mechanism for that. No sense in duplicating it.
If that means updating to Java 8, then so be it.
Gary
On Sat, Jan 4, 2020, 07:58 Emmanuel Bourg wrote:
> Le 04/01/2020 à 12:19, Stefan Bodewig a écrit :
>
> > This won't work as CompressorStreamFactory depends on the
Le 04/01/2020 à 12:19, Stefan Bodewig a écrit :
> This won't work as CompressorStreamFactory depends on the package.
Maybe some reflection could address that?
> https://github.com/pack200/pack200 looks pretty public to me :-)
I've just pushed a raw extraction of the OpenJDK code with its
On Sat, 4 Jan 2020 at 11:19, Stefan Bodewig wrote:
> On 2020-01-04, Emmanuel Bourg wrote:
>
> > Le 02/01/2020 à 11:06, Stefan Bodewig a écrit :
>
> >> Any other ideas?
>
> > The removal of pack200 isn't an issue for the upcoming release yet since
> > we still target Java 7. For now this is just
On 2020-01-04, Emmanuel Bourg wrote:
> Le 02/01/2020 à 11:06, Stefan Bodewig a écrit :
>> Any other ideas?
> The removal of pack200 isn't an issue for the upcoming release yet since
> we still target Java 7. For now this is just an issue with the CI using
> Java 14+. Maybe we can deal with this
Le 02/01/2020 à 11:06, Stefan Bodewig a écrit :
> Any other ideas?
The removal of pack200 isn't an issue for the upcoming release yet since
we still target Java 7. For now this is just an issue with the CI using
Java 14+. Maybe we can deal with this by using a Maven profile excluding
the pack200
On 2020-01-02, Bruno P. Kinoshita wrote:
> I think if we are going to release it soon, the only option to support java
> 14+ the would be to remove it. Tell users it may be added back later either
> as-was or as a separate artefact.
If we want to cut a new release soon, we can just tell people
I think if we are going to release it soon, the only option to support java 14+
the would be to remove it. Tell users it may be added back later either as-was
or as a separate artefact.
Just my 0.02 cents
CheersBruno
Sent from Yahoo Mail on Android
On Thu, 2 Jan 2020 at 23:06, Stefan
Hi
our travis build also uses the combination
- dist: trusty
jdk: openjdk-ea
which has started to use OpenJDK 14 a while ago and our build has been
failing there ever since. The reason is
https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been
removed without any
14 matches
Mail list logo
