Re: jpackage custom resources not found

> On 15 Jan 2019, at 7.36, Michael Hall wrote: > > FWIW, for OS X I just set this in my .bash_profile Thanks, my preference is to be explicit so that my build don't depend on the environment and changes to it , I've got about 8 x jdk on this machine and I (almost) never use the command

Re: jpackage custom resources not found

> On Jan 14, 2019, at 11:08 PM, Kustaa Nyholm > wrote: > > > For reference and posterity in case anyone comes hear searching for a worked > out sample here is my simplistic test script: > > #!/bin/bash > > set -e > >

Re: jpackage custom resources not found

Seems to work not! Thanks! Some small quibbles: The build directory is not kept or used: Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) Kept working directory for debug:

Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

PS And for good measure, made analogous changes in Executable.java:     http://cr.openjdk.java.net/~darcy/8217000.1/ Patch: --- old/src/java.base/share/classes/java/lang/reflect/Executable.java 2019-01-14 19:39:53.855000999 -0800 +++

JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

Hello, Please review a small factoring of several methods in java.lang.Class:     JDK-8217000: Refactor Class::methodToString     http://cr.openjdk.java.net/~darcy/8217000.0/ Patch below; thanks, -Joe --- old/src/java.base/share/classes/java/lang/Class.java 2019-01-14 18:05:22.194000999

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi John, On 15/01/2019 11:47 am, John Rose wrote: On Jan 11, 2019, at 4:53 PM, David Holmes > wrote: I think there is a problem knowing when "access check" means just access check and when it means "access check plus the special hack for setting final fields".

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On Jan 11, 2019, at 4:53 PM, David Holmes wrote: > > I think there is a problem knowing when "access check" means just access > check and when it means "access check plus the special hack for setting final > fields". I'm not reading any final field semantics into the existing text, > because

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

Hello Alan. Could you review the fix again ? Bug:https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ I added IBM29626C charset as standard way. Please give any suggestion and question. Thanks, Ichiroh Takiguchi IBM Japan,

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

> On Jan 14, 2019, at 2:05 PM, Alan Bateman wrote: > > On 12/01/2019 20:13, Lance Andersen wrote: >> Hi all, >> >> The following patch addresses the issue where the stream of paths where not >> relative to the specified directory as needed. >> >> As part of the fix, I added additional

Re: Modular Applications - Regression

On 14/01/2019 20:21, Scott Palmer wrote: Aren’t you just saying that jlink works when you don’t use the stuff that broke? Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files from JDK 9 or 10? Is there a way to use JAXB or JAX-WS on the module path like there was with

Re: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int)

Hello Tagir, I've reworked the benchmark [1] to test also the case when non-latin characters are appended (e.g. Russian). Measurements for both average time and memory allocation per benchmark method invocation are done for C2 and C1. [2] As for other instances of CharSequence in JDK

Re: Modular Applications - Regression

Well, I think that (jaxb) is a different (but related) issue. I was just addressing the „generate smaller runtime Image with jimage for classpath usage“ part. And that works. You can either do it on the command line or introduce an empty module with the needed Imports. In both cases jlink can

Re: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Neat! +1 -Brent On 1/14/19 12:05 PM, Roger Riggs wrote: Hi, Thanks for the reviews. As suggested, cleaned up a bit more dead wood. http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-4/ Thanks, Roger On 01/14/2019 01:56 PM, Brent Christian wrote: Hi, Roger On Windows, the

Re: Modular Applications - Regression

Aren’t you just saying that jlink works when you don’t use the stuff that broke? Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files from JDK 9 or 10? Is there a way to use JAXB or JAX-WS on the module path like there was with JDK 9 & 10? From what I can tell, if one

Re: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Dead wood be gone :-) All good > On Jan 14, 2019, at 3:05 PM, Roger Riggs wrote: > > Hi, > > Thanks for the reviews. > > As suggested, cleaned up a bit more dead wood. > > http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-4/ > > Thanks, Roger > > > On 01/14/2019 01:56 PM,

Re: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Hi, Thanks for the reviews. As suggested, cleaned up a bit more dead wood. http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-4/ Thanks, Roger On 01/14/2019 01:56 PM, Brent Christian wrote: Hi, Roger On Windows, the test did not check liveness, but will check it now; seems

Re: Modular Applications - Regression

JLink works fine with applications on the classpath, all you have to do is to list the modules needed manually (and JDeps helps with that). Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Scott Palmer Gesendet: Montag, Januar 14,

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

On 12/01/2019 20:13, Lance Andersen wrote: Hi all, The following patch addresses the issue where the stream of paths where not relative to the specified directory as needed. As part of the fix, I added additional DirectoryStream tests similar to the tests in

Re: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException

Hi Stuart, On 1/11/2019 11:08 AM, Stuart Marks wrote: Drat, you pushed this already. But I wanted to mention a couple style points: On 1/10/19 10:13 PM, Joe Darcy wrote: + sb.append(Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). +         

Re: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Hi, Roger On Windows, the test did not check liveness, but will check it now; seems desirable. I think the changes look fine as they are. Additional refactoring possibilities for your consideration, to take or leave: * ProcessTest::isAlive() is not used * killProc() no longer needs

Re: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Hi Roger, The changes look reasonable to me! Best Lance > On Jan 14, 2019, at 11:56 AM, Roger Riggs wrote: > > Please review removing a test for Process.destroy(). [1] > It fails intermittently and is based on an incorrect assumption. > > The child is a bash script that uses trap to ignore

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

Hi Christoph Thank you for the feedback, please see below > On Jan 14, 2019, at 9:13 AM, Langer, Christoph > wrote: > > Hi Lance, > > as I'm currently active in that area, it's an easy one for me to review this  > > Overall the change looks good, thanks for doing it. Here are some few nits

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

