RFR: JDK-8217393 Re: Clarification in Attributes equal

Hi all, Please review the fix for JDK-8217393 which updates the javadocs for Attriibutes::equals to clarify its behavior to match its implementation — hg diff diff -r c5d6b4480c6c src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attr

Re: jpackage errors

1.) jpackage is only compatible with JDK9+,  so it can't work with --runtime-image pointing to JDK8, but clearly I need some work to detect that and display a clear error message. 2.) javax.script.ScriptException is a public API so I don't see why you would get this NoClassDefFoundError, can y

Re: jpackage errors

> On Jan 19, 2019, at 8:19 AM, Andy Herrick wrote: > > 1.) jpackage is only compatible with JDK9+, so it can't work with > --runtime-image pointing to JDK8, but clearly I need some work to detect that > and display a clear error message. OK thanks. I did also try 9 and 11 the same way. I h

jpackage OS X Classes directory

Going back to old legacy application building code on OS X the original OS X port project came up with AppBundler. That had included a feature where a Classes directory was included in /Contents/Java/Classes. This directory was also automatically added into classpath. I found it convenient for a

Re: jpackage java.library.path

> On Jan 18, 2019, at 6:53 PM, Michael Hall wrote: > > How is java.library.path supposed to work? I’m not seeing anything on a quick > browse of the —help. > It used to be I would manually move jni libraries into the MacOS directory > which was the default setting. > Is there a better way f

Re: jpackage errors

> >> can you shar the entire jpackage build command ? FWIW, based off of Kustaa’s earlier… #!/bin/bash set -e PACKAGER=`/usr/libexec/java_home`/bin/jpackage ${PACKAGER} --version ${PACKAGER} \ create-image \ --force \ --verbose \ --input ../HalfPipe12.app/Co

Re: jpackage OS X Classes directory

I don’t see the need. Can’t you just include whatever files you want in the application image? Scott > On Jan 19, 2019, at 9:41 AM, Michael Hall wrote: > > Going back to old legacy application building code on OS X the original OS X > port project came up with AppBundler. That had included a

Re: jpackage OS X Classes directory

> On Jan 19, 2019, at 9:16 AM, Scott Palmer wrote: > > I don’t see the need. Can’t you just include whatever files you want in the > application image? > > Scott > >> On Jan 19, 2019, at 9:41 AM, Michael Hall wrote: >> >> Going back to old legacy application building code on OS X the orig

Re: [13] RFR: 8216969: ParseException thrown for certain months with russian locale

Hi Naoto, SimpleDateFormat: 2454, perhaps add javadoc about what it is doing and why.   Use only the official style fields and avoid using the 0x8000 that is supposed to be internal to Calendar. 2457: (forceStandaloneForm ? Calendar.SHORT_STANDALONE ? SHORT_FORMAT) 2460: (forceStandaloneForm

Manifest copy constructor does not deeply copy individual section Attributes

Hi, Creating a new manifest as a copy from an existing one using the copy constructor assigns the new manifest individual sections entries map the same values which are references to attributes as the original rather than copying them as well deeply resulting in two manifests pointing to the same

Re: Manifest copy constructor does not deeply copy individual section Attributes

Hi again, Just after having sent the previous mail I found Manifest::clone explicitly says it creates a shallow copy which is true only to a certain extent. It deeply copies main attributes as well as individual sections map already now and only shallowly copies individual sections attributes maps.

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

Looks OK but I would consider simply deleting the javadoc for equals (and hashCode) completely. We don't really have anything to add to the Map interface spec. On Sat, Jan 19, 2019 at 4:47 AM Lance Andersen wrote: > > Hi all, > > Please review the fix for JDK-8217393 which updates the javadocs