On 06/02/2018 08:36 AM, Magnus Ihse Bursie wrote:
> The actual changes look good to me.
>
> As a follow up, I think we should check if we could remove some of the JDK
> prefixes that was in
> place just to differentiate from the JRE. The term JDK is so overloaded, so
> it would be good to
> get
On 01/06/2018 23:02, Erik Joelsson wrote:
Since JDK 9 and modules, the idea of a prebuilt JRE is no longer
providing much value. The idea is rather that you link together an
image with the modules and settings you actually need, either with or
without your application. For this reason oracle wi
On 02/06/2018 08:05, Aleksey Shipilev wrote:
:
Unfortunately, in the age of containers, distribution size matters. It makes
the whole sense to ship
JRE in Docker containers to provide the execution environment for the upper
layers. Remember, hardly
any application is fully modularized and/or us
It is probably relatively trivial to add a configure option to select just the
"JRE modules" when building, rather than all modules. If we add such an option,
it would still be possible to build a traditional JRE, not just at the same
time as building the full JDK. Doing Erik's change as suggest
I work on a product that is built from a collection of plugins. Many of the
plugins are distributed after the main framework is installed. That product
will always need a full JRE because there is no way to know in advance which
modules will be needed.
A full JRE “image” is a requirement for
On 02/06/2018 15:07, Magnus Ihse Bursie wrote:
It is probably relatively trivial to add a configure option to select just the "JRE
modules" when building, rather than all modules. If we add such an option, it would
still be possible to build a traditional JRE, not just at the same time as build
Hi!
Please review this very small fix. It only applies to JDK 8.
bug report:
https://bugs.openjdk.java.net/browse/JDK-8204053
webrev:
http://cr.openjdk.java.net/~dbuck/8204053.0/
JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.
Cheers,
-Buck
