Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36496 > unrolled thread

Re: Jigsaw

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-20 21:37 -0400
    Re: Jigsaw omegajunior <omegajunior@protonmail.com> - 2017-04-24 08:45 -0400
      Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-24 10:44 -0400
        Re: Jigsaw Eric Douglas <e.d.programmer@gmail.com> - 2017-04-24 08:15 -0700
          Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-24 11:29 -0400
            Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-24 11:29 -0400
            Re: Jigsaw omegajunior <omegajunior@protonmail.com> - 2017-04-26 18:32 -0400
              Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-26 19:49 -0400
          Re: Jigsaw Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-04-24 11:51 -0400
            Re: Jigsaw omegajunior <omegajunior@protonmail.com> - 2017-04-26 18:37 -0400
              Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-26 19:49 -0400
              Re: Jigsaw Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-04-27 07:42 -0400

#36496 — Re: Jigsaw

On 4/20/2017 9:10 PM, Stefan Ram wrote:
>   No, my post is not about Scott Stark's blog entry,
>   but rather about this sentence:
>
>       »The previously monolithic runtime library rt.jar is
>       now split up in Java 9.«
>       ¯¯¯¯¯¯¯¯¯¯¯¯
>   Didn't I hear that some years before? Wait!
>   Yes - here it is:
>
>       »Java SE 6 Update 10 consists of several technologies
>       that improve the user experience related to installing
>       the JRE, and to deploying and running rich-client Java
>       (and JavaFX) programs: · Java Kernel Online Installer
>       - The JRE is now divided into small bundles.«.
>                    ¯¯¯¯¯¯¯¯¯¯¯

Not the same.

The Java Kernel Online Installer are able to download the
JRE in distinct chunks, but when everything is downloaded
the result is exactly as for a normal download including
a single rt.jar.

http://www.oracle.com/technetwork/java/javase/kernel-135055.html

http://www.oracle.com/technetwork/java/javase/downloads/6u10faq-jsp-137957.html#JKernel

The Java 9 split in modules actually end up with multiple
module files in the JRE installation.

Arne

[toc] | [next] | [standalone]

#36513

Arne Vajhøj <arne@vajhoej.dk> Wrote in message:
> On 4/20/2017 9:10 PM, Stefan Ram wrote:
>>   No, my post is not about Scott Stark's blog entry,
>>   but rather about this sentence:
>>
>>       »The previously monolithic runtime library rt.jar is
>>       now split up in Java 9.«
>>       ¯¯¯¯¯¯¯¯¯¯¯¯
>>   Didn't I hear that some years before? Wait!
>>   Yes - here it is:
>>
>>       »Java SE 6 Update 10 consists of several technologies
>>       that improve the user experience related to installing
>>       the JRE, and to deploying and running rich-client Java
>>       (and JavaFX) programs: · Java Kernel Online Installer
>>       - The JRE is now divided into small bundles.«.
>>                    ¯¯¯¯¯¯¯¯¯¯¯
> 
> Not the same.
> 
> The Java Kernel Online Installer are able to download the
> JRE in distinct chunks, but when everything is downloaded
> the result is exactly as for a normal download including
> a single rt.jar.
> 
> http://www.oracle.com/technetwork/java/javase/kernel-135055.html
> 
> http://www.oracle.com/technetwork/java/javase/downloads/6u10faq-jsp-137957.html#JKernel
> 
> The Java 9 split in modules actually end up with multiple
> module files in the JRE installation.
> 
> Arne
> 
> 
> 

I've read about this. Does the separation imply independent
 distribution? Or independent (and hopefully reduced) class
 loading? Both? Neither? 
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#36516

On 4/24/2017 8:45 AM, omegajunior wrote:
> Arne Vajhøj <arne@vajhoej.dk> Wrote in message:
>> The Java 9 split in modules actually end up with multiple
>> module files in the JRE installation.
>
> I've read about this. Does the separation imply independent
>  distribution? Or independent (and hopefully reduced) class
>  loading? Both? Neither?

Java classes are loaded when they are needed, so I would assume
no changes to classes loaded.

In theory it should be possible to create a JRE subset with only
some modules.

I don't think the Java license permits it.

I don't think there is much point. Given todays network speeds
and disk sizes the JRE is relative small.

I assume they have done the split for the same reasons other
would want to use the module system. To decouple things better
and make it easier to maintain.

Arne

[toc] | [prev] | [next] | [standalone]

#36518

On Monday, April 24, 2017 at 10:44:28 AM UTC-4, Arne Vajhøj wrote:
> Java classes are loaded when they are needed, so I would assume
> no changes to classes loaded.
> 
> In theory it should be possible to create a JRE subset with only
> some modules.
> 
> I don't think the Java license permits it.
> 
> I don't think there is much point. Given todays network speeds
> and disk sizes the JRE is relative small.
> 
> I assume they have done the split for the same reasons other
> would want to use the module system. To decouple things better
> and make it easier to maintain.
> 
> Arne

http://openjdk.java.net/projects/jigsaw/

The first stated goal was to scale down to fit a Java on smaller devices.  I'm not sure how much space a JRE takes up or what sort of devices you'd need to be able to fit just part of the JRE.

I'm not sure if this "jigsaw" is the same JRE classes broken up to different jars, or how this accomplishes the other stated goals of improving security, maintainability, and application performance.

I can't think of a practical application for wanting a client device to install just part of a JRE.  I would think running Java on current hardware that shouldn't be much of an issue, as you say the speeds and disk sizes are rapidly increasing.

[toc] | [prev] | [next] | [standalone]

#36521

On 4/24/2017 11:15 AM, Eric Douglas wrote:
> On Monday, April 24, 2017 at 10:44:28 AM UTC-4, Arne Vajhøj wrote:
>> Java classes are loaded when they are needed, so I would assume no
>> changes to classes loaded.
>>
>> In theory it should be possible to create a JRE subset with only
>> some modules.
>>
>> I don't think the Java license permits it.
>>
>> I don't think there is much point. Given todays network speeds and
>> disk sizes the JRE is relative small.
>>
>> I assume they have done the split for the same reasons other would
>> want to use the module system. To decouple things better and make
>> it easier to maintain.
>
> http://openjdk.java.net/projects/jigsaw/
>
> The first stated goal was to scale down to fit a Java on smaller
> devices.  I'm not sure how much space a JRE takes up or what sort of
> devices you'd need to be able to fit just part of the JRE.

I believe a full JRE is still less than 200 MB. Should not be
a problem in EE or SE world.

But maybe there is a case in embedded (SE Embedded) space.

> I'm not sure if this "jigsaw" is the same JRE classes broken up to
> different jars, or how this accomplishes the other stated goals of
> improving security, maintainability, and application performance.

The modular split and the dependency management can certainly
improve things for large systems.

Arne

[toc] | [prev] | [next] | [standalone]

#36522

On 4/24/2017 11:29 AM, Arne Vajhøj wrote:
> On 4/24/2017 11:15 AM, Eric Douglas wrote:
>> I'm not sure if this "jigsaw" is the same JRE classes broken up to
>> different jars, or how this accomplishes the other stated goals of
>> improving security, maintainability, and application performance.
>
> The modular split and the dependency management can certainly
> improve things for large systems.

I really like it!

Arne

[toc] | [prev] | [next] | [standalone]

#36539

Arne Vajhøj <arne@vajhoej.dk> Wrote in message:
> On 4/24/2017 11:15 AM, Eric Douglas wrote:
>> On Monday, April 24, 2017 at 10:44:28 AM UTC-4, Arne Vajhøj wrote:
>>> Java classes are loaded when they are needed, so I would assume no
>>> changes to classes loaded.
>>>
>>> In theory it should be possible to create a JRE subset with only
>>> some modules.
>>>
>>> I don't think the Java license permits it.
>>>
>>> I don't think there is much point. Given todays network speeds and
>>> disk sizes the JRE is relative small.
>>>
>>> I assume they have done the split for the same reasons other would
>>> want to use the module system. To decouple things better and make
>>> it easier to maintain.
>>
>> http://openjdk.java.net/projects/jigsaw/
>>
>> The first stated goal was to scale down to fit a Java on smaller
>> devices.  I'm not sure how much space a JRE takes up or what sort of
>> devices you'd need to be able to fit just part of the JRE.
> 
> I believe a full JRE is still less than 200 MB. Should not be
> a problem in EE or SE world.
> 
> But maybe there is a case in embedded (SE Embedded) space.
> 
>> I'm not sure if this "jigsaw" is the same JRE classes broken up to
>> different jars, or how this accomplishes the other stated goals of
>> improving security, maintainability, and application performance.
> 
> The modular split and the dependency management can certainly
> improve things for large systems.
> 
> Arne
> 
> 

Yes, for limited systems (mobile phones, set-top boxes, smart
 cards)
both the file size and the amount of memory (both stack
 and heap) used by the JRE form prohibitive factors.
 
  
I love these programming quizzes that ask, how many objects does
 this program create? How much memory does this structure use? It
 pales in comparison to how many objects the JRE or the SDK
 generate just to live, and how much memory they allocate, with
 maybe only a memory monitor running. 
  
I do hope that Jigsaw forces core java to separate class loading
 between concerns, so I can, for instance, totally remove
 java.xml, if my application doesn't use xml, or allows me to
 replace a default  implementation of some interface entirely with
 a competing one. 

-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#36541

On 4/26/2017 6:32 PM, omegajunior wrote:
> Arne Vajhøj <arne@vajhoej.dk> Wrote in message:
>> On 4/24/2017 11:15 AM, Eric Douglas wrote:
>>> I'm not sure if this "jigsaw" is the same JRE classes broken up to
>>> different jars, or how this accomplishes the other stated goals of
>>> improving security, maintainability, and application performance.
>>
>> The modular split and the dependency management can certainly
>> improve things for large systems.
>
> Yes, for limited systems (mobile phones, set-top boxes, smart
>  cards)
> both the file size and the amount of memory (both stack
>  and heap) used by the JRE form prohibitive factors.

> I do hope that Jigsaw forces core java to separate class loading
>  between concerns, so I can, for instance, totally remove
>  java.xml, if my application doesn't use xml, or allows me to
>  replace a default  implementation of some interface entirely with
>  a competing one.

It can help on disk space.

It can not help with memory.

JVM's does not load jar files - they load single classes
when they are needed. Same number of classes will be
in memory without and with jigsaw.

Memory usage is up to the developer.

Arne

[toc] | [prev] | [next] | [standalone]

#36523

On 4/24/2017 11:15 AM, Eric Douglas wrote:
> On Monday, April 24, 2017 at 10:44:28 AM UTC-4, Arne Vajhøj wrote:
>> Java classes are loaded when they are needed, so I would assume
>> no changes to classes loaded.
>>
>> In theory it should be possible to create a JRE subset with only
>> some modules.
>>
>> I don't think the Java license permits it.
>>
>> I don't think there is much point. Given todays network speeds
>> and disk sizes the JRE is relative small.
>>
>> I assume they have done the split for the same reasons other
>> would want to use the module system. To decouple things better
>> and make it easier to maintain.
>>
>> Arne
> 
> http://openjdk.java.net/projects/jigsaw/
> 
> The first stated goal was to scale down to fit a Java on smaller devices.  I'm not sure how much space a JRE takes up or what sort of devices you'd need to be able to fit just part of the JRE.

     Data point: On a Windows machine, the current JRE takes 179MB.
Class libraries take 96MB, with 53MB devoted to rt.jar, the "core"
classes. Binaries take another 83MB, of which 40MB are used by
something called "jfxwebkit.dll" -- perhaps the way to slim down
Java is to ditch JavaFX!  :)

-- 
esosman@comcast-dot-net.invalid
Thirteen hundred sixty-seven days to go.

[toc] | [prev] | [next] | [standalone]

#36540

Eric Sosman <esosman@comcast-dot-net.invalid> Wrote in message:
> On 4/24/2017 11:15 AM, Eric Douglas wrote:
>> On Monday, April 24, 2017 at 10:44:28 AM UTC-4, Arne Vajhøj wrote:
>>> Java classes are loaded when they are needed, so I would assume
>>> no changes to classes loaded.
>>>
>>> In theory it should be possible to create a JRE subset with only
>>> some modules.
>>>
>>> I don't think the Java license permits it.
>>>
>>> I don't think there is much point. Given todays network speeds
>>> and disk sizes the JRE is relative small.
>>>
>>> I assume they have done the split for the same reasons other
>>> would want to use the module system. To decouple things better
>>> and make it easier to maintain.
>>>
>>> Arne
>> 
>> http://openjdk.java.net/projects/jigsaw/
>> 
>> The first stated goal was to scale down to fit a Java on smaller devices.  I'm not sure how much space a JRE takes up or what sort of devices you'd need to be able to fit just part of the JRE.
> 
>      Data point: On a Windows machine, the current JRE takes 179MB.
> Class libraries take 96MB, with 53MB devoted to rt.jar, the "core"
> classes. Binaries take another 83MB, of which 40MB are used by
> something called "jfxwebkit.dll" -- perhaps the way to slim down
> Java is to ditch JavaFX!  :)
> 
> -- 
> esosman@comcast-dot-net.invalid
> Thirteen hundred sixty-seven days to go.
> 

JavaFX indeed is huge, and most of its standard GUI are severely
 lacking. I've found myself adding the most basic of GUI
 functionalities, or adding components from JFXtras
 etc.
  
And yes, if your application doesn't need JavaFX, you should be
 able to cut it out of the distribution. 
  
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#36542

On 4/26/2017 6:37 PM, omegajunior wrote:
> And yes, if your application doesn't need JavaFX, you should be
>  able to cut it out of the distribution.

Be sure to check Oracle's license terms first.

I believe they specify what can be cut and what can not be cut.

Arne

[toc] | [prev] | [next] | [standalone]

#36543

On 4/26/2017 6:37 PM, omegajunior wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> Wrote in message:
>> On 4/24/2017 11:15 AM, Eric Douglas wrote:
>>> [...]
>>> The first stated goal was to scale down to fit a Java on smaller devices.  I'm not sure how much space a JRE takes up or what sort of devices you'd need to be able to fit just part of the JRE.
>>
>>       Data point: On a Windows machine, the current JRE takes 179MB.
>> Class libraries take 96MB, with 53MB devoted to rt.jar, the "core"
>> classes. Binaries take another 83MB, of which 40MB are used by
>> something called "jfxwebkit.dll" -- perhaps the way to slim down
>> Java is to ditch JavaFX!  :)
>>
> 
> JavaFX indeed is huge, and most of its standard GUI are severely
>   lacking. I've found myself adding the most basic of GUI
>   functionalities, or adding components from JFXtras
>   etc.

     If your application doesn't use FX, the FX classes and FX libraries
aren't loaded.  They'll use disk space, yes, but although the amount
would have been troublesome twenty-five years ago it doesn't come to
much nowadays.  Let's see <checks>: I can get a 2TB drive for US$63,
which is three thousandths of a cent per megabyte, so space to store
the entire JRE will set you back just over half a cent.  Even at SSD
prices (240GB for US$78) you'll need to scrounge up less than six cents.

> And yes, if your application doesn't need JavaFX, you should be
>   able to cut it out of the distribution.

     First, I'll second Arne Vajhøj's suggestion that you check the
license for any prohibitions on subsetting.  I'm not sure whether
JavaFX is yet part of the "official" Java or whether it's still
"just along for the ride," but don't rush ahead without checking.

     Second, if you can in fact purge FX and its forty or fifty MB,
be careful not to hurt your arm trying to pat yourself on the back
for saving not quite two-tenths of a cent.

-- 
esosman@comcast-dot-net.invalid
Thirteen hundred sixty-four days to go.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web