Re: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test

[Chris Bensen]

It will fail to compile. Is there a way to test if jdk.packager is present 
before compiling?

Chris


> On Feb 7, 2017, at 10:38 AM, David DeHaven  wrote:
> 
> 
>> Kevin, Mandy,
>> 
>> Please review my new unit test for javapackager. It reads redistributable 
>> module list from jdk.packager, if a module in the list doesn't exist, then 
>> the test fails.
>> 
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200
>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/
> 
> Just thought of something, what happens if FX is not imported?
> 
> -DrD-
> 

Re: RFR: JDK-8159172 - Update usage of jlink/jimage/jmod to show option patterns

[Chris Bensen]

--mp should be -p, at least according to Mark’s email about options unification:

>> Existing spellings  New spellings
>> ---

>> -modulepath | -mp | --modulepath--module-path | -p

Chris


> On Jun 23, 2016, at 11:40 AM, Jim Laskey (Oracle)  
> wrote:
> 
> 
> http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html 
> 
> https://bugs.openjdk.java.net/browse/JDK-8159172 
> 
> 
> This is an initial clean up of help for jlink/jimage/jmod.  More work is 
> required (like unifying the options tooling), but comments welcome. — Jim
> 
> /Projects/jdk9-dev% jmod --help
> Usage: jmod (create|list|describe|hash)  
> 
> Main operation modes:
>  create- Creates a new jmod archive
>  list  - Prints the names of all the entries
>  describe  - Prints the module details
>  hash  - Records hashes of tied modules.
> 
> Option Description   
> -- ---   
>  --class-path Application jar files|dir containing  
>   classes 
>  --cmds   Location of native commands   
>  --config Location of user-editable config files
>  --dry-run  Dry run of hash mode  
>  --excludeExclude files matching the supplied   
>   comma separated pattern list, each  
>   element using one the following 
>   forms: , glob:   pattern> or regex:   
>  --hash-modules  Compute and record hashes to tie a
>   packaged module with modules
>   matching the given   
>   and depending upon it directly or   
>   indirectly. The hashes are recorded 
>   in the JMOD file being created, or a
>   JMOD file or modular JAR on the 
>   module path specified the jmod hash 
>   command.
>  --help Print this usage message  
>  --libs   Location of native libraries  
>  --main-class   Main class
>  --module-version   Module version
>  --modulepath, --mp   Module path   
>  --os-arch Operating system architecture 
>  --os-name Operating system name 
>  --os-version   Operating system version  
>  --version  Version information   
>  @Read options from the specified file  
> 
> /Projects/jdk9-dev% jimage --help
> Usage: jimage   jimage...
> 
>  extract  - Extract all jimage entries and place in a directory specified
> by the --dir= (default=.) option.
> 
>  info - Prints detailed information contained in the jimage header.
> 
>  list - Prints the names of all the entries in the jimage.  When used with
> --verbose, list will also print entry size and offset attributes.
> 
>  verify   - Reports on any .class entries that dont verify as classes.
> 
> Possible options include:
>  --dir Target directory for extract directive
>  --include   Pattern list for filtering list or extract 
> entries.w
>  --fullversion Print full version information
>  --helpPrint usage message
>  --verbose Listing prints entry size and offset 
> attributes
>  --version Print version information
> 
> For options requiring a , the value will be a comma separated 
> list of elements each using one the following forms:
>  
>  glob:
>  regex:
> 
>  @ where filename is the name of a file containing patterns to be  
> used, one pattern per line
> 
> /Projects/jdk9-dev% jlink --list-plugins
> 
> List of available plugins:
> 
> Plugin Name: class-optim
> Option: --class-optim=[:log=]
> Description: Class optimization. Warning: This plugin is experimental.
> An optional  can be specified to log applied optimizations.
> 
> Plugin Name: compress
> Option: --compress=<0|1|2>[:filter=]
> Description: Compress all resources in the output image.
> Level 0: constant string sharing
> Level 1: ZIP
> Level 2: both.
> An optional  filter can be 

Re: Review Request: JDK-8155955: packager needs to determine the root modules to create JRE image

[Chris Bensen]