Thank you Mandy for review. Vladimir On 1/14/19 10:29 AM, Mandy Chung wrote: On 1/14/19 9:39 AM, Vladimir Kozlov wrote: Thank you, Alan On 1/14/19 2:27 AM, Alan Bateman wrote: On 13/01/2019 02:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

On 1/14/19 9:39 AM, Vladimir Kozlov wrote: Thank you, Alan On 1/14/19 2:27 AM, Alan Bateman wrote: On 13/01/2019 02:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8216151 Have to update default.policy after changes in

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

Thank you, Alan On 1/14/19 2:27 AM, Alan Bateman wrote: On 13/01/2019 02:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8216151 Have to update default.policy after changes in jdk.internal.vm.compiler.management files done

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi All, Some comments below. > A CSR request will need to be filed. > > >>> > >>> Of course, as this is a spec change. > >> > >> I'm unclear what spec is actually to be changed here and in what way? As am I. > > > > I expect Adam will send a revised webrev to include the proposed

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

Thank you, Tobias Vladimir On 1/14/19 2:04 AM, Tobias Hartmann wrote: Hi Vladimir, looks good to me. Best regards, Tobias On 13.01.19 03:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8216151 Have to update

RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely"

Please review removing a test for Process.destroy().  [1] It fails intermittently and is based on an incorrect assumption. The child is a bash script that uses trap to ignore SIGTERM.  The child is started and then sent SIGTERM. The child should not terminate.  However, there is a race in which

Re: Modular Applications - Regression

> On Jan 14, 2019, at 10:33 AM, Alan Bateman wrote: > > On 14/01/2019 15:03, Scott Palmer wrote: >> : >> >> Does this not require ALL dependencies - down the entire dependency chain, >> including every transitive dependency, to be 100% modular? > Look for "automatic modules", this is how

Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Hi Patrick, Please re-post the entire proposed patch based on the JDK 13 repo. BTW, there is already a "#ifndef _MSC_VER" at line 36. Thanks, Roger On 01/14/2019 09:02 AM, Magnus Ihse Bursie wrote: On 2019-01-02 00:11, David Holmes wrote: Hi Patrick, On 13/12/2018 1:23 pm, Patrick Zhang

Re: Modular Applications - Regression

On 14/01/2019 15:03, Scott Palmer wrote: : Does this not require ALL dependencies - down the entire dependency chain, including every transitive dependency, to be 100% modular? Look for "automatic modules", this is how the module system facilitates top-down migration where you can migrate to

Re: Modular Applications - Regression

I'm very new to modular stuff but I've just experimented with my java6 application that I've been bringing to this century by trying to use jdk11. During these rehearsal I've been using various versions of javapackager, jpackager and jpackage. jpackager (from Java8) seems to build a .app that

Modular Applications - Regression

Hi, I’ld like to confirm something, because I see suggestions to “build X as a modular app” or “build as a modular jar” and I’m wondering if I’m missing something. These options don’t seem to be practical for most applications. Does this not require ALL dependencies - down the entire

Re: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int)

Hi, I recently used the append(str, beginIndex, endIndex) method for an optimization an code simplification and I was wondered that performance instead decreased. It turned out that the usual append(String) method is intrinsic. I'm not a JVM expert but I guess that it should be easy to implement

Re: jpackage custom resources not found

On 1/14/2019 9:02 AM, Kustaa Nyholm wrote: Thanks! I could have sworn I had the correct jpackage in use, turns out I using referring to jpackager. When I tried jpackage (copied jpackage from 13 to my 11 jdk) I got: dyld: Library not loaded: @rpath/libjli.dylib Referenced from:

RE: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

Hi Lance, as I'm currently active in that area, it's an easy one for me to review this  Overall the change looks good, thanks for doing it. Here are some few nits I discovered: src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java: in the comments: line 426: Maybe you could take the

Re: jpackage custom resources not found

Thanks! I could have sworn I had the correct jpackage in use, turns out I using referring to jpackager. When I tried jpackage (copied jpackage from 13 to my 11 jdk) I got: dyld: Library not loaded: @rpath/libjli.dylib Referenced from:

Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

On 2019-01-02 00:11, David Holmes wrote: Hi Patrick, On 13/12/2018 1:23 pm, Patrick Zhang wrote: Ping... Apply for a sponsor for this simple patch. Seems no one wants to own this one :( For what it's worth, it looks good to me. (But I'd like to see a core library developer chime in as

Re: jpackage custom resources not found

I can see from the verbose message that you are not using the jpackage from the latest EA2 at https://jdk.java.net/jpackage/ (run jpackage --version to see what version you are running) Did you download the earlier EA and copy it over installed jdk-11.0.1 ? In any case the behavior you are

jpackage custom resources not found

Hi, over the weekend I tried to use the EA jpackage from here: https://jdk.java.net/jpackage/ I invoke it like this: PACKAGER=/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/jpackager ${PACKAGER} \ create-image \ --build-root build-jpackager \ --verbose \ --echo-mode \

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

On 13/01/2019 02:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8216151 Have to update default.policy after changes in jdk.internal.vm.compiler.management files done by JDK-8199755: "Update Graal". Ran

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

Hi Vladimir, looks good to me. Best regards, Tobias On 13.01.19 03:46, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8216151 > > Have to update default.policy after changes in > jdk.internal.vm.compiler.management files

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

On 14/01/2019 07:42, Langer, Christoph wrote: Hi Lance, I was not aware of JDK-8182117 and by its description it does not fit exactly to the updates to jdk.zipfs module documentation that I propose. However, yes, it is probably a bit more natural to include that part in a potential patch