I can continue to use the hard coded list of modules in the meantime. I was 
hoping this class could be refactored to reduce duplication.

Chris


> On Jun 4, 2016, at 12:18 PM, Mandy Chung  wrote:
> 
> 
>> On Jun 4, 2016, at 10:01 AM, Alan Bateman  wrote:
>> 
>> On 04/06/2016 17:01, Kevin Rushforth wrote:
>> 
>>> What the packager needs is a means at runtime to get the same set of JRE 
>>> modules that an application in the unnamed module reads by default. If 
>>> there is a better way to provide this, then that would be fine, but for 
>>> both backward compatibility, and to allow a non-modular application to 
>>> package the application + JRE that will run the same way -- seeing the same 
>>> JRE modules -- that it does when running from the installed JDK.
>>> 
>>> -- Kevin 
>> I understand but there are a couple of issues here, one is that the set of 
>> modules in the JRE build includes a number of modules that are not defined 
>> to either loader. The other thing, and this is probably the more important 
>> one, is that this set of modules should not be picked up from the runtime 
>> that the packager (and jlink) is running on. I think this will become 
>> clearer once we start to work through the implications of jlink or packager 
>> running on JDK 10 or 9.x from the JDK 9 package modules for example. So I 
>> think anything related to policy or the target runtime needs to come from 
>> the modules that go into that runtime. It might be that we have to create an 
>> aggregator module in the build or some up with another way to have the set 
>> of modules available in or co-existing with the packaged modules.
> 
> I agree that a custom image should be created independent of the runtime the 
> tool is running on.  
> 
> As commented in JDK-8155955, there are a couple options as long-term 
> solution, creating an aggregator module or generate the list of JRE modules 
> at build time and included in the packaged modules (probably in java.base).  
> I think packager will need more experiences in getting their options right.  
> It does not really take the exact same set of modules in JRE and it may 
> filter out JRE tool modules and a couple others.  Packager may probably need 
> to use ModuleFinder and Configuration to build its root set.  One issue is 
> that packager could not configure ModuleFinder as link phase to find what 
> packaged modules on a module path unless it adds a qualified export (possibly 
> a public API to allow that while I think this should wait until we get more 
> experience and feedback on the packager).
> 
> This patch was intended to help them to remove their current hard coded list 
> while come up with a proper solution.  I do share your concern of 
> maintainability and FX and JDK separate forests add another complication in 
> coordinating the changes.  I think probably the right thing not to move 
> forward with this patch and Chris can continue with his workaround which I 
> think it should allow him to clean up the packager CLI options in the meatime 
> (that’s the main objective from my side).
> 
> Mandy

Re: JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

Ugh, day of mistakes. Here’s the correct link:

http://cr.openjdk.java.net/~cbensen/JDK-8150990/webrev.02/


> On Apr 28, 2016, at 7:07 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Doesn’t look like it’s been pushed. I revised the change:
> 
> http://cr.openjdk.java.net/~cbensen/JDK-8150990/webrev.01/
> 
> Chris
> 
> 
>> On Apr 28, 2016, at 6:55 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
>> 
>> If it hasn’t been pushed I’ll change it?
>> 
>> Chris
>> 
>> 
>>> On Apr 27, 2016, at 11:58 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>>> 
>>> 
>>> 
>>> On 27/04/2016 21:44, Kevin Rushforth wrote:
>>>> Looks fine to me, too.
>>>> 
>>>> Btw, I thought Mandy had earlier suggested 
>>>> jdk.tools.jlink.internal.packager as a name, but it's currently 
>>>> jdk.tools.internal.packager (without the jlink). I don't care one way or 
>>>> the other and the current one is shorter.
>>> Mandy's suggestion sounds right to me as jlink already has internals in 
>>> jdk.tools.jlink.internal.**. If it's temporary then the suggest is probably 
>>> okay although if temporary means to JDK 9 GA then it might be better to 
>>> change it now.
>>> 
>>> -Alan
>> 
> 

Re: JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

Doesn’t look like it’s been pushed. I revised the change:

http://cr.openjdk.java.net/~cbensen/JDK-8150990/webrev.01/

Chris


> On Apr 28, 2016, at 6:55 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> If it hasn’t been pushed I’ll change it?
> 
> Chris
> 
> 
>> On Apr 27, 2016, at 11:58 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>> 
>> 
>> 
>> On 27/04/2016 21:44, Kevin Rushforth wrote:
>>> Looks fine to me, too.
>>> 
>>> Btw, I thought Mandy had earlier suggested 
>>> jdk.tools.jlink.internal.packager as a name, but it's currently 
>>> jdk.tools.internal.packager (without the jlink). I don't care one way or 
>>> the other and the current one is shorter.
>> Mandy's suggestion sounds right to me as jlink already has internals in 
>> jdk.tools.jlink.internal.**. If it's temporary then the suggest is probably 
>> okay although if temporary means to JDK 9 GA then it might be better to 
>> change it now.
>> 
>> -Alan
> 

Re: JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

If it hasn’t been pushed I’ll change it?

Chris


> On Apr 27, 2016, at 11:58 PM, Alan Bateman  wrote:
> 
> 
> 
> On 27/04/2016 21:44, Kevin Rushforth wrote:
>> Looks fine to me, too.
>> 
>> Btw, I thought Mandy had earlier suggested jdk.tools.jlink.internal.packager 
>> as a name, but it's currently jdk.tools.internal.packager (without the 
>> jlink). I don't care one way or the other and the current one is shorter.
> Mandy's suggestion sounds right to me as jlink already has internals in 
> jdk.tools.jlink.internal.**. If it's temporary then the suggest is probably 
> okay although if temporary means to JDK 9 GA then it might be better to 
> change it now.
> 
> -Alan

Re: JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

To be honest I messed up. I noticed when I was building and testing just before 
sending out the review. I kinda liked it after I noticed but I’m good with 
either one.

Chris


> On Apr 27, 2016, at 1:59 PM, Mandy Chung  wrote:
> 
> 
>> On Apr 27, 2016, at 1:44 PM, Kevin Rushforth  
>> wrote:
>> 
>> Looks fine to me, too.
>> 
>> Btw, I thought Mandy had earlier suggested jdk.tools.jlink.internal.packager 
>> as a name, but it's currently jdk.tools.internal.packager (without the 
>> jlink). I don't care one way or the other and the current one is shorter.
> 
> I don’t have a preference on either one. This is just temporary and this may 
> go away when jlink API is simplified and becomes stable (something to revisit 
> later).
> 
> Mandy
> 

Re: JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

> On Apr 27, 2016, at 11:09 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> 
> On 27/04/2016 19:00, Chris Bensen wrote:
>> Because the Java Packager lives in the JavaFX repository and jlink lives in 
>> the JDK repository, changes to the jlink API have caused a lot of headaches. 
>> This change introduces a new class for jdk.packager in the jdk.jlink module 
>> to coordinate the jlink API changes. This is an interim solution and will go 
>> away at at some point in the future when the jdk.packager can be brought 
>> into the JDK.
>> 
>> Review: https://java.se.oracle.com/code/cru/CR-JDK9DEV-1361 
>> <https://java.se.oracle.com/code/cru/CR-JDK9DEV-1361>
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8150990 
>> <https://bugs.openjdk.java.net/browse/JDK-8150990>
>> 
>> 
> Chris - this seems to be an Oracle internal link so better to post the patch 
> on cr.openjdk.java.net.
> 
> -Alan.

OK, I’ll do that right after lunch.

Chris

JDK-8150990: [packager] Research Refactoring Packager

[Chris Bensen]

Because the Java Packager lives in the JavaFX repository and jlink lives in the 
JDK repository, changes to the jlink API have caused a lot of headaches. This 
change introduces a new class for jdk.packager in the jdk.jlink module to 
coordinate the jlink API changes. This is an interim solution and will go away 
at at some point in the future when the jdk.packager can be brought into the 
JDK.

Review: https://java.se.oracle.com/code/cru/CR-JDK9DEV-1361 

JIRA: https://bugs.openjdk.java.net/browse/JDK-8150990 


Thanks,
Chris