From ivan.gerasimov at oracle.com Tue Jan 1 04:12:22 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 31 Dec 2018 20:12:22 -0800 Subject: RFR 6996807 : FieldReflectorKey hash code computation can be improved In-Reply-To: <489a4621-b763-8d8e-f4d0-4d611eb4f196@oracle.com> References: <489a4621-b763-8d8e-f4d0-4d611eb4f196@oracle.com> Message-ID: <727bdb40-7386-f96a-40a3-e923b08454b1@oracle.com> Gentle ping. I updated the copyright year, as it seems unlikely this fix is going to be reviewed in 2018 :) Happy New Year to everyone! Ivan On 12/18/18 2:42 AM, Ivan Gerasimov wrote: > Hello! > > FieldReflectorKey class contains a combined-string representation of > the fields (their names and signatures). > > This string is used for calculating the hash code and comparing two > FieldReflectorKey objects for equality, which is expensive. > > It is proposed to store the names and signatures (which are likely to > be interned) in an array an use this array for both tasks utilizing > Arrays.hashCode() and Arrays.equals(). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6996807 > WEBREV: http://cr.openjdk.java.net/~igerasim/6996807/00/webrev/ > > Would you please help review the fix? > -- With kind regards, Ivan Gerasimov From forax at univ-mlv.fr Tue Jan 1 19:16:06 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Jan 2019 20:16:06 +0100 (CET) Subject: enhanced for loop with multiple iteration variables In-Reply-To: <4AA5A92A-A2A0-4423-9596-ED203651FC65@cbfiddle.com> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> <4AA5A92A-A2A0-4423-9596-ED203651FC65@cbfiddle.com> Message-ID: <1348325550.82953.1546370166932.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Snyder" > ?: "Brian Goetz" > Cc: "core-libs-dev" > Envoy?: Vendredi 21 D?cembre 2018 03:19:14 > Objet: Re: enhanced for loop with multiple iteration variables > RIght, but I don?t see that as a general solution. > > Its also a bit kludgy, like saying that methods need only one parameter because > you can always pass a data object. yes, that's the point, as part of Valhalla, we want to introduce value types in Java. A value type is an almost zero cost abstraction that let you group and ungroup values. Also as part of Amber, we want to be able to de-construct record types (product types) in order to support pattern matching. If we have value types and de-construction, we are not far be able to write something like: for((var key, var value): map.entrySet()) { // ... } with no runtime cost. So being able to use the enhanced for loop on tuples is clearly something we want to have, but to achieve that goal i don't think that introducing a new Iterator2 interface is the right way to do that. regards, R?mi > >> On Dec 20, 2018, at 2:50 PM, Brian Goetz wrote: >> >> For Map, you can do: >> >> for (Map.Entry e : map.entrySet()) { ... } >> >> and you're already there. >> >> >> >> On 12/19/2018 9:54 AM, Alan Snyder wrote: >>> Has any consideration been given to supporting iterators that provide more than >>> one iteration variable in the enhanced for loop? >>> >>> Obvious uses would be maps (keys and values) and lists (indexes and values). >>> >>> I have in mind keeping the syntactic sugar approach by using one or more >>> extensions of the Iterator/Iterable interfaces, such as, for example: >>> >>> interface Iterator2 extends Iterator { >>> E2 get2(); >>> } >>> >>> with the extra methods providing the values for the extra variables (associated >>> with the previous call to next). >>> >>> Extending interfaces is not required, but it makes the trailing variables >>> optional, which might be useful. For example, the same iterator could provide >>> values or values and keys. >>> >>> The fact that this approach only works for a fixed set of numbers of variables >>> does not bother me unduly. >>> >>> Alan >>> From david.holmes at oracle.com Tue Jan 1 23:11:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jan 2019 09:11:07 +1000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> Message-ID: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> 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 :( > I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- > > Regards > Patrick > > -----Original Message----- > From: core-libs-dev On Behalf Of Patrick Zhang > Sent: Thursday, December 6, 2018 4:28 PM > To: core-libs-dev at openjdk.java.net; David Holmes > Cc: Florian Weimer > Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > To All, > Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. > > Regards > Patrick > > -----Original Message----- > From: David Holmes > Sent: Monday, December 3, 2018 8:11 AM > To: Patrick Zhang ; Florian Weimer > Cc: core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > Hi Patrick, > > On 30/11/2018 11:41 pm, Patrick Zhang wrote: >> Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). >> >> Hi David, >> Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. > > You'd need some assistance testing a wider range of platforms but that can be arranged. > >> In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. > _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. > > Cheers, > David > >> #ifdef _MSC_VER // Windows >> #define gmtime_r(t, s) gmtime(t) >> #endif >> >> Regards >> Patrick >> >> -----Original Message----- >> From: Florian Weimer >> Sent: Thursday, November 29, 2018 8:02 PM >> To: David Holmes >> Cc: Patrick Zhang ; >> jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: OpenJDK fails to build with GCC when the #include >> inside zip.cpp comes from a non-sysroot path >> >> * David Holmes: >> >>> This should really be being discussed on core-libs-dev. >> >> Okay, moving the conversation. >> >>>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp >>>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 >>>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 >>>> @@ -415,9 +415,7 @@ >>>> ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>>> } >>>> -#ifdef _REENTRANT // solaris >>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>>> +#if !defined(_REENTRANT) // linux >>>> #define gmtime_r(t, s) gmtime(t) >>>> #endif >>>> /* >>> >>> Under the theme "two wrongs don't make a right" the use of _REENTRANT >>> here is totally inappropriate AFAICS. It seems to be a misguided >>> attempt at determining whether we need the thread-safe gmtime_r or >>> not >>> - and the answer to that should always be yes IMHO. >>> >>> We define _REENTRANT for: >>> - linux >>> - gcc >>> - xlc >>> >>> So the original code will define: >>> >>> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >>> >>> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >>> >>> But Solaris has gmtime_r anyway. So the existing code seems a really >>> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >>> (where gmtime is already thread-safe). So it seems to me that all we >>> should need here is: >>> >>> -#ifdef _REENTRANT // solaris >>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>> +#ifdef _MSC_VER // Windows >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >> >> That looks much cleaner. >> >> Thanks, >> Florian >> From david.holmes at oracle.com Tue Jan 1 23:14:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jan 2019 09:14:17 +1000 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> <23a18f59-b3f9-4d6a-1e74-39f5ef87d57c@oracle.com> Message-ID: Hi Sergei, On 20/12/2018 6:50 am, Sergei Ustimenko wrote: > Hi, > > Coming back to the topic, I feel like I need some help. I can't really help. I agree with your analysis. We need to keep track of the scopes correctly even when one of them is implemented as a VM anonymous class! David ----- > Below is a stack trace so things would be easier to explain: > > "main at 1" prio=5 tid=0x1 nid=NA runnable > ? java.lang.Thread.State: RUNNABLE > ??? ? at > sun.reflect.generics.scope.ClassScope.computeEnclosingScope(ClassScope.java:51) > ??? ? at > sun.reflect.generics.scope.AbstractScope.getEnclosingScope(AbstractScope.java:77) > ??? ? at > sun.reflect.generics.scope.AbstractScope.lookup(AbstractScope.java:95) > ??? ? at > sun.reflect.generics.factory.CoreReflectionFactory.findTypeVariable(CoreReflectionFactory.java:110) > ??? ? at > sun.reflect.generics.visitor.Reifier.visitTypeVariableSignature(Reifier.java:165) > ??? ? at > sun.reflect.generics.tree.TypeVariableSignature.accept(TypeVariableSignature.java:43) > ??? ? at > sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68) > ??? ? at > sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138) > ??? ? at > sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) > ??? ? at > sun.reflect.generics.repository.ClassRepository.computeSuperclass(ClassRepository.java:104) > ??? ? at > sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:86) > ??? ? at java.lang.Class.getGenericSuperclass(Class.java:955) > ??? ? at Bug8213465.printIt(Bug8213465.java:15) > ??? ? at Bug8213465.lambda$main$0(Bug8213465.java:8) > ??? ? at Bug8213465$$Lambda$1.1229416514.run(Unknown Source:-1) > ??? ? at Bug8213465.main(Bug8213465.java:9) > > ClassScope in our case is created by the CoreReflectionFactory, when > Class#getGenericSuperclass being called. Creation is triggered, when type > variable lookup happens. Class Scope in our case is the scope of > anonymous class. Since type variable is not defined on the anonymous > class, lookup is delegated to the enclosing scope, which is the lambda's > scope i.e. MethodScope. > > As you see, I have a breakpoint at the ClassScope.java:51 which is > ``` > > Method m = receiver.getEnclosingMethod(); > > ``` > Lambda obviously doesn't declare the type variable => the next scope > that would be queried is the lambda's enclosing scope which is the class > scope. That ends up with the DummyScope and at Reifier.java:69 > a null value is being placed into the Type[0]. All the way down that > results in the type variable being resolved to null. > > The problem here is that type variable is declared at the method which > encloses lambda, so that is the place where the problem comes in - > we should somehow query the `main` method (in the example) for > it's type variable declaration. > > I've tried to query it with some sort of stack walking. That I've tried at > the ClassScope:51, so simply check if the method returned by the > `getEnclosingMethod()` is synthetic, then use stack walker to baktrack. > That is not working, since I there's no way to retain method > arguments. Thus it wouldn't work for overloaded methods. > > I've searched through the `Method` class and found `Method#root` > property. Could you please shine a light on it? Maybe we could harness > it for lambdas to find the lambda's enclosing method? > > The other way I thought of is whether it make sense to add a new > `Method#getEnclosingMethod` method, that in case of synthetic > methods would return non-null method, which encloses it. > > So it seems a bit cumbersome, but I really need a bit of advise here. > If anyone wants to participate and has some time, your thoughts would > be of the great value! > > Thanks, > Sergei > > > On Tue, 11 Dec 2018 at 08:20, David Holmes > wrote: > > On 11/12/2018 4:27 pm, Sergei Ustimenko wrote: > > Hi David, > > > > Thanks for checking it, I'll continue working on it then. > > Just wondering if you have any thoughts on how fix would > > look like. > > No. I tried tracking through the Java code to see how this works but > the > path is too long and convoluted :( The information is correct in the > classfile, but somewhere along the way the nature of the enclosing type > affects the answer that is produced. See ParameterizedTypeImpl and how > it gets created by CoreReflectionFactory. > > BTW as far as I can see it is not allowed for that method to produce > null: the type array can be empty, or creating it can throw an > exception, but otherwise the entries cannot be null. > > Cheers, > David > > > Regards, > > Sergei > > > > On Tue, 11 Dec 2018 at 02:34, David Holmes > > > >> wrote: > > > >? ? ?Hi Sergey, > > > >? ? ?I've had a look and I don't think this issue is relevant to > >? ? ?JDK-8171335. > >? ? ?The problem seems to occur when you have a "hidden" enclosing > context > >? ? ?for the type, and that doesn't change with JDK-8171335. > > > >? ? ?David > > > >? ? ?On 9/12/2018 6:04 am, Sergey wrote: > >? ? ? > Hi David, > >? ? ? > > >? ? ? > Thanks for pointing that out! > >? ? ? > > >? ? ? >? >We need to see how this example work in that case. > >? ? ? > > >? ? ? > I guess anyone involved could have straight away two > >? ? ? > test cases: one from the bug itself and another from the > >? ? ? > observation above. > >? ? ? > > >? ? ? > In any case. looking forward for that being fixed. I would > >? ? ? > also be happy to be able to help with anything if needed. > >? ? ? > > >? ? ? > Thanks and regards, > >? ? ? > Sergei > >? ? ? > > >? ? ? > On Sat, 8 Dec 2018 at 12:03, David Holmes > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?Hi Sergey, > >? ? ? > > >? ? ? >? ? ?Just FYI we're in the process of moving away from > using anonymous > >? ? ? >? ? ?classes for lambda's to using an extended > Lookup.defineClass > >? ? ?API - see: > >? ? ? > > >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8171335 > >? ? ? > > >? ? ? >? ? ?this is being done under Project Valhalla, with > current work > >? ? ?in the > >? ? ? >? ? ?nestmates branch. > >? ? ? > > >? ? ? >? ? ?We need to see how this example work in that case. > >? ? ? > > >? ? ? >? ? ?Cheers, > >? ? ? >? ? ?David > > > From li.jiang at oracle.com Wed Jan 2 06:06:25 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Wed, 2 Jan 2019 14:06:25 +0800 Subject: UnicodeDecoder U+FFFE handling In-Reply-To: References: Message-ID: Sounds this request is reasonable since Unicode 7: do not consider the U+FFFE in the middle of stream as malformed. FAQ about private use characters and non-characters. [1] http://www.unicode.org/faq/private_use.html Q: Are noncharacters invalid in Unicode strings and UTFs? A: Absolutely not. Noncharacters do not cause a Unicode string to be ill-formed in any UTF. Q: So how should libraries and tools handle noncharacters? A: Library APIs, components, and tool applications (such as low-level text editors) which handle all Unicode strings should also handle noncharacters. Often this means simple pass-through, the same way such an API or tool would handle a reserved unassigned code point. Thanks Leo On 12/24/18 3:06 AM, Cl?ment MATHIEU wrote: > Hi, > > I am wondering if UnicodeDecoder handling of U+FFFE is compliant with > current Unicode specification. Supsicious code is: > > if (c == REVERSED_MARK) { > // A reversed BOM cannot occur within middle of stream > return CoderResult.malformedForLength(2); > } > > Up to Unicode 6.3 Unicode specification said that U+FFFE is a non > character and that non characters "should never been interchanged". > Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8 > (Unicode 6.2). > > However, Unicode 7 changed that and now says: > > Applications are free to use any of these noncharacter code > points internally. They have no standard interpretation when > exchanged outside the context of internal use. However, they are > not illegal in interchange, nor does their presence cause Unicode > text to be ill-formed. [...] They are not prohibited from > occurring in valid Unicode strings which happen to be in > terchanged. [...]. If a noncharacter is received in open > interchange, an application is not required to interpret it in > any way. It is good practice, however, to recognize it as a > noncharacter and to take appropriate action, such as replacing it > with U+FFFD replacement character, to indicate > the problem in the text. It is not recommended to simpl > y delete noncharacter code points from such text, because of > the potential security issues caused by deleting uninterpreted > characters. > > See: > - http://www.unicode.org/versions/corrigendum9.html > - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7) > > Do you think that returning CR_MALFORMED is still OK? > > Regards, > Cl?ment MATHIEU > From claes.redestad at oracle.com Wed Jan 2 08:44:20 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 09:44:20 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> Message-ID: <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> Hi, new webrev: http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ - Adds a forgotten String.valueOf in println(String), making sure all methods are semantically the same for - Remove the isInternal method and use only exact match with PrintStream.class to determine whether to use the optimized paths. As before: On 2018-12-14 21:22, Claes Redestad wrote: > Same performance characteristics in the simple tests I've used to > verify this, and no measurable regression (but no speed-up) for classes > overriding PrintStream. I've withdrawn the related CSR, since it's not relevant for this implementation as it doesn't observably alter behavior of types inheriting from PrintStream. Thanks! /Claes From Alan.Bateman at oracle.com Wed Jan 2 11:45:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 11:45:15 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: <61d492fa-5b08-7847-01f1-492725aae4a6@oracle.com> On 21/12/2018 13:43, Langer, Christoph wrote: > Hi Alan, > >> Adding support for POSIX file permissions to the zip APIs is problematic >> as we've been discussing here. There are security concerns and also >> concerns that how it interacts with JAR files and signed JAR in >> particular. I don't disagree that we can come to agreement on zipfs >> supporting a solution but I think we need to get the bigger picture on >> where this is going first. If the piece to change the java.util.zip APIs >> is dropped then it would make these discussions a lot simpler as it >> removes most of the security issues from the table. > Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. > I've looked at the updated CSR. It would be good to include the spec changes, meaning the javadoc update to jdk.zipfs/module-info.java where it will document that it supports PosixFileAttributeView. I suspect there is also a discussion point around owner/group as I can't tell from the CSR if the UNIX extra fields are being used to encode the uid/gid (the original spec did not envisage supporting PosixFileAttributeView without also supporting file ownership). -Alan From forax at univ-mlv.fr Wed Jan 2 12:05:13 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Jan 2019 13:05:13 +0100 (CET) Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> Message-ID: <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> Hi Claes, did you try instead of having a field 'internal' to inline the class check (this.getClass() == PrintStream.class) at every call site you are reading that field ? for a method like println(), the VM has to do a class check (if CHA is defeated) before entering the method println so the JIT might be able to remove the check this.getClass() == PrintStream.class because it already know at that point that the current class is PrintStream. happy new year, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Roger Riggs" , "core-libs-dev" > Envoy?: Mercredi 2 Janvier 2019 09:44:20 > Objet: Re: RFR: 8215412: Optimize PrintStream.println methods > Hi, > > new webrev: > > http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ > > - Adds a forgotten String.valueOf in println(String), making sure all > methods are semantically the same for > - Remove the isInternal method and use only exact match with > PrintStream.class to determine whether to use the optimized paths. > > As before: > > On 2018-12-14 21:22, Claes Redestad wrote: >> Same performance characteristics in the simple tests I've used to >> verify this, and no measurable regression (but no speed-up) for classes >> overriding PrintStream. > > I've withdrawn the related CSR, since it's not relevant for this > implementation as it doesn't observably alter behavior of types > inheriting from PrintStream. > > Thanks! > > /Claes From claes.redestad at oracle.com Wed Jan 2 12:29:18 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 13:29:18 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> Message-ID: <7986ef57-2ccd-fda1-c73b-601e7505e806@oracle.com> Hi R?mi, On 2019-01-02 13:05, Remi Forax wrote: > Hi Claes, > did you try instead of having a field 'internal' to inline the class check (this.getClass() == PrintStream.class) at every call site you are reading that field ? > > for a method like println(), the VM has to do a class check (if CHA is defeated) before entering the method println so the JIT might be able to remove the check this.getClass() == PrintStream.class because it already know at that point that the current class is PrintStream. interesting idea - I'll try it out. I don't expect it to make much of a difference in my current (trivial) tests, but perhaps in a slightly more contrived setup. happy new year! /Claes From Roger.Riggs at oracle.com Wed Jan 2 15:26:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 2 Jan 2019 07:26:21 -0800 (PST) Subject: RFR 6996807 : FieldReflectorKey hash code computation can be improved In-Reply-To: <727bdb40-7386-f96a-40a3-e923b08454b1@oracle.com> References: <489a4621-b763-8d8e-f4d0-4d611eb4f196@oracle.com> <727bdb40-7386-f96a-40a3-e923b08454b1@oracle.com> Message-ID: <8d76026b-aa80-2c7b-b4e9-b1fc6c40015b@oracle.com> Hi Ivan, Happy New Year! This looks fine. The indentation of line 2311 makes it harder to see all the conditions for the true case. No new webrev needed. Thanks, Roger On 12/31/2018 11:12 PM, Ivan Gerasimov wrote: > Gentle ping. > > I updated the copyright year, as it seems unlikely this fix is going > to be reviewed in 2018 :) > > Happy New Year to everyone! > > Ivan > > > On 12/18/18 2:42 AM, Ivan Gerasimov wrote: >> Hello! >> >> FieldReflectorKey class contains a combined-string representation of >> the fields (their names and signatures). >> >> This string is used for calculating the hash code and comparing two >> FieldReflectorKey objects for equality, which is expensive. >> >> It is proposed to store the names and signatures (which are likely to >> be interned) in an array an use this array for both tasks utilizing >> Arrays.hashCode() and Arrays.equals(). >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6996807 >> WEBREV: http://cr.openjdk.java.net/~igerasim/6996807/00/webrev/ >> >> Would you please help review the fix? >> > From GROEGES at uk.ibm.com Wed Jan 2 16:33:53 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 2 Jan 2019 16:33:53 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods Message-ID: I am looking into an issue where the Class.getDeclaredMethods() is returning inherited methods, where the Java Doc here:- https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() states:- "Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods". with the last part of the statement being the relevant part, "but excluding inherited methods" This was raised as an issue a long time ago: https://bugs.openjdk.java.net/browse/JDK-6815786 but has not been fixed and is still an issue in JDK11. Before I go looking into why this is occurring and producing a fix, is this still seen as an issue and does it need to be fixed / should it be fixed. I dont want to do lots of investigation and produce a fix just to be told we cant contribute this as it will break too many people that might have been using this feature !!!! Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From peter.levart at gmail.com Wed Jan 2 17:45:12 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 2 Jan 2019 18:45:12 +0100 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: Message-ID: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> Hi Steve, What you have observed is an artifact of how Java the language is compiled into bytecode contained in .class files and the fact that Java reflection API returns information about the compiled .class files. The quoted sample code: package x.y; class A { ? public void m() { ? } } public class B { } ...is one example where the compiler must create a synthetic method in class B which overrides public method in class A and delegates to it. Java access checks allow invoking A.m() only from package x.y since A is a package private class. OTOH m() is a public method and as such is inherited by B. so m() can be called on an instance of type B from anywhere because B is a public class. To accommodate that, javac synthesizes public method B.m() which delegates to A.m() as thought you would have written the following code: package x.y; class A { ? public void m() { ? } } public class B { ? public void m() { ??? super.m(); ? } } ... B.class.getDeclaredMethods() therefore returns this synthetic method B.m() and not the inherited method A.m(). You can verify that by invoking .getDeclaringClass() on it, which should give you B.class and not A.class. Strictly speaking such synthetic method on B is not really needed by JVM to invoke A.m() from anywhere via the instance of B. Invocation of m() given an instance of B could be compiled by javac in exactly the same way even if there was no synthetic method B.m(). Javac could pretend there is a method B.m() and emit invoke instruction referencing the imaginative method. At runtime JVM would dispatch the virtual call to inherited A.m and allow such call from anywhere since it references a public method in a public class (although imaginative). The only reason javac generates synthetic method B.m() is to actually allow A.m() to be called via reflection API. Reflection API does not allow invoking A.m() directly from anywhere, but it allows invoking the synthetic B.m() which then delegates to A.m(). If we wanted to get rid of this synthetic method, reflection would have to be fixed 1st to accommodate calling public methods inherited from non-public classes if they are called via an instance of a public subclass (or a subclass of it). The reason this has not been done yet is probably that it is more tricky that it seems at first. Imagine the following situation: package p1; class A { ??? public void m() { ??? } } public class B extends A { } package p2; class C extends B { } public class Builder { ??? public static B build() { ??? ??? return new C(); ??? } } package p3; public class App { ??? public static void main(String[] args) { ??? ??? B b = p2.Builder.build(); ??????? b.m(); // << HERE ??? } } ...javac would have an easy job here. It knows the static (compile-time) type of variable b (which is a public class B) so it can directly emit invoke instruction for imaginative method B.m() here. Reflection API OTOH has a more difficult job in the following code: package p3; public class App { ??? public static void main(String[] args) { ??? ??? B b = p2.Builder.build(); ??????? Method m = B.class.getMethod("m"); // m.getDeclatingClass() == A.class ??????? m.invoke(b); // << HERE ??? } } ...reflection has at its disposal: - a Method object 'm' representing method A.m() which is located in a non-public class p1.A - a target instance 'b' which is of type p2.C which is also a non-public class - the invocation is being performed from package p3 In order for reflection to allow such invocation it would have to assume that such invocation is performed via some imaginative method X.m() such that: - X is a public class and is a subclass of A - C is a subclass of X Such decision is inherently non-local meaning that reflection would have to search class hierarchy to allow it. It is possible though, but probably to complicated for such use case. What do others think? Regards, Peter On 1/2/19 5:33 PM, Steve Groeger wrote: > I am looking into an issue where the Class.getDeclaredMethods() is > returning inherited methods, > where the Java Doc here:- > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() > states:- > > "Returns an array containing Method objects reflecting all the declared > methods of the class or interface represented by this Class object, > including public, protected, default (package) access, and private > methods, but excluding inherited methods". > > with the last part of the statement being the relevant part, "but > excluding inherited methods" > > This was raised as an issue a long time ago: > https://bugs.openjdk.java.net/browse/JDK-6815786 but has not been fixed > and is still an issue in JDK11. > > Before I go looking into why this is occurring and producing a fix, is > this still seen as an issue and does it need to be fixed / should it be > fixed. > I dont want to do lots of investigation and produce a fix just to be told > we cant contribute this as it will break too many people that might have > been using this feature !!!! > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From james.laskey at oracle.com Wed Jan 2 18:02:59 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 2 Jan 2019 14:02:59 -0400 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 Message-ID: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Looking for reviewers to make sure this CSR passes muster. CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 Thank you. Cheers, ? Jim From claes.redestad at oracle.com Wed Jan 2 18:17:43 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 19:17:43 +0100 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections Message-ID: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> Hi, the Set and List implementations in java.util.ImmutableCollections inherits toArray from AbstractCollection, whose implementations always fall back to an iterator-based approach. Additionally there's logic to deal with not getting the expected number of elements from the iterator, which can't happen for these immutable collections. This patch add specialized implementations, along with a microbenchmark to back up the claim that these are actually faster (a few tests I created when working on JDK-8193128 are also included). Webrev: http://cr.openjdk.java.net/~redestad/8215995/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215995 Test running: java -jar build/linux-x64/images/test/micro/benchmarks.jar Immutable.*to -f 5 -w 4 -r 4: Baseline: Benchmark Mode Cnt Score Error Units ImmutableColls.toArrayFromList thrpt 25 2.949 ? 0.031 ops/us ImmutableColls.toArrayFromSet thrpt 25 3.822 ? 0.075 ops/us ImmutableColls.toTypedArrayFromList thrpt 25 2.474 ? 0.023 ops/us ImmutableColls.toTypedArrayFromSet thrpt 25 3.237 ? 0.085 ops/us Patch: Benchmark Mode Cnt Score Error Units ImmutableColls.toArrayFromList thrpt 25 7.939 ? 0.101 ops/us ImmutableColls.toArrayFromSet thrpt 25 5.399 ? 0.099 ops/us ImmutableColls.toTypedArrayFromList thrpt 25 3.941 ? 0.003 ops/us ImmutableColls.toTypedArrayFromSet thrpt 25 4.111 ? 0.101 ops/us These micros use a mix of Set12/SetN and List12/ListN/SubList - larger speedups could be provoked if only testing 1 and 2-elements lists and sets, but I don't want to be too synthetic. Thanks! /Claes From martinrb at google.com Wed Jan 2 19:00:35 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Jan 2019 11:00:35 -0800 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> Message-ID: Looks good to me. Can you explain why there are two identical test methods get and get2 ? I was surprised by the use of SALT in SetN. I'm guessing you could improve SetN by adapting the tricky circular array traversal code from ArrayDeque. I'm not convinced that the extra non-determinism from negative SALT pulls its weight. On Wed, Jan 2, 2019 at 10:12 AM Claes Redestad wrote: > Hi, > > the Set and List implementations in java.util.ImmutableCollections > inherits toArray from AbstractCollection, whose implementations always > fall back to an iterator-based approach. Additionally there's logic to > deal with not getting the expected number of elements from the iterator, > which can't happen for these immutable collections. > > This patch add specialized implementations, along with a microbenchmark > to back up the claim that these are actually faster (a few tests I > created when working on JDK-8193128 are also included). > > Webrev: http://cr.openjdk.java.net/~redestad/8215995/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215995 > > Test running: > java -jar build/linux-x64/images/test/micro/benchmarks.jar Immutable.*to > -f 5 -w 4 -r 4: > > Baseline: > Benchmark Mode Cnt Score Error Units > ImmutableColls.toArrayFromList thrpt 25 2.949 ? 0.031 ops/us > ImmutableColls.toArrayFromSet thrpt 25 3.822 ? 0.075 ops/us > ImmutableColls.toTypedArrayFromList thrpt 25 2.474 ? 0.023 ops/us > ImmutableColls.toTypedArrayFromSet thrpt 25 3.237 ? 0.085 ops/us > > Patch: > Benchmark Mode Cnt Score Error Units > ImmutableColls.toArrayFromList thrpt 25 7.939 ? 0.101 ops/us > ImmutableColls.toArrayFromSet thrpt 25 5.399 ? 0.099 ops/us > ImmutableColls.toTypedArrayFromList thrpt 25 3.941 ? 0.003 ops/us > ImmutableColls.toTypedArrayFromSet thrpt 25 4.111 ? 0.101 ops/us > > These micros use a mix of Set12/SetN and List12/ListN/SubList - > larger speedups could be provoked if only testing 1 and 2-elements lists > and sets, but I don't want to be too synthetic. > > Thanks! > > /Claes > From claes.redestad at oracle.com Wed Jan 2 19:16:46 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 20:16:46 +0100 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> Message-ID: <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> Hi Martin, On 2019-01-02 20:00, Martin Buchholz wrote: > Looks good to me. thanks! > > Can you explain why there are two identical test methods get and get2 ? It was to provoke the expected level of mono-, bi- and megamorphicness at each callsite depending on the method under test, while ensuring the different benchmarks doesn't pollute eachother. I should add a comment about that... > > I was surprised by the use of SALT in SetN. I'm guessing you could > improve SetN by adapting the tricky circular array traversal code from > ArrayDeque. > I'm not convinced that the extra non-determinism from negative SALT > pulls its weight. This is one of Stuart's designs - the goal being to avoid situations where tests and production code create an unintended dependency on the iteration order - giving us more freedom to change hash algorithm etc. Since the SALT is calculated only once the untaken paths should be DCE'd, so we're not paying any real cost for this. (I'm guilty of moving the use of SALT from creation time to the iterators, though, to at least ensure consistent run-to-run memory layout of SetN/MapN so that we can archive these collections) /Claes > > On Wed, Jan 2, 2019 at 10:12 AM Claes Redestad From martinrb at google.com Wed Jan 2 19:26:20 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Jan 2019 11:26:20 -0800 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> Message-ID: On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad wrote: > > > I was surprised by the use of SALT in SetN. I'm guessing you could > > improve SetN by adapting the tricky circular array traversal code from > > ArrayDeque. > > I'm not convinced that the extra non-determinism from negative SALT > > pulls its weight. > > This is one of Stuart's designs - the goal being to avoid > situations where tests and production code create an unintended > dependency on the iteration order - giving us more freedom to change > hash algorithm etc. Since the SALT is calculated only once the untaken > paths should be DCE'd, so we're not paying any real cost for this. > > you could elide the creation of an Iterator object in toArray. you could elide the bounds check on the second leg of the iteration if you rewrote the loop in ArrayDeque style. But on modern hardware with a modern JIT you might not even notice. From claes.redestad at oracle.com Wed Jan 2 19:52:36 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 20:52:36 +0100 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> Message-ID: <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> Hi, On 2019-01-02 20:26, Martin Buchholz wrote: > > > On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad > > wrote: > > > > I was surprised by the use of SALT in SetN. I'm guessing you could > > improve SetN by adapting the tricky circular array traversal code > from > > ArrayDeque. > > I'm not convinced that the extra non-determinism from negative SALT > > pulls its weight. > > This is one of Stuart's designs - the goal being to avoid > situations where tests and production code create an unintended > dependency on the iteration order - giving us more freedom to change > hash algorithm etc. Since the SALT is calculated only once the untaken > paths should be DCE'd, so we're not paying any real cost for this. > > > you could elide the creation of an Iterator object in toArray. I'm assuming you mean SetN::toArray, and yes I could, but that'd require replicating most of the logic in SetNIterator which didn't seem worthwhile to get rid of an iterator allocation. I can run the numbers: likely a quite small improvement, which I'm not sure will be worth the extra duplication. > you could elide the bounds check on the second leg of the iteration if > you rewrote the loop in ArrayDeque style. Which bounds check? If this is about the if (SALT >= 0)..else-construct in SetNIterator::nextIndex then the JIT should ideally only care about the live branch (since SALT doesn't mutate the other leg is effectively dead). This matches my reading of the JITted code as given by running micros with -prof perfasm > But on modern hardware with a modern JIT you might not even notice. That's definitely a possibility. I do try look at behavior in the interpreter and -XX:TierStopAtLevel=1 as a gauge for how things behave in simpler worlds. :-) /Claes From jan.lahoda at oracle.com Wed Jan 2 19:46:49 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 Jan 2019 20:46:49 +0100 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> References: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Message-ID: <5C2D1529.4090802@oracle.com> Done. I've changed the Compatibility Kind to "source" (as I guess it better reflects the change, and the original CSR appears to have it as well) and added "Language Construct" to Interface Kind. Jan On 2.1.2019 19:02, Jim Laskey wrote: > Looking for reviewers to make sure this CSR passes muster. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 > > Thank you. > > Cheers, > > ? Jim > > From martinrb at google.com Wed Jan 2 19:55:51 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Jan 2019 11:55:51 -0800 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> Message-ID: I'm happy with what you've got now. On Wed, Jan 2, 2019 at 11:46 AM Claes Redestad wrote: > Hi, > > On 2019-01-02 20:26, Martin Buchholz wrote: > > > > > > On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad > > > wrote: > > > > > > > I was surprised by the use of SALT in SetN. I'm guessing you could > > > improve SetN by adapting the tricky circular array traversal code > > from > > > ArrayDeque. > > > I'm not convinced that the extra non-determinism from negative > SALT > > > pulls its weight. > > > > This is one of Stuart's designs - the goal being to avoid > > situations where tests and production code create an unintended > > dependency on the iteration order - giving us more freedom to change > > hash algorithm etc. Since the SALT is calculated only once the > untaken > > paths should be DCE'd, so we're not paying any real cost for this. > > > > > > you could elide the creation of an Iterator object in toArray. > > I'm assuming you mean SetN::toArray, and yes I could, but that'd require > replicating most of the logic in SetNIterator which didn't seem > worthwhile to get rid of an iterator allocation. I can run the numbers: > likely a quite small improvement, which I'm not sure will be worth the > extra duplication. > > > you could elide the bounds check on the second leg of the iteration if > > you rewrote the loop in ArrayDeque style. > > Which bounds check? On the second leg, you know you'll never hit the end of the array, so you can elide the check. But hotspot may not be so clever and may re-insert it, in a slightly more expensive variant that has actual exception throwing code. > If this is about the if (SALT >= 0)..else-construct > in SetNIterator::nextIndex then the JIT should ideally only care about > the live branch (since SALT doesn't mutate the other leg is effectively > dead). This matches my reading of the JITted code as given by running > micros with -prof perfasm > > I never added perfasm to my toolbox. Maybe next year. Oh wait, it's already next year ... > > But on modern hardware with a modern JIT you might not even notice. > > That's definitely a possibility. I do try look at behavior in the > interpreter and -XX:TierStopAtLevel=1 as a gauge for how things behave > in simpler worlds. :-) > > I do something similar with my less sophisticated benchmark. > /Claes > From claes.redestad at oracle.com Wed Jan 2 20:17:06 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 21:17:06 +0100 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> Message-ID: <88e7b229-06a5-e308-de6d-b9c8311eb61b@oracle.com> On 2019-01-02 20:55, Martin Buchholz wrote: > Which bounds check? > > > On the second leg, you know you'll never hit the end of the array, so > you can elide the check.? But hotspot may not be so clever and may > re-insert it, in a slightly more expensive variant that has actual > exception throwing code. I see what you mean now and perhaps that'd eliminate a branch per element if we did toArray inline rather than use an iterator. Might be a reasonable optimization that can stand on it's own in a follow-up. /Claes From claes.redestad at oracle.com Wed Jan 2 20:32:09 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 21:32:09 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <7986ef57-2ccd-fda1-c73b-601e7505e806@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> <7986ef57-2ccd-fda1-c73b-601e7505e806@oracle.com> Message-ID: <9a358a03-b380-08ac-f27a-e7638b0d8bfe@oracle.com> Hi again, as expected not much of a difference on the test I was using (a small cost on the startup/warmup numbers due replacing a boolean check with a method call), but on a test that adds in a few extended PrintStreams and mixes those with use of System.out I can get a ~3-4% statistical improvement with your idea - so I think it's better to peel off the PrintStream.class check like this: http://cr.openjdk.java.net/~redestad/8215412/jdk.03/ Thanks! /Claes On 2019-01-02 13:29, Claes Redestad wrote: > Hi R?mi, > > > On 2019-01-02 13:05, Remi Forax wrote: >> Hi Claes, >> did you try instead of having a field 'internal' to inline the class >> check (this.getClass() == PrintStream.class) at every call site you >> are reading that field ? >> >> for a method like println(), the VM has to do a class check (if CHA is >> defeated) before entering the method println so the JIT might be able >> to remove the check this.getClass() == PrintStream.class because it >> already know at that point that the current class is PrintStream. > > interesting idea - I'll try it out. I don't expect it to make much of a > difference in my current (trivial) tests, but perhaps in a slightly more > contrived setup. > > happy new year! > > /Claes From sergei.tsypanov at yandex.ru Wed Jan 2 21:56:46 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 02 Jan 2019 23:56:46 +0200 Subject: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1 Message-ID: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> Hello, -XX:TieredStopAtLevel=1 flag is often used in some applications (e.g. Spring Boot based) to reduce start-up time. With this flag I've spotted huge performance degradation of Array::newInstance comparing to plain constructor call. I've used this benchmark @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class ArrayInstantiationBenchmark { @Param({"10", "100", "1000"}) private int length; @Benchmark public Object newInstance() { return Array.newInstance(Object.class, length); } @Benchmark public Object constructor() { return new Object[length]; } } On C2 (JDK 11) both methods perform the same: Benchmark (length) Mode Cnt Score Error Units ArrayInstantiationBenchmark.constructor 10 avgt 50 11,557 ? 0,316 ns/op ArrayInstantiationBenchmark.constructor 100 avgt 50 86,944 ? 4,945 ns/op ArrayInstantiationBenchmark.constructor 1000 avgt 50 520,722 ? 28,068 ns/op ArrayInstantiationBenchmark.newInstance 10 avgt 50 11,899 ? 0,569 ns/op ArrayInstantiationBenchmark.newInstance 100 avgt 50 86,805 ? 5,103 ns/op ArrayInstantiationBenchmark.newInstance 1000 avgt 50 488,647 ? 20,829 ns/op On C1 however there's a huge difference (approximately 8 times!) for length = 10: Benchmark (length) Mode Cnt Score Error Units ArrayInstantiationBenchmark.constructor 10 avgt 50 11,183 ? 0,168 ns/op ArrayInstantiationBenchmark.constructor 100 avgt 50 92,215 ? 4,425 ns/op ArrayInstantiationBenchmark.constructor 1000 avgt 50 838,303 ? 33,161 ns/op ArrayInstantiationBenchmark.newInstance 10 avgt 50 86,696 ? 1,297 ns/op ArrayInstantiationBenchmark.newInstance 100 avgt 50 106,751 ? 2,796 ns/op ArrayInstantiationBenchmark.newInstance 1000 avgt 50 840,582 ? 24,745 ns/op Pay attention that performance for length = {100, 1000} is almost the same. I suppose it's a bug somewhere on VM because both methods just allocate memory and do zeroing elimination and subsequently there shouldn't be such a huge difference between them. Sergey Tsypanov From javalists at cbfiddle.com Wed Jan 2 22:51:50 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 2 Jan 2019 14:51:50 -0800 Subject: enhanced for loop with multiple iteration variables In-Reply-To: <1348325550.82953.1546370166932.JavaMail.zimbra@u-pem.fr> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> <4AA5A92A-A2A0-4423-9596-ED203651FC65@cbfiddle.com> <1348325550.82953.1546370166932.JavaMail.zimbra@u-pem.fr> Message-ID: <46239E48-214D-4BF8-8896-EC3636E55ABF@cbfiddle.com> Thank you for your informative response. What you describe sounds very promising. (I hope the extra parentheses will not be required, though.) I take it that by ?no runtime cost? you mean that something like the following would do only one heap allocation (for the iterator)? T[] array; for (int index, T element : Arrays.indexedElements(array)) { ... } Map.entrySet() is not a good test of performance since the Entry objects already exist and are returned without copying. Alan > On Jan 1, 2019, at 11:16 AM, Remi Forax wrote: > > ----- Mail original ----- >> De: "Alan Snyder" >> ?: "Brian Goetz" >> Cc: "core-libs-dev" >> Envoy?: Vendredi 21 D?cembre 2018 03:19:14 >> Objet: Re: enhanced for loop with multiple iteration variables > >> RIght, but I don?t see that as a general solution. >> >> Its also a bit kludgy, like saying that methods need only one parameter because >> you can always pass a data object. > > yes, that's the point, as part of Valhalla, we want to introduce value types in Java. > A value type is an almost zero cost abstraction that let you group and ungroup values. > > Also as part of Amber, we want to be able to de-construct record types (product types) in order to support pattern matching. > > If we have value types and de-construction, we are not far be able to write something like: > for((var key, var value): map.entrySet()) { > // ... > } > with no runtime cost. > > So being able to use the enhanced for loop on tuples is clearly something we want to have, but to achieve that goal i don't think that introducing a new Iterator2 interface is the right way to do that. > > regards, > R?mi > > >> >>> On Dec 20, 2018, at 2:50 PM, Brian Goetz wrote: >>> >>> For Map, you can do: >>> >>> for (Map.Entry e : map.entrySet()) { ... } >>> >>> and you're already there. >>> >>> >>> >>> On 12/19/2018 9:54 AM, Alan Snyder wrote: >>>> Has any consideration been given to supporting iterators that provide more than >>>> one iteration variable in the enhanced for loop? >>>> >>>> Obvious uses would be maps (keys and values) and lists (indexes and values). >>>> >>>> I have in mind keeping the syntactic sugar approach by using one or more >>>> extensions of the Iterator/Iterable interfaces, such as, for example: >>>> >>>> interface Iterator2 extends Iterator { >>>> E2 get2(); >>>> } >>>> >>>> with the extra methods providing the values for the extra variables (associated >>>> with the previous call to next). >>>> >>>> Extending interfaces is not required, but it makes the trailing variables >>>> optional, which might be useful. For example, the same iterator could provide >>>> values or values and keys. >>>> >>>> The fact that this approach only works for a fixed set of numbers of variables >>>> does not bother me unduly. >>>> >>>> Alan >>>> > From claes.redestad at oracle.com Wed Jan 2 23:46:26 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 3 Jan 2019 00:46:26 +0100 Subject: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1 In-Reply-To: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> References: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> Message-ID: Hi, what you're seeing specifically here is likely the native overhead: Array::newInstance calls into the native method Array::newArray, and C1 (TierStopAtLevel=1) doesn't have an intrinsic for this, while C2 does. C1 and the interpreter will instead call into Java_java_lang_reflect_Array_newArray in libjava / Array.c over JNI, which will add a rather expensive constant overhead.. TieredStopAtLevel=1/C1 performance is expected to be relatively slower than C2 in general, and often much worse in cases like this there are optimized intrinsics at play. Have you seen a regression here compared to some older JDK release? It would also be very helpful if you could shed more light on the use case and point out what particular startup issues you're seeing that prevents you from using full tiered compilation and Spring Boot. /Claes On 2019-01-02 22:56, ?????? ??????? wrote: > Hello, > > -XX:TieredStopAtLevel=1 flag is often used in some applications (e.g. Spring Boot based) to reduce start-up time. > > With this flag I've spotted huge performance degradation of Array::newInstance comparing to plain constructor call. > > I've used this benchmark > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class ArrayInstantiationBenchmark { > > @Param({"10", "100", "1000"}) > private int length; > > @Benchmark > public Object newInstance() { > return Array.newInstance(Object.class, length); > } > > @Benchmark > public Object constructor() { > return new Object[length]; > } > > } > > On C2 (JDK 11) both methods perform the same: > > Benchmark (length) Mode Cnt Score Error Units > ArrayInstantiationBenchmark.constructor 10 avgt 50 11,557 ? 0,316 ns/op > ArrayInstantiationBenchmark.constructor 100 avgt 50 86,944 ? 4,945 ns/op > ArrayInstantiationBenchmark.constructor 1000 avgt 50 520,722 ? 28,068 ns/op > > ArrayInstantiationBenchmark.newInstance 10 avgt 50 11,899 ? 0,569 ns/op > ArrayInstantiationBenchmark.newInstance 100 avgt 50 86,805 ? 5,103 ns/op > ArrayInstantiationBenchmark.newInstance 1000 avgt 50 488,647 ? 20,829 ns/op > > On C1 however there's a huge difference (approximately 8 times!) for length = 10: > > Benchmark (length) Mode Cnt Score Error Units > ArrayInstantiationBenchmark.constructor 10 avgt 50 11,183 ? 0,168 ns/op > ArrayInstantiationBenchmark.constructor 100 avgt 50 92,215 ? 4,425 ns/op > ArrayInstantiationBenchmark.constructor 1000 avgt 50 838,303 ? 33,161 ns/op > > ArrayInstantiationBenchmark.newInstance 10 avgt 50 86,696 ? 1,297 ns/op > ArrayInstantiationBenchmark.newInstance 100 avgt 50 106,751 ? 2,796 ns/op > ArrayInstantiationBenchmark.newInstance 1000 avgt 50 840,582 ? 24,745 ns/op > > Pay attention that performance for length = {100, 1000} is almost the same. > > I suppose it's a bug somewhere on VM because both methods just allocate memory and do zeroing elimination and subsequently there shouldn't be such a huge difference between them. > > Sergey Tsypanov > > From sundararajan.athijegannathan at oracle.com Thu Jan 3 02:43:24 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 03 Jan 2019 08:13:24 +0530 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> References: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Message-ID: <5C2D76CC.8080705@oracle.com> Looks good. -Sundar On 02/01/19, 11:32 PM, Jim Laskey wrote: > Looking for reviewers to make sure this CSR passes muster. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 > > Thank you. > > Cheers, > > ? Jim > > From GROEGES at uk.ibm.com Thu Jan 3 09:33:57 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 3 Jan 2019 09:33:57 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> Message-ID: Hi Peter, Thank you very much for your detailed and very informative explanation. I have one more question for clarification. If I have the following code: abstract class A { public void foo() {} } import java.lang.reflect.*; public class B extends A { public static void main(String[] args) throws Exception { System.out.println("----- getDeclaredMethods -----"); Method[] methods = B.class.getDeclaredMethods(); for( int i = 0 ; i < methods.length ; i++ ){ System.out.println(methods[i]); } } } If I compile and run this class "java --classpath . B" I get I get the following output: ----- getDeclaredMethods ----- public static void B.main(java.lang.String[]) throws java.lang.Exception public void B.foo() which seems to fit with your explanation (noting that A is an abstract class). However, if I make A a public class public class A { public void foo() {} } the output is different and doesnt contain the foo() method. ----- getDeclaredMethods ----- public static void B.main(java.lang.String[]) throws java.lang.Exception Is this as expected? Should there be a difference between the output from running the getDelaredMethods() on 1) a class extending an abstract class with a public method (non abstract) and 2) a class extending a public class with a public method? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Peter Levart To: Steve Groeger , OpenJDK Core Libs Developers Date: 02/01/2019 17:45 Subject: Re: Class.getDeclaredMethods() is returning inherited methods Hi Steve, What you have observed is an artifact of how Java the language is compiled into bytecode contained in .class files and the fact that Java reflection API returns information about the compiled .class files. The quoted sample code: package x.y; class A { public void m() { } } public class B { } ...is one example where the compiler must create a synthetic method in class B which overrides public method in class A and delegates to it. Java access checks allow invoking A.m() only from package x.y since A is a package private class. OTOH m() is a public method and as such is inherited by B. so m() can be called on an instance of type B from anywhere because B is a public class. To accommodate that, javac synthesizes public method B.m() which delegates to A.m() as thought you would have written the following code: package x.y; class A { public void m() { } } public class B { public void m() { super.m(); } } ... B.class.getDeclaredMethods() therefore returns this synthetic method B.m() and not the inherited method A.m(). You can verify that by invoking .getDeclaringClass() on it, which should give you B.class and not A.class. Strictly speaking such synthetic method on B is not really needed by JVM to invoke A.m() from anywhere via the instance of B. Invocation of m() given an instance of B could be compiled by javac in exactly the same way even if there was no synthetic method B.m(). Javac could pretend there is a method B.m() and emit invoke instruction referencing the imaginative method. At runtime JVM would dispatch the virtual call to inherited A.m and allow such call from anywhere since it references a public method in a public class (although imaginative). The only reason javac generates synthetic method B.m() is to actually allow A.m() to be called via reflection API. Reflection API does not allow invoking A.m() directly from anywhere, but it allows invoking the synthetic B.m() which then delegates to A.m(). If we wanted to get rid of this synthetic method, reflection would have to be fixed 1st to accommodate calling public methods inherited from non-public classes if they are called via an instance of a public subclass (or a subclass of it). The reason this has not been done yet is probably that it is more tricky that it seems at first. Imagine the following situation: package p1; class A { public void m() { } } public class B extends A { } package p2; class C extends B { } public class Builder { public static B build() { return new C(); } } package p3; public class App { public static void main(String[] args) { B b = p2.Builder.build(); b.m(); // << HERE } } ...javac would have an easy job here. It knows the static (compile-time) type of variable b (which is a public class B) so it can directly emit invoke instruction for imaginative method B.m() here. Reflection API OTOH has a more difficult job in the following code: package p3; public class App { public static void main(String[] args) { B b = p2.Builder.build(); Method m = B.class.getMethod("m"); // m.getDeclatingClass() == A.class m.invoke(b); // << HERE } } ...reflection has at its disposal: - a Method object 'm' representing method A.m() which is located in a non-public class p1.A - a target instance 'b' which is of type p2.C which is also a non-public class - the invocation is being performed from package p3 In order for reflection to allow such invocation it would have to assume that such invocation is performed via some imaginative method X.m() such that: - X is a public class and is a subclass of A - C is a subclass of X Such decision is inherently non-local meaning that reflection would have to search class hierarchy to allow it. It is possible though, but probably to complicated for such use case. What do others think? Regards, Peter On 1/2/19 5:33 PM, Steve Groeger wrote: > I am looking into an issue where the Class.getDeclaredMethods() is > returning inherited methods, > where the Java Doc here:- > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() > states:- > > "Returns an array containing Method objects reflecting all the declared > methods of the class or interface represented by this Class object, > including public, protected, default (package) access, and private > methods, but excluding inherited methods". > > with the last part of the statement being the relevant part, "but > excluding inherited methods" > > This was raised as an issue a long time ago: > https://bugs.openjdk.java.net/browse/JDK-6815786 but has not been fixed > and is still an issue in JDK11. > > Before I go looking into why this is occurring and producing a fix, is > this still seen as an issue and does it need to be fixed / should it be > fixed. > I dont want to do lots of investigation and produce a fix just to be told > we cant contribute this as it will break too many people that might have > been using this feature !!!! > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Thu Jan 3 11:20:17 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 3 Jan 2019 11:20:17 +0000 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? Message-ID: Hi, I'm currently investigating bug JDK-8215626 and have discovered the problem is in the Pattern interpretation of the [^..&&..] negation when applied to "intersected" expressions. So I have simplified the bug example to a more extreme and obvious example: Input string: "1234 ABCDEFG !$%^& abcdefg" pattern RegEx: "[^[A-B]&&[^ef]]" Operation: pattern.matcher(input).replaceAll(""); JDK8 output: 1234 CDEFG !$%^& abcdefg JDK11 output: AB So from the "spec" : A character class is a set of characters enclosed within square brackets. It specifies the characters that will successfully match a single character from a given input string Intersection: To create a single character class matching only the characters common to all of its nested classes, use &&, as in [0-9&&[345]]. Negation: To match all characters except those listed, insert the "^" metacharacter at the beginning of the character class. The way I read the "spec" is the "^" negation negates the whole character class within the outer square brackets, thus in this example: "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" ie.the negation of the intersect of chars A,B and everything other than e,f which is thus the negation of A,B hence the operation above will remove any character in the input string other than A,B Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is applying the ^ negation to just [A-B] and then intersecting it with [^ef], which to me is the wrong interpretation of the "spec". Your thoughts please? If JDK11 is correct, and JDK8 wrong, then the next question is do we fix JDK8? as there's obviously potential "behavioural" impacts to existing applications....? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From patrick at os.amperecomputing.com Thu Jan 3 11:23:19 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Thu, 3 Jan 2019 11:23:19 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> Message-ID: Thank you very much, David, for helping file the bug in system. Hi, Core Libraries Group, I am not quite clear who owns jdk.pack/share/native/common-unpack/zip.cpp (at jdk/jdk for example). Could anyone please help? The issue covered in this thread is a simple but a generic concern to all branches having the same declaration of "gmtime_r", and it was found with GCC 8.2 but a generic one to other versions, including the latest GCC 9. I tested the combinations such as CentOS+aarch64, Ubuntu+x86 etc., the patch works well for compilation. I have no permission to upload the webrev result to cr.openjdk.java.net, attached it << JDK-8215976.webrev.00.zip>>. If you cannot get it, see detail in https://bugs.openjdk.java.net/browse/JDK-8215976 please. Thanks for your review. Regards Patrick -----Original Message----- From: David Holmes Sent: Wednesday, January 2, 2019 7:11 AM To: Patrick Zhang ; core-libs-dev at openjdk.java.net Cc: Florian Weimer Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path 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 :( > I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- > > Regards > Patrick > > -----Original Message----- > From: core-libs-dev On Behalf > Of Patrick Zhang > Sent: Thursday, December 6, 2018 4:28 PM > To: core-libs-dev at openjdk.java.net; David Holmes > > Cc: Florian Weimer > Subject: RE: OpenJDK fails to build with GCC when the #include > inside zip.cpp comes from a non-sysroot path > > To All, > Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. > > Regards > Patrick > > -----Original Message----- > From: David Holmes > Sent: Monday, December 3, 2018 8:11 AM > To: Patrick Zhang ; Florian Weimer > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include > inside zip.cpp comes from a non-sysroot path > > Hi Patrick, > > On 30/11/2018 11:41 pm, Patrick Zhang wrote: >> Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). >> >> Hi David, >> Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. > > You'd need some assistance testing a wider range of platforms but that can be arranged. > >> In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. > _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. > > Cheers, > David > >> #ifdef _MSC_VER // Windows >> #define gmtime_r(t, s) gmtime(t) >> #endif >> >> Regards >> Patrick >> >> -----Original Message----- >> From: Florian Weimer >> Sent: Thursday, November 29, 2018 8:02 PM >> To: David Holmes >> Cc: Patrick Zhang ; >> jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: OpenJDK fails to build with GCC when the >> #include inside zip.cpp comes from a non-sysroot path >> >> * David Holmes: >> >>> This should really be being discussed on core-libs-dev. >> >> Okay, moving the conversation. >> >>>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp >>>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 >>>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 >>>> @@ -415,9 +415,7 @@ >>>> ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>>> } >>>> -#ifdef _REENTRANT // solaris >>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >>>> -#else >>>> +#if !defined(_REENTRANT) // linux >>>> #define gmtime_r(t, s) gmtime(t) >>>> #endif >>>> /* >>> >>> Under the theme "two wrongs don't make a right" the use of >>> _REENTRANT here is totally inappropriate AFAICS. It seems to be a >>> misguided attempt at determining whether we need the thread-safe >>> gmtime_r or not >>> - and the answer to that should always be yes IMHO. >>> >>> We define _REENTRANT for: >>> - linux >>> - gcc >>> - xlc >>> >>> So the original code will define: >>> >>> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >>> >>> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >>> >>> But Solaris has gmtime_r anyway. So the existing code seems a really >>> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >>> (where gmtime is already thread-safe). So it seems to me that all we >>> should need here is: >>> >>> -#ifdef _REENTRANT // solaris >>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>> +#ifdef _MSC_VER // Windows >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >> >> That looks much cleaner. >> >> Thanks, >> Florian >> From peter.levart at gmail.com Thu Jan 3 11:33:51 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Jan 2019 12:33:51 +0100 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> Message-ID: <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> Hi Steve, The difference you observe between variants of class A is not about the "abstract" vs. non-"abstract" but about "public" vs. non-"public"... Your variants of class A are: public class A { ??? public void foo() {} } vs. abstract class A { ??? public void foo() {} } The 1st is public but the 2nd is package-private. Try with the following variant: class A { ??? public void foo() {} } ... and you'll see the same behavior as with abstract package-private class. Try also with the following variant: public abstract class A { ??? public void foo() {} } ...and you'll see the same behavior as with public concrete class. The reason why javac does not generate synthetic method when extending public class is obvious. It is not needed since A.m() can be invoked from anywhere if A is public. Regards, Peter On 1/3/19 10:33 AM, Steve Groeger wrote: > Hi Peter, > > Thank you very much for your detailed and very informative explanation. I > have one more question for clarification. > If I have the following code: > > abstract class A { > public void foo() {} > } > > > import java.lang.reflect.*; > > public class B extends A { > public static void main(String[] args) throws Exception { > System.out.println("----- getDeclaredMethods -----"); > Method[] methods = B.class.getDeclaredMethods(); > for( int i = 0 ; i < methods.length ; i++ ){ > System.out.println(methods[i]); > } > } > } > > If I compile and run this class "java --classpath . B" I get I get the > following output: > > ----- getDeclaredMethods ----- > public static void B.main(java.lang.String[]) throws java.lang.Exception > public void B.foo() > > which seems to fit with your explanation (noting that A is an abstract > class). However, if I make A a public class > > public class A { > public void foo() {} > } > > > the output is different and doesnt contain the foo() method. > > ----- getDeclaredMethods ----- > public static void B.main(java.lang.String[]) throws java.lang.Exception > > Is this as expected? > > Should there be a difference between the output from running the > getDelaredMethods() on > 1) a class extending an abstract class with a public method (non abstract) > and > 2) a class extending a public class with a public method? > > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Peter Levart > To: Steve Groeger , OpenJDK Core Libs Developers > > Date: 02/01/2019 17:45 > Subject: Re: Class.getDeclaredMethods() is returning inherited > methods > > > > Hi Steve, > > What you have observed is an artifact of how Java the language is > compiled into bytecode contained in .class files and the fact that Java > reflection API returns information about the compiled .class files. The > quoted sample code: > > package x.y; > > class A { > public void m() { > } > } > > public class B { > } > > ...is one example where the compiler must create a synthetic method in > class B which overrides public method in class A and delegates to it. > Java access checks allow invoking A.m() only from package x.y since A is > a package private class. OTOH m() is a public method and as such is > inherited by B. so m() can be called on an instance of type B from > anywhere because B is a public class. To accommodate that, javac > synthesizes public method B.m() which delegates to A.m() as thought you > would have written the following code: > > package x.y; > > class A { > public void m() { > } > } > > public class B { > public void m() { > super.m(); > } > } > > > ... B.class.getDeclaredMethods() therefore returns this synthetic method > B.m() and not the inherited method A.m(). You can verify that by > invoking .getDeclaringClass() on it, which should give you B.class and > not A.class. > > Strictly speaking such synthetic method on B is not really needed by JVM > to invoke A.m() from anywhere via the instance of B. Invocation of m() > given an instance of B could be compiled by javac in exactly the same > way even if there was no synthetic method B.m(). Javac could pretend > there is a method B.m() and emit invoke instruction referencing the > imaginative method. At runtime JVM would dispatch the virtual call to > inherited A.m and allow such call from anywhere since it references a > public method in a public class (although imaginative). > > The only reason javac generates synthetic method B.m() is to actually > allow A.m() to be called via reflection API. Reflection API does not > allow invoking A.m() directly from anywhere, but it allows invoking the > synthetic B.m() which then delegates to A.m(). > > If we wanted to get rid of this synthetic method, reflection would have > to be fixed 1st to accommodate calling public methods inherited from > non-public classes if they are called via an instance of a public > subclass (or a subclass of it). The reason this has not been done yet is > probably that it is more tricky that it seems at first. Imagine the > following situation: > > package p1; > > class A { > public void m() { > } > } > > public class B extends A { > } > > > package p2; > > class C extends B { > } > > public class Builder { > public static B build() { > return new C(); > } > } > > > package p3; > > public class App { > public static void main(String[] args) { > B b = p2.Builder.build(); > b.m(); // << HERE > } > } > > > ...javac would have an easy job here. It knows the static (compile-time) > type of variable b (which is a public class B) so it can directly emit > invoke instruction for imaginative method B.m() here. > > Reflection API OTOH has a more difficult job in the following code: > > package p3; > > public class App { > public static void main(String[] args) { > B b = p2.Builder.build(); > Method m = B.class.getMethod("m"); // m.getDeclatingClass() == > A.class > m.invoke(b); // << HERE > } > } > > ...reflection has at its disposal: > > - a Method object 'm' representing method A.m() which is located in a > non-public class p1.A > - a target instance 'b' which is of type p2.C which is also a non-public > class > - the invocation is being performed from package p3 > > In order for reflection to allow such invocation it would have to assume > that such invocation is performed via some imaginative method X.m() such > that: > - X is a public class and is a subclass of A > - C is a subclass of X > > Such decision is inherently non-local meaning that reflection would have > to search class hierarchy to allow it. It is possible though, but > probably to complicated for such use case. > > What do others think? > > Regards, Peter > > > On 1/2/19 5:33 PM, Steve Groeger wrote: >> I am looking into an issue where the Class.getDeclaredMethods() is >> returning inherited methods, >> where the Java Doc here:- >> > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() > >> states:- >> >> "Returns an array containing Method objects reflecting all the declared >> methods of the class or interface represented by this Class object, >> including public, protected, default (package) access, and private >> methods, but excluding inherited methods". >> >> with the last part of the statement being the relevant part, "but >> excluding inherited methods" >> >> This was raised as an issue a long time ago: >> > https://bugs.openjdk.java.net/browse/JDK-6815786 > but has not been fixed >> and is still an issue in JDK11. >> >> Before I go looking into why this is occurring and producing a fix, is >> this still seen as an issue and does it need to be fixed / should it be >> fixed. >> I dont want to do lots of investigation and produce a fix just to be > told >> we cant contribute this as it will break too many people that might have >> been using this feature !!!! >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From GROEGES at uk.ibm.com Thu Jan 3 12:19:40 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 3 Jan 2019 12:19:40 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> Message-ID: Hi Peter, Thanks again for your explanation. It was the public vs. non-public part that I had missed and I was getting confused thinking it was related to abstract vs. non-abstract classes. The generation of the synthetic methods and why the methods are shown via the getDeclaredMethods() makes a lot more sense now. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Peter Levart To: Steve Groeger Cc: OpenJDK Core Libs Developers Date: 03/01/2019 11:33 Subject: Re: Class.getDeclaredMethods() is returning inherited methods Hi Steve, The difference you observe between variants of class A is not about the "abstract" vs. non-"abstract" but about "public" vs. non-"public"... Your variants of class A are: public class A { public void foo() {} } vs. abstract class A { public void foo() {} } The 1st is public but the 2nd is package-private. Try with the following variant: class A { public void foo() {} } ... and you'll see the same behavior as with abstract package-private class. Try also with the following variant: public abstract class A { public void foo() {} } ...and you'll see the same behavior as with public concrete class. The reason why javac does not generate synthetic method when extending public class is obvious. It is not needed since A.m() can be invoked from anywhere if A is public. Regards, Peter On 1/3/19 10:33 AM, Steve Groeger wrote: > Hi Peter, > > Thank you very much for your detailed and very informative explanation. I > have one more question for clarification. > If I have the following code: > > abstract class A { > public void foo() {} > } > > > import java.lang.reflect.*; > > public class B extends A { > public static void main(String[] args) throws Exception { > System.out.println("----- getDeclaredMethods -----"); > Method[] methods = B.class.getDeclaredMethods(); > for( int i = 0 ; i < methods.length ; i++ ){ > System.out.println(methods[i]); > } > } > } > > If I compile and run this class "java --classpath . B" I get I get the > following output: > > ----- getDeclaredMethods ----- > public static void B.main(java.lang.String[]) throws java.lang.Exception > public void B.foo() > > which seems to fit with your explanation (noting that A is an abstract > class). However, if I make A a public class > > public class A { > public void foo() {} > } > > > the output is different and doesnt contain the foo() method. > > ----- getDeclaredMethods ----- > public static void B.main(java.lang.String[]) throws java.lang.Exception > > Is this as expected? > > Should there be a difference between the output from running the > getDelaredMethods() on > 1) a class extending an abstract class with a public method (non abstract) > and > 2) a class extending a public class with a public method? > > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Peter Levart > To: Steve Groeger , OpenJDK Core Libs Developers > > Date: 02/01/2019 17:45 > Subject: Re: Class.getDeclaredMethods() is returning inherited > methods > > > > Hi Steve, > > What you have observed is an artifact of how Java the language is > compiled into bytecode contained in .class files and the fact that Java > reflection API returns information about the compiled .class files. The > quoted sample code: > > package x.y; > > class A { > public void m() { > } > } > > public class B { > } > > ...is one example where the compiler must create a synthetic method in > class B which overrides public method in class A and delegates to it. > Java access checks allow invoking A.m() only from package x.y since A is > a package private class. OTOH m() is a public method and as such is > inherited by B. so m() can be called on an instance of type B from > anywhere because B is a public class. To accommodate that, javac > synthesizes public method B.m() which delegates to A.m() as thought you > would have written the following code: > > package x.y; > > class A { > public void m() { > } > } > > public class B { > public void m() { > super.m(); > } > } > > > ... B.class.getDeclaredMethods() therefore returns this synthetic method > B.m() and not the inherited method A.m(). You can verify that by > invoking .getDeclaringClass() on it, which should give you B.class and > not A.class. > > Strictly speaking such synthetic method on B is not really needed by JVM > to invoke A.m() from anywhere via the instance of B. Invocation of m() > given an instance of B could be compiled by javac in exactly the same > way even if there was no synthetic method B.m(). Javac could pretend > there is a method B.m() and emit invoke instruction referencing the > imaginative method. At runtime JVM would dispatch the virtual call to > inherited A.m and allow such call from anywhere since it references a > public method in a public class (although imaginative). > > The only reason javac generates synthetic method B.m() is to actually > allow A.m() to be called via reflection API. Reflection API does not > allow invoking A.m() directly from anywhere, but it allows invoking the > synthetic B.m() which then delegates to A.m(). > > If we wanted to get rid of this synthetic method, reflection would have > to be fixed 1st to accommodate calling public methods inherited from > non-public classes if they are called via an instance of a public > subclass (or a subclass of it). The reason this has not been done yet is > probably that it is more tricky that it seems at first. Imagine the > following situation: > > package p1; > > class A { > public void m() { > } > } > > public class B extends A { > } > > > package p2; > > class C extends B { > } > > public class Builder { > public static B build() { > return new C(); > } > } > > > package p3; > > public class App { > public static void main(String[] args) { > B b = p2.Builder.build(); > b.m(); // << HERE > } > } > > > ...javac would have an easy job here. It knows the static (compile-time) > type of variable b (which is a public class B) so it can directly emit > invoke instruction for imaginative method B.m() here. > > Reflection API OTOH has a more difficult job in the following code: > > package p3; > > public class App { > public static void main(String[] args) { > B b = p2.Builder.build(); > Method m = B.class.getMethod("m"); // m.getDeclatingClass() == > A.class > m.invoke(b); // << HERE > } > } > > ...reflection has at its disposal: > > - a Method object 'm' representing method A.m() which is located in a > non-public class p1.A > - a target instance 'b' which is of type p2.C which is also a non-public > class > - the invocation is being performed from package p3 > > In order for reflection to allow such invocation it would have to assume > that such invocation is performed via some imaginative method X.m() such > that: > - X is a public class and is a subclass of A > - C is a subclass of X > > Such decision is inherently non-local meaning that reflection would have > to search class hierarchy to allow it. It is possible though, but > probably to complicated for such use case. > > What do others think? > > Regards, Peter > > > On 1/2/19 5:33 PM, Steve Groeger wrote: >> I am looking into an issue where the Class.getDeclaredMethods() is >> returning inherited methods, >> where the Java Doc here:- >> > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() > >> states:- >> >> "Returns an array containing Method objects reflecting all the declared >> methods of the class or interface represented by this Class object, >> including public, protected, default (package) access, and private >> methods, but excluding inherited methods". >> >> with the last part of the statement being the relevant part, "but >> excluding inherited methods" >> >> This was raised as an issue a long time ago: >> > https://bugs.openjdk.java.net/browse/JDK-6815786 > but has not been fixed >> and is still an issue in JDK11. >> >> Before I go looking into why this is occurring and producing a fix, is >> this still seen as an issue and does it need to be fixed / should it be >> fixed. >> I dont want to do lots of investigation and produce a fix just to be > told >> we cant contribute this as it will break too many people that might have >> been using this feature !!!! >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Thu Jan 3 14:22:28 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Jan 2019 09:22:28 -0500 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> Message-ID: <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> Hi, With a link to the explanation added to the issue, I think it can be closed as not-an-issue. Roger On 01/03/2019 07:19 AM, Steve Groeger wrote: > Hi Peter, > > Thanks again for your explanation. > It was the public vs. non-public part that I had missed and I was getting > confused thinking it was related to abstract vs. non-abstract classes. > The generation of the synthetic methods and why the methods are shown via > the getDeclaredMethods() makes a lot more sense now. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Peter Levart > To: Steve Groeger > Cc: OpenJDK Core Libs Developers > Date: 03/01/2019 11:33 > Subject: Re: Class.getDeclaredMethods() is returning inherited > methods > > > > Hi Steve, > > The difference you observe between variants of class A is not about the > "abstract" vs. non-"abstract" but about "public" vs. non-"public"... > > Your variants of class A are: > > public class A { > public void foo() {} > } > > vs. > > abstract class A { > public void foo() {} > } > > > The 1st is public but the 2nd is package-private. Try with the following > variant: > > class A { > public void foo() {} > } > > ... and you'll see the same behavior as with abstract package-private > class. Try also with the following variant: > > public abstract class A { > public void foo() {} > } > > ...and you'll see the same behavior as with public concrete class. > > > The reason why javac does not generate synthetic method when extending > public class is obvious. It is not needed since A.m() can be invoked > from anywhere if A is public. > > Regards, Peter > > On 1/3/19 10:33 AM, Steve Groeger wrote: >> Hi Peter, >> >> Thank you very much for your detailed and very informative explanation. > I >> have one more question for clarification. >> If I have the following code: >> >> abstract class A { >> public void foo() {} >> } >> >> >> import java.lang.reflect.*; >> >> public class B extends A { >> public static void main(String[] args) throws Exception { >> System.out.println("----- getDeclaredMethods -----"); >> Method[] methods = B.class.getDeclaredMethods(); >> for( int i = 0 ; i < methods.length ; i++ ){ >> System.out.println(methods[i]); >> } >> } >> } >> >> If I compile and run this class "java --classpath . B" I get I get the >> following output: >> >> ----- getDeclaredMethods ----- >> public static void B.main(java.lang.String[]) throws java.lang.Exception >> public void B.foo() >> >> which seems to fit with your explanation (noting that A is an abstract >> class). However, if I make A a public class >> >> public class A { >> public void foo() {} >> } >> >> >> the output is different and doesnt contain the foo() method. >> >> ----- getDeclaredMethods ----- >> public static void B.main(java.lang.String[]) throws java.lang.Exception >> >> Is this as expected? >> >> Should there be a difference between the output from running the >> getDelaredMethods() on >> 1) a class extending an abstract class with a public method (non > abstract) >> and >> 2) a class extending a public class with a public method? >> >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU >> >> >> From: Peter Levart >> To: Steve Groeger , OpenJDK Core Libs Developers >> >> Date: 02/01/2019 17:45 >> Subject: Re: Class.getDeclaredMethods() is returning inherited >> methods >> >> >> >> Hi Steve, >> >> What you have observed is an artifact of how Java the language is >> compiled into bytecode contained in .class files and the fact that Java >> reflection API returns information about the compiled .class files. The >> quoted sample code: >> >> package x.y; >> >> class A { >> public void m() { >> } >> } >> >> public class B { >> } >> >> ...is one example where the compiler must create a synthetic method in >> class B which overrides public method in class A and delegates to it. >> Java access checks allow invoking A.m() only from package x.y since A is >> a package private class. OTOH m() is a public method and as such is >> inherited by B. so m() can be called on an instance of type B from >> anywhere because B is a public class. To accommodate that, javac >> synthesizes public method B.m() which delegates to A.m() as thought you >> would have written the following code: >> >> package x.y; >> >> class A { >> public void m() { >> } >> } >> >> public class B { >> public void m() { >> super.m(); >> } >> } >> >> >> ... B.class.getDeclaredMethods() therefore returns this synthetic method >> B.m() and not the inherited method A.m(). You can verify that by >> invoking .getDeclaringClass() on it, which should give you B.class and >> not A.class. >> >> Strictly speaking such synthetic method on B is not really needed by JVM >> to invoke A.m() from anywhere via the instance of B. Invocation of m() >> given an instance of B could be compiled by javac in exactly the same >> way even if there was no synthetic method B.m(). Javac could pretend >> there is a method B.m() and emit invoke instruction referencing the >> imaginative method. At runtime JVM would dispatch the virtual call to >> inherited A.m and allow such call from anywhere since it references a >> public method in a public class (although imaginative). >> >> The only reason javac generates synthetic method B.m() is to actually >> allow A.m() to be called via reflection API. Reflection API does not >> allow invoking A.m() directly from anywhere, but it allows invoking the >> synthetic B.m() which then delegates to A.m(). >> >> If we wanted to get rid of this synthetic method, reflection would have >> to be fixed 1st to accommodate calling public methods inherited from >> non-public classes if they are called via an instance of a public >> subclass (or a subclass of it). The reason this has not been done yet is >> probably that it is more tricky that it seems at first. Imagine the >> following situation: >> >> package p1; >> >> class A { >> public void m() { >> } >> } >> >> public class B extends A { >> } >> >> >> package p2; >> >> class C extends B { >> } >> >> public class Builder { >> public static B build() { >> return new C(); >> } >> } >> >> >> package p3; >> >> public class App { >> public static void main(String[] args) { >> B b = p2.Builder.build(); >> b.m(); // << HERE >> } >> } >> >> >> ...javac would have an easy job here. It knows the static (compile-time) >> type of variable b (which is a public class B) so it can directly emit >> invoke instruction for imaginative method B.m() here. >> >> Reflection API OTOH has a more difficult job in the following code: >> >> package p3; >> >> public class App { >> public static void main(String[] args) { >> B b = p2.Builder.build(); >> Method m = B.class.getMethod("m"); // m.getDeclatingClass() == >> A.class >> m.invoke(b); // << HERE >> } >> } >> >> ...reflection has at its disposal: >> >> - a Method object 'm' representing method A.m() which is located in a >> non-public class p1.A >> - a target instance 'b' which is of type p2.C which is also a non-public >> class >> - the invocation is being performed from package p3 >> >> In order for reflection to allow such invocation it would have to assume >> that such invocation is performed via some imaginative method X.m() such >> that: >> - X is a public class and is a subclass of A >> - C is a subclass of X >> >> Such decision is inherently non-local meaning that reflection would have >> to search class hierarchy to allow it. It is possible though, but >> probably to complicated for such use case. >> >> What do others think? >> >> Regards, Peter >> >> >> On 1/2/19 5:33 PM, Steve Groeger wrote: >>> I am looking into an issue where the Class.getDeclaredMethods() is >>> returning inherited methods, >>> where the Java Doc here:- >>> > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() > >>> states:- >>> >>> "Returns an array containing Method objects reflecting all the declared >>> methods of the class or interface represented by this Class object, >>> including public, protected, default (package) access, and private >>> methods, but excluding inherited methods". >>> >>> with the last part of the statement being the relevant part, "but >>> excluding inherited methods" >>> >>> This was raised as an issue a long time ago: >>> > https://bugs.openjdk.java.net/browse/JDK-6815786 > >> but has not been fixed >>> and is still an issue in JDK11. >>> >>> Before I go looking into why this is occurring and producing a fix, is >>> this still seen as an issue and does it need to be fixed / should it be >>> fixed. >>> I dont want to do lots of investigation and produce a fix just to be >> told >>> we cant contribute this as it will break too many people that might > have >>> been using this feature !!!! >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From roger.calnan at oracle.com Thu Jan 3 16:51:44 2019 From: roger.calnan at oracle.com (Roger Calnan) Date: Thu, 3 Jan 2019 08:51:44 -0800 Subject: RFR: 8182992 Typo in DatagramPacket constructor API doc Message-ID: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> I was looking at the fix for: https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in DatagramPacket constructor API doc and searched around for other similar issues. I found: 4 in networking 2 in SQL 2 in client libs all of which are cases of missing spaces. I will ask for review of the the client ones on the client alias but was hoping to review the rest as one, as they are all very similar. Let me know if the reviews should be separated out, Thanks, Roger https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in DatagramPacket constructor API doc diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/DatagramPacket.java --- a/src/java.base/share/classes/java/net/DatagramPacket.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.base/share/classes/java/net/DatagramPacket.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -102,7 +102,7 @@ /** * Constructs a datagram packet for sending packets of length - * {@code length} with offset {@code ioffset}to the + * {@code length} with offset {@code offset} to the * specified port number on the specified host. The * {@code length} argument must be less than or equal to * {@code buf.length}. @@ -125,7 +125,7 @@ /** * Constructs a datagram packet for sending packets of length - * {@code length} with offset {@code ioffset}to the + * {@code length} with offset {@code offset} to the * specified port number on the specified host. The * {@code length} argument must be less than or equal to * {@code buf.length}. JDK-8215912 Various Typos in java.net Method Documentation https://bugs.openjdk.java.net/browse/JDK-8215912 https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/InetAddress.html#isReachable(java.net.NetworkInterface,int,int) https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/InetAddress.java#l534 diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/InetAddress.java --- a/src/java.base/share/classes/java/net/InetAddress.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.base/share/classes/java/net/InetAddress.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -531,7 +531,7 @@ * @param timeout the time, in milliseconds, before the call aborts * @throws IllegalArgumentException if either {@code timeout} * or {@code ttl} are negative. - * @return a {@code boolean}indicating if the address is reachable. + * @return a {@code boolean} indicating if the address is reachable. * @throws IOException if a network error occurs * @since 1.5 */ https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/Socket.java#l1105 https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/Socket.html#getOOBInline() diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/Socket.java --- a/src/java.base/share/classes/java/net/Socket.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.base/share/classes/java/net/Socket.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1102,7 +1102,7 @@ * Tests if {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE} is enabled. * * @return a {@code boolean} indicating whether or not - * {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE}is enabled. + * {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE} is enabled. * * @exception SocketException if there is an error * in the underlying protocol, such as a TCP error. https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLConnection.html#getHeaderField(int) https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/URLConnection.java#l684 diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/URLConnection.java --- a/src/java.base/share/classes/java/net/URLConnection.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.base/share/classes/java/net/URLConnection.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -681,7 +681,7 @@ /** * Returns the value for the {@code n}th header field. * It returns {@code null} if there are fewer than - * {@code n+1}fields. + * {@code n+1} fields. *

* This method can be used in conjunction with the * {@link #getHeaderFieldKey(int) getHeaderFieldKey} method to iterate through all JDK-8215911 Various Typos in SQL Method Documentation https://bugs.openjdk.java.net/browse/JDK-8215911 https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java#l1067 diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java --- a/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1064,7 +1064,7 @@ /** * Returns the insert row or the current row of this - * {@code CachedRowSetImpl}object. + * {@code CachedRowSetImpl} object. * * @return the {@code Row} object on which this {@code CachedRowSetImpl} * objects's cursor is positioned @@ -4326,7 +4326,7 @@ * * @param columnName a {@code String} object that must match the * SQL name of a column in this rowset, ignoring case - * @param c the new column {@code Clob}value + * @param c the new column {@code Clob} value * @throws SQLException if (1) the given column name does not match the * name of a column in this rowset, (2) the cursor is not on * one of this rowset's rows or its insert row, or (3) this https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l1136 https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l6191 diff -r abe21b82ff7c src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java --- a/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1133,7 +1133,7 @@ * as a stream of Unicode characters. * The value can then be read in chunks from the * stream. This method is particularly - * suitable for retrieving large{@code LONGVARCHAR}values. The JDBC driver will + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will * do any necessary conversion from the database format into Unicode. * The byte format of the Unicode stream must be Java UTF-8, * as specified in the Java virtual machine specification. @@ -6188,7 +6188,7 @@ * @param parameterIndex index of the first parameter is 1, the second is 2, ... * @param reader An object that contains the data to set the parameter value to. * @throws SQLException if a database access error occurs, this method is called on - * a closed {@code PreparedStatement}or if parameterIndex does not correspond to a parameter + * a closed {@code PreparedStatement} or if parameterIndex does not correspond to a parameter * marker in the SQL statement * * @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method From naoto.sato at oracle.com Thu Jan 3 16:56:10 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 3 Jan 2019 08:56:10 -0800 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates Message-ID: Hello, Please review the fix to the following issue (and its approved CSR): https://bugs.openjdk.java.net/browse/JDK-8215303 https://bugs.openjdk.java.net/browse/JDK-8215305 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ This is a spec only modification that will allow future code point additions to the Unicode currency symbols block without any spec changes. This is especially important for update releases (such as 8u) without releasing a Maintenance Release. Naoto From Roger.Riggs at oracle.com Thu Jan 3 16:56:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Jan 2019 11:56:38 -0500 Subject: [PATCH] Remove unused variables in io_util_md.c handleLseek In-Reply-To: References: Message-ID: Hi Andrew, Created Jira 8216067 and will sponsor the patch. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-luo-patch-8216067-1/ Thanks and Happy New Year, Roger On 12/21/2018 10:19 PM, Andrew Luo wrote: > While looking through this code debugging another issue I noticed there were some extra unused local variables. Patch is inline below. > > Thanks, > > -Andrew > > diff --git a/src/java.base/windows/native/libjava/io_util_md.c b/src/java.base/windows/native/libjava/io_util_md.c > --- a/src/java.base/windows/native/libjava/io_util_md.c > +++ b/src/java.base/windows/native/libjava/io_util_md.c > @@ -559,8 +559,6 @@ > handleLseek(FD fd, jlong offset, jint whence) > { > LARGE_INTEGER pos, distance; > - DWORD lowPos = 0; > - long highPos = 0; > DWORD op = FILE_CURRENT; > HANDLE h = (HANDLE)fd; > From sean.coffey at oracle.com Thu Jan 3 17:00:56 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Jan 2019 17:00:56 +0000 Subject: RFR: 8182992 Typo in DatagramPacket constructor API doc In-Reply-To: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> References: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> Message-ID: Looks fine to me. We can update the bug summary to make it more general to affected classes. I can help sponsor this change if required. regards, Sean. On 03/01/2019 16:51, Roger Calnan wrote: > I was looking at the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in DatagramPacket constructor API doc > > and searched around for other similar issues. I found: > > 4 in networking > 2 in SQL > 2 in client libs > > all of which are cases of missing spaces. I will ask for review of the the client ones on the > client alias but was hoping to review the rest as one, as they are all very similar. Let me > know if the reviews should be separated out, > > Thanks, > > Roger > > > https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in DatagramPacket constructor API doc > diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/DatagramPacket.java > --- a/src/java.base/share/classes/java/net/DatagramPacket.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.base/share/classes/java/net/DatagramPacket.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -102,7 +102,7 @@ > > /** > * Constructs a datagram packet for sending packets of length > - * {@code length} with offset {@code ioffset}to the > + * {@code length} with offset {@code offset} to the > * specified port number on the specified host. The > * {@code length} argument must be less than or equal to > * {@code buf.length}. > @@ -125,7 +125,7 @@ > > /** > * Constructs a datagram packet for sending packets of length > - * {@code length} with offset {@code ioffset}to the > + * {@code length} with offset {@code offset} to the > * specified port number on the specified host. The > * {@code length} argument must be less than or equal to > * {@code buf.length}. > > JDK-8215912 Various Typos in java.net Method Documentation > https://bugs.openjdk.java.net/browse/JDK-8215912 > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/InetAddress.html#isReachable(java.net.NetworkInterface,int,int) > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/InetAddress.java#l534 > > diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/InetAddress.java > --- a/src/java.base/share/classes/java/net/InetAddress.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.base/share/classes/java/net/InetAddress.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -531,7 +531,7 @@ > * @param timeout the time, in milliseconds, before the call aborts > * @throws IllegalArgumentException if either {@code timeout} > * or {@code ttl} are negative. > - * @return a {@code boolean}indicating if the address is reachable. > + * @return a {@code boolean} indicating if the address is reachable. > * @throws IOException if a network error occurs > * @since 1.5 > */ > > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/Socket.java#l1105 > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/Socket.html#getOOBInline() > > diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/Socket.java > --- a/src/java.base/share/classes/java/net/Socket.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.base/share/classes/java/net/Socket.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1102,7 +1102,7 @@ > * Tests if {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE} is enabled. > * > * @return a {@code boolean} indicating whether or not > - * {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE}is enabled. > + * {@link SocketOptions#SO_OOBINLINE SO_OOBINLINE} is enabled. > * > * @exception SocketException if there is an error > * in the underlying protocol, such as a TCP error. > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLConnection.html#getHeaderField(int) > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.base/share/classes/java/net/URLConnection.java#l684 > > diff -r 3d0f6ef91216 src/java.base/share/classes/java/net/URLConnection.java > --- a/src/java.base/share/classes/java/net/URLConnection.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.base/share/classes/java/net/URLConnection.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -681,7 +681,7 @@ > /** > * Returns the value for the {@code n}th header field. > * It returns {@code null} if there are fewer than > - * {@code n+1}fields. > + * {@code n+1} fields. > *

> * This method can be used in conjunction with the > * {@link #getHeaderFieldKey(int) getHeaderFieldKey} method to iterate through all > > > > > JDK-8215911 Various Typos in SQL Method Documentation > https://bugs.openjdk.java.net/browse/JDK-8215911 https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java#l1067 > > diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java > --- a/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1064,7 +1064,7 @@ > > /** > * Returns the insert row or the current row of this > - * {@code CachedRowSetImpl}object. > + * {@code CachedRowSetImpl} object. > * > * @return the {@code Row} object on which this {@code CachedRowSetImpl} > * objects's cursor is positioned > @@ -4326,7 +4326,7 @@ > * > * @param columnName a {@code String} object that must match the > * SQL name of a column in this rowset, ignoring case > - * @param c the new column {@code Clob}value > + * @param c the new column {@code Clob} value > * @throws SQLException if (1) the given column name does not match the > * name of a column in this rowset, (2) the cursor is not on > * one of this rowset's rows or its insert row, or (3) this > > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l1136 > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l6191 > > diff -r abe21b82ff7c src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java > diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java > --- a/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1133,7 +1133,7 @@ > * as a stream of Unicode characters. > * The value can then be read in chunks from the > * stream. This method is particularly > - * suitable for retrieving large{@code LONGVARCHAR}values. The JDBC driver will > + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will > * do any necessary conversion from the database format into Unicode. > * The byte format of the Unicode stream must be Java UTF-8, > * as specified in the Java virtual machine specification. > @@ -6188,7 +6188,7 @@ > * @param parameterIndex index of the first parameter is 1, the second is 2, ... > * @param reader An object that contains the data to set the parameter value to. > * @throws SQLException if a database access error occurs, this method is called on > - * a closed {@code PreparedStatement}or if parameterIndex does not correspond to a parameter > + * a closed {@code PreparedStatement} or if parameterIndex does not correspond to a parameter > * marker in the SQL statement > * > * @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method > > From daniel.fuchs at oracle.com Thu Jan 3 17:17:11 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 3 Jan 2019 18:17:11 +0100 Subject: RFR: 8182992 Typo in DatagramPacket constructor API doc In-Reply-To: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> References: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> Message-ID: <278f63ab-e2f2-fe3c-bcc8-59ea27d85071@oracle.com> Hi Roger, On 03/01/2019 17:51, Roger Calnan wrote: > + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will I believe there's still a space missing after `large` in the line above. best regards, -- daniel From vicente.romero at oracle.com Thu Jan 3 17:21:54 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 3 Jan 2019 12:21:54 -0500 Subject: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec Message-ID: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> Please review the fix for bug [1] at [2]. Basically the constants API introduced as part of JEP-334 [3] were accepting descriptors and class names not allowed by the spec. This implementation fixes several issues found by TCK tests on JEP-334, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8215510 [2] http://cr.openjdk.java.net/~vromero/8215510/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8203252 From lance.andersen at oracle.com Thu Jan 3 17:53:07 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 3 Jan 2019 12:53:07 -0500 Subject: RFR: 8182992 Typo in DatagramPacket constructor API doc In-Reply-To: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> References: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> Message-ID: Hi Roger, Please see below. I am not sure how much review the javadocs have gotten for the com/sun/rowset/internal classes > > > > JDK-8215911 Various Typos in SQL Method Documentation > https://bugs.openjdk.java.net/browse/JDK-8215911 https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java#l1067 > > diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java > --- a/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1064,7 +1064,7 @@ > > /** > * Returns the insert row or the current row of this > - * {@code CachedRowSetImpl}object. > + * {@code CachedRowSetImpl} object. > * > * @return the {@code Row} object on which this {@code CachedRowSetImpl} > * objects's cursor is positioned > @@ -4326,7 +4326,7 @@ > * > * @param columnName a {@code String} object that must match the > * SQL name of a column in this rowset, ignoring case > - * @param c the new column {@code Clob}value > + * @param c the new column {@code Clob} value > * @throws SQLException if (1) the given column name does not match the > * name of a column in this rowset, (2) the cursor is not on > * one of this rowset's rows or its insert row, or (3) this > > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l1136 > https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l6191 > > diff -r abe21b82ff7c src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java > diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java > --- a/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:37:55 2019 -0500 > +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1133,7 +1133,7 @@ > * as a stream of Unicode characters. > * The value can then be read in chunks from the > * stream. This method is particularly > - * suitable for retrieving large{@code LONGVARCHAR}values. The JDBC driver will > + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will Needs a space after large > * do any necessary conversion from the database format into Unicode. > * The byte format of the Unicode stream must be Java UTF-8, > * as specified in the Java virtual machine specification. > @@ -6188,7 +6188,7 @@ > * @param parameterIndex index of the first parameter is 1, the second is 2, ... > * @param reader An object that contains the data to set the parameter value to. > * @throws SQLException if a database access error occurs, this method is called on > - * a closed {@code PreparedStatement}or if parameterIndex does not correspond to a parameter > + * a closed {@code PreparedStatement} or if parameterIndex does not correspond to a parameter > * marker in the SQL statement > * > * @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method > > looks fine otherwise Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mvala at redhat.com Thu Jan 3 20:31:51 2019 From: mvala at redhat.com (Michal Vala) Date: Thu, 3 Jan 2019 21:31:51 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: Hi Martin, can we please finish this review? On 12/19/18 6:32 PM, Michal Vala wrote: > > > On 12/19/18 4:15 PM, Martin Buchholz wrote: >> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: >> >>> Hi Martin, >>> >>> It is also useful and conventional to print the seed of the random >>> so that if necessary it can be reproduced. >>> >> >> For many years, we've been using ThreadLocalRandom for testing, and that >> does not allow setting a seed. >> >> I remain unconvinced that saving a seed has value in the real world.? When >> a randomized test fails, running it with sufficient iterations has always >> worked for me. >> > > What's the reason behind using ThreadLocalRandom? > > In my opinion, reproducing the issue is key. One failure of randomized test run > might be caused by one issue, second run due to another issue. How we reproduce > then and how we know even how many issues we have? When we're running random > tests until it pass, it might even hide the issue. > > They sure have good value on reveal the issue, but then we have to know how to > reproduce and what we're searching for. > > If this case would not require ThreadLocalRandom and Random is enough, I'd like > to use that because of benefits I've mentioned. > -- Michal Vala OpenJDK QE Red Hat Czech From Roger.Riggs at oracle.com Thu Jan 3 20:47:36 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Jan 2019 15:47:36 -0500 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams Message-ID: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> Please review a bug fix for the ProcessBuilder startPipeline test and Windows implementation. The test failed to check that Process.getInputStream returned the null stream for all but the last process in the pipeline.? When the test was fixed it failed on Windows. The Windows ProcessImpl did not ensure that getInputStream returned a null stream. The same issue was found and fixed in the AIX implementation (JDK-8211844) which prompted investigation of the test. Webrev: ?http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ Happy New Year!? Roger From naoto.sato at oracle.com Thu Jan 3 21:06:47 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 3 Jan 2019 13:06:47 -0800 Subject: UnicodeDecoder U+FFFE handling In-Reply-To: References: Message-ID: Sounds reasonable. Filed the following issue: https://bugs.openjdk.java.net/browse/JDK-8216140 Naoto On 1/1/19 10:06 PM, li.jiang at oracle.com wrote: > Sounds this request is reasonable since Unicode 7: do not consider the > U+FFFE in the middle of stream as malformed. > > FAQ about private use characters and non-characters. [1] > http://www.unicode.org/faq/private_use.html > > Q: Are noncharacters invalid in Unicode strings and UTFs? > A: Absolutely not. Noncharacters do not cause a Unicode string to be > ill-formed in any UTF. > > Q: So how should libraries and tools handle noncharacters? > A: Library APIs, components, and tool applications (such as low-level > text editors) which handle all Unicode strings should also handle > noncharacters. Often this means simple pass-through, the same way such > an API or tool would handle a reserved unassigned code point. > > Thanks > Leo > > On 12/24/18 3:06 AM, Cl?ment MATHIEU wrote: >> Hi, >> >> I am wondering if UnicodeDecoder handling of U+FFFE is compliant with >> current Unicode specification. Supsicious code is: >> >> ??????? if (c == REVERSED_MARK) { >> ???????????? // A reversed BOM cannot occur within middle of stream >> ???????????? return CoderResult.malformedForLength(2); >> ??????? } >> >> Up to Unicode 6.3 Unicode specification said that U+FFFE is a non >> character and that non characters "should never been interchanged". >> Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8 >> (Unicode 6.2). >> >> However, Unicode 7 changed that and now says: >> >> ?????? Applications are free to use any of these noncharacter code >> ?????? points internally. They have no standard interpretation when >> ?????? exchanged outside the context of internal use. However, they are >> ?????? not illegal in interchange, nor does their presence cause Unicode >> ?????? text to be ill-formed. [...] They are not prohibited from >> ?????? occurring? in? valid? Unicode? strings? which? happen? to? be? in >> ?????? terchanged. [...]. If a noncharacter is received in open >> ?????? interchange, an application is not required to interpret it in >> ?????? any way. It is good practice, however, to recognize it as a >> ?????? noncharacter and to take appropriate action, such as replacing it >> ?????? with U+FFFD replacement character, to indicate >> ?????? the? problem? in? the? text.? It? is? not? recommended? to? simpl >> ?????? y? delete? noncharacter? code points from such text, because of >> ?????? the potential security issues caused by deleting uninterpreted >> ?????? characters. >> >> See: >> ? - http://www.unicode.org/versions/corrigendum9.html >> ? - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7) >> >> Do you think that returning CR_MALFORMED is still OK? >> >> Regards, >> Cl?ment MATHIEU >> From lance.andersen at oracle.com Thu Jan 3 22:27:19 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 3 Jan 2019 17:27:19 -0500 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> Message-ID: <31B396B7-FA7F-43A4-87F7-1B1EC3F62C9A@oracle.com> Hi Roger, The changes look reasonable to me. Happy New Year > On Jan 3, 2019, at 3:47 PM, Roger Riggs wrote: > > Please review a bug fix for the ProcessBuilder startPipeline test and Windows implementation. > The test failed to check that Process.getInputStream returned the null stream > for all but the last process in the pipeline. When the test was fixed it failed on Windows. > The Windows ProcessImpl did not ensure that getInputStream returned a null stream. > > The same issue was found and fixed in the AIX implementation (JDK-8211844) > which prompted investigation of the test. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ > > Happy New Year! Roger > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Thu Jan 3 22:32:17 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Jan 2019 17:32:17 -0500 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <31B396B7-FA7F-43A4-87F7-1B1EC3F62C9A@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> <31B396B7-FA7F-43A4-87F7-1B1EC3F62C9A@oracle.com> Message-ID: <4c0a2b21-9949-fdd2-d360-0b458afd6c5c@oracle.com> Thanks Lance, Happy New Year On 01/03/2019 05:27 PM, Lance Andersen wrote: > Hi Roger, > > The changes look reasonable to me. > > Happy New Year > >> On Jan 3, 2019, at 3:47 PM, Roger Riggs > > wrote: >> >> Please review a bug fix for the ProcessBuilder startPipeline test and >> Windows implementation. >> The test failed to check that Process.getInputStream returned the >> null stream >> for all but the last process in the pipeline.? When the test was >> fixed it failed on Windows. >> The Windows ProcessImpl did not ensure that getInputStream returned a >> null stream. >> >> The same issue was found and fixed in the AIX implementation >> (JDK-8211844) >> which prompted investigation of the test. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ >> >> >> Happy New Year!? Roger >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From brent.christian at oracle.com Thu Jan 3 22:37:29 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 3 Jan 2019 14:37:29 -0800 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <4c0a2b21-9949-fdd2-d360-0b458afd6c5c@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> <31B396B7-FA7F-43A4-87F7-1B1EC3F62C9A@oracle.com> <4c0a2b21-9949-fdd2-d360-0b458afd6c5c@oracle.com> Message-ID: <68884c86-35c5-9cfb-c896-154ef4138d0b@oracle.com> Speaking of, you might want to change the copyright years to 2019. :) -Brent On 1/3/19 2:32 PM, Roger Riggs wrote: > > Happy New Year > > On 01/03/2019 05:27 PM, Lance Andersen wrote: >> >> Happy New Year >> >>> On Jan 3, 2019, at 3:47 PM, Roger Riggs >> >>> Happy New Year! From david.holmes at oracle.com Thu Jan 3 22:58:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Jan 2019 08:58:34 +1000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> Message-ID: <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> Hi Roger, On 4/01/2019 12:22 am, Roger Riggs wrote: > Hi, > > With a link to the explanation added to the issue, I think it can be > closed as not-an-issue. Do you think the Class.getDeclared* method specs should be updated to reflect (pardon the pun) that synthetic methods/constructors will be included? Cheers, David > Roger > > > On 01/03/2019 07:19 AM, Steve Groeger wrote: >> Hi Peter, >> >> Thanks again for your explanation. >> It was the public vs. non-public? part that I had missed and I was >> getting >> confused thinking it was related to abstract vs. non-abstract classes. >> The generation of the synthetic methods and why the methods are shown via >> the getDeclaredMethods() makes a lot more sense now. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911? Mobex: 279990? Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> >> >> >> From:?? Peter Levart >> To:???? Steve Groeger >> Cc:???? OpenJDK Core Libs Developers >> Date:?? 03/01/2019 11:33 >> Subject:??????? Re: Class.getDeclaredMethods() is returning inherited >> methods >> >> >> >> Hi Steve, >> >> The difference you observe between variants of class A is not about the >> "abstract" vs. non-"abstract" but about "public" vs. non-"public"... >> >> Your variants of class A are: >> >> public class A { >> ????? public void foo() {} >> } >> >> vs. >> >> abstract class A { >> ????? public void foo() {} >> } >> >> >> The 1st is public but the 2nd is package-private. Try with the following >> variant: >> >> class A { >> ????? public void foo() {} >> } >> >> ... and you'll see the same behavior as with abstract package-private >> class. Try also with the following variant: >> >> public abstract class A { >> ????? public void foo() {} >> } >> >> ...and you'll see the same behavior as with public concrete class. >> >> >> The reason why javac does not generate synthetic method when extending >> public class is obvious. It is not needed since A.m() can be invoked >> from anywhere if A is public. >> >> Regards, Peter >> >> On 1/3/19 10:33 AM, Steve Groeger wrote: >>> Hi Peter, >>> >>> Thank you very much for your detailed and very informative explanation. >> I >>> have one more question for clarification. >>> If I have the following code: >>> >>> abstract class A { >>> ????? public void foo() {} >>> } >>> >>> >>> import java.lang.reflect.*; >>> >>> public class B extends A { >>> ????? public static void main(String[] args) throws Exception { >>> ????????? System.out.println("----- getDeclaredMethods -----"); >>> ????????? Method[] methods = B.class.getDeclaredMethods(); >>> ????????? for( int i = 0 ; i < methods.length ; i++ ){ >>> ????????????? System.out.println(methods[i]); >>> ????????? } >>> ????? } >>> } >>> >>> If I compile and run this class "java --classpath . B" I get I get the >>> following output: >>> >>> ----- getDeclaredMethods ----- >>> public static void B.main(java.lang.String[]) throws java.lang.Exception >>> public void B.foo() >>> >>> which seems to fit with your explanation? (noting that A is an abstract >>> class). However, if I make A a public class >>> >>> public class A { >>> ????? public void foo() {} >>> } >>> >>> >>> the output is different and doesnt contain the foo() method. >>> >>> ----- getDeclaredMethods ----- >>> public static void B.main(java.lang.String[]) throws java.lang.Exception >>> >>> Is this as expected? >>> >>> Should there be a difference between the output from running the >>> getDelaredMethods() on >>> 1) a class extending an abstract class with a public method (non >> abstract) >>> and >>> 2) a class extending a public class with a public method? >>> >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911? Mobex: 279990? Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >>> >>> >>> From:?? Peter Levart >>> To:???? Steve Groeger , OpenJDK Core Libs Developers >>> >>> Date:?? 02/01/2019 17:45 >>> Subject:??????? Re: Class.getDeclaredMethods() is returning inherited >>> methods >>> >>> >>> >>> Hi Steve, >>> >>> What you have observed is an artifact of how Java the language is >>> compiled into bytecode contained in .class files and the fact that Java >>> reflection API returns information about the compiled .class files. The >>> quoted sample code: >>> >>> package x.y; >>> >>> class A { >>> ???? public void m() { >>> ???? } >>> } >>> >>> public class B { >>> } >>> >>> ...is one example where the compiler must create a synthetic method in >>> class B which overrides public method in class A and delegates to it. >>> Java access checks allow invoking A.m() only from package x.y since A is >>> a package private class. OTOH m() is a public method and as such is >>> inherited by B. so m() can be called on an instance of type B from >>> anywhere because B is a public class. To accommodate that, javac >>> synthesizes public method B.m() which delegates to A.m() as thought you >>> would have written the following code: >>> >>> package x.y; >>> >>> class A { >>> ???? public void m() { >>> ???? } >>> } >>> >>> public class B { >>> ???? public void m() { >>> ?????? super.m(); >>> ???? } >>> } >>> >>> >>> ... B.class.getDeclaredMethods() therefore returns this synthetic method >>> B.m() and not the inherited method A.m(). You can verify that by >>> invoking .getDeclaringClass() on it, which should give you B.class and >>> not A.class. >>> >>> Strictly speaking such synthetic method on B is not really needed by JVM >>> to invoke A.m() from anywhere via the instance of B. Invocation of m() >>> given an instance of B could be compiled by javac in exactly the same >>> way even if there was no synthetic method B.m(). Javac could pretend >>> there is a method B.m() and emit invoke instruction referencing the >>> imaginative method. At runtime JVM would dispatch the virtual call to >>> inherited A.m and allow such call from anywhere since it references a >>> public method in a public class (although imaginative). >>> >>> The only reason javac generates synthetic method B.m() is to actually >>> allow A.m() to be called via reflection API. Reflection API does not >>> allow invoking A.m() directly from anywhere, but it allows invoking the >>> synthetic B.m() which then delegates to A.m(). >>> >>> If we wanted to get rid of this synthetic method, reflection would have >>> to be fixed 1st to accommodate calling public methods inherited from >>> non-public classes if they are called via an instance of a public >>> subclass (or a subclass of it). The reason this has not been done yet is >>> probably that it is more tricky that it seems at first. Imagine the >>> following situation: >>> >>> package p1; >>> >>> class A { >>> ?????? public void m() { >>> ?????? } >>> } >>> >>> public class B extends A { >>> } >>> >>> >>> package p2; >>> >>> class C extends B { >>> } >>> >>> public class Builder { >>> ?????? public static B build() { >>> ?????????? return new C(); >>> ?????? } >>> } >>> >>> >>> package p3; >>> >>> public class App { >>> ?????? public static void main(String[] args) { >>> ?????????? B b = p2.Builder.build(); >>> ?????????? b.m(); // << HERE >>> ?????? } >>> } >>> >>> >>> ...javac would have an easy job here. It knows the static (compile-time) >>> type of variable b (which is a public class B) so it can directly emit >>> invoke instruction for imaginative method B.m() here. >>> >>> Reflection API OTOH has a more difficult job in the following code: >>> >>> package p3; >>> >>> public class App { >>> ?????? public static void main(String[] args) { >>> ?????????? B b = p2.Builder.build(); >>> ?????????? Method m = B.class.getMethod("m"); // >>> m.getDeclatingClass() == >>> A.class >>> ?????????? m.invoke(b); // << HERE >>> ?????? } >>> } >>> >>> ...reflection has at its disposal: >>> >>> - a Method object 'm' representing method A.m() which is located in a >>> non-public class p1.A >>> - a target instance 'b' which is of type p2.C which is also a non-public >>> class >>> - the invocation is being performed from package p3 >>> >>> In order for reflection to allow such invocation it would have to assume >>> that such invocation is performed via some imaginative method X.m() such >>> that: >>> - X is a public class and is a subclass of A >>> - C is a subclass of X >>> >>> Such decision is inherently non-local meaning that reflection would have >>> to search class hierarchy to allow it. It is possible though, but >>> probably to complicated for such use case. >>> >>> What do others think? >>> >>> Regards, Peter >>> >>> >>> On 1/2/19 5:33 PM, Steve Groeger wrote: >>>> I am looking into an issue where the Class.getDeclaredMethods() is >>>> returning inherited methods, >>>> where the Java Doc here:- >>>> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() >> >> >>>> states:- >>>> >>>> "Returns an array containing Method objects reflecting all the declared >>>> methods of the class or interface represented by this Class object, >>>> including public, protected, default (package) access, and private >>>> methods, but excluding inherited methods". >>>> >>>> with the last part of the statement being the relevant part, "but >>>> excluding inherited methods" >>>> >>>> This was raised as an issue a long time ago: >>>> >> https://bugs.openjdk.java.net/browse/JDK-6815786 >> >>> but has not been fixed >>>> and is still an issue in JDK11. >>>> >>>> Before I go looking into why this is occurring and producing a fix, is >>>> this still seen as an issue and does it need to be fixed / should it be >>>> fixed. >>>> I dont want to do lots of investigation and produce a fix just to be >>> told >>>> we cant contribute this as it will break too many people that might >> have >>>> been using this feature !!!! >>>> >>>> Thanks >>>> Steve Groeger >>>> IBM Runtime Technologies >>>> Hursley, Winchester >>>> Tel: (44) 1962 816911? Mobex: 279990? Mobile: 07718 517 129 >>>> Fax (44) 1962 816800 >>>> Lotus Notes: Steve Groeger/UK/IBM >>>> Internet: groeges at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >>> >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU > From huizhe.wang at oracle.com Thu Jan 3 23:25:02 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 03 Jan 2019 15:25:02 -0800 Subject: RFR(JDK 13/java.xml) javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match Message-ID: <5C2E99CE.30302@oracle.com> Hi, Please review a fix to the impl for the Catalog. The reporter was right, in the Group case, we failed to update the currently longest match when a match is found. JBS: https://bugs.openjdk.java.net/browse/JDK-8215330 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8215330/webrev/ Thanks, Joe From brent.christian at oracle.com Thu Jan 3 23:36:24 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 3 Jan 2019 15:36:24 -0800 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <68884c86-35c5-9cfb-c896-154ef4138d0b@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> <31B396B7-FA7F-43A4-87F7-1B1EC3F62C9A@oracle.com> <4c0a2b21-9949-fdd2-d360-0b458afd6c5c@oracle.com> <68884c86-35c5-9cfb-c896-154ef4138d0b@oracle.com> Message-ID: <7eca6876-5981-35c3-eaff-1c426a12b3ee@oracle.com> The webrev looks fine to me, too. Unrelated to this change, but something I noticed: test/jdk/java/lang/ProcessBuilder/PipelineTest.java 173 setFileContents(infile, expected); Shouldn't the contents of 'infile' be set to 'input', rather than 'expected'? Thanks, -Brent On 1/3/19 2:37 PM, Brent Christian wrote: > Speaking of, you might want to change the copyright years to 2019. :) > From lance.andersen at oracle.com Thu Jan 3 23:48:59 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 3 Jan 2019 18:48:59 -0500 Subject: RFR(JDK 13/java.xml) javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match In-Reply-To: <5C2E99CE.30302@oracle.com> References: <5C2E99CE.30302@oracle.com> Message-ID: Hi Joe, The changes and test seem fine! Happy New Year > On Jan 3, 2019, at 6:25 PM, Joe Wang wrote: > > Hi, > > Please review a fix to the impl for the Catalog. The reporter was right, in the Group case, we failed to update the currently longest match when a match is found. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215330 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8215330/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From dan.z.zhou at oracle.com Fri Jan 4 02:28:09 2019 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Fri, 4 Jan 2019 10:28:09 +0800 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. Message-ID: Hello, Please help review the fix for the test bug java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ Thanks, Dora From sergei.tsypanov at yandex.ru Fri Jan 4 07:25:03 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 04 Jan 2019 09:25:03 +0200 Subject: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1 In-Reply-To: References: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> Message-ID: <31308541546586703@sas1-0a6c2e2b59d7.qloud-c.yandex.net> Hi Claes, thanks for the explanation, I suspected something like that. I've run into this performance effect while investigating creation of Spring's ConcurrentReferenceHashMap, it turned out that it used Array::newInstance to create array of References stored in a map's Segment: private Reference[] createReferenceArray(int size) { return Array.newInstance(Reference.class, size); } The code above was rewritten into plain array constructor call gaining some performance improvement: private Reference[] createReferenceArray(int size) { return new Reference[size]; } This was the reason to go deeper and look how both methods behave. The actual behaviour is the same on both JDK 8 and JDK 11. And creation of ConcurrentReferenceHashMap is important on some workloads, in my case it's database access via Spring Data where creation of ConcurrentReferenceHashMap takes approximately 1/5 of execution profile. Talkin about Spring Boot it's possible to run SB application in IntelliJ IDEA in certain mode adding -XX:TieredStopAtLevel=1 and -noverify VM options. With full compilation the simplest application takes this to start up Mode Cnt Score Error Units start-up ss 100 2885,493 ? 167,660 ms/op and with `-XX:TieredStopAtLevel=1 -noverify` Benchmark Mode Cnt Score Error Units start-up ss 100 1707,342 ? 75,166 ms/op > Hi, > > what you're seeing specifically here is likely the native overhead: > Array::newInstance calls into the native method Array::newArray, and C1 > (TierStopAtLevel=1) doesn't have an intrinsic for this, while C2 does. > > C1 and the interpreter will instead call into > Java_java_lang_reflect_Array_newArray in libjava / Array.c over JNI, > which will add a rather expensive constant overhead.. > > TieredStopAtLevel=1/C1 performance is expected to be relatively slower > than C2 in general, and often much worse in cases like this there are > optimized intrinsics at play. > > Have you seen a regression here compared to some older JDK release? > > It would also be very helpful if you could shed more light on the use > case and point out what particular startup issues you're seeing that > prevents you from using full tiered compilation and Spring Boot. > > /Claes > > On 2019-01-02 22:56, ?????? ??????? wrote: > >> Hello, >> >> -XX:TieredStopAtLevel=1 flag is often used in some applications (e.g. Spring Boot based) to reduce start-up time. >> >> With this flag I've spotted huge performance degradation of Array::newInstance comparing to plain constructor call. >> >> I've used this benchmark >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class ArrayInstantiationBenchmark { >> >> @Param({"10", "100", "1000"}) >> private int length; >> >> @Benchmark >> public Object newInstance() { >> return Array.newInstance(Object.class, length); >> } >> >> @Benchmark >> public Object constructor() { >> return new Object[length]; >> } >> >> } >> >> On C2 (JDK 11) both methods perform the same: >> >> Benchmark (length) Mode Cnt Score Error Units >> ArrayInstantiationBenchmark.constructor 10 avgt 50 11,557 ? 0,316 ns/op >> ArrayInstantiationBenchmark.constructor 100 avgt 50 86,944 ? 4,945 ns/op >> ArrayInstantiationBenchmark.constructor 1000 avgt 50 520,722 ? 28,068 ns/op >> >> ArrayInstantiationBenchmark.newInstance 10 avgt 50 11,899 ? 0,569 ns/op >> ArrayInstantiationBenchmark.newInstance 100 avgt 50 86,805 ? 5,103 ns/op >> ArrayInstantiationBenchmark.newInstance 1000 avgt 50 488,647 ? 20,829 ns/op >> >> On C1 however there's a huge difference (approximately 8 times!) for length = 10: >> >> Benchmark (length) Mode Cnt Score Error Units >> ArrayInstantiationBenchmark.constructor 10 avgt 50 11,183 ? 0,168 ns/op >> ArrayInstantiationBenchmark.constructor 100 avgt 50 92,215 ? 4,425 ns/op >> ArrayInstantiationBenchmark.constructor 1000 avgt 50 838,303 ? 33,161 ns/op >> >> ArrayInstantiationBenchmark.newInstance 10 avgt 50 86,696 ? 1,297 ns/op >> ArrayInstantiationBenchmark.newInstance 100 avgt 50 106,751 ? 2,796 ns/op >> ArrayInstantiationBenchmark.newInstance 1000 avgt 50 840,582 ? 24,745 ns/op >> >> Pay attention that performance for length = {100, 1000} is almost the same. >> >> I suppose it's a bug somewhere on VM because both methods just allocate memory and do zeroing elimination and subsequently there shouldn't be such a huge difference between them. >> >> Sergey Tsypanov From rachna.goel at oracle.com Fri Jan 4 09:44:38 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 4 Jan 2019 15:14:38 +0530 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: References: Message-ID: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> Hi Dora, Kindly update copyright years in both files and add bug id in LocaleProvidersRun.java. Other than that, it looks good to me. Thanks, Rachna On 1/4/19 7:58 AM, Dora Zhou wrote: > Hello, > > Please help review the fix for the test bug > java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP > locale. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 > > Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ > > Thanks, > Dora > -- Thanks, Rachna From claes.redestad at oracle.com Fri Jan 4 09:57:35 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 10:57:35 +0100 Subject: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1 In-Reply-To: <31308541546586703@sas1-0a6c2e2b59d7.qloud-c.yandex.net> References: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> <31308541546586703@sas1-0a6c2e2b59d7.qloud-c.yandex.net> Message-ID: Hi, I've also taken a look at your microbenchmark and seen a few regressions from 9 through 12, some of which I've identified - and some that might be (partially) actionable. Mostly related to recent additions of low overhead heap sampling and allocator/GC changes. All of the blame is in hotspot, so let's leave the core-libs-devs alone for now. :-) Some additional comments below... On 2019-01-04 08:25, ?????? ??????? wrote: > Hi Claes, > > thanks for the explanation, I suspected something like that. > > I've run into this performance effect while investigating creation of Spring's ConcurrentReferenceHashMap, > it turned out that it used Array::newInstance to create array of References stored in a map's Segment: > > private Reference[] createReferenceArray(int size) { > return Array.newInstance(Reference.class, size); > } > > The code above was rewritten into plain array constructor call gaining some performance improvement: > > private Reference[] createReferenceArray(int size) { > return new Reference[size]; > } while a point fix, avoiding reflection seems like the right thing to do when the array type is known statically, anyhow. > > This was the reason to go deeper and look how both methods behave. > The actual behaviour is the same on both JDK 8 and JDK 11. > > And creation of ConcurrentReferenceHashMap is important on some workloads, in my case it's > database access via Spring Data where creation of ConcurrentReferenceHashMap takes approximately 1/5 > of execution profile. > > Talkin about Spring Boot it's possible to run SB application in IntelliJ IDEA in certain mode adding > -XX:TieredStopAtLevel=1 and -noverify VM options. > > With full compilation the simplest application takes this to start up > > Mode Cnt Score Error Units > start-up ss 100 2885,493 ? 167,660 ms/op > > and with `-XX:TieredStopAtLevel=1 -noverify` > > Benchmark Mode Cnt Score Error Units > start-up ss 100 1707,342 ? 75,166 ms/op Thanks! Which JDK version are you using? -noverify can be used without -XX:TieredStopAtLevel=1 (but don't use this in production!). You might gain some by enabling CDS (run java -Xshare:dump once, then add -Xshare:auto to your command lines). There are a few other tricks to pull that might help startup without sacrificing peak performance. /Claes > >> Hi, >> >> what you're seeing specifically here is likely the native overhead: >> Array::newInstance calls into the native method Array::newArray, and C1 >> (TierStopAtLevel=1) doesn't have an intrinsic for this, while C2 does. >> >> C1 and the interpreter will instead call into >> Java_java_lang_reflect_Array_newArray in libjava / Array.c over JNI, >> which will add a rather expensive constant overhead.. >> >> TieredStopAtLevel=1/C1 performance is expected to be relatively slower >> than C2 in general, and often much worse in cases like this there are >> optimized intrinsics at play. >> >> Have you seen a regression here compared to some older JDK release? >> >> It would also be very helpful if you could shed more light on the use >> case and point out what particular startup issues you're seeing that >> prevents you from using full tiered compilation and Spring Boot. >> >> /Claes >> >> On 2019-01-02 22:56, ?????? ??????? wrote: >> >>> Hello, >>> >>> -XX:TieredStopAtLevel=1 flag is often used in some applications (e.g. Spring Boot based) to reduce start-up time. >>> >>> With this flag I've spotted huge performance degradation of Array::newInstance comparing to plain constructor call. >>> >>> I've used this benchmark >>> >>> @State(Scope.Thread) >>> @BenchmarkMode(Mode.AverageTime) >>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> public class ArrayInstantiationBenchmark { >>> >>> @Param({"10", "100", "1000"}) >>> private int length; >>> >>> @Benchmark >>> public Object newInstance() { >>> return Array.newInstance(Object.class, length); >>> } >>> >>> @Benchmark >>> public Object constructor() { >>> return new Object[length]; >>> } >>> >>> } >>> >>> On C2 (JDK 11) both methods perform the same: >>> >>> Benchmark (length) Mode Cnt Score Error Units >>> ArrayInstantiationBenchmark.constructor 10 avgt 50 11,557 ? 0,316 ns/op >>> ArrayInstantiationBenchmark.constructor 100 avgt 50 86,944 ? 4,945 ns/op >>> ArrayInstantiationBenchmark.constructor 1000 avgt 50 520,722 ? 28,068 ns/op >>> >>> ArrayInstantiationBenchmark.newInstance 10 avgt 50 11,899 ? 0,569 ns/op >>> ArrayInstantiationBenchmark.newInstance 100 avgt 50 86,805 ? 5,103 ns/op >>> ArrayInstantiationBenchmark.newInstance 1000 avgt 50 488,647 ? 20,829 ns/op >>> >>> On C1 however there's a huge difference (approximately 8 times!) for length = 10: >>> >>> Benchmark (length) Mode Cnt Score Error Units >>> ArrayInstantiationBenchmark.constructor 10 avgt 50 11,183 ? 0,168 ns/op >>> ArrayInstantiationBenchmark.constructor 100 avgt 50 92,215 ? 4,425 ns/op >>> ArrayInstantiationBenchmark.constructor 1000 avgt 50 838,303 ? 33,161 ns/op >>> >>> ArrayInstantiationBenchmark.newInstance 10 avgt 50 86,696 ? 1,297 ns/op >>> ArrayInstantiationBenchmark.newInstance 100 avgt 50 106,751 ? 2,796 ns/op >>> ArrayInstantiationBenchmark.newInstance 1000 avgt 50 840,582 ? 24,745 ns/op >>> >>> Pay attention that performance for length = {100, 1000} is almost the same. >>> >>> I suppose it's a bug somewhere on VM because both methods just allocate memory and do zeroing elimination and subsequently there shouldn't be such a huge difference between them. >>> >>> Sergey Tsypanov From rachna.goel at oracle.com Fri Jan 4 10:22:09 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 4 Jan 2019 15:52:09 +0530 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: Message-ID: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> Hi Naoto, Your fix looks good to me. Thanks, Rachna On 1/3/19 10:26 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue (and its approved CSR): > > https://bugs.openjdk.java.net/browse/JDK-8215303 > https://bugs.openjdk.java.net/browse/JDK-8215305 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ > > This is a spec only modification that will allow future code point > additions to the Unicode currency symbols block without any spec > changes. This is especially important for update releases (such as 8u) > without releasing a Maintenance Release. > > Naoto -- Thanks, Rachna From rachna.goel at oracle.com Fri Jan 4 10:24:42 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 4 Jan 2019 15:54:42 +0530 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: Message-ID: Hi Naoto, just one nit, copyright year need to be updated in Character.java. Thanks, Rachna On 1/3/19 10:26 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue (and its approved CSR): > > https://bugs.openjdk.java.net/browse/JDK-8215303 > https://bugs.openjdk.java.net/browse/JDK-8215305 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ > > This is a spec only modification that will allow future code point > additions to the Unicode currency symbols block without any spec > changes. This is especially important for update releases (such as 8u) > without releasing a Maintenance Release. > > Naoto -- Thanks, Rachna From nishit.jain at oracle.com Fri Jan 4 10:28:12 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 4 Jan 2019 15:58:12 +0530 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: Message-ID: <65abc1b3-adc7-48ce-619d-8264a8c01472@oracle.com> Changes looks fine to me. Regards, Nishit Jain On 03-01-2019 22:26, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue (and its approved CSR): > > https://bugs.openjdk.java.net/browse/JDK-8215303 > https://bugs.openjdk.java.net/browse/JDK-8215305 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ > > This is a spec only modification that will allow future code point > additions to the Unicode currency symbols block without any spec > changes. This is especially important for update releases (such as 8u) > without releasing a Maintenance Release. > > Naoto From GROEGES at uk.ibm.com Fri Jan 4 11:03:54 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 4 Jan 2019 11:03:54 +0000 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> Message-ID: Roger, Looks OK. One small point, I know it is only a test but do you need the extra System.out.printf statements, they look as though they might have been just for debugging. No issues if they stay in there just wondering if it was a oversight in removing them. Also, need to have the copyright dates changed as we are now in 2019. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Roger Riggs To: core-libs-dev Date: 03/01/2019 20:48 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams Sent by: "core-libs-dev" Please review a bug fix for the ProcessBuilder startPipeline test and Windows implementation. The test failed to check that Process.getInputStream returned the null stream for all but the last process in the pipeline. When the test was fixed it failed on Windows. The Windows ProcessImpl did not ensure that getInputStream returned a null stream. The same issue was found and fixed in the AIX implementation (JDK-8211844) which prompted investigation of the test. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ Happy New Year! Roger Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Fri Jan 4 14:13:42 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 4 Jan 2019 14:13:42 +0000 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> Message-ID: <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> On 1/3/19 10:26 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue (and its approved CSR): > > https://bugs.openjdk.java.net/browse/JDK-8215303 > https://bugs.openjdk.java.net/browse/JDK-8215305 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ I think this is a positive change, but for clarity ( since I cannot find it in the CSR ), will this change have an impact on the set of allowable characters that can be used as identifiers, i.e. isJavaIdentifierStart, isJavaIdentifierPart? -Chris. From Roger.Riggs at oracle.com Fri Jan 4 14:52:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 09:52:38 -0500 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> Message-ID: Hi Brent, Steve, Thanks for the review and corrections for copyrights, removing debugging info, and input file contents. Updated Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844-2/ Regards, Roger On 01/04/2019 06:03 AM, Steve Groeger wrote: > Roger, > > Looks OK. > > One small point, I know it is only a test but do you need the extra > System.out.printf statements, they look as though they might have been > just for debugging. > No issues if they stay in there just wondering if it was a oversight > in removing them. > > Also, need to have the copyright dates changed as we are now in 2019. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Roger Riggs > To: core-libs-dev > Date: 03/01/2019 20:48 > Subject: 8216134 (process) ProcessBuilder startPipeline does not hide > piped streams > Sent by: "core-libs-dev" > ------------------------------------------------------------------------ > > > > Please review a bug fix for the ProcessBuilder startPipeline test and > Windows implementation. > The test failed to check that Process.getInputStream returned the null > stream > for all but the last process in the pipeline.? When the test was fixed > it failed on Windows. > The Windows ProcessImpl did not ensure that getInputStream returned a > null stream. > > The same issue was found and fixed in the AIX implementation (JDK-8211844) > which prompted investigation of the test. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ > > > Happy New Year!? Roger > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Fri Jan 4 15:21:40 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 10:21:40 -0500 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> References: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> Message-ID: <75358210-bdd2-4f54-e310-62a4525516fa@oracle.com> +1 On 01/04/2019 04:44 AM, Rachna Goel wrote: > Hi Dora, > > Kindly update copyright years in both files and add bug id in > LocaleProvidersRun.java. > > Other than that, it looks good to me. > > Thanks, > > Rachna > > > On 1/4/19 7:58 AM, Dora Zhou wrote: >> Hello, >> >> Please help review the fix for the test bug >> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP >> locale. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 >> >> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ >> >> Thanks, >> Dora >> > From Roger.Riggs at oracle.com Fri Jan 4 15:38:06 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 10:38:06 -0500 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> Message-ID: <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> Hi Claes, The logic looks fine, but the 'internal' field name doesn't mean anything and there's no description of the optimization. The field could be renamed:? noOverride or notOverridden or noDoubleSync or ... or add a comment to the field describing its purpose. Update copyright date on PrintStream.java. Thanks, Roger On 01/02/2019 03:44 AM, Claes Redestad wrote: > Hi, > > new webrev: > > ?http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ > > - Adds a forgotten String.valueOf in println(String), making sure all > methods are semantically the same for > - Remove the isInternal method and use only exact match with > PrintStream.class to determine whether to use the optimized paths. > > As before: > > On 2018-12-14 21:22, Claes Redestad wrote: >> Same performance characteristics in the simple tests I've used to >> verify this, and no measurable regression (but no speed-up) for classes >> overriding PrintStream. > > I've withdrawn the related CSR, since it's not relevant for this > implementation as it doesn't observably alter behavior of types > inheriting from PrintStream. > > Thanks! > > /Claes From forax at univ-mlv.fr Fri Jan 4 15:44:24 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 Jan 2019 16:44:24 +0100 (CET) Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> Message-ID: <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> Hi Roger, the field has disappear in the latest webrev. R?mi ----- Mail original ----- > De: "Roger Riggs" > ?: "Claes Redestad" , "core-libs-dev" > Envoy?: Vendredi 4 Janvier 2019 16:38:06 > Objet: Re: RFR: 8215412: Optimize PrintStream.println methods > Hi Claes, > > The logic looks fine, but the 'internal' field name doesn't mean anything > and there's no description of the optimization. > > The field could be renamed:? noOverride or notOverridden or noDoubleSync > or ... > or add a comment to the field describing its purpose. > > Update copyright date on PrintStream.java. > > Thanks, Roger > > On 01/02/2019 03:44 AM, Claes Redestad wrote: >> Hi, >> >> new webrev: >> >> ?http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ >> >> - Adds a forgotten String.valueOf in println(String), making sure all >> methods are semantically the same for >> - Remove the isInternal method and use only exact match with >> PrintStream.class to determine whether to use the optimized paths. >> >> As before: >> >> On 2018-12-14 21:22, Claes Redestad wrote: >>> Same performance characteristics in the simple tests I've used to >>> verify this, and no measurable regression (but no speed-up) for classes >>> overriding PrintStream. >> >> I've withdrawn the related CSR, since it's not relevant for this >> implementation as it doesn't observably alter behavior of types >> inheriting from PrintStream. >> >> Thanks! >> > > /Claes From forax at univ-mlv.fr Fri Jan 4 15:46:13 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 4 Jan 2019 16:46:13 +0100 (CET) Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <9a358a03-b380-08ac-f27a-e7638b0d8bfe@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> <7986ef57-2ccd-fda1-c73b-601e7505e806@oracle.com> <9a358a03-b380-08ac-f27a-e7638b0d8bfe@oracle.com> Message-ID: <55309305.338798.1546616773220.JavaMail.zimbra@u-pem.fr> The perf diff is more that what i was expected :) Looks good to me ! R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mercredi 2 Janvier 2019 21:32:09 > Objet: Re: RFR: 8215412: Optimize PrintStream.println methods > Hi again, > > as expected not much of a difference on the test I was using (a small > cost on the startup/warmup numbers due replacing a boolean check with a > method call), but on a test that adds in a few extended PrintStreams > and mixes those with use of System.out I can get a ~3-4% statistical > improvement with your idea - so I think it's better to peel off > the PrintStream.class check like this: > > http://cr.openjdk.java.net/~redestad/8215412/jdk.03/ > > Thanks! > > /Claes > > On 2019-01-02 13:29, Claes Redestad wrote: >> Hi R?mi, >> >> >> On 2019-01-02 13:05, Remi Forax wrote: >>> Hi Claes, >>> did you try instead of having a field 'internal' to inline the class >>> check (this.getClass() == PrintStream.class) at every call site you >>> are reading that field ? >>> >>> for a method like println(), the VM has to do a class check (if CHA is >>> defeated) before entering the method println so the JIT might be able >>> to remove the check this.getClass() == PrintStream.class because it >>> already know at that point that the current class is PrintStream. >> >> interesting idea - I'll try it out. I don't expect it to make much of a >> difference in my current (trivial) tests, but perhaps in a slightly more >> contrived setup. >> >> happy new year! >> > > /Claes From Roger.Riggs at oracle.com Fri Jan 4 15:55:37 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 10:55:37 -0500 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> Message-ID: Oops, missed a revision. Looks good, though the reader may puzzle a while about why. Thanks, Roger On 01/04/2019 10:44 AM, Remi Forax wrote: > Hi Roger, > the field has disappear in the latest webrev. > > R?mi > > ----- Mail original ----- >> De: "Roger Riggs" >> ?: "Claes Redestad" , "core-libs-dev" >> Envoy?: Vendredi 4 Janvier 2019 16:38:06 >> Objet: Re: RFR: 8215412: Optimize PrintStream.println methods >> Hi Claes, >> >> The logic looks fine, but the 'internal' field name doesn't mean anything >> and there's no description of the optimization. >> >> The field could be renamed:? noOverride or notOverridden or noDoubleSync >> or ... >> or add a comment to the field describing its purpose. >> >> Update copyright date on PrintStream.java. >> >> Thanks, Roger >> >> On 01/02/2019 03:44 AM, Claes Redestad wrote: >>> Hi, >>> >>> new webrev: >>> >>> ?http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ >>> >>> - Adds a forgotten String.valueOf in println(String), making sure all >>> methods are semantically the same for >>> - Remove the isInternal method and use only exact match with >>> PrintStream.class to determine whether to use the optimized paths. >>> >>> As before: >>> >>> On 2018-12-14 21:22, Claes Redestad wrote: >>>> Same performance characteristics in the simple tests I've used to >>>> verify this, and no measurable regression (but no speed-up) for classes >>>> overriding PrintStream. >>> I've withdrawn the related CSR, since it's not relevant for this >>> implementation as it doesn't observably alter behavior of types >>> inheriting from PrintStream. >>> >>> Thanks! >>> >>> /Claes From Roger.Riggs at oracle.com Fri Jan 4 16:08:56 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 11:08:56 -0500 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> Message-ID: <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> Hi David, Its worth considering and so I reset the issue so it would be re-triaged and assigned for an appropriate person to consider. Roger On 01/03/2019 05:58 PM, David Holmes wrote: > Hi Roger, > > On 4/01/2019 12:22 am, Roger Riggs wrote: >> Hi, >> >> With a link to the explanation added to the issue, I think it can be >> closed as not-an-issue. > > Do you think the Class.getDeclared* method specs should be updated to > reflect (pardon the pun) that synthetic methods/constructors will be > included? > > Cheers, > David From Roger.Riggs at oracle.com Fri Jan 4 16:18:37 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 11:18:37 -0500 Subject: 8215798: [javadoc] Use {@systemProperty} for org.openjdk.java.util.stream.tripwire system property Message-ID: <1676b257-b843-9aeb-bb68-4cb02d9a8852@oracle.com> Please review using @systemProperty to refer to the org.openjdk.java.util.stream.tripwire system property. diff --git a/src/java.base/share/classes/java/util/Spliterator.java b/src/java.base/share/classes/java/util/Spliterator.java --- a/src/java.base/share/classes/java/util/Spliterator.java +++ b/src/java.base/share/classes/java/util/Spliterator.java @@ -284,7 +284,7 @@ import java.util.function.LongConsumer; ? * }} ? * ? * @implNote - * If the boolean system property {@code org.openjdk.java.util.stream.tripwire} + * If the boolean system property {@systemProperty org.openjdk.java.util.stream.tripwire} ? * is set to {@code true} then diagnostic warnings are reported if boxing of ? * primitive values occur when operating on primitive subtype specializations. ? * Thanks, Roger From claes.redestad at oracle.com Fri Jan 4 16:33:25 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 17:33:25 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <55309305.338798.1546616773220.JavaMail.zimbra@u-pem.fr> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <44756146.122819.1546430713805.JavaMail.zimbra@u-pem.fr> <7986ef57-2ccd-fda1-c73b-601e7505e806@oracle.com> <9a358a03-b380-08ac-f27a-e7638b0d8bfe@oracle.com> <55309305.338798.1546616773220.JavaMail.zimbra@u-pem.fr> Message-ID: On 2019-01-04 16:46, forax at univ-mlv.fr wrote: > The perf diff is more that what i was expected :) > > Looks good to me ! Thanks! /Claes From claes.redestad at oracle.com Fri Jan 4 16:39:13 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 17:39:13 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> Message-ID: <6b5ebe7b-8f14-6d2b-102f-9d9622e1042f@oracle.com> On 2019-01-04 16:55, Roger Riggs wrote: > Oops, missed a revision. > > Looks good, Thanks! > though the reader may puzzle a while about why. I'll mull a bit about a succinct comment, but at least the version history will point to this RFE.. /Claes From lance.andersen at oracle.com Fri Jan 4 16:55:46 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 4 Jan 2019 11:55:46 -0500 Subject: 8215798: [javadoc] Use {@systemProperty} for org.openjdk.java.util.stream.tripwire system property In-Reply-To: <1676b257-b843-9aeb-bb68-4cb02d9a8852@oracle.com> References: <1676b257-b843-9aeb-bb68-4cb02d9a8852@oracle.com> Message-ID: +1 > On Jan 4, 2019, at 11:18 AM, Roger Riggs wrote: > > Please review using @systemProperty to refer to the org.openjdk.java.util.stream.tripwire > system property. > > > diff --git a/src/java.base/share/classes/java/util/Spliterator.java b/src/java.base/share/classes/java/util/Spliterator.java > --- a/src/java.base/share/classes/java/util/Spliterator.java > +++ b/src/java.base/share/classes/java/util/Spliterator.java > @@ -284,7 +284,7 @@ import java.util.function.LongConsumer; > * }} > * > * @implNote > - * If the boolean system property {@code org.openjdk.java.util.stream.tripwire} > + * If the boolean system property {@systemProperty org.openjdk.java.util.stream.tripwire} > * is set to {@code true} then diagnostic warnings are reported if boxing of > * primitive values occur when operating on primitive subtype specializations. > * > > Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Fri Jan 4 17:10:38 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 4 Jan 2019 09:10:38 -0800 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> Message-ID: Hi Chris, Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of. - The Currency Symbols range is very limited (U+20A0-U+20CF) - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work. - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done. Naoto On 1/4/19 6:13 AM, Chris Hegarty wrote: > > > On 1/3/19 10:26 PM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue (and its approved CSR): >> >> https://bugs.openjdk.java.net/browse/JDK-8215303 >> https://bugs.openjdk.java.net/browse/JDK-8215305 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ > > I think this is a positive change, but for clarity ( since I cannot find it > in the CSR ), will this change have an impact on the set of allowable > characters that can be used as identifiers, i.e. isJavaIdentifierStart, > isJavaIdentifierPart? > > -Chris. > > > From naoto.sato at oracle.com Fri Jan 4 17:11:34 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 4 Jan 2019 09:11:34 -0800 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: <75358210-bdd2-4f54-e310-62a4525516fa@oracle.com> References: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> <75358210-bdd2-4f54-e310-62a4525516fa@oracle.com> Message-ID: +1 Naoto On 1/4/19 7:21 AM, Roger Riggs wrote: > +1 > > On 01/04/2019 04:44 AM, Rachna Goel wrote: >> Hi Dora, >> >> Kindly update copyright years in both files and add bug id in >> LocaleProvidersRun.java. >> >> Other than that, it looks good to me. >> >> Thanks, >> >> Rachna >> >> >> On 1/4/19 7:58 AM, Dora Zhou wrote: >>> Hello, >>> >>> Please help review the fix for the test bug >>> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP >>> locale. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 >>> >>> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ >>> >>> Thanks, >>> Dora >>> >> > From chris.hegarty at oracle.com Fri Jan 4 17:18:42 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 4 Jan 2019 17:18:42 +0000 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> Message-ID: Thanks Naoto. > On 4 Jan 2019, at 17:10, naoto.sato at oracle.com wrote: > > Hi Chris, > > Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of. Ok. Should the CSR be updated to indicate this? > - The Currency Symbols range is very limited (U+20A0-U+20CF) > - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work. > - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done. Sure, all good and valid reasons. Will compilations with `--release N-1` wind back the set of allowable identifiers? It possibly should, if so how does one do similar when/if the set of currency characters is expanded in an update release? -Chris. > Naoto > > On 1/4/19 6:13 AM, Chris Hegarty wrote: >> On 1/3/19 10:26 PM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue (and its approved CSR): >>> >>> https://bugs.openjdk.java.net/browse/JDK-8215303 >>> https://bugs.openjdk.java.net/browse/JDK-8215305 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ >> I think this is a positive change, but for clarity ( since I cannot find it >> in the CSR ), will this change have an impact on the set of allowable >> characters that can be used as identifiers, i.e. isJavaIdentifierStart, >> isJavaIdentifierPart? >> -Chris. From roger.calnan at oracle.com Fri Jan 4 17:41:59 2019 From: roger.calnan at oracle.com (Roger Calnan) Date: Fri, 4 Jan 2019 09:41:59 -0800 Subject: RFR: 8182992 Typo in DatagramPacket constructor API doc In-Reply-To: References: <4ADA3A23-28BB-41CB-BEAD-6A973975C7E4@oracle.com> Message-ID: <19E6432F-8429-4E72-8CA5-779A2DA75609@oracle.com> >> - * suitable for retrieving large{@code LONGVARCHAR}values. The JDBC driver will >> + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will > Needs a space after large indeed, I looked for other examples and found a couple more. I?ll file a bug to get them fixed, Thanks, Roger > From: Lance Andersen > Subject: Re: RFR: 8182992 Typo in DatagramPacket constructor API doc > Date: January 3, 2019 at 9:53:07 AM PST > To: Roger Calnan > Cc: core-libs-dev at openjdk.java.net > > > Hi Roger, > > Please see below. I am not sure how much review the javadocs have gotten for the com/sun/rowset/internal classes > > >> >> >> >> JDK-8215911 Various Typos in SQL Method Documentation >> https://bugs.openjdk.java.net/browse/JDK-8215911 >https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java#l1067 > >> >> diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java >> --- a/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:37:55 2019 -0500 >> +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java Wed Jan 02 13:19:38 2019 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -1064,7 +1064,7 @@ >> >> /** >> * Returns the insert row or the current row of this >> - * {@code CachedRowSetImpl}object. >> + * {@code CachedRowSetImpl} object. >> * >> * @return the {@code Row} object on which this {@code CachedRowSetImpl} >> * objects's cursor is positioned >> @@ -4326,7 +4326,7 @@ >> * >> * @param columnName a {@code String} object that must match the >> * SQL name of a column in this rowset, ignoring case >> - * @param c the new column {@code Clob}value >> + * @param c the new column {@code Clob} value >> * @throws SQLException if (1) the given column name does not match the >> * name of a column in this rowset, (2) the cursor is not on >> * one of this rowset's rows or its insert row, or (3) this >> >> https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l1136 > >> https://hg.openjdk.java.net/jdk/jdk/file/abe21b82ff7c/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java#l6191 > >> >> diff -r abe21b82ff7c src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java >> diff -r 3d0f6ef91216 src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java >> --- a/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:37:55 2019 -0500 >> +++ b/src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java Wed Jan 02 13:19:38 2019 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -1133,7 +1133,7 @@ >> * as a stream of Unicode characters. >> * The value can then be read in chunks from the >> * stream. This method is particularly >> - * suitable for retrieving large{@code LONGVARCHAR}values. The JDBC driver will >> + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will > Needs a space after large >> * do any necessary conversion from the database format into Unicode. >> * The byte format of the Unicode stream must be Java UTF-8, >> * as specified in the Java virtual machine specification. >> @@ -6188,7 +6188,7 @@ >> * @param parameterIndex index of the first parameter is 1, the second is 2, ... >> * @param reader An object that contains the data to set the parameter value to. >> * @throws SQLException if a database access error occurs, this method is called on >> - * a closed {@code PreparedStatement}or if parameterIndex does not correspond to a parameter >> + * a closed {@code PreparedStatement} or if parameterIndex does not correspond to a parameter >> * marker in the SQL statement >> * >> * @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method >> >> > > looks fine otherwise > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From naoto.sato at oracle.com Fri Jan 4 17:43:37 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 4 Jan 2019 09:43:37 -0800 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: Message-ID: <892612da-1663-6dfe-ef95-a17ac3513bbe@oracle.com> Hi Rachna, Updated: http://cr.openjdk.java.net/~naoto/8215303/webrev.01/ Naoto On 1/4/19 2:24 AM, Rachna Goel wrote: > Hi Naoto, > > just one nit, copyright year need to be updated in Character.java. > > Thanks, > > Rachna > > > On 1/3/19 10:26 PM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue (and its approved CSR): >> >> https://bugs.openjdk.java.net/browse/JDK-8215303 >> https://bugs.openjdk.java.net/browse/JDK-8215305 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ >> >> This is a spec only modification that will allow future code point >> additions to the Unicode currency symbols block without any spec >> changes. This is especially important for update releases (such as 8u) >> without releasing a Maintenance Release. >> >> Naoto > > -- > Thanks, > Rachna > From naoto.sato at oracle.com Fri Jan 4 17:53:53 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 4 Jan 2019 09:53:53 -0800 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> Message-ID: <5a3e575e-a698-ad79-8b5f-a0337a1b8f72@oracle.com> Hi Chris, Yes. I just updated the CSR, adding the description in the compatibility risk: https://bugs.openjdk.java.net/browse/JDK-8215305 Naoto On 1/4/19 9:18 AM, Chris Hegarty wrote: > Thanks Naoto. > >> On 4 Jan 2019, at 17:10, naoto.sato at oracle.com wrote: >> >> Hi Chris, >> >> Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of. > > Ok. Should the CSR be updated to indicate this? > >> - The Currency Symbols range is very limited (U+20A0-U+20CF) >> - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work. >> - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done. > > Sure, all good and valid reasons. > > Will compilations with `--release N-1` wind back the set of allowable > identifiers? It possibly should, if so how does one do similar when/if > the set of currency characters is expanded in an update release? > > -Chris. > >> Naoto >> >> On 1/4/19 6:13 AM, Chris Hegarty wrote: >>> On 1/3/19 10:26 PM, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue (and its approved CSR): >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8215303 >>>> https://bugs.openjdk.java.net/browse/JDK-8215305 >>>> >>>> The proposed changeset is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ >>> I think this is a positive change, but for clarity ( since I cannot find it >>> in the CSR ), will this change have an impact on the set of allowable >>> characters that can be used as identifiers, i.e. isJavaIdentifierStart, >>> isJavaIdentifierPart? >>> -Chris. > From brent.christian at oracle.com Fri Jan 4 17:59:57 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 4 Jan 2019 09:59:57 -0800 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> Message-ID: <7831ce6f-6f25-9b99-db72-787e85d7bd51@oracle.com> Looks good. If you wanted to break up L278 in the test before pushing, I wouldn't complain. :) -Brent On 1/4/19 6:52 AM, Roger Riggs wrote: > Hi Brent, Steve, > > Thanks for the review and corrections for copyrights, removing debugging > info, and > input file contents. > > Updated Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844-2/ > > Regards, Roger > > On 01/04/2019 06:03 AM, Steve Groeger wrote: >> Roger, >> >> Looks OK. >> >> One small point, I know it is only a test but do you need the extra >> System.out.printf statements, they look as though they might have been >> just for debugging. >> No issues if they stay in there just wondering if it was a oversight >> in removing them. >> >> Also, need to have the copyright dates changed as we are now in 2019. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> >> >> >> From: Roger Riggs >> To: core-libs-dev >> Date: 03/01/2019 20:48 >> Subject: 8216134 (process) ProcessBuilder startPipeline does not hide >> piped streams >> Sent by: "core-libs-dev" >> ------------------------------------------------------------------------ >> >> >> >> Please review a bug fix for the ProcessBuilder startPipeline test and >> Windows implementation. >> The test failed to check that Process.getInputStream returned the null >> stream >> for all but the last process in the pipeline.? When the test was fixed >> it failed on Windows. >> The Windows ProcessImpl did not ensure that getInputStream returned a >> null stream. >> >> The same issue was found and fixed in the AIX implementation >> (JDK-8211844) >> which prompted investigation of the test. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ >> >> >> Happy New Year!? Roger >> >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU > From Roger.Riggs at oracle.com Fri Jan 4 18:12:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 13:12:18 -0500 Subject: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams In-Reply-To: <7831ce6f-6f25-9b99-db72-787e85d7bd51@oracle.com> References: <584a2f3c-68d1-e1b5-a25e-1a9c5da02397@oracle.com> <7831ce6f-6f25-9b99-db72-787e85d7bd51@oracle.com> Message-ID: Thanks Brent, I will re-wrap L278 before pushing. On 01/04/2019 12:59 PM, Brent Christian wrote: > Looks good. > If you wanted to break up L278 in the test before pushing, I wouldn't > complain. :) > > -Brent > > On 1/4/19 6:52 AM, Roger Riggs wrote: >> Hi Brent, Steve, >> >> Thanks for the review and corrections for copyrights, removing >> debugging info, and >> input file contents. >> >> Updated Webrev: >> ?? http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844-2/ >> >> Regards, Roger >> >> On 01/04/2019 06:03 AM, Steve Groeger wrote: >>> Roger, >>> >>> Looks OK. >>> >>> One small point, I know it is only a test but do you need the extra >>> System.out.printf statements, they look as though they might have >>> been just for debugging. >>> No issues if they stay in there just wondering if it was a oversight >>> in removing them. >>> >>> Also, need to have the copyright dates changed as we are now in 2019. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>> >>> >>> >>> From: Roger Riggs >>> To: core-libs-dev >>> Date: 03/01/2019 20:48 >>> Subject: 8216134 (process) ProcessBuilder startPipeline does not >>> hide piped streams >>> Sent by: "core-libs-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Please review a bug fix for the ProcessBuilder startPipeline test and >>> Windows implementation. >>> The test failed to check that Process.getInputStream returned the null >>> stream >>> for all but the last process in the pipeline.? When the test was fixed >>> it failed on Windows. >>> The Windows ProcessImpl did not ensure that getInputStream returned a >>> null stream. >>> >>> The same issue was found and fixed in the AIX implementation >>> (JDK-8211844) >>> which prompted investigation of the test. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8211844/ >>> >>> >>> Happy New Year!? Roger >>> >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >> From martinrb at google.com Fri Jan 4 18:31:03 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 4 Jan 2019 10:31:03 -0800 Subject: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1 In-Reply-To: <31308541546586703@sas1-0a6c2e2b59d7.qloud-c.yandex.net> References: <44521121546466206@myt4-174696c9aa9d.qloud-c.yandex.net> <31308541546586703@sas1-0a6c2e2b59d7.qloud-c.yandex.net> Message-ID: On Thu, Jan 3, 2019 at 11:26 PM ?????? ??????? wrote: > > I've run into this performance effect while investigating creation of > Spring's ConcurrentReferenceHashMap, > it turned out that it used Array::newInstance to create array of > References stored in a map's Segment: > Slight tangent - ConcurrentHashMap used to use Segments, but no longer does. Probably ConcurrentReferenceHashMap is based on an old version of ConcurrentHashMap and would benefit from a re-port. From huizhe.wang at oracle.com Fri Jan 4 18:53:38 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 04 Jan 2019 10:53:38 -0800 Subject: RFR(JDK 13/java.xml) 8215330: javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match In-Reply-To: References: <5C2E99CE.30302@oracle.com> Message-ID: <5C2FABB2.4050808@oracle.com> Thanks Lance! The change is in now. -Joe On 1/3/19, 3:48 PM, Lance Andersen wrote: > Hi Joe, > > The changes and test seem fine! > > Happy New Year > >> On Jan 3, 2019, at 6:25 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a fix to the impl for the Catalog. The reporter was >> right, in the Group case, we failed to update the currently longest >> match when a match is found. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8215330 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8215330/webrev/ >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From claes.redestad at oracle.com Fri Jan 4 19:40:21 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 20:40:21 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <6b5ebe7b-8f14-6d2b-102f-9d9622e1042f@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> <6b5ebe7b-8f14-6d2b-102f-9d9622e1042f@oracle.com> Message-ID: <609cb630-c95d-3112-3982-d31b25ac7452@oracle.com> On 2019-01-04 17:39, Claes Redestad wrote: > > I'll mull a bit about a succinct comment, but at least the version > history will point to this RFE.. Lest I hear any objections, I'll push with this comment added to the two new writeln methods: // Used to optimize away back-to-back flushing and synchronization when // using println, but since subclasses could exist which depend on // observing a call to print followed by newLine we only use this if // getClass() == PrintStream.class to avoid compatibility issues. /Claes From Roger.Riggs at oracle.com Fri Jan 4 19:36:37 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Jan 2019 14:36:37 -0500 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <609cb630-c95d-3112-3982-d31b25ac7452@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> <7c4fd8a3-7988-e0a2-04be-9b00098c3f11@oracle.com> <99356572-b4d7-66e1-fd1c-e5d2acb23b1e@oracle.com> <703101575.338492.1546616664357.JavaMail.zimbra@u-pem.fr> <6b5ebe7b-8f14-6d2b-102f-9d9622e1042f@oracle.com> <609cb630-c95d-3112-3982-d31b25ac7452@oracle.com> Message-ID: +1 Thanks On 01/04/2019 02:40 PM, Claes Redestad wrote: > > > On 2019-01-04 17:39, Claes Redestad wrote: >> >> I'll mull a bit about a succinct comment, but at least the version >> history will point to this RFE.. > > Lest I hear any objections, I'll push with this comment added to the > two new writeln methods: > > ?// Used to optimize away back-to-back flushing and synchronization when > ?// using println, but since subclasses could exist which depend on > ?// observing a call to print followed by newLine we only use this if > ?// getClass() == PrintStream.class to avoid compatibility issues. > > /Claes From some-java-user-99206970363698485155 at vodafonemail.de Fri Jan 4 23:01:14 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sat, 5 Jan 2019 00:01:14 +0100 (CET) Subject: Feature suggestion: Allow generic wildcard in class literal expression Message-ID: <926413616.355273.1546642874476@mail.vodafone.de> JDK-6184881 describes that Object.getClass() should ideally not return classes of raw types anymore but instead use wildcards. The problem is that, as noted in the comments, this breaks compability with previously written code and therefore this change is not very likely (at the moment?). However, the report does not cover the class literal expression (https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.8.2). It would be good to allow the usage of the wildcard (`?`) for this expression: List.class => Class> Since it is currently not allowed to provide type parameters in the class literal expression there should not be any compatibility issues. Additionally if at some point JDK-6184881 is fixed for class literals as well, then the expression List.class could just be a verbose variant of List.class without causing any problems either. This would make writing methods or constructors which determine a generic type based on a given class easier for generic classes, e.g.: public class MyContainer { private final Class valueClass; public MyContainer(Class valueClass) { this.valueClass = valueClass; } public static void main(String[] args) { MyContainer stringContainer = new MyContainer<>(String.class); // Have to use raw type (or verbose casting of class) MyContainer listContainer = new MyContainer<>(List.class); // With suggested change: MyContainer> listContainer = new MyContainer<>(List.class); } } From some-java-user-99206970363698485155 at vodafonemail.de Fri Jan 4 23:11:09 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sat, 5 Jan 2019 00:11:09 +0100 (CET) Subject: Feature suggestion: Add static equals methods to Float and Double Message-ID: <1901070898.355299.1546643469299@mail.vodafone.de> To test whether primitive float or double values are equal according to `Float.equals` and `Double.equals` you either have to create wrapper instances for them (possible performance decrease), use the respective static `compareTo` (verbose) or have to use the appropriate methods (`floatToIntBits` / `doubleToLongBits`) (verbose and error-prone since you could confuse them with the other conversion methods). It would be good to provide static methods for testing for equality of the primitive values: // In Float.java public static boolean equals(float a, float b) { return Float.floatToIntBits(a) == Float.floatToIntBits(b); } // In Double.java public static boolean equals(double a, double b) { return Double.doubleToLongBits(a) == Double.doubleToLongBits(b); } This would be very convenient for developers and prevent them from writing (possibly faulty) code for this themselves. From some-java-user-99206970363698485155 at vodafonemail.de Fri Jan 4 23:34:17 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sat, 5 Jan 2019 00:34:17 +0100 (CET) Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map Message-ID: <828995999.355333.1546644857686@mail.vodafone.de> The methods currently provided by the Map interface (https://docs.oracle.com/javase/8/docs/api/java/util/Map.html) do not provide an efficient way to look up nullable values. This problem would be solved if JDK-6552529 was implemented, but that will likely not be happening since the interface cannot be changed without breaking compatibility. Ways to currently look up nullable values are: * Combined ussage of `get()` and `containsKey()` -> inefficient * Usage of `getOrDefault()` with private no-value constant, e.g.: private static final Object NO_VALUE = new Object(); // ... V value = map.getOrDefault(key, (V) NO_VALUE); if (value == NO_VALUE) { // No value } else { // Value exists } Both solutions are not really that great, therefore it would be good to provide an easier and (if overridden) more efficient method: default OptionalNullable getOptional(Object key) { V value = get(key); if (value != null || containsKey(key)) { return OptionalNullable.of(value); } else { return OptionalNullable.empty(); } } Where `OptionalNullable` is a new class similar to `Optional` except that null is considered a value. Maybe a `void ifExists(K key, Consumer consumer)`, which makes the consumer consume the value if it exists (= nullable), would be good as well to avoid creation of `OptionalNullable` objects, though that method might (at least for performance reasons) become obsolute when `OptionalNullable` becomes a value type. From forax at univ-mlv.fr Fri Jan 4 23:50:13 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 5 Jan 2019 00:50:13 +0100 (CET) Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <1901070898.355299.1546643469299@mail.vodafone.de> References: <1901070898.355299.1546643469299@mail.vodafone.de> Message-ID: <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> Hi, it's not obvious to me that this is a source backward compatible change. if you have something like: interface Fun { boolean eq(Double a, double b); } ... Fun fun = Double::equals; it's not clear to me which variant will be selected ? regards, R?mi ----- Mail original ----- > De: some-java-user-99206970363698485155 at vodafonemail.de > ?: "core-libs-dev" > Envoy?: Samedi 5 Janvier 2019 00:11:09 > Objet: Feature suggestion: Add static equals methods to Float and Double > To test whether primitive float or double values are equal according to > `Float.equals` and `Double.equals` you either have to create wrapper instances > for them (possible performance decrease), use the respective static `compareTo` > (verbose) or have to use the appropriate methods (`floatToIntBits` / > `doubleToLongBits`) (verbose and error-prone since you could confuse them with > the other conversion methods). > > It would be good to provide static methods for testing for equality of the > primitive values: > > // In Float.java > > public static boolean equals(float a, float b) { > return Float.floatToIntBits(a) == Float.floatToIntBits(b); > } > > // In Double.java > > public static boolean equals(double a, double b) { > return Double.doubleToLongBits(a) == Double.doubleToLongBits(b); > } > > This would be very convenient for developers and prevent them from writing > (possibly faulty) code for this themselves. From some-java-user-99206970363698485155 at vodafonemail.de Sat Jan 5 00:31:51 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sat, 5 Jan 2019 01:31:51 +0100 (CET) Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> Message-ID: <1804954602.355374.1546648311803@mail.vodafone.de> Hello Remi, You are right, the proposed method names would prevent backwards compatibility, I forgot to think about that. Sorry for the trouble. Maybe a different, currently not used name, such as `areEqual`, `primitiveEquals` or similar would be better. What do You think about the addition of such a method? Kind regards > Remi Forax hat am 5. Januar 2019 um 00:50 geschrieben: > > > Hi, > it's not obvious to me that this is a source backward compatible change. > > if you have something like: > interface Fun { boolean eq(Double a, double b); } > ... > Fun fun = Double::equals; > > it's not clear to me which variant will be selected ? > > regards, > R?mi From Alan.Bateman at oracle.com Sat Jan 5 17:03:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 5 Jan 2019 17:03:15 +0000 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> Message-ID: <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com> On 04/01/2019 17:18, Chris Hegarty wrote: > Will compilations with `--release N-1` wind back the set of allowable > identifiers? It possibly should, if so how does one do similar when/if > the set of currency characters is expanded in an update release? > I don't think `javac --release` takes the Unicode version into account. Using JDK 11 javac, I can compile the following with `--release 8` and it will compile even though the Bitcoin currency symbol was only added in Unicode 10 and Java SE 11. It won't compile with JDK 10 or older of course. class X { ?? double ? = 0.0; } I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N. -Alan From orionllmain at gmail.com Sun Jan 6 10:56:20 2019 From: orionllmain at gmail.com (Zheka Kozlov) Date: Sun, 6 Jan 2019 17:56:20 +0700 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <1804954602.355374.1546648311803@mail.vodafone.de> References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> Message-ID: Why don't we just add a generic method which compares any instances of Comparable? public interface Comparator { ... public static > boolean equal(T x, T y) { return x.compareTo(y) == 0; } } Usage: Comparator.equal(1, 1); // true Comparator.equal(1.0, 1.0); // true Comparator.equal(2.0f, 2.0f); // true Comparator.equal("abc", "def"); // false Comparator.equal("abc", 1); // compilation error ??, 5 ???. 2019 ?. ? 09:33, < some-java-user-99206970363698485155 at vodafonemail.de>: > Hello Remi, > You are right, the proposed method names would prevent backwards > compatibility, I forgot to think > about that. Sorry for the trouble. > Maybe a different, currently not used name, such as `areEqual`, > `primitiveEquals` or similar would > be better. > What do You think about the addition of such a method? > > Kind regards > > > Remi Forax hat am 5. Januar 2019 um 00:50 > geschrieben: > > > > > > Hi, > > it's not obvious to me that this is a source backward compatible change. > > > > if you have something like: > > interface Fun { boolean eq(Double a, double b); } > > ... > > Fun fun = Double::equals; > > > > it's not clear to me which variant will be selected ? > > > > regards, > > R?mi > From some-java-user-99206970363698485155 at vodafonemail.de Sun Jan 6 18:41:02 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sun, 6 Jan 2019 19:41:02 +0100 (CET) Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> Message-ID: <529288991.228183.1546800062161@mail.vodafone.de> If the developer implemented the Comparable interface correctly, the method you proposed would be equivalent to java.util.Objects.equals(Object, Object). Additionally both variants would require boxing for primitive types which I initially wanted to prevent. > Zheka Kozlov hat am 6. Januar 2019 um 11:56 geschrieben: > > > Why don't we just add a generic method which compares any instances of Comparable? > ? > > public interface Comparator { > ? ? ? ? ... > ? > public static > boolean equal(T x, T y) { > return x.compareTo(y) == 0; > } > } > > ? > Usage: > ? > Comparator.equal(1, 1); // true > Comparator.equal(1.0, 1.0); // true > Comparator.equal(2.0f, 2.0f); // true?? > Comparator.equal("abc", "def"); // false > Comparator.equal("abc", 1); // compilation error From hboehm at google.com Sun Jan 6 18:40:26 2019 From: hboehm at google.com (Hans Boehm) Date: Sun, 6 Jan 2019 10:40:26 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> Message-ID: What's the motivation for making it easier to spell a comparison method that tells me that -1.0*0.0 is not equal to 1.0*0.0? I would have thought that making this somewhat hard to write is a feature? I agree that there are cases in which this method is useful. But they all seem esoteric enough to me that it's not unreasonable for users to have enough expertise to write the method. Or at least the method should have a name that makes the unusual behavior explicit. On Sun, Jan 6, 2019 at 2:58 AM Zheka Kozlov wrote: > Why don't we just add a generic method which compares any instances of > Comparable? > > public interface Comparator { > ... > > public static > boolean equal(T x, T y) { > return x.compareTo(y) == 0; > } > } > > Usage: > > Comparator.equal(1, 1); // true > Comparator.equal(1.0, 1.0); // true > Comparator.equal(2.0f, 2.0f); // true > Comparator.equal("abc", "def"); // false > Comparator.equal("abc", 1); // compilation error > > ??, 5 ???. 2019 ?. ? 09:33, < > some-java-user-99206970363698485155 at vodafonemail.de>: > > > Hello Remi, > > You are right, the proposed method names would prevent backwards > > compatibility, I forgot to think > > about that. Sorry for the trouble. > > Maybe a different, currently not used name, such as `areEqual`, > > `primitiveEquals` or similar would > > be better. > > What do You think about the addition of such a method? > > > > Kind regards > > > > > Remi Forax hat am 5. Januar 2019 um 00:50 > > geschrieben: > > > > > > > > > Hi, > > > it's not obvious to me that this is a source backward compatible > change. > > > > > > if you have something like: > > > interface Fun { boolean eq(Double a, double b); } > > > ... > > > Fun fun = Double::equals; > > > > > > it's not clear to me which variant will be selected ? > > > > > > regards, > > > R?mi > > > From some-java-user-99206970363698485155 at vodafonemail.de Sun Jan 6 19:01:18 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Sun, 6 Jan 2019 20:01:18 +0100 (CET) Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> Message-ID: <1661909988.228347.1546801278210@mail.vodafone.de> My main goal was to provide a way where NaN is equal to NaN and I went with the behavior of the respective wrapper classes, Float and Double, which consider -0.0 and +0.0 as not equal. The static method could be called "exactlyEquals" if that is better. It might also depend on the usecase whether you want -0.0 being equal to +0.0. Maybe an additional method would be required for the case you are describing, e.g. "valueEquals" (though that can be ambiguous). > Hans Boehm hat am 6. Januar 2019 um 19:40 geschrieben: > > > What's the motivation for making it easier to spell a comparison method that tells me that -1.0*0.0 is not equal to 1.0*0.0? I would have thought that making this somewhat hard to write is a feature? > ? > I agree that there are cases in which this method is useful. But they all seem esoteric enough to me that it's not unreasonable for users to have enough expertise to write the method. Or at least the method should have a name that makes the unusual behavior explicit. From brian.goetz at oracle.com Sun Jan 6 23:54:41 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 6 Jan 2019 18:54:41 -0500 Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map In-Reply-To: <828995999.355333.1546644857686@mail.vodafone.de> References: <828995999.355333.1546644857686@mail.vodafone.de> Message-ID: <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> FYI, the comment about compatibility was obsoleted by the addition of default methods in Java 8. On 1/4/2019 6:34 PM, some-java-user-99206970363698485155 at vodafonemail.de wrote: > The methods currently provided by the Map interface (https://docs.oracle.com/javase/8/docs/api/java/util/Map.html) do not provide an efficient way to look up nullable values. This problem would be solved if JDK-6552529 was implemented, but that will likely not be happening since the interface cannot be changed without breaking compatibility. > > Ways to currently look up nullable values are: > > * Combined ussage of `get()` and `containsKey()` -> inefficient > * Usage of `getOrDefault()` with private no-value constant, e.g.: > private static final Object NO_VALUE = new Object(); > // ... > V value = map.getOrDefault(key, (V) NO_VALUE); > if (value == NO_VALUE) { > // No value > } > else { > // Value exists > } > > Both solutions are not really that great, therefore it would be good to provide an easier and (if overridden) more efficient method: default OptionalNullable getOptional(Object key) { > V value = get(key); > > if (value != null || containsKey(key)) { > return OptionalNullable.of(value); > } > else { > return OptionalNullable.empty(); > } > } > > Where `OptionalNullable` is a new class similar to `Optional` except that null is considered a value. > > Maybe a `void ifExists(K key, Consumer consumer)`, which makes the consumer consume the value if it exists (= nullable), would be good as well to avoid creation of `OptionalNullable` objects, though that method might (at least for performance reasons) become obsolute when `OptionalNullable` becomes a value type. From brian.goetz at oracle.com Sun Jan 6 23:57:02 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 6 Jan 2019 18:57:02 -0500 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <1661909988.228347.1546801278210@mail.vodafone.de> References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> Message-ID: <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Followers of Project Valhalla will see that this issue comes up when defining equality on value types.? The relation you are looking for is being called "substitutible"; it asks whether there is any way to distinguish between two values.? For primitives other than float/double, this coincides with `==`, and similarly for references. An `isSubstitutible()` API point will likely emerge from Valhalla. On 1/6/2019 2:01 PM, some-java-user-99206970363698485155 at vodafonemail.de wrote: > My main goal was to provide a way where NaN is equal to NaN and I went with the behavior of the > respective wrapper classes, Float and Double, which consider -0.0 and +0.0 as not equal. > The static method could be called "exactlyEquals" if that is better. > > It might also depend on the usecase whether you want -0.0 being equal to +0.0. Maybe an additional > method would be required for the case you are describing, e.g. "valueEquals" (though that can be > ambiguous). > >> Hans Boehm hat am 6. Januar 2019 um 19:40 geschrieben: >> >> >> What's the motivation for making it easier to spell a comparison method that tells me that -1.0*0.0 is not equal to 1.0*0.0? I would have thought that making this somewhat hard to write is a feature? >> >> I agree that there are cases in which this method is useful. But they all seem esoteric enough to me that it's not unreasonable for users to have enough expertise to write the method. Or at least the method should have a name that makes the unusual behavior explicit. From hboehm at google.com Mon Jan 7 00:36:39 2019 From: hboehm at google.com (Hans Boehm) Date: Sun, 6 Jan 2019 16:36:39 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: IIUC, isSubstitutible() is not quite what's being proposed here. The proposed definition here uses floatToIntBits(), not floatToRawIntBits(). Hans On Sun, Jan 6, 2019 at 3:59 PM Brian Goetz wrote: > Followers of Project Valhalla will see that this issue comes up when > defining equality on value types. The relation you are looking for is > being called "substitutible"; it asks whether there is any way to > distinguish between two values. For primitives other than float/double, > this coincides with `==`, and similarly for references. > > An `isSubstitutible()` API point will likely emerge from Valhalla. > > On 1/6/2019 2:01 PM, some-java-user-99206970363698485155 at vodafonemail.de > wrote: > > My main goal was to provide a way where NaN is equal to NaN and I went > with the behavior of the > > respective wrapper classes, Float and Double, which consider -0.0 and > +0.0 as not equal. > > The static method could be called "exactlyEquals" if that is better. > > > > It might also depend on the usecase whether you want -0.0 being equal to > +0.0. Maybe an additional > > method would be required for the case you are describing, e.g. > "valueEquals" (though that can be > > ambiguous). > > > >> Hans Boehm hat am 6. Januar 2019 um 19:40 > geschrieben: > >> > >> > >> What's the motivation for making it easier to spell a comparison method > that tells me that -1.0*0.0 is not equal to 1.0*0.0? I would have thought > that making this somewhat hard to write is a feature? > >> > >> I agree that there are cases in which this method is useful. But they > all seem esoteric enough to me that it's not unreasonable for users to have > enough expertise to write the method. Or at least the method should have a > name that makes the unusual behavior explicit. > > From orionllmain at gmail.com Mon Jan 7 04:02:38 2019 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 7 Jan 2019 11:02:38 +0700 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <529288991.228183.1546800062161@mail.vodafone.de> References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <529288991.228183.1546800062161@mail.vodafone.de> Message-ID: Objects.equals is not type-safe: Objects.equals(1, "your mom"); // returns false Comparator.equal(1, "your mom"); // error However, I agree that they are both slower than Float.equal(float, float) and Double.equal(double, double). ??, 7 ???. 2019 ?. ? 01:41, < some-java-user-99206970363698485155 at vodafonemail.de>: > If the developer implemented the Comparable interface correctly, the > method you proposed would be > equivalent to java.util.Objects.equals(Object, Object). > > Additionally both variants would require boxing for primitive types which > I initially wanted to prevent. > > > Zheka Kozlov hat am 6. Januar 2019 um 11:56 > geschrieben: > > > > > > Why don't we just add a generic method which compares any instances of > Comparable? > > > > > > public interface Comparator { > > ... > > > > public static > boolean equal(T x, T y) { > > return x.compareTo(y) == 0; > > } > > } > > > > > > Usage: > > > > Comparator.equal(1, 1); // true > > Comparator.equal(1.0, 1.0); // true > > Comparator.equal(2.0f, 2.0f); // true > > Comparator.equal("abc", "def"); // false > > Comparator.equal("abc", 1); // compilation error > From dan.z.zhou at oracle.com Mon Jan 7 07:06:07 2019 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Mon, 7 Jan 2019 15:06:07 +0800 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> References: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> Message-ID: Hi Rachna, Updated the webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.01/ Regards, Dora On 2019/1/4 17:44, Rachna Goel wrote: > > Hi Dora, > > Kindly update copyright years in both files and add bug id in > LocaleProvidersRun.java. > > Other than that, it looks good to me. > > Thanks, > > Rachna > > > On 1/4/19 7:58 AM, Dora Zhou wrote: >> Hello, >> >> Please help review the fix for the test bug >> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP >> locale. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 >> >> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ >> >> Thanks, >> Dora >> > > -- > Thanks, > Rachna From chris.hegarty at oracle.com Mon Jan 7 10:11:38 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Jan 2019 10:11:38 +0000 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com> References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com> Message-ID: <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com> > On 5 Jan 2019, at 17:03, Alan Bateman wrote: > > On 04/01/2019 17:18, Chris Hegarty wrote: >> Will compilations with `--release N-1` wind back the set of allowable >> identifiers? It possibly should, if so how does one do similar when/if >> the set of currency characters is expanded in an update release? >> > I don't think `javac --release` takes the Unicode version into account. That is a bug. > I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N. The question is whether, or not, it is reasonable to allow ( part of ) the set of Java identifiers, in the language, to be an implementation detail? If so, then certain code compiled and run on BuzzCorps Java implementation may not compile or run on WollyInc's Java implementation. ( Both are compliant Java SE implementations ) I accept that the set of implementation specific currency characters may noy be all that large, but this does seem like a significant change, and I want to ensure that the implications are fully understood. -Chris. From rachna.goel at oracle.com Mon Jan 7 10:29:28 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 7 Jan 2019 15:59:28 +0530 Subject: [13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: References: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com> Message-ID: <27e5a10a-2e52-bb11-11b0-8e3d235847f5@oracle.com> Looks good to me. Thanks, Rachna On 1/7/19 12:36 PM, Dora Zhou wrote: > > Hi Rachna, > > Updated the webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.01/ > > Regards, > Dora > On 2019/1/4 17:44, Rachna Goel wrote: >> >> Hi Dora, >> >> Kindly update copyright years in both files and add bug id in >> LocaleProvidersRun.java. >> >> Other than that, it looks good to me. >> >> Thanks, >> >> Rachna >> >> >> On 1/4/19 7:58 AM, Dora Zhou wrote: >>> Hello, >>> >>> Please help review the fix for the test bug >>> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP >>> locale. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 >>> >>> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ >>> >>> Thanks, >>> Dora >>> >> >> -- >> Thanks, >> Rachna -- Thanks, Rachna From Michael.Rasmussen at roguewave.com Mon Jan 7 10:46:16 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 7 Jan 2019 10:46:16 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com>, <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> Message-ID: Hi, We recently discovered something similar, although with the native counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and the JDI method ReferenceType.methods(). The documentation for which states "Only directly declared methods are returned (not inherited methods)" or "(...) declared directly in this type. Inherited methods are not included." When running the code pasted below with HotSpot (tried OpenJDK8 and 11), I get the following output: [public abstract java.lang.String app1.Test$Child.method2()] [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] As visible, the native call also includes the inherited method() from Parent in the list, which is not present in Child's classfile. Verified with javap -v, an no traces of "method" were found anywhere. For abbreviation, here is grepped output: javap -v app1.Test$Child | grep method #4 = Utf8 method2 public abstract java.lang.String method2(); For comparison, tried running on IBM SDK 8, and OpenJDK 11 with OpenJ9. Neither of those listed method() from the native methods. Kind regards Michael Rasmussen Code snippets: // --- snip --- package app1; import java.lang.reflect.Method; import java.util.Arrays; class Test { public static native Method[] getJVMTIDeclaredMethods(Class klass); public interface Parent { default String def() { return "Parent"; } String method(); } public interface Child extends Parent { String method2(); } public static class Impl implements Child { public String method() { return ""; } public String method2() { return ""; } } public static void main(String[] args) { new Impl(); System.out.println(Arrays.toString(Child.class.getDeclaredMethods())); System.out.println(Arrays.toString(getJVMTIDeclaredMethods(Child.class))); } } // --- snap --- and the corresponding native component: // -- snip --- #include #include "jni.h" #include "jvmti.h" static jvmtiEnv *jvmti; JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *vm, char *options, void *reserved) { (*vm)->GetEnv(vm, (void **)&jvmti, JVMTI_VERSION_1_2); return 0; } JNIEXPORT jobjectArray JNICALL Java_app1_Test_getJVMTIDeclaredMethods(JNIEnv *env, jclass static_klass, jclass klass) { jint method_count; jmethodID* methods; (*jvmti)->GetClassMethods(jvmti, klass, &method_count, &methods); jclass method_cls = (*env)->FindClass(env, "java/lang/reflect/Method"); jobjectArray array = (*env)->NewObjectArray(env, method_count, method_cls, NULL); for (int i = 0; i < method_count; i++) { jint modifiers = (*jvmti)->GetMethodModifiers(jvmti, methods[i], &modifiers); jobject m = (*env)->ToReflectedMethod(env, klass, methods[i], modifiers & 8 == 8); (*env)->SetObjectArrayElement(env, array, i, m); (*env)->DeleteLocalRef(env, m); } (*jvmti)->Deallocate(jvmti, (unsigned char *)methods); return array; } // --- snap --- Example run on Windows with OpenJDK 8 (HotSpot): C:\XWork\native-test>\Work\jvm\jdk8\bin\java -agentpath:build\libs\hello\shared\hello.dll -cp build\classes\java\main app1.Test [public abstract java.lang.String app1.Test$Child.method2()] [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] From christoph.langer at sap.com Mon Jan 7 11:13:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Jan 2019 11:13:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Hi, I?ve amended the jdk.zipfs module documentation in src/jdk.zipfs/share/classes/module-info.java to document the new behavior (e.g. support of PosixFileAttributeView) as requested by Alan. I?ve also updated the CSR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Please review both, CSR and changeset and let me know if this is good now or what else needs to be addressed. Thanks and best regards, Christoph From: Volker Simonis Sent: Freitag, 21. Dezember 2018 17:34 To: Langer, Christoph Cc: Java Core Libs ; security-dev ; SHEN, XUEMING ; Alan Bateman ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Christoph, thanks for updating the change. I think it is in a good state now and ready to go! Also the documentation in the CSR for this issue (https://bugs.openjdk.java.net/browse/JDK-8213082) is greatly appreciated and answers all the questions which have been raised so far. So if there are still any open questions I'd recommend that any potential reviewer consults the CSR at https://bugs.openjdk.java.net/browse/JDK-8213082 first. Thank you and best regards, Volker On Fri, Dec 21, 2018 at 3:31 PM Langer, Christoph > wrote: Hi all, here comes the updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ I've rebased the change to the current state of the JDK depot. Thanks to Volker, the test has been enhanced and now also tests more copy operations (from zip file system to zip file system and from zip file system to default file system and back). The points below were also addressed: > ZipFileAttributeView.java > - can you please throw an AssertionError() for the default branch in > the switch expression in the "ZipFileAttributeView.name()". The default branch will return "basic". Looking at the code it should not be jumped to anyway. > ZipFileSystem.java > - please also put @Override annotations on the method implementations > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > a comment at the place where the implementation of the > "PosixFileAttributes" methods starts. Done, I also reordered the methods - first "basic" then "posix" then "zip". > ZipUtils.java > - just a question: isn't it possible to reuse > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > constants from sun.nio.fs.UnixConstants instead of redefining them > here? You could export them from java.base to jdk.zipfs but the > problem is probably that at least sun.nio.fs.UnixConstants is a > generated class which only gets generated on Unix systems, right ? You've already answered yourself ?? These classes only exist on Unix type JDKs. > ZipFileAttributes.java > - it seems a little odd that you've added "setPermissions()" to > ZipFileAttributes. All the attribute classes (i.e. > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > possible to implement "ZipFileAttributeView.setPermissions()" by > calling "path.setPermissions()" (as this is done in > "ZipFileAttributeView.setTimes()") and handle everything in > ZipFileSyste (as this is done with "setTimes()"). Good catch & thanks for providing the better implementation. I think this version is quite final now and thoroughly tested. I hope to get some valid reviews soon... Thanks Christoph From Michael.Rasmussen at roguewave.com Mon Jan 7 12:13:50 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 7 Jan 2019 12:13:50 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com>, <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com>, Message-ID: Ups, just noticed a small error in the native code, assigning the error-result of GetMethodModifiers to modifiers. For the test at hand though it doesn't change anything, as modifiers is only used to check if it's a static method or not. /Michael ________________________________ From: core-libs-dev on behalf of Michael Rasmussen Sent: 07 January 2019 12:46:16 To: Roger Riggs; David Holmes; core-libs-dev at openjdk.java.net Subject: Re: Class.getDeclaredMethods() is returning inherited methods Hi, We recently discovered something similar, although with the native counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and the JDI method ReferenceType.methods(). The documentation for which states "Only directly declared methods are returned (not inherited methods)" or "(...) declared directly in this type. Inherited methods are not included." When running the code pasted below with HotSpot (tried OpenJDK8 and 11), I get the following output: [public abstract java.lang.String app1.Test$Child.method2()] [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] As visible, the native call also includes the inherited method() from Parent in the list, which is not present in Child's classfile. Verified with javap -v, an no traces of "method" were found anywhere. For abbreviation, here is grepped output: javap -v app1.Test$Child | grep method #4 = Utf8 method2 public abstract java.lang.String method2(); For comparison, tried running on IBM SDK 8, and OpenJDK 11 with OpenJ9. Neither of those listed method() from the native methods. Kind regards Michael Rasmussen Code snippets: // --- snip --- package app1; import java.lang.reflect.Method; import java.util.Arrays; class Test { public static native Method[] getJVMTIDeclaredMethods(Class klass); public interface Parent { default String def() { return "Parent"; } String method(); } public interface Child extends Parent { String method2(); } public static class Impl implements Child { public String method() { return ""; } public String method2() { return ""; } } public static void main(String[] args) { new Impl(); System.out.println(Arrays.toString(Child.class.getDeclaredMethods())); System.out.println(Arrays.toString(getJVMTIDeclaredMethods(Child.class))); } } // --- snap --- and the corresponding native component: // -- snip --- #include #include "jni.h" #include "jvmti.h" static jvmtiEnv *jvmti; JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *vm, char *options, void *reserved) { (*vm)->GetEnv(vm, (void **)&jvmti, JVMTI_VERSION_1_2); return 0; } JNIEXPORT jobjectArray JNICALL Java_app1_Test_getJVMTIDeclaredMethods(JNIEnv *env, jclass static_klass, jclass klass) { jint method_count; jmethodID* methods; (*jvmti)->GetClassMethods(jvmti, klass, &method_count, &methods); jclass method_cls = (*env)->FindClass(env, "java/lang/reflect/Method"); jobjectArray array = (*env)->NewObjectArray(env, method_count, method_cls, NULL); for (int i = 0; i < method_count; i++) { jint modifiers = (*jvmti)->GetMethodModifiers(jvmti, methods[i], &modifiers); jobject m = (*env)->ToReflectedMethod(env, klass, methods[i], modifiers & 8 == 8); (*env)->SetObjectArrayElement(env, array, i, m); (*env)->DeleteLocalRef(env, m); } (*jvmti)->Deallocate(jvmti, (unsigned char *)methods); return array; } // --- snap --- Example run on Windows with OpenJDK 8 (HotSpot): C:\XWork\native-test>\Work\jvm\jdk8\bin\java -agentpath:build\libs\hello\shared\hello.dll -cp build\classes\java\main app1.Test [public abstract java.lang.String app1.Test$Child.method2()] [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] From david.holmes at oracle.com Mon Jan 7 12:46:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Jan 2019 22:46:43 +1000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> Message-ID: On 7/01/2019 8:46 pm, Michael Rasmussen wrote: > Hi, > > We recently discovered something similar, although with the native counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and the JDI method ReferenceType.methods(). > The documentation for which states "Only directly declared methods are returned (not inherited methods)" or "(...) declared directly in this type. Inherited methods are not included." > > When running the code pasted below with HotSpot (tried OpenJDK8 and 11), I get the following output: > [public abstract java.lang.String app1.Test$Child.method2()] > [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] This would appear to be a bug with JVM TI in how default methods are accounted for. GetClassMethods simply looks at the methods defined in the instanceKlass, but for interfaces default methods are included. I'll look into this in more detail and file a hotspot bug. David ------ > As visible, the native call also includes the inherited method() from Parent in the list, which is not present in Child's classfile. Verified with javap -v, an no traces of "method" were found anywhere. For abbreviation, here is grepped output: > javap -v app1.Test$Child | grep method > #4 = Utf8 method2 > public abstract java.lang.String method2(); > > For comparison, tried running on IBM SDK 8, and OpenJDK 11 with OpenJ9. Neither of those listed method() from the native methods. > > Kind regards > Michael Rasmussen > > Code snippets: > // --- snip --- > package app1; > > import java.lang.reflect.Method; > import java.util.Arrays; > > class Test { > public static native Method[] getJVMTIDeclaredMethods(Class klass); > > public interface Parent { > default String def() { return "Parent"; } > String method(); > } > > public interface Child extends Parent { > String method2(); > } > > public static class Impl implements Child { > public String method() { return ""; } > public String method2() { return ""; } > } > > public static void main(String[] args) { > new Impl(); > System.out.println(Arrays.toString(Child.class.getDeclaredMethods())); > System.out.println(Arrays.toString(getJVMTIDeclaredMethods(Child.class))); > } > } > // --- snap --- > > and the corresponding native component: > // -- snip --- > #include > > #include "jni.h" > #include "jvmti.h" > > static jvmtiEnv *jvmti; > > JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *vm, char *options, void *reserved) { > (*vm)->GetEnv(vm, (void **)&jvmti, JVMTI_VERSION_1_2); > > return 0; > } > > JNIEXPORT jobjectArray JNICALL Java_app1_Test_getJVMTIDeclaredMethods(JNIEnv *env, jclass static_klass, jclass klass) { > jint method_count; > jmethodID* methods; > (*jvmti)->GetClassMethods(jvmti, klass, &method_count, &methods); > > jclass method_cls = (*env)->FindClass(env, "java/lang/reflect/Method"); > jobjectArray array = (*env)->NewObjectArray(env, method_count, method_cls, NULL); > > for (int i = 0; i < method_count; i++) { > jint modifiers = (*jvmti)->GetMethodModifiers(jvmti, methods[i], &modifiers); > > jobject m = (*env)->ToReflectedMethod(env, klass, methods[i], modifiers & 8 == 8); > (*env)->SetObjectArrayElement(env, array, i, m); > > (*env)->DeleteLocalRef(env, m); > } > > (*jvmti)->Deallocate(jvmti, (unsigned char *)methods); > > return array; > } > // --- snap --- > > Example run on Windows with OpenJDK 8 (HotSpot): > C:\XWork\native-test>\Work\jvm\jdk8\bin\java -agentpath:build\libs\hello\shared\hello.dll -cp build\classes\java\main app1.Test > [public abstract java.lang.String app1.Test$Child.method2()] > [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] > From hannes at angst.email Mon Jan 7 13:05:16 2019 From: hannes at angst.email (Hannes Angst) Date: Mon, 7 Jan 2019 14:05:16 +0100 (CET) Subject: jdk1.8 sun.util.locale.LocaleMatcher StringIndexOutOfBoundsException with acceptLanguage TLH Message-ID: <1789650462.2035354.1546866316920.JavaMail.open-xchange@ox-api-1.vpn.udag.de> Hi, I encountered an error while parsing acceptHeader languages with JDK 1.8 on OSX. Since the involved JDK code from RT is in share, OS should not matter. What happened: (1) Accept-Language: tlh (2) Locale.LanguageRange.parse("tlh") returns "tlh" and "i-klingon" as LanguageRange. (3) Locale.lookup -> LocaleMatcher.lookupTag at 202 fails on line 231 because rangeForRegex.length()-2 is "-1". As I am not allowed to file a bug report, nor am I sure this is really a bug, I hope I am on the right mailing list and you can help me with that. Test-Case: ---------------------------------------------------------------------------------------- import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.Arrays; import java.util.List; import java.util.Locale; @RunWith(JUnit4.class) public class LocaleTest { @Test public void testLocaleParser() { String acceptLanguageHeader = "tlh"; List supportedLocales = Arrays.asList(Locale.GERMAN, Locale.ENGLISH); Locale fallback = Locale.ENGLISH; Locale locale = Locale.lookup(Locale.LanguageRange.parse(acceptLanguageHeader), supportedLocales); if (locale == null) { locale = fallback; } Assert.assertEquals(fallback, locale); } } ---------------------------------------------------------------------------------------- Output ---------------------------------------------------------------------------------------- java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1967) at sun.util.locale.LocaleMatcher.lookupTag(LocaleMatcher.java:233) at sun.util.locale.LocaleMatcher.lookup(LocaleMatcher.java:193) at java.util.Locale.lookup(Locale.java:3261) -snip- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) ---------------------------------------------------------------------------------------- I would have written this mail in Klingon, if only I was able to ;) Cheers, Hannes From Michael.Rasmussen at roguewave.com Mon Jan 7 13:35:02 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 7 Jan 2019 13:35:02 +0000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> , Message-ID: > On 7/01/2019 8:46 pm, Michael Rasmussen wrote: > > Hi, > > > > We recently discovered something similar, although with the native counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and the JDI method ReferenceType.methods(). > > The documentation for which states "Only directly declared methods are returned (not inherited methods)" or "(...) declared directly in this type. Inherited methods are not included." > > > > When running the code pasted below with HotSpot (tried OpenJDK8 and 11), I get the following output: > > [public abstract java.lang.String app1.Test$Child.method2()] > > [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] > > This would appear to be a bug with JVM TI in how default methods are > accounted for. GetClassMethods simply looks at the methods defined in > the instanceKlass, but for interfaces default methods are included. I'll > look into this in more detail and file a hotspot bug. An interesting thing is that it's not the default method "def" that is listed, but the abstract method "method" (with incorrect modifier?) /Michael From andrew_m_leonard at uk.ibm.com Mon Jan 7 13:50:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 7 Jan 2019 13:50:34 +0000 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? In-Reply-To: References: Message-ID: Anyone got any views on which "regex" beheviour is correct JDK8 or JDK11 ? thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: "OpenJDK Core Libs Developers" Date: 03/01/2019 11:20 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? Hi, I'm currently investigating bug JDK-8215626 and have discovered the problem is in the Pattern interpretation of the [^..&&..] negation when applied to "intersected" expressions. So I have simplified the bug example to a more extreme and obvious example: Input string: "1234 ABCDEFG !$%^& abcdefg" pattern RegEx: "[^[A-B]&&[^ef]]" Operation: pattern.matcher(input).replaceAll(""); JDK8 output: 1234 CDEFG !$%^& abcdefg JDK11 output: AB So from the "spec" : A character class is a set of characters enclosed within square brackets. It specifies the characters that will successfully match a single character from a given input string Intersection: To create a single character class matching only the characters common to all of its nested classes, use &&, as in [0-9&&[345]]. Negation: To match all characters except those listed, insert the "^" metacharacter at the beginning of the character class. The way I read the "spec" is the "^" negation negates the whole character class within the outer square brackets, thus in this example: "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" ie.the negation of the intersect of chars A,B and everything other than e,f which is thus the negation of A,B hence the operation above will remove any character in the input string other than A,B Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is applying the ^ negation to just [A-B] and then intersecting it with [^ef], which to me is the wrong interpretation of the "spec". Your thoughts please? If JDK11 is correct, and JDK8 wrong, then the next question is do we fix JDK8? as there's obviously potential "behavioural" impacts to existing applications....? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Mon Jan 7 15:22:15 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Jan 2019 10:22:15 -0500 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? In-Reply-To: References: Message-ID: <25fad9c3-59ee-f5cf-3d80-a63ef4c2a142@oracle.com> Hi Andrew, Did your investigation lead you to: 6609854: Regex does not match correctly for negative nested character classes That might explain when the behavior changed and perhaps why. $.02, Roger On 01/03/2019 06:20 AM, Andrew Leonard wrote: > Hi, > I'm currently investigating bug JDK-8215626 and have discovered the > problem is in the Pattern interpretation of the [^..&&..] negation when > applied to "intersected" expressions. So I have simplified the bug example > to a more extreme and obvious example: > Input string: "1234 ABCDEFG !$%^& abcdefg" > pattern RegEx: "[^[A-B]&&[^ef]]" > Operation: pattern.matcher(input).replaceAll(""); > > JDK8 output: > 1234 CDEFG !$%^& abcdefg > JDK11 output: > AB > > So from the "spec" : > A character class is a set of characters enclosed within square brackets. > It specifies the characters that will successfully match a single > character from a given input string > Intersection: > To create a single character class matching only the characters common to > all of its nested classes, use &&, as in [0-9&&[345]]. > Negation: > To match all characters except those listed, insert the "^" metacharacter > at the beginning of the character class. > > The way I read the "spec" is the "^" negation negates the whole character > class within the outer square brackets, thus in this example: > "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" > ie.the negation of the intersect of chars A,B and everything other > than e,f > which is thus the negation of A,B > hence the operation above will remove any character in the input > string other than A,B > Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is > applying the ^ negation to just [A-B] and then intersecting it with [^ef], > which to me is the wrong interpretation of the "spec". > > Your thoughts please? > > If JDK11 is correct, and JDK8 wrong, then the next question is do we fix > JDK8? as there's obviously potential "behavioural" impacts to existing > applications....? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Mon Jan 7 15:36:37 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Jan 2019 10:36:37 -0500 Subject: jdk1.8 sun.util.locale.LocaleMatcher StringIndexOutOfBoundsException with acceptLanguage TLH In-Reply-To: <1789650462.2035354.1546866316920.JavaMail.open-xchange@ox-api-1.vpn.udag.de> References: <1789650462.2035354.1546866316920.JavaMail.open-xchange@ox-api-1.vpn.udag.de> Message-ID: <95f4cda9-2552-0253-d3a1-bf715ab376bb@oracle.com> Hi, That looks like bug fixed in JDK 9: 8135061: java.util.Locale#lookup throws java.lang.StringIndexOutOfBoundsException for range having '-' as second character Roger On 01/07/2019 08:05 AM, Hannes Angst wrote: > Hi, > > I encountered an error while parsing acceptHeader languages with JDK 1.8 on OSX. > > Since the involved JDK code from RT is in share, OS should not matter. > > What happened: > > (1) Accept-Language: tlh > (2) Locale.LanguageRange.parse("tlh") returns "tlh" and "i-klingon" as > LanguageRange. > (3) Locale.lookup -> > LocaleMatcher.lookupTag at 202 fails on line 231 because > rangeForRegex.length()-2 is "-1". > > > As I am not allowed to file a bug report, nor am I sure this is really a bug, I > hope I am on the right mailing list and you can help me with that. > > > Test-Case: > ---------------------------------------------------------------------------------------- > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import org.junit.runners.JUnit4; > > import java.util.Arrays; > import java.util.List; > import java.util.Locale; > > > @RunWith(JUnit4.class) > public class LocaleTest { > @Test > public void testLocaleParser() { > String acceptLanguageHeader = "tlh"; > List supportedLocales = Arrays.asList(Locale.GERMAN, > Locale.ENGLISH); > Locale fallback = Locale.ENGLISH; > > Locale locale = > Locale.lookup(Locale.LanguageRange.parse(acceptLanguageHeader), > supportedLocales); > > if (locale == null) { > locale = fallback; > } > Assert.assertEquals(fallback, locale); > } > } > ---------------------------------------------------------------------------------------- > Output > ---------------------------------------------------------------------------------------- > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(String.java:1967) > at sun.util.locale.LocaleMatcher.lookupTag(LocaleMatcher.java:233) > at sun.util.locale.LocaleMatcher.lookup(LocaleMatcher.java:193) > at java.util.Locale.lookup(Locale.java:3261) > -snip- > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > ---------------------------------------------------------------------------------------- > > > I would have written this mail in Klingon, if only I was able to ;) > > > > Cheers, > > > Hannes From naoto.sato at oracle.com Mon Jan 7 16:26:12 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 7 Jan 2019 08:26:12 -0800 Subject: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates In-Reply-To: <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com> References: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com> <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com> <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com> <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com> Message-ID: Hi Chris, On 1/7/19 2:11 AM, Chris Hegarty wrote: > >> On 5 Jan 2019, at 17:03, Alan Bateman wrote: >> >> On 04/01/2019 17:18, Chris Hegarty wrote: >>> Will compilations with `--release N-1` wind back the set of allowable >>> identifiers? It possibly should, if so how does one do similar when/if >>> the set of currency characters is expanded in an update release? >>> >> I don't think `javac --release` takes the Unicode version into account. > > That is a bug. Yes. > >> I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N. > > > The question is whether, or not, it is reasonable to allow ( part of ) > the set of Java identifiers, in the language, to be an implementation > detail? If so, then certain code compiled and run on BuzzCorps Java > implementation may not compile or run on WollyInc's Java implementation. > ( Both are compliant Java SE implementations ) > > I accept that the set of implementation specific currency characters > may noy be all that large, but this does seem like a significant > change, and I want to ensure that the implications are fully understood. Agree. It's good to have more insights here. I will need to wait for someone more appropriate to answer to this question. Naoto From Andrew.Auclair at G2TCG.COM Mon Jan 7 15:47:03 2019 From: Andrew.Auclair at G2TCG.COM (Andrew Auclair) Date: Mon, 7 Jan 2019 15:47:03 +0000 Subject: jpackage Packaging Tool EA Build Question Message-ID: <463f77b129e44145a72b9cea49aa9a80@G2TCG.COM> Hi, We are currently using JDK 10 with javapackager and have looked at the Early Access build available for the jpackage enhancement. We have a question about an issue we are currently experiencing with javapackager, which appears to have the same behavior in jpackage. Background: In our install we have several 32 bit C++ applications, some 64 bit C++ applications and 64 bit JDK 10 Java applications. The 64 bit C++ and Java applications both use a set of C++ DLLs. This has forced us to place the 64 bit C++ applications in the app folder that the javapackager creates. Jpackage appears to create the same app folder. Our folder structure is outlined below. The executable generated by javapackager appears to be hardcoded to use the app/*.cfg files. We would like the ability to place the contents of the app folder directly in our bin64 folder along with the exe and ico that are generated. Install / bin64 / app / native64.dll Install / bin64 / app / cpp64bitapp.exe Install / bin64 / app / javaapp.jar Install / bin64 / app / javaapp.cfg Install / bin64 / javaapp.exe Install / bin64 / runtime <-- JRE 10 runtime Install / native.dll Install / cpp32bitapp.exe Question: Is it possible for us to rename or change the app folder, or to place the contents of the app folder in the parent directory? Thank you for taking the time to read this, any response is greatly appreciated, Andrew Auclair Software Engineer Tactical Communications Group, LLC 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 978-654-4849 From vicente.romero at oracle.com Mon Jan 7 18:17:45 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 7 Jan 2019 13:17:45 -0500 Subject: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec In-Reply-To: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> References: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> Message-ID: I have updated the webrev after additional feedback from the TCK tester please check last version at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8215510/webrev.01 On 1/3/19 12:21 PM, Vicente Romero wrote: > Please review the fix for bug [1] at [2]. Basically the constants API > introduced as part of JEP-334 [3] were accepting descriptors and class > names not allowed by the spec. This implementation fixes several > issues found by TCK tests on JEP-334, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8215510 > [2] http://cr.openjdk.java.net/~vromero/8215510/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8203252 From Roger.Riggs at oracle.com Mon Jan 7 18:45:48 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Jan 2019 13:45:48 -0500 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv Message-ID: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> Please review a javadoc fix. Only @link is needed, @code is removed. diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.java +++ b/src/java.base/share/classes/java/lang/System.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -1055,7 +1055,7 @@ public final class System { ????? *

If a security manager exists, its ????? * {@link SecurityManager#checkPermission checkPermission} ????? * method is called with a -???? * {@code {@link RuntimePermission}("getenv.*")} permission. +???? * {@link RuntimePermission RuntimePermission("getenv.*")} permission. ????? * This may result in a {@link SecurityException} being thrown. ????? * ????? *

When passing information to a Java subprocess, Thanks, Roger From lance.andersen at oracle.com Mon Jan 7 18:48:48 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 7 Jan 2019 13:48:48 -0500 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> Message-ID: <63C1411F-D368-4848-AFF0-DDF994D0B0C7@oracle.com> +1 > On Jan 7, 2019, at 1:45 PM, Roger Riggs wrote: > > Please review a javadoc fix. Only @link is needed, @code is removed. > > > diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java > +++ b/src/java.base/share/classes/java/lang/System.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1055,7 +1055,7 @@ public final class System { > *

If a security manager exists, its > * {@link SecurityManager#checkPermission checkPermission} > * method is called with a > - * {@code {@link RuntimePermission}("getenv.*")} permission. > + * {@link RuntimePermission RuntimePermission("getenv.*")} permission. > * This may result in a {@link SecurityException} being thrown. > * > *

When passing information to a Java subprocess, > > > Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Mon Jan 7 18:56:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 18:56:33 +0000 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> Message-ID: <2311b641-c0f3-6efe-f02f-3b3e589221a1@oracle.com> On 07/01/2019 18:45, Roger Riggs wrote: > -???? * {@code {@link RuntimePermission}("getenv.*")} permission. > +???? * {@link RuntimePermission RuntimePermission("getenv.*")} > permission. Looks okay. From brent.christian at oracle.com Mon Jan 7 18:58:30 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 7 Jan 2019 10:58:30 -0800 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> Message-ID: Looks good, though it looks like a similar change is needed on L987 for System.getenv(name). -Brent On 1/7/19 10:45 AM, Roger Riggs wrote: > Please review a javadoc fix. Only @link is needed, @code is removed. > > > diff --git a/src/java.base/share/classes/java/lang/System.java > b/src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java > +++ b/src/java.base/share/classes/java/lang/System.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -1055,7 +1055,7 @@ public final class System { > ????? *

If a security manager exists, its > ????? * {@link SecurityManager#checkPermission checkPermission} > ????? * method is called with a > -???? * {@code {@link RuntimePermission}("getenv.*")} permission. > +???? * {@link RuntimePermission RuntimePermission("getenv.*")} permission. > ????? * This may result in a {@link SecurityException} being thrown. > ????? * > ????? *

When passing information to a Java subprocess, > > > Thanks, Roger From brent.christian at oracle.com Mon Jan 7 19:03:59 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 7 Jan 2019 11:03:59 -0800 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> Message-ID: <110253d8-1d27-1753-6b66-5640e2e4c278@oracle.com> Also, AFAICT all the other javadoc mentions of RuntimePermission (besides "getenv") use @code, rather than @link. -Brent On 1/7/19 10:58 AM, Brent Christian wrote: > Looks good, though it looks like a similar change is needed on L987 for > System.getenv(name). > > -Brent > > On 1/7/19 10:45 AM, Roger Riggs wrote: >> Please review a javadoc fix. Only @link is needed, @code is removed. >> >> >> diff --git a/src/java.base/share/classes/java/lang/System.java >> b/src/java.base/share/classes/java/lang/System.java >> --- a/src/java.base/share/classes/java/lang/System.java >> +++ b/src/java.base/share/classes/java/lang/System.java >> @@ -1,5 +1,5 @@ >> ??/* >> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ?? * >> ?? * This code is free software; you can redistribute it and/or modify it >> @@ -1055,7 +1055,7 @@ public final class System { >> ?????? *

If a security manager exists, its >> ?????? * {@link SecurityManager#checkPermission checkPermission} >> ?????? * method is called with a >> -???? * {@code {@link RuntimePermission}("getenv.*")} permission. >> +???? * {@link RuntimePermission RuntimePermission("getenv.*")} >> permission. >> ?????? * This may result in a {@link SecurityException} being thrown. >> ?????? * >> ?????? *

When passing information to a Java subprocess, >> >> >> Thanks, Roger From Alan.Bateman at oracle.com Mon Jan 7 19:09:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 19:09:44 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <7b513a34196141f595cd5d194fb9d8a2@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > I?ve amended the jdk.zipfs module documentation in > src/jdk.zipfs/share/classes/module-info.java to document the new > behavior (e.g. support of PosixFileAttributeView) as requested by > Alan. I?ve also updated the CSR. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > > I think this is on the right path now. I'll start with the javadoc as that will take a few iterations and you'll need to get that agreed before finalizing the CSR. The proposed update starts out "Path objects residing in a zip file system ..." isn't quite right. I think you want start with something like "File systems created by the zip file system provider support the POSIX file attributes defined by the {@link PosixFileAttributeView}". I think the main issue that will need to be worked out is how the bulk read PosixFileAttributeView::readAttributes behaves when the zip entry doesn't have the external file attributes. UOE isn't right because UOE should be thrown or not thrown based on concrete/implementation type. One option is to throw IOE, another is to have it return a PosixFileAttributes that contains an empty permission set. The latter has the advantage that? you can pass the object to anything that excepts a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we have agreement on how the bulk read behaves then it should be easy to agree the javadoc change. -Alan. From Roger.Riggs at oracle.com Mon Jan 7 19:19:02 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Jan 2019 14:19:02 -0500 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <110253d8-1d27-1753-6b66-5640e2e4c278@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> <110253d8-1d27-1753-6b66-5640e2e4c278@oracle.com> Message-ID: <2940b4e0-d0c3-e72d-9305-69367ffc09d9@oracle.com> Hi Brent, Thanks for spotting the 2nd formatting error. I think the references in getenv() are the most useful to have a link to RuntimePermission. Too many links impact readability. Thanks, Roger Updated: diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.java +++ b/src/java.base/share/classes/java/lang/System.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -984,7 +984,7 @@ public final class System { ????? *

If a security manager exists, its ????? * {@link SecurityManager#checkPermission checkPermission} ????? * method is called with a -???? * {@code {@link RuntimePermission}("getenv."+name)} +???? * {@link RuntimePermission RuntimePermission("getenv."+name)} ????? * permission.? This may result in a {@link SecurityException} ????? * being thrown.? If no exception is thrown the value of the ????? * variable {@code name} is returned. @@ -1055,7 +1055,7 @@ public final class System { ????? *

If a security manager exists, its ????? * {@link SecurityManager#checkPermission checkPermission} ????? * method is called with a -???? * {@code {@link RuntimePermission}("getenv.*")} permission. +???? * {@link RuntimePermission RuntimePermission("getenv.*")} permission. ????? * This may result in a {@link SecurityException} being thrown. ????? * ????? *

When passing information to a Java subprocess, On 01/07/2019 02:03 PM, Brent Christian wrote: > Also, AFAICT all the other javadoc mentions of RuntimePermission > (besides "getenv") use @code, rather than @link. > > -Brent > > On 1/7/19 10:58 AM, Brent Christian wrote: >> Looks good, though it looks like a similar change is needed on L987 >> for System.getenv(name). >> >> -Brent >> >> On 1/7/19 10:45 AM, Roger Riggs wrote: >>> Please review a javadoc fix. Only @link is needed, @code is removed. >>> >>> >>> diff --git a/src/java.base/share/classes/java/lang/System.java >>> b/src/java.base/share/classes/java/lang/System.java >>> --- a/src/java.base/share/classes/java/lang/System.java >>> +++ b/src/java.base/share/classes/java/lang/System.java >>> @@ -1,5 +1,5 @@ >>> ??/* >>> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ?? * >>> ?? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -1055,7 +1055,7 @@ public final class System { >>> ?????? *

If a security manager exists, its >>> ?????? * {@link SecurityManager#checkPermission checkPermission} >>> ?????? * method is called with a >>> -???? * {@code {@link RuntimePermission}("getenv.*")} permission. >>> +???? * {@link RuntimePermission RuntimePermission("getenv.*")} >>> permission. >>> ?????? * This may result in a {@link SecurityException} being thrown. >>> ?????? * >>> ?????? *

When passing information to a Java subprocess, >>> >>> >>> Thanks, Roger From lance.andersen at oracle.com Mon Jan 7 19:25:02 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 7 Jan 2019 14:25:02 -0500 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <2940b4e0-d0c3-e72d-9305-69367ffc09d9@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> <110253d8-1d27-1753-6b66-5640e2e4c278@oracle.com> <2940b4e0-d0c3-e72d-9305-69367ffc09d9@oracle.com> Message-ID: +1 * 2 ;-) > On Jan 7, 2019, at 2:19 PM, Roger Riggs wrote: > > Hi Brent, > > Thanks for spotting the 2nd formatting error. > I think the references in getenv() are the most useful to have a link to RuntimePermission. > Too many links impact readability. > > Thanks, Roger > > > Updated: > > diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java > +++ b/src/java.base/share/classes/java/lang/System.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -984,7 +984,7 @@ public final class System { > *

If a security manager exists, its > * {@link SecurityManager#checkPermission checkPermission} > * method is called with a > - * {@code {@link RuntimePermission}("getenv."+name)} > + * {@link RuntimePermission RuntimePermission("getenv."+name)} > * permission. This may result in a {@link SecurityException} > * being thrown. If no exception is thrown the value of the > * variable {@code name} is returned. > @@ -1055,7 +1055,7 @@ public final class System { > *

If a security manager exists, its > * {@link SecurityManager#checkPermission checkPermission} > * method is called with a > - * {@code {@link RuntimePermission}("getenv.*")} permission. > + * {@link RuntimePermission RuntimePermission("getenv.*")} permission. > * This may result in a {@link SecurityException} being thrown. > * > *

When passing information to a Java subprocess, > > > > > > On 01/07/2019 02:03 PM, Brent Christian wrote: >> Also, AFAICT all the other javadoc mentions of RuntimePermission (besides "getenv") use @code, rather than @link. >> >> -Brent >> >> On 1/7/19 10:58 AM, Brent Christian wrote: >>> Looks good, though it looks like a similar change is needed on L987 for System.getenv(name). >>> >>> -Brent >>> >>> On 1/7/19 10:45 AM, Roger Riggs wrote: >>>> Please review a javadoc fix. Only @link is needed, @code is removed. >>>> >>>> >>>> diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java >>>> --- a/src/java.base/share/classes/java/lang/System.java >>>> +++ b/src/java.base/share/classes/java/lang/System.java >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or modify it >>>> @@ -1055,7 +1055,7 @@ public final class System { >>>> *

If a security manager exists, its >>>> * {@link SecurityManager#checkPermission checkPermission} >>>> * method is called with a >>>> - * {@code {@link RuntimePermission}("getenv.*")} permission. >>>> + * {@link RuntimePermission RuntimePermission("getenv.*")} permission. >>>> * This may result in a {@link SecurityException} being thrown. >>>> * >>>> *

When passing information to a Java subprocess, >>>> >>>> >>>> Thanks, Roger > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From volker.simonis at gmail.com Mon Jan 7 19:26:46 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Jan 2019 20:26:46 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: Hi Alan, thaks for looking at the javadoc/CSR. On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman wrote: > > On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > > > I?ve amended the jdk.zipfs module documentation in src/jdk.zipfs/share/classes/module-info.java to document the new behavior (e.g. support of PosixFileAttributeView) as requested by Alan. I?ve also updated the CSR. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > > I think this is on the right path now. I'll start with the javadoc as that will take a few iterations and you'll need to get that agreed before finalizing the CSR. > > The proposed update starts out "Path objects residing in a zip file system ..." isn't quite right. I think you want start with something like "File systems created by the zip file system provider support the POSIX file attributes defined by the {@link PosixFileAttributeView}". > > I think the main issue that will need to be worked out is how the bulk read PosixFileAttributeView::readAttributes behaves when the zip entry doesn't have the external file attributes. UOE isn't right because UOE should be thrown or not thrown based on concrete/implementation type. One option is to throw IOE, another is to have it return a PosixFileAttributes that contains an empty permission set. We considered this, but it is problematic because it is perfectly valid to have a file with external file attributes where none of the Posix attributes is actually set (i.e. an empty set of Posix files attributes). This wouldn't be distinguishable from the case where a file has no external file attributes. So it seems we have to resort to throwing an IOE? > The latter has the advantage that you can pass the object to anything that excepts a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we have agreement on how the bulk read behaves then it should be easy to agree the javadoc change. > > -Alan. From brent.christian at oracle.com Mon Jan 7 19:31:55 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 7 Jan 2019 11:31:55 -0800 Subject: RFR 8216205: Java API documentation formatting error in System.getEnv In-Reply-To: <2940b4e0-d0c3-e72d-9305-69367ffc09d9@oracle.com> References: <88cf79e0-4df5-9f91-706e-f0e620a64735@oracle.com> <110253d8-1d27-1753-6b66-5640e2e4c278@oracle.com> <2940b4e0-d0c3-e72d-9305-69367ffc09d9@oracle.com> Message-ID: <1cda5a3e-b7c9-6d42-7da2-49a4574b3181@oracle.com> OK - looks good. -B On 1/7/19 11:19 AM, Roger Riggs wrote: > Hi Brent, > > Thanks for spotting the 2nd formatting error. > I think the references in getenv() are the most useful to have a link to > RuntimePermission. > Too many links impact readability. > > Thanks, Roger > > > Updated: > > diff --git a/src/java.base/share/classes/java/lang/System.java > b/src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java > +++ b/src/java.base/share/classes/java/lang/System.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -984,7 +984,7 @@ public final class System { > ????? *

If a security manager exists, its > ????? * {@link SecurityManager#checkPermission checkPermission} > ????? * method is called with a > -???? * {@code {@link RuntimePermission}("getenv."+name)} > +???? * {@link RuntimePermission RuntimePermission("getenv."+name)} > ????? * permission.? This may result in a {@link SecurityException} > ????? * being thrown.? If no exception is thrown the value of the > ????? * variable {@code name} is returned. > @@ -1055,7 +1055,7 @@ public final class System { > ????? *

If a security manager exists, its > ????? * {@link SecurityManager#checkPermission checkPermission} > ????? * method is called with a > -???? * {@code {@link RuntimePermission}("getenv.*")} permission. > +???? * {@link RuntimePermission RuntimePermission("getenv.*")} permission. > ????? * This may result in a {@link SecurityException} being thrown. > ????? * > ????? *

When passing information to a Java subprocess, > > > > > > On 01/07/2019 02:03 PM, Brent Christian wrote: >> Also, AFAICT all the other javadoc mentions of RuntimePermission >> (besides "getenv") use @code, rather than @link. >> >> -Brent >> >> On 1/7/19 10:58 AM, Brent Christian wrote: >>> Looks good, though it looks like a similar change is needed on L987 >>> for System.getenv(name). >>> >>> -Brent >>> >>> On 1/7/19 10:45 AM, Roger Riggs wrote: >>>> Please review a javadoc fix. Only @link is needed, @code is removed. >>>> >>>> >>>> diff --git a/src/java.base/share/classes/java/lang/System.java >>>> b/src/java.base/share/classes/java/lang/System.java >>>> --- a/src/java.base/share/classes/java/lang/System.java >>>> +++ b/src/java.base/share/classes/java/lang/System.java >>>> @@ -1,5 +1,5 @@ >>>> ??/* >>>> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All >>>> rights reserved. >>>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> ?? * >>>> ?? * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -1055,7 +1055,7 @@ public final class System { >>>> ?????? *

If a security manager exists, its >>>> ?????? * {@link SecurityManager#checkPermission checkPermission} >>>> ?????? * method is called with a >>>> -???? * {@code {@link RuntimePermission}("getenv.*")} permission. >>>> +???? * {@link RuntimePermission RuntimePermission("getenv.*")} >>>> permission. >>>> ?????? * This may result in a {@link SecurityException} being thrown. >>>> ?????? * >>>> ?????? *

When passing information to a Java subprocess, >>>> >>>> >>>> Thanks, Roger > From joe.darcy at oracle.com Mon Jan 7 19:41:12 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Jan 2019 11:41:12 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: <1901070898.355299.1546643469299@mail.vodafone.de> References: <1901070898.355299.1546643469299@mail.vodafone.de> Message-ID: <0c608e4a-9112-794e-48da-970d71f787e9@oracle.com> Hello 99206970363698485155,h On 1/4/2019 3:11 PM, some-java-user-99206970363698485155 at vodafonemail.de wrote: > To test whether primitive float or double values are equal according to `Float.equals` and `Double.equals` you either have to create wrapper instances for them (possible performance decrease), use the respective static `compareTo` (verbose) or have to use the appropriate methods (`floatToIntBits` / `doubleToLongBits`) (verbose and error-prone since you could confuse them with the other conversion methods). In the context of a mathematics course, it is common to define multiple equivalence relations over the same set of values. For objects in Java, we see this in object identity under "a == b" as possibly distinct from? "a.equals(b)". For floating-point, I've written about this years back, please excuse some artifacts introduced by blog conversions: ??? "Notions of Floating-Point Equality" https://blogs.oracle.com/darcy/notions-of-floating-point-equality tl;dr it would be helpful in some contexts to have an "is-equivalent" test for floating-point values. When I need this, say in numerics regression tests, I use ??? Double.compare(a, b) == 0 or a method wrapping that or an equivalent expression. This expression distinguishes -0.0 from +0.0, but treats all NaNs as equivalent. If writing test vectors for a specific chip, then the semantics of which NaN bit pattern is returned are generally defined and a "doubleToRawLongBits?" notion of equality would be appropriate instead. If a static two-argument equals method were to to added to Double, to avoid confusion I think it would need to be added as public boolean equals(double a, double b) { ?? return a == b; } say, to provide the ability to have a method reference to the double == operation. However, I don't think it is necessary to add that method and I don't find a sufficiently compelling case to add "isEquivalent" at this time. Cheers, -Joe > > It would be good to provide static methods for testing for equality of the primitive values: > > // In Float.java > > public static boolean equals(float a, float b) { > return Float.floatToIntBits(a) == Float.floatToIntBits(b); > } > > // In Double.java > > public static boolean equals(double a, double b) { > return Double.doubleToLongBits(a) == Double.doubleToLongBits(b); > } > > This would be very convenient for developers and prevent them from writing (possibly faulty) code for this themselves. From joe.darcy at oracle.com Mon Jan 7 19:43:12 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Jan 2019 11:43:12 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> Message-ID: <1ec36eea-83f2-bcea-921a-0ef331e187c3@oracle.com> See https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Objects.html#compare(T,T,java.util.Comparator) -Joe On 1/6/2019 2:56 AM, Zheka Kozlov wrote: > Why don't we just add a generic method which compares any instances of > Comparable? > > public interface Comparator { > ... > > public static > boolean equal(T x, T y) { > return x.compareTo(y) == 0; > } > } > > Usage: > > Comparator.equal(1, 1); // true > Comparator.equal(1.0, 1.0); // true > Comparator.equal(2.0f, 2.0f); // true > Comparator.equal("abc", "def"); // false > Comparator.equal("abc", 1); // compilation error > > ??, 5 ???. 2019 ?. ? 09:33, < > some-java-user-99206970363698485155 at vodafonemail.de>: > >> Hello Remi, >> You are right, the proposed method names would prevent backwards >> compatibility, I forgot to think >> about that. Sorry for the trouble. >> Maybe a different, currently not used name, such as `areEqual`, >> `primitiveEquals` or similar would >> be better. >> What do You think about the addition of such a method? >> >> Kind regards >> >>> Remi Forax hat am 5. Januar 2019 um 00:50 >> geschrieben: >>> >>> Hi, >>> it's not obvious to me that this is a source backward compatible change. >>> >>> if you have something like: >>> interface Fun { boolean eq(Double a, double b); } >>> ... >>> Fun fun = Double::equals; >>> >>> it's not clear to me which variant will be selected ? >>> >>> regards, >>> R?mi From andy.herrick at oracle.com Mon Jan 7 19:50:19 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 7 Jan 2019 14:50:19 -0500 Subject: Removing Single Instance Service from jpackage Message-ID: <4667fc9e-0904-0df6-c22b-7d86ebd87c52@oracle.com> I would like to propose that we remove SingleInstanceService (and the --singleton command line option) from jpackage. The functionality can easily be implemented in pure java, and I no longer see the necessity of having it implemented in the launcher. (When this functionality was first introduced in the JNLP specification in 2003, and implemented in Java Web Start, launching java was very time-consuming on the hardware available at that time.) I have created a? simple prototype of a java class "Singleton" that implements most of the same functionality in pure java. (see http://cr.openjdk.java.net/~herrick/Singleton.java) The prototype has the following public methods start(), stop(), running(), and invoke(), and could either be: a.) implemented by any application requiring this functionality. b.) added to the JDK for use in any java application c.) added as a demo or otherwise published by Oracle so it could be included as a library in any java applications. I have created bug to remove this functionality from jpackage (https://bugs.openjdk.java.net/browse/JDK-8216190) and am soliciting feedback. /Andy From Alan.Bateman at oracle.com Mon Jan 7 20:46:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 20:46:07 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> On 07/01/2019 19:26, Volker Simonis wrote: > : > We considered this, but it is problematic because it is perfectly > valid to have a file with external file attributes where none of the > Posix attributes is actually set (i.e. an empty set of Posix files > attributes). This wouldn't be distinguishable from the case where a > file has no external file attributes. So it seems we have to resort to > throwing an IOE? > Maybe although it would be a bit awkward to deal with. The issues around this remind me a bit about mounting fat32 file systems on Linux or Unix systems where the fields in the stat structure are populated with default values. PosixFileAttributeView::readAttributes is? essentially the equivalent of a stat call. This might be something to look at for the file owner at least. -Alan From andy.herrick at oracle.com Mon Jan 7 20:59:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 7 Jan 2019 15:59:55 -0500 Subject: jpackage Packaging Tool EA Build Question In-Reply-To: <463f77b129e44145a72b9cea49aa9a80@G2TCG.COM> References: <463f77b129e44145a72b9cea49aa9a80@G2TCG.COM> Message-ID: <5490a1f9-e005-3638-e1c3-fb3fa493087a@oracle.com> interesting ... I would think I would want to do this by first building the app image, then moving the pieces around before building the installer. But that doesn't work: 1.) the installer expects to find a "runtime" sub-directory of the app-image directory.? This could be considered a bug, and I will fix it, but it can be worked around by creating an extra empty "runtime" subdir in the app image. 2.) the installer needs to find the app itself (for installing shortcuts to it).? When using an app-image it determines the app name by looking for a cfg file in the "app" sub-directory of the app-image.? Then given the name, it looks for executable and ico of that name in the top level app-image directory. I suspect I could work around even that by using drop-in resources with the new --resource-dir arg but not sure.? I will look into it and get back to you. (this is significantly different since JDK-8215515 , so even if I can work around this in that way - you would have to wait for the next EA drop). The bigger question is should there be some way to express the install root differently from the app root ? /Andy On 1/7/2019 10:47 AM, Andrew Auclair wrote: > Hi, > > We are currently using JDK 10 with javapackager and have looked at the Early Access build available for the jpackage enhancement. We have a question about an issue we are currently experiencing with javapackager, which appears to have the same behavior in jpackage. > > Background: > > In our install we have several 32 bit C++ applications, some 64 bit C++ applications and 64 bit JDK 10 Java applications. The 64 bit C++ and Java applications both use a set of C++ DLLs. This has forced us to place the 64 bit C++ applications in the app folder that the javapackager creates. Jpackage appears to create the same app folder. > > Our folder structure is outlined below. The executable generated by javapackager appears to be hardcoded to use the app/*.cfg files. We would like the ability to place the contents of the app folder directly in our bin64 folder along with the exe and ico that are generated. > > Install / bin64 / app / native64.dll > Install / bin64 / app / cpp64bitapp.exe > Install / bin64 / app / javaapp.jar > Install / bin64 / app / javaapp.cfg > Install / bin64 / javaapp.exe > Install / bin64 / runtime <-- JRE 10 runtime > Install / native.dll > Install / cpp32bitapp.exe > > Question: > Is it possible for us to rename or change the app folder, or to place the contents of the app folder in the parent directory? > > > > Thank you for taking the time to read this, any response is greatly appreciated, > > > > Andrew Auclair > > Software Engineer > > Tactical Communications Group, LLC > > 2 Highwood Drive, Building 2, Suite 200 > > Tewksbury, MA 01876-1157 > > 978-654-4849 > From philipp.kunz at paratix.ch Mon Jan 7 22:39:38 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 07 Jan 2019 23:39:38 +0100 Subject: [PATCH] for error message not containing file name of jar with bad manifest Message-ID: <1546900778.2438.5.camel@paratix.ch> Hi, I suspect that the filename of a jar never gets into the error message because the only place?Manifest.jarFilename is assigned is in Manifest.Manifest(JarVerifier,InputStream,String) only after a successful call to Manifest.read by which the manifest is already fully read and parsed and after which no error from reading and parsing it could possibly occur any more. The closest related bug I found is 8205525. I would have considered filing a new bug if I had the privileges. For now, I put the existing 8205525 bug number in the @bug tag of the test. Another flaw is that after the manifest has been read from the jar that the jar file name is not reset and a subsequent call to Manifest.read would report the name of the jar file of which the manifest was loaded initially which is admittedly somewhat a strange form of use but absolutely possible with the API as it currently is. I figure the jar file name could go instead to Manifest.jarFilename be added to Manifest.read as a new overloaded kind of optional parameter and then be set in a new Manifest.FastInputStream member variable. Worth a bug? I found an opening bracket missing in an error message fragment and included it in the attached patch without a separate bug or patch. Curiously looking forward to any comment, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 8205525.patch Type: text/x-patch Size: 4724 bytes Desc: not available URL: From lance.andersen at oracle.com Mon Jan 7 23:05:47 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 7 Jan 2019 18:05:47 -0500 Subject: [PATCH] for error message not containing file name of jar with bad manifest In-Reply-To: <1546900778.2438.5.camel@paratix.ch> References: <1546900778.2438.5.camel@paratix.ch> Message-ID: <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> Hi Philipp, I would like to suggest a new bug for this so if you can do that I can sponsor the proposed change Thank you > On Jan 7, 2019, at 5:39 PM, Philipp Kunz wrote: > > <8205525.patch> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From john.r.rose at oracle.com Tue Jan 8 01:34:32 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 7 Jan 2019 17:34:32 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: As I think you expect, isSubstitutible(x,y) will mean that x and y are equivalent for all practical purposes. One hard question is nailing down what are "all practical purposes". Certainly it's unfair to flip a coin while evaluating x and y separately, and claim that a distinct outcome proves a difference. What about viewing the bits of x and y using the Unsafe API? That's unfair also, since it opens the door to implementation-dependent behavior which might detect a difference (an irrelevant difference) between x and y. Now, floatToRawIntBits can detect differences between NaNs which have different numeric codes. Are two such NaNs substitutable or not? The evidence in favor: - They become equivalent when boxed in a Float, and Float claims to be an all-purpose box for float values. - The extra information produced by floatToRawIntBits is implementation specific, and in particular processor dependent. - Joe Darcy suggested to me that some processors, like x87, may perturb NaN bits (turning off the "signalling" bit, for example), even if the float value is simply bound to a parameter. This means that the operand to floatToRawIntBits *might*, in compiled code, possibly have *some* of its bits perturbed. (Thanks, Joe, for that and similar hair-raising stories.) - The previous point implies that compiled code and interpreted code might, in the same JVM instance, produce different results on the same argument. That is quite implementation specific indeed! The evidence against: - The existing standard API point floatToRawIntBits is not going away. So the isSubstitutable API point must document that floatToRawIntBits has the processor-dependent ability to conjure up different bits for x and y. Maybe it should be called isAlmostSubstitutable?? The right trade-off here, I think, is to align isSubstitutable with Float::equals and simply increase the warnings on floatToRawIntBits, that this method can produce platform-specific results in an unpredictable way, and that in particular it can produce distinct answers for otherwise substitutable results. I also suggested to Dr. Deprecator (Stuart Marks) that floatToRawIntBits might be a candidate for deprecation; he said it would be a lot of expense for relatively little benefit. I think at least the javadoc for floatToRawIntBits should not speak so confidently, as it does, of "preserving Not-a-Number (NaN) values", as if these values were something that had a stable semantics, as if they could somehow carry application information. More background (thanks again to Joe): The NaN bits don't have a standard format. Different CPUs can (and often do) disagree on which bits mean what, and how standard arithmetic operations consume and produce them. There is apparently no agreed standard NaN pattern, although Java favors the "all zero" bit pattern as normative. Different CPUs may disagree on which bits denote signaling or quiet NaNs, and when such bits may be queried or modified. Adding the possible distinct treatment of the "same" NaN value in compiled vs. interpreted code (as well as strictfp vs. non-strictfp code), and the use of "raw" NaN bits seems a very risky proposition, useful only for people writing processor-specific code, with great care. In hindsight, I think it would have been nice to place the "raw bits" API points to Unsafe or a separate module. But when those API points were designed (1.0), there were no such hiding places. And it's probably too costly to fix now. If the sweet spot is to acknowledge the wart, but not let it spread, then we design the substitutability test based on Float::equals, not floatToRawIntBits. ? John On Jan 6, 2019, at 4:36 PM, Hans Boehm wrote: > > IIUC, isSubstitutible() is not quite what's being proposed here. The > proposed definition here uses floatToIntBits(), not floatToRawIntBits(). > > Hans > > On Sun, Jan 6, 2019 at 3:59 PM Brian Goetz wrote: > >> Followers of Project Valhalla will see that this issue comes up when >> defining equality on value types. The relation you are looking for is >> being called "substitutible"; it asks whether there is any way to >> distinguish between two values. For primitives other than float/double, >> this coincides with `==`, and similarly for references. >> >> An `isSubstitutible()` API point will likely emerge from Valhalla. From david.holmes at oracle.com Tue Jan 8 01:38:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jan 2019 11:38:45 +1000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> Message-ID: On 7/01/2019 11:35 pm, Michael Rasmussen wrote: >> On 7/01/2019 8:46 pm, Michael Rasmussen wrote: >>> Hi, >>> >>> We recently discovered something similar, although with the native counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and the JDI method ReferenceType.methods(). >>> The documentation for which states "Only directly declared methods are returned (not inherited methods)" or "(...) declared directly in this type. Inherited methods are not included." >>> >>> When running the code pasted below with HotSpot (tried OpenJDK8 and 11), I get the following output: >>> [public abstract java.lang.String app1.Test$Child.method2()] >>> [public default java.lang.String app1.Test$Child.method(), public abstract java.lang.String app1.Test$Child.method2()] >> >> This would appear to be a bug with JVM TI in how default methods are >> accounted for. GetClassMethods simply looks at the methods defined in >> the instanceKlass, but for interfaces default methods are included. I'll >> look into this in more detail and file a hotspot bug. > > An interesting thing is that it's not the default method "def" that is listed, but the abstract method "method" (with incorrect modifier?) Sorry yes I misread the original code and just looked at the extra "default method" in the output. Definitely something not right there. Thanks, David > > /Michael > From stuart.marks at oracle.com Tue Jan 8 02:44:41 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 7 Jan 2019 18:44:41 -0800 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: <88e7b229-06a5-e308-de6d-b9c8311eb61b@oracle.com> References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> <88e7b229-06a5-e308-de6d-b9c8311eb61b@oracle.com> Message-ID: <832fede7-b98c-4a37-4224-7c9317f431e9@oracle.com> > This is one of Stuart's designs Trying to blame it all on me, aren't you? :-) Overall the changes look good. I can't really speak to how to improve the loops in certain circumstances (the "tricky circular array traversal code from ArrayDeque" as Martin puts it). But I observe that moving the randomization to iteration has started to increase the complexity of the code. I understand why we did this, but it's starting to look like we might want to refactor the various loops into a single internal "iterator" to avoid duplicating it all over the place. Perhaps for a future enhancement. I observe that the serialized forms aren't randomized. When the storage order was randomized, the serial form was also randomized. But now that randomization is done during iteration, the serialized forms are fixed. Hmmm. Not sure what I think about that. s'marks From david.holmes at oracle.com Tue Jan 8 04:31:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jan 2019 14:31:09 +1000 Subject: Class.getDeclaredMethods() is returning inherited methods In-Reply-To: References: <8204d18f-ec21-abe0-89fe-802f4f1b4b2e@gmail.com> <5267a6e4-7da5-b268-4e32-076cbe148052@gmail.com> <733f9703-7560-257c-e704-55ed42bbe9e9@oracle.com> <89b7f4e4-31e1-4e92-0eb6-09f37ea53acb@oracle.com> <2c71252d-2e1c-75ee-3a25-646e775985b3@oracle.com> Message-ID: I've filed: https://bugs.openjdk.java.net/browse/JDK-8216324 for the JVM TI bug. David ----- On 8/01/2019 11:38 am, David Holmes wrote: > On 7/01/2019 11:35 pm, Michael Rasmussen wrote: >>> On 7/01/2019 8:46 pm, Michael Rasmussen wrote: >>>> Hi, >>>> >>>> We recently discovered something similar, although with the native >>>> counterparts of getDeclaredMethods: the JVM-TI function >>>> GetClassMethods and the JDI method ReferenceType.methods(). >>>> The documentation for which states "Only directly declared methods >>>> are returned (not inherited methods)" or "(...) declared directly in >>>> this type. Inherited methods are not included." >>>> >>>> When running the code pasted below with HotSpot (tried OpenJDK8 and >>>> 11), I get the following output: >>>> [public abstract java.lang.String app1.Test$Child.method2()] >>>> [public default java.lang.String app1.Test$Child.method(), public >>>> abstract java.lang.String app1.Test$Child.method2()] >>> >>> This would appear to be a bug with JVM TI in how default methods are >>> accounted for. GetClassMethods simply looks at the methods defined in >>> the instanceKlass, but for interfaces default methods are included. I'll >>> look into this in more detail and file a hotspot bug. >> >> An interesting thing is that it's not the default method "def" that is >> listed, but the abstract method "method" (with incorrect modifier?) > > Sorry yes I misread the original code and just looked at the extra > "default method" in the output. Definitely something not right there. > > Thanks, > David >> >> /Michael >> From christoph.langer at sap.com Tue Jan 8 08:27:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Jan 2019 08:27:07 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> Message-ID: Hi Alan, Volker, thanks for bringing up these discussion points. I agree that we shall carefully revisit that. First of all, I'd like to point out that PosixFileAttributeView::readAttributes won't ever throw UOE with the proposed changes to zipfs. It should always return an object of type PosixFileAttributes which will be an incarnation of ZipFileSystem.Entry. The returned PosixFileAttributes(ZipFileSystem.Entry) object now implements 3 additional methods: owner(), group() and permissions(). I can see that UOE should only be thrown if something is not supported by an implementation at all. So it perfectly fits to owner() and group() because this is simply not implemented in zipfs (yet...). As for permissions, I then agree, UOE probably isn't the right thing to do because permissions will now be supported by zipfs. Still, we need to distinguish between the case where no permission information is present vs. an empty set of permissions that was explicitly stored. You brought up IOException as an alternative. But I think this is not really feasible for the following main reason: IOE is no RuntimeException, so it has to be declared for a method when it is thrown. PosixFileAttributes::permissions, however, does not declare IOE so far. And I don't think we can/want to modify the PosixFileAttributes interface for the sake of that zipfs implementation change. I think, we should look into using/returning null for "no permission information present". With that, the point is: What happens if we pass null to another PosixFileAttributeView::setPermissions implementation (or to Files::setPosixFilePermissions, which ends up there). For zipfs, with the proposed changeset, this would work perfectly fine. We translate the null value into (int)-1 for the "posixPerms" field of "Entry" and will then not set permission information in the zip file. But other places in the JDK that implement PosixFileAttributeView need some rework. Those are: src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFileAttributeViewImpl And we should amend the specs/doc for the following methods to define the handling of the null value as a noop: PosixFileAttributeView::setPermissions PosixFileAttributes::permissions Files::setPosixFilePermissions Files::getPosixFilePermissions In the implementation I can see that we modify the aforementioned places to handle null by translating it to (int)-1 in UnixFileModeAttribute::toUnixMode and then using this value as noop in 'setMode' resp. 'fchmod'. Do you think this is the right way to go? Should we maybe do the spec update of the permission methods in a separate change? Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 7. Januar 2019 21:46 > To: Volker Simonis > Cc: Langer, Christoph ; nio-dev dev at openjdk.java.net>; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > On 07/01/2019 19:26, Volker Simonis wrote: > > : > > We considered this, but it is problematic because it is perfectly > > valid to have a file with external file attributes where none of the > > Posix attributes is actually set (i.e. an empty set of Posix files > > attributes). This wouldn't be distinguishable from the case where a > > file has no external file attributes. So it seems we have to resort to > > throwing an IOE? > > > Maybe although it would be a bit awkward to deal with. The issues around > this remind me a bit about mounting fat32 file systems on Linux or Unix > systems where the fields in the stat structure are populated with > default values. PosixFileAttributeView::readAttributes is? essentially > the equivalent of a stat call. This might be something to look at for > the file owner at least. > > -Alan From ulfjack at google.com Tue Jan 8 09:16:36 2019 From: ulfjack at google.com (Ulf Adams) Date: Tue, 8 Jan 2019 10:16:36 +0100 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: Technically, another option would be to have Java standardize a meaning, and I take it you're not mentioning that because of the performance implications? On Tue, Jan 8, 2019 at 2:37 AM John Rose wrote: > As I think you expect, isSubstitutible(x,y) will mean that x and y are > equivalent > for all practical purposes. One hard question is nailing down what are > "all practical purposes". Certainly it's unfair to flip a coin while > evaluating > x and y separately, and claim that a distinct outcome proves a difference. > What about viewing the bits of x and y using the Unsafe API? That's > unfair also, since it opens the door to implementation-dependent behavior > which might detect a difference (an irrelevant difference) between x and y. > > Now, floatToRawIntBits can detect differences between NaNs which > have different numeric codes. Are two such NaNs substitutable or not? > The evidence in favor: > - They become equivalent when boxed in a Float, and Float claims to > be an all-purpose box for float values. > - The extra information produced by floatToRawIntBits is implementation > specific, and in particular processor dependent. > - Joe Darcy suggested to me that some processors, like x87, may > perturb NaN bits (turning off the "signalling" bit, for example), even > if the float value is simply bound to a parameter. This means that > the operand to floatToRawIntBits *might*, in compiled code, possibly > have *some* of its bits perturbed. (Thanks, Joe, for that and similar > hair-raising stories.) > - The previous point implies that compiled code and interpreted code > might, in the same JVM instance, produce different results on the > same argument. That is quite implementation specific indeed! > > The evidence against: > - The existing standard API point floatToRawIntBits is not going away. > So the isSubstitutable API point must document that floatToRawIntBits > has the processor-dependent ability to conjure up different bits for > x and y. Maybe it should be called isAlmostSubstitutable?? > > The right trade-off here, I think, is to align isSubstitutable with > Float::equals > and simply increase the warnings on floatToRawIntBits, that this method > can produce platform-specific results in an unpredictable way, and that > in particular it can produce distinct answers for otherwise substitutable > results. > > I also suggested to Dr. Deprecator (Stuart Marks) that floatToRawIntBits > might be a candidate for deprecation; he said it would be a lot of expense > for relatively little benefit. I think at least the javadoc for > floatToRawIntBits > should not speak so confidently, as it does, of "preserving Not-a-Number > (NaN) values", as if these values were something that had a stable > semantics, as if they could somehow carry application information. > > More background (thanks again to Joe): The NaN bits don't have a standard > format. Different CPUs can (and often do) disagree on which bits > mean what, and how standard arithmetic operations consume and produce > them. There is apparently no agreed standard NaN pattern, although > Java favors the "all zero" bit pattern as normative. Different CPUs > may disagree on which bits denote signaling or quiet NaNs, and when > such bits may be queried or modified. Adding the possible distinct > treatment of the "same" NaN value in compiled vs. interpreted code > (as well as strictfp vs. non-strictfp code), and the use of "raw" NaN > bits seems a very risky proposition, useful only for people writing > processor-specific code, with great care. > > In hindsight, I think it would have been nice to place the "raw bits" > API points to Unsafe or a separate module. But when those API > points were designed (1.0), there were no such hiding places. > And it's probably too costly to fix now. If the sweet spot is to > acknowledge the wart, but not let it spread, then we design the > substitutability test based on Float::equals, not floatToRawIntBits. > > ? John > > On Jan 6, 2019, at 4:36 PM, Hans Boehm wrote: > > > > IIUC, isSubstitutible() is not quite what's being proposed here. The > > proposed definition here uses floatToIntBits(), not floatToRawIntBits(). > > > > Hans > > > > On Sun, Jan 6, 2019 at 3:59 PM Brian Goetz > wrote: > > > >> Followers of Project Valhalla will see that this issue comes up when > >> defining equality on value types. The relation you are looking for is > >> being called "substitutible"; it asks whether there is any way to > >> distinguish between two values. For primitives other than float/double, > >> this coincides with `==`, and similarly for references. > >> > >> An `isSubstitutible()` API point will likely emerge from Valhalla. > > From claes.redestad at oracle.com Tue Jan 8 09:52:26 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 10:52:26 +0100 Subject: RFR: 8215995: Add specialized toArray methods to immutable collections In-Reply-To: <832fede7-b98c-4a37-4224-7c9317f431e9@oracle.com> References: <3b7fbae4-6669-a60f-3ae4-8b181badd365@oracle.com> <07330134-270a-f080-d29d-76b2132d2a98@oracle.com> <93fd00c5-ac7c-d661-5beb-d174f3bc87bc@oracle.com> <88e7b229-06a5-e308-de6d-b9c8311eb61b@oracle.com> <832fede7-b98c-4a37-4224-7c9317f431e9@oracle.com> Message-ID: On 2019-01-08 03:44, Stuart Marks wrote: >> This is one of Stuart's designs > > Trying to blame it all on me, aren't you? :-) Yes: you are being too nice! :-) > > Overall the changes look good. Thanks! > > I can't really speak to how to improve the loops in certain > circumstances (the "tricky circular array traversal code from > ArrayDeque" as Martin puts it). But I observe that moving the > randomization to iteration has started to increase the complexity of the > code. I understand why we did this, but it's starting to look like we > might want to refactor the various loops into a single internal > "iterator" to avoid duplicating it all over the place. Perhaps for a > future enhancement. Right, one generic loop method which accepts one of a few statically defined Functions might cut it, but it would need to be implemented with care not to regress anything and might not significantly reduce complexity until we add a few more specializations. > > I observe that the serialized forms aren't randomized. When the storage > order was randomized, the serial form was also randomized. But now that > randomization is done during iteration, the serialized forms are fixed. > Hmmm. Not sure what I think about that. Doesn't it mean we're now actually better at randomizing iteration order on a run-to-run basis, whereas if we just picked up and went with a serialized storage we'd retain the iteration order you'd get in the old VM instance? Thanks! /Claes From lance.andersen at oracle.com Tue Jan 8 12:15:26 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 8 Jan 2019 07:15:26 -0500 Subject: [PATCH] for error message not containing file name of jar with bad manifest In-Reply-To: <1546928657.2438.8.camel@paratix.ch> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> Message-ID: <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> Hi Philipp, I created JDK-8216362 and will look to address later today or tomorrow Best Lance > On Jan 8, 2019, at 1:24 AM, Philipp Kunz wrote: > > Hi Lance, > > I also see fit for a new bug. But I cannot create it now because I cannot log in to Jira and don't know how else to create one and I don't have the slightest idea how to get such a privilege. Could you give me a hint how to proceed? > > Philipp > > On Mon, 2019-01-07 at 18:05 -0500, Lance Andersen wrote: >> Hi Philipp, >> >> I would like to suggest a new bug for this so if you can do that I can sponsor the proposed change >> >> Thank you >>> On Jan 7, 2019, at 5:39 PM, Philipp Kunz > wrote: >>> >>> <8205525.patch> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andrew_m_leonard at uk.ibm.com Tue Jan 8 13:27:31 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 8 Jan 2019 13:27:31 +0000 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? In-Reply-To: <25fad9c3-59ee-f5cf-3d80-a63ef4c2a142@oracle.com> References: <25fad9c3-59ee-f5cf-3d80-a63ef4c2a142@oracle.com> Message-ID: Thanks Roger, I hadn't seen those existing bugs, so following that trail I get to: https://bugs.openjdk.java.net/browse/JDK-8189343 JDK-8189343: Change of behavior of java.util.regex.Pattern between JDK 8 and JDK 9 Which was resolved as "Not an issue", as the related fix to 6609854 you refer to changed the behaviour... The basic discussion point which can be found here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html basically points out that the negate operator "^" has the "lowest" precedence of the operations by design/spec, so essentially for example: [^a-b&&b-d] is NOT logically [^a-b]&&[b-d] but is in fact ^[[a-b]&&[b-d]] as ^ takes the least precedence compared to && So the new bug JDK-8211526 is in fact working as now designed. I will update it and close it appropriately. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 07/01/2019 15:33 Subject: Re: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? Sent by: "core-libs-dev" Hi Andrew, Did your investigation lead you to: 6609854: Regex does not match correctly for negative nested character classes That might explain when the behavior changed and perhaps why. $.02, Roger On 01/03/2019 06:20 AM, Andrew Leonard wrote: > Hi, > I'm currently investigating bug JDK-8215626 and have discovered the > problem is in the Pattern interpretation of the [^..&&..] negation when > applied to "intersected" expressions. So I have simplified the bug example > to a more extreme and obvious example: > Input string: "1234 ABCDEFG !$%^& abcdefg" > pattern RegEx: "[^[A-B]&&[^ef]]" > Operation: pattern.matcher(input).replaceAll(""); > > JDK8 output: > 1234 CDEFG !$%^& abcdefg > JDK11 output: > AB > > So from the "spec" : > A character class is a set of characters enclosed within square brackets. > It specifies the characters that will successfully match a single > character from a given input string > Intersection: > To create a single character class matching only the characters common to > all of its nested classes, use &&, as in [0-9&&[345]]. > Negation: > To match all characters except those listed, insert the "^" metacharacter > at the beginning of the character class. > > The way I read the "spec" is the "^" negation negates the whole character > class within the outer square brackets, thus in this example: > "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" > ie.the negation of the intersect of chars A,B and everything other > than e,f > which is thus the negation of A,B > hence the operation above will remove any character in the input > string other than A,B > Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is > applying the ^ negation to just [A-B] and then intersecting it with [^ef], > which to me is the wrong interpretation of the "spec". > > Your thoughts please? > > If JDK11 is correct, and JDK8 wrong, then the next question is do we fix > JDK8? as there's obviously potential "behavioural" impacts to existing > applications....? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Tue Jan 8 14:27:50 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Jan 2019 09:27:50 -0500 Subject: [PATCH] for error message not containing file name of jar with bad manifest In-Reply-To: <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> Message-ID: <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> Hi, Even though this is a bug fix, the security concerns about putting the full pathnames of files in exceptions should be considered.? I would be fine with putting only the filename (no path) in the message. If a typo is in scope:? line 89 "occured" -> "occurred". Thanks, Roger On 01/08/2019 07:15 AM, Lance Andersen wrote: > Hi Philipp, > > I created JDK-8216362 and will look to address later today or tomorrow > > Best > Lance >> On Jan 8, 2019, at 1:24 AM, Philipp Kunz wrote: >> >> Hi Lance, >> >> I also see fit for a new bug. But I cannot create it now because I cannot log in to Jira and don't know how else to create one and I don't have the slightest idea how to get such a privilege. Could you give me a hint how to proceed? >> >> Philipp >> >> On Mon, 2019-01-07 at 18:05 -0500, Lance Andersen wrote: >>> Hi Philipp, >>> >>> I would like to suggest a new bug for this so if you can do that I can sponsor the proposed change >>> >>> Thank you >>>> On Jan 7, 2019, at 5:39 PM, Philipp Kunz > wrote: >>>> >>>> <8205525.patch> >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From some-java-user-99206970363698485155 at vodafonemail.de Tue Jan 8 15:50:09 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Tue, 8 Jan 2019 16:50:09 +0100 (CET) Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map In-Reply-To: <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> References: <828995999.355333.1546644857686@mail.vodafone.de> <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> Message-ID: <179313584.256301.1546962610206@mail.vodafone.de> Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` requested by JDK-6552529 as default methods, however both would have to include that "The default implementation returns the provided key. Overriding implementations may return the actual key used by the map." In this case it is questionable how useful the methods actually are, e.g. Two key objects k1 and k2 with `k1.equals(k2)` Two objects m1 and m2 of different map implementations both containing k1. Then the following is possible: m1.getKey(k2) == k2 // true m2.getKey(k2) == k2 // false > Brian Goetz hat am 7. Januar 2019 um 00:54 geschrieben: > > > FYI, the comment about compatibility was obsoleted by the addition of > default methods in Java 8. From brian.goetz at oracle.com Tue Jan 8 15:57:53 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 8 Jan 2019 10:57:53 -0500 Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map In-Reply-To: <179313584.256301.1546962610206@mail.vodafone.de> References: <828995999.355333.1546644857686@mail.vodafone.de> <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> <179313584.256301.1546962610206@mail.vodafone.de> Message-ID: <88041f41-8d9b-b4b5-c36e-f980f334c725@oracle.com> Here's a default implementation that returns the actual key: ?? default Optional> getEntry(K key) { ?????? for (Map.Entry e : entrySet) { ?????????? if (Objects.equals(key, e.getKey()) ?????????????? return Optional.of(e); ?????? } ?????? return Optional.empty(); ?? } On 1/8/2019 10:50 AM, some-java-user-99206970363698485155 at vodafonemail.de wrote: > Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` > requested by JDK-6552529 as default methods, however both would have to include that > "The default implementation returns the provided key. Overriding implementations may return the > actual key used by the map." > In this case it is questionable how useful the methods actually are, e.g. > Two key objects k1 and k2 with `k1.equals(k2)` > Two objects m1 and m2 of different map implementations both containing k1. > Then the following is possible: > m1.getKey(k2) == k2 // true > m2.getKey(k2) == k2 // false > >> Brian Goetz hat am 7. Januar 2019 um 00:54 geschrieben: >> >> >> FYI, the comment about compatibility was obsoleted by the addition of >> default methods in Java 8. From some-java-user-99206970363698485155 at vodafonemail.de Tue Jan 8 16:16:02 2019 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Tue, 8 Jan 2019 17:16:02 +0100 (CET) Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map In-Reply-To: <88041f41-8d9b-b4b5-c36e-f980f334c725@oracle.com> References: <828995999.355333.1546644857686@mail.vodafone.de> <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> <179313584.256301.1546962610206@mail.vodafone.de> <88041f41-8d9b-b4b5-c36e-f980f334c725@oracle.com> Message-ID: <1885903001.256664.1546964162946@mail.vodafone.de> Would this method then be useful enough if the default implementation is that inefficient (in case you only want to get a nullable value)? > Brian Goetz hat am 8. Januar 2019 um 16:57 geschrieben: > > > Here's a default implementation that returns the actual key: > > ?? default Optional> getEntry(K key) { > ?????? for (Map.Entry e : entrySet) { > ?????????? if (Objects.equals(key, e.getKey()) > ?????????????? return Optional.of(e); > ?????? } > ?????? return Optional.empty(); > ?? } > > On 1/8/2019 10:50 AM, > some-java-user-99206970363698485155 at vodafonemail.de wrote: > > Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` > > requested by JDK-6552529 as default methods, however both would have to include that > > "The default implementation returns the provided key. Overriding implementations may return the > > actual key used by the map." > > In this case it is questionable how useful the methods actually are, e.g. > > Two key objects k1 and k2 with `k1.equals(k2)` > > Two objects m1 and m2 of different map implementations both containing k1. > > Then the following is possible: > > m1.getKey(k2) == k2 // true > > m2.getKey(k2) == k2 // false > > > >> Brian Goetz hat am 7. Januar 2019 um 00:54 geschrieben: > >> > >> > >> FYI, the comment about compatibility was obsoleted by the addition of > >> default methods in Java 8. > From xueming.shen at gmail.com Tue Jan 8 16:49:34 2019 From: xueming.shen at gmail.com (Xueming Shen) Date: Tue, 8 Jan 2019 08:49:34 -0800 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? In-Reply-To: References: Message-ID: <64326404-7984-83d2-60e4-f86c6078d006@gmail.com> Hi Andrew, See [1]/[2] for the background of the fix. I would say jdk11 behavior is correct and expected :-) anyway, it's a? behavior change, so probably will not be easily to go back into jdk8. Regards, Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html [2] http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction On 1/7/19 5:50 AM, Andrew Leonard wrote: > Anyone got any views on which "regex" beheviour is correct JDK8 or JDK11 ? > thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Andrew Leonard/UK/IBM > To: "OpenJDK Core Libs Developers" > Date: 03/01/2019 11:20 > Subject: JDK-8215626 : Correct [^..&&..] intersection negation > behaviour JDK8 vs JDK11 ?? > > > Hi, > I'm currently investigating bug JDK-8215626 and have discovered the > problem is in the Pattern interpretation of the [^..&&..] negation when > applied to "intersected" expressions. So I have simplified the bug example > to a more extreme and obvious example: > Input string: "1234 ABCDEFG !$%^& abcdefg" > pattern RegEx: "[^[A-B]&&[^ef]]" > Operation: pattern.matcher(input).replaceAll(""); > > JDK8 output: > 1234 CDEFG !$%^& abcdefg > JDK11 output: > AB > > So from the "spec" : > A character class is a set of characters enclosed within square brackets. > It specifies the characters that will successfully match a single > character from a given input string > Intersection: > To create a single character class matching only the characters common to > all of its nested classes, use &&, as in [0-9&&[345]]. > Negation: > To match all characters except those listed, insert the "^" metacharacter > at the beginning of the character class. > > The way I read the "spec" is the "^" negation negates the whole character > class within the outer square brackets, thus in this example: > "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" > ie.the negation of the intersect of chars A,B and everything other > than e,f > which is thus the negation of A,B > hence the operation above will remove any character in the input > string other than A,B > Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is > applying the ^ negation to just [A-B] and then intersecting it with [^ef], > which to me is the wrong interpretation of the "spec". > > Your thoughts please? > > If JDK11 is correct, and JDK8 wrong, then the next question is do we fix > JDK8? as there's obviously potential "behavioural" impacts to existing > applications....? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From rob.mckenna at oracle.com Tue Jan 8 17:03:04 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 Jan 2019 17:03:04 +0000 Subject: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" Message-ID: <20190108170304.GC3629@vimes> Hi folks, I'd like to fix this test failure caused by 8160768. The problem is that the LdapDnsProviderResult sets the hostname to the empty String and gets passed to StartTlsResponseImpl.verify. Unfortunately StartTlsResponseImpl.verify only expects null values. Since null and the empty String are functionally equivalent I've added a check to StartTlsResponseImpl.verify to take the empty String into account. http://cr.openjdk.java.net/~robm/8214440/webrev.01/ This was caught by an existing test which I managed to miss in my testing incantation. -Rob From naoto.sato at oracle.com Tue Jan 8 17:46:27 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 8 Jan 2019 09:46:27 -0800 Subject: [12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class Message-ID: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com> Hello, Please review the change for the following issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216176/webrev.00/ This is a simple one line change that is clarifying the era singleton description, which was added with the fix to 8212941. Naoto From Roger.Riggs at oracle.com Tue Jan 8 17:53:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Jan 2019 12:53:57 -0500 Subject: [12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class In-Reply-To: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com> References: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com> Message-ID: <2048cfad-649c-ed54-674a-e6a103e93f49@oracle.com> Hi Naoto, Looks fine. Roger On 01/08/2019 12:46 PM, Naoto Sato wrote: > Hello, > > Please review the change for the following issue: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 > CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8216176/webrev.00/ > > This is a simple one line change that is clarifying the era singleton > description, which was added with the fix to 8212941. > > Naoto From sean.mullan at oracle.com Tue Jan 8 18:07:07 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Jan 2019 13:07:07 -0500 Subject: [PATCH] for error message not containing file name of jar with bad manifest In-Reply-To: <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> Message-ID: <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> In this case, the caller is passing in the filename through the public JarFile API so as long as it is not modified it should be ok. The concerns I raised previously are situations where the caller did not pass in the file or the JDK converts a relative path to an absolute path, which could reveal sensitive details about the filesystem. --Sean On 1/8/19 9:27 AM, Roger Riggs wrote: > Hi, > > Even though this is a bug fix, the security concerns about putting the > full pathnames of files > in exceptions should be considered.? I would be fine with putting only > the filename (no path) in the message. > > If a typo is in scope:? line 89 "occured" -> "occurred". > > Thanks, Roger > > > On 01/08/2019 07:15 AM, Lance Andersen wrote: >> Hi Philipp, >> >> I created JDK-8216362 and will look to address later today or tomorrow >> >> Best >> Lance >>> On Jan 8, 2019, at 1:24 AM, Philipp Kunz >>> wrote: >>> >>> Hi Lance, >>> >>> I also see fit for a new bug. But I cannot create it now because I >>> cannot log in to Jira and don't know how else to create one and I >>> don't have the slightest idea how to get such a privilege. Could you >>> give me a hint how to proceed? >>> >>> Philipp >>> >>> On Mon, 2019-01-07 at 18:05 -0500, Lance Andersen wrote: >>>> Hi Philipp, >>>> >>>> I would like to suggest a new bug for this so if you can do that I >>>> can sponsor the proposed change >>>> >>>> Thank you >>>>> On Jan 7, 2019, at 5:39 PM, Philipp Kunz >>>> > wrote: >>>>> >>>>> <8205525.patch> >>>> >>>> >>>> ? >>>> >>>> ? Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >> ? >> ? >> >> ? Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From ivan.gerasimov at oracle.com Tue Jan 8 18:16:35 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 8 Jan 2019 10:16:35 -0800 Subject: RFR (XS) 8210788 : Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero Message-ID: Hello! It is a minor javadoc editing to cover the case thread.join(0, 0). Currently, the documentation may give a wrong impression that such a call will not block execution of the current thread at all. Would you please help review the fix and CSR? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210788 CSR: https://bugs.openjdk.java.net/browse/JDK-8216379 WEBREV: http://cr.openjdk.java.net/~igerasim/8210788/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From hboehm at google.com Tue Jan 8 18:55:59 2019 From: hboehm at google.com (Hans Boehm) Date: Tue, 8 Jan 2019 10:55:59 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: The IEEE standard does say that for quiet NaNs, the value (or one of them) "should" be preserved by most operations on the quiet NaN. I have not heard of implementations violating this for anything other than the "quiet" bit. Thus I don't immediately see why it would be problematic to encode an explicitly programmer-introduced error cause in the remaining bits (as opposed to relying on hardware-generated patterns). I have not seen non-testing code that does so, but I would be mildly surprised if it doesn't exist somewhere. On Tue, Jan 8, 2019 at 1:16 AM Ulf Adams wrote: > Technically, another option would be to have Java standardize a meaning, > and I take it you're not mentioning that because of the performance > implications? > > On Tue, Jan 8, 2019 at 2:37 AM John Rose wrote: > >> As I think you expect, isSubstitutible(x,y) will mean that x and y are >> equivalent >> for all practical purposes. One hard question is nailing down what are >> "all practical purposes". Certainly it's unfair to flip a coin while >> evaluating >> x and y separately, and claim that a distinct outcome proves a difference. >> What about viewing the bits of x and y using the Unsafe API? That's >> unfair also, since it opens the door to implementation-dependent behavior >> which might detect a difference (an irrelevant difference) between x and >> y. >> >> Now, floatToRawIntBits can detect differences between NaNs which >> have different numeric codes. Are two such NaNs substitutable or not? >> The evidence in favor: >> - They become equivalent when boxed in a Float, and Float claims to >> be an all-purpose box for float values. >> - The extra information produced by floatToRawIntBits is implementation >> specific, and in particular processor dependent. >> - Joe Darcy suggested to me that some processors, like x87, may >> perturb NaN bits (turning off the "signalling" bit, for example), even >> if the float value is simply bound to a parameter. This means that >> the operand to floatToRawIntBits *might*, in compiled code, possibly >> have *some* of its bits perturbed. (Thanks, Joe, for that and similar >> hair-raising stories.) >> - The previous point implies that compiled code and interpreted code >> might, in the same JVM instance, produce different results on the >> same argument. That is quite implementation specific indeed! >> >> The evidence against: >> - The existing standard API point floatToRawIntBits is not going away. >> So the isSubstitutable API point must document that floatToRawIntBits >> has the processor-dependent ability to conjure up different bits for >> x and y. Maybe it should be called isAlmostSubstitutable?? >> >> The right trade-off here, I think, is to align isSubstitutable with >> Float::equals >> and simply increase the warnings on floatToRawIntBits, that this method >> can produce platform-specific results in an unpredictable way, and that >> in particular it can produce distinct answers for otherwise substitutable >> results. >> >> I also suggested to Dr. Deprecator (Stuart Marks) that floatToRawIntBits >> might be a candidate for deprecation; he said it would be a lot of expense >> for relatively little benefit. I think at least the javadoc for >> floatToRawIntBits >> should not speak so confidently, as it does, of "preserving Not-a-Number >> (NaN) values", as if these values were something that had a stable >> semantics, as if they could somehow carry application information. >> >> More background (thanks again to Joe): The NaN bits don't have a standard >> format. Different CPUs can (and often do) disagree on which bits >> mean what, and how standard arithmetic operations consume and produce >> them. There is apparently no agreed standard NaN pattern, although >> Java favors the "all zero" bit pattern as normative. Different CPUs >> may disagree on which bits denote signaling or quiet NaNs, and when >> such bits may be queried or modified. Adding the possible distinct >> treatment of the "same" NaN value in compiled vs. interpreted code >> (as well as strictfp vs. non-strictfp code), and the use of "raw" NaN >> bits seems a very risky proposition, useful only for people writing >> processor-specific code, with great care. >> >> In hindsight, I think it would have been nice to place the "raw bits" >> API points to Unsafe or a separate module. But when those API >> points were designed (1.0), there were no such hiding places. >> And it's probably too costly to fix now. If the sweet spot is to >> acknowledge the wart, but not let it spread, then we design the >> substitutability test based on Float::equals, not floatToRawIntBits. >> >> ? John >> >> On Jan 6, 2019, at 4:36 PM, Hans Boehm wrote: >> > >> > IIUC, isSubstitutible() is not quite what's being proposed here. The >> > proposed definition here uses floatToIntBits(), not floatToRawIntBits(). >> > >> > Hans >> > >> > On Sun, Jan 6, 2019 at 3:59 PM Brian Goetz >> wrote: >> > >> >> Followers of Project Valhalla will see that this issue comes up when >> >> defining equality on value types. The relation you are looking for is >> >> being called "substitutible"; it asks whether there is any way to >> >> distinguish between two values. For primitives other than >> float/double, >> >> this coincides with `==`, and similarly for references. >> >> >> >> An `isSubstitutible()` API point will likely emerge from Valhalla. >> >> From brian.goetz at oracle.com Tue Jan 8 20:32:28 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 8 Jan 2019 15:32:28 -0500 Subject: Feature suggestion: Provide efficient way for nullable value lookup in Map In-Reply-To: <1885903001.256664.1546964162946@mail.vodafone.de> References: <828995999.355333.1546644857686@mail.vodafone.de> <660f0385-4917-0958-30dc-00f7e0150252@oracle.com> <179313584.256301.1546962610206@mail.vodafone.de> <88041f41-8d9b-b4b5-c36e-f980f334c725@oracle.com> <1885903001.256664.1546964162946@mail.vodafone.de> Message-ID: <887dbfbe-ce90-82d3-adbf-3433f0e8642c@oracle.com> Usually when we add defaults to Collection interfaces, we provide efficient implementations for the several dozen primary JDK implementations. On 1/8/2019 11:16 AM, some-java-user-99206970363698485155 at vodafonemail.de wrote: > Would this method then be useful enough if the default implementation is that inefficient (in case > you only want to get a nullable value)? > >> Brian Goetz hat am 8. Januar 2019 um 16:57 geschrieben: >> >> >> Here's a default implementation that returns the actual key: >> >> ?? default Optional> getEntry(K key) { >> ?????? for (Map.Entry e : entrySet) { >> ?????????? if (Objects.equals(key, e.getKey()) >> ?????????????? return Optional.of(e); >> ?????? } >> ?????? return Optional.empty(); >> ?? } >> >> On 1/8/2019 10:50 AM, >> some-java-user-99206970363698485155 at vodafonemail.de wrote: >>> Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` >>> requested by JDK-6552529 as default methods, however both would have to include that >>> "The default implementation returns the provided key. Overriding implementations may return the >>> actual key used by the map." >>> In this case it is questionable how useful the methods actually are, e.g. >>> Two key objects k1 and k2 with `k1.equals(k2)` >>> Two objects m1 and m2 of different map implementations both containing k1. >>> Then the following is possible: >>> m1.getKey(k2) == k2 // true >>> m2.getKey(k2) == k2 // false >>> >>>> Brian Goetz hat am 7. Januar 2019 um 00:54 geschrieben: >>>> >>>> >>>> FYI, the comment about compatibility was obsoleted by the addition of >>>> default methods in Java 8. From openjdk at icemanx.nl Tue Jan 8 21:08:59 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 8 Jan 2019 22:08:59 +0100 Subject: Feature suggestion: Add support to Base64.Encoder and Base64.Decoder to wrap Writer / Reader Message-ID: <592919b8-d11d-371d-7c94-6a7d90613e58@icemanx.nl> Java 8 added Base64 with its nested classes Encoder and Decoder. These both have methods to wrap an OutputStream / InputStream respectively. However, base64 is text; the alphabets exist out of ASCII characters only. This is (somewhat) acknowledged by the presence of the encodeToString(byte[]) and decode(String) methods. Doesn't it then also make sense to add methods to wrap a Writer and Reader respectively? (Perhaps Appendable / Readable is even better to provide more flexibility.) When reading an exception can be thrown if an unsupported character is encountered. I have already written a simple example to wrap a StringBuilder in an OutputStream that I then wrap using Base64.Encoder: https://github.com/robtimus/data-url/blob/master/src/main/java/com/github/robtimus/net/protocol/data/DataURLs.java. This could probably add some validation that characters are limited to the actual alphabet in the convert method, but I was a bit lazy there. If an Appendable is wrapped the flush and close methods should delegate to the wrapped object if that implements Flushable / Closeable respectively. From Roger.Riggs at oracle.com Tue Jan 8 21:34:16 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Jan 2019 16:34:16 -0500 Subject: RFR (XS) 8210788 : Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero In-Reply-To: References: Message-ID: <736f1a60-3a76-a4bd-dab4-dfb70742fe09@oracle.com> Hi Ivan, Both the CSR and the code review look fine. Thanks, Roger On 01/08/2019 01:16 PM, Ivan Gerasimov wrote: > Hello! > > It is a minor javadoc editing to cover the case thread.join(0, 0). > Currently, the documentation may give a wrong impression that such a > call will not block execution of the current thread at all. > > Would you please help review the fix and CSR? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210788 > CSR: https://bugs.openjdk.java.net/browse/JDK-8216379 > WEBREV: http://cr.openjdk.java.net/~igerasim/8210788/00/webrev/ > > Thanks in advance! > From philipp.kunz at paratix.ch Wed Jan 9 00:17:12 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 09 Jan 2019 01:17:12 +0100 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> Message-ID: <1546993032.2438.12.camel@paratix.ch> Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful construction with read and will be used by subsequent calls to read if read is called (again) after the manifest has been constructed. The call to the constructor could be in a different context than the call to read and the jar file name could therefore be exposed in an unexpected context.?After I first thought it was just annoying to get an unrelated jar file name in an exception message I see now a security concern as well. At first glance and in terms of expectable code changes to the questionable constructor of Manifest the above mentioned seems to be overlapping with issue JDK-8216362 but then?JDK-8216362 is about the jar file name missing in an error message when it should be present and not the other way round. Attached is a patch for JDK-8216362 as it is described at the moment. Philipp On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: > In this case, the caller is passing in the filename through the public > JarFile API so as long as it is not modified it should be ok. The > concerns I raised previously are situations where the caller did not > pass in the file or the JDK converts a relative path to an absolute > path, which could reveal sensitive details about the filesystem. > > --Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: 8216362.patch Type: text/x-patch Size: 5380 bytes Desc: not available URL: From lance.andersen at oracle.com Wed Jan 9 00:24:35 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 8 Jan 2019 19:24:35 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <1546993032.2438.12.camel@paratix.ch> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> Message-ID: <96A41ABE-52C1-4AA6-818A-E7C9BAD0FA4F@oracle.com> Thanks Phillipp, I had already updated the test to account for both scenarios. I will push out the webrev tomorrow Best Lance > On Jan 8, 2019, at 7:17 PM, Philipp Kunz wrote: > > Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful construction with read and will be used by subsequent calls to read if read is called (again) after the manifest has been constructed. The call to the constructor could be in a different context than the call to read and the jar file name could therefore be exposed in an unexpected context. After I first thought it was just annoying to get an unrelated jar file name in an exception message I see now a security concern as well. > > At first glance and in terms of expectable code changes to the questionable constructor of Manifest the above mentioned seems to be overlapping with issue JDK-8216362 but then JDK-8216362 is about the jar file name missing in an error message when it should be present and not the other way round. Attached is a patch for JDK-8216362 as it is described at the moment. > > Philipp > > > On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: >> In this case, the caller is passing in the filename through the public >> JarFile API so as long as it is not modified it should be ok. The >> concerns I raised previously are situations where the caller did not >> pass in the file or the JDK converts a relative path to an absolute >> path, which could reveal sensitive details about the filesystem. >> >> --Sean > <8216362.patch> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From rachna.goel at oracle.com Wed Jan 9 06:35:43 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Wed, 9 Jan 2019 12:05:43 +0530 Subject: [12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class In-Reply-To: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com> References: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com> Message-ID: <9cfef47f-19f8-48f8-d2d4-dd06ff89812d@oracle.com> Looks good to me. On 1/8/19 11:16 PM, Naoto Sato wrote: > Hello, > > Please review the change for the following issue: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 > CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8216176/webrev.00/ > > This is a simple one line change that is clarifying the era singleton > description, which was added with the fix to 8212941. > > Naoto -- Thanks, Rachna From vyom.tewari at oracle.com Wed Jan 9 07:03:46 2019 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 9 Jan 2019 12:33:46 +0530 Subject: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" In-Reply-To: <20190108170304.GC3629@vimes> References: <20190108170304.GC3629@vimes> Message-ID: <0a1cd64e-0e76-e97f-a8fc-8199fe495d83@oracle.com> Hi Rob, Thanks for fixing this issue, please use hostname.isEmpty(), instead of "".equal(hostname). I have a question to you, why we are converting null to empty string("") in LdapDnsProvider ?. If you see the java doc it tells that domainname can be null /** ???? * Construct an LdapDnsProviderResult consisting of a resolved domain name ???? * and the ldap server endpoints that serve the domain. ???? * ???? * @param domainName??? the resolved domain name; can be null. My personal suggestion is not to replace null to empty string("") in "LdapDnsProviderResult" either throw some exception or just pass whatever you got in LdapDnsProviderResult constructor. Thanks, Vyom On 08/01/19 10:33 PM, Rob McKenna wrote: > Hi folks, > > I'd like to fix this test failure caused by 8160768. > > The problem is that the LdapDnsProviderResult sets the hostname to the > empty String and gets passed to StartTlsResponseImpl.verify. > Unfortunately StartTlsResponseImpl.verify only expects null values. > Since null and the empty String are functionally equivalent I've added a > check to StartTlsResponseImpl.verify to take the empty String into > account. > > http://cr.openjdk.java.net/~robm/8214440/webrev.01/ > > This was caught by an existing test which I managed to miss in my > testing incantation. > > -Rob > From ivan.gerasimov at oracle.com Wed Jan 9 07:19:17 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 8 Jan 2019 23:19:17 -0800 Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long} Message-ID: <349ea61b-e831-f200-d832-884d5dbc2aba@oracle.com> Hello! The javadoc for Long.parseLong() mistakenly mentions {@code int} while it should have been {@code long}. Would you please help review a trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216413 WEBREV: http://cr.openjdk.java.net/~igerasim/8216413/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From martin.desruisseaux at geomatys.com Wed Jan 9 09:00:36 2019 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Wed, 9 Jan 2019 10:00:36 +0100 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: Le 08/01/2019 ? 19:55, Hans Boehm a ?crit?: > The IEEE standard does say that for quiet NaNs, the value (or one of them) > "should" be preserved by most operations on the quiet NaN. I have not heard > of implementations violating this for anything other than the "quiet" bit. > Thus I don't immediately see why it would be problematic to encode an > explicitly programmer-introduced error cause in the remaining bits (as > opposed to relying on hardware-generated patterns). I have not seen > non-testing code that does so, but I would be mildly surprised if it > doesn't exist somewhere. I confirm that such code exist and are used in production for 15 years at least in the GeoTools and Apache Spatial Information System (SIS) projects. Earth Observation data are often images mixing measurement values with different kind of missing values. So above-cited projects perform computation on float primitive types where, for example: * Real values are Sea Surface Temperatures values in ?C. * One NaN bit pattern stands for values missing because the sea was hidden by a cloud. * Another NaN bit pattern stands for values missing because the pixel is over a land. * Another NaN bit pattern stands for values missing because the remote sensor did not fly over that area. * etc. Actually those data are typically encoded as integers in some file format where each missing value is associated to a different color (clouds in white, lands in brown, etc.). But they are converted to float values for performing calculations (e.g. applying the "gradient magnitude" operator provided by Java Advanced Imaging library), then converted back to integers for displaying purpose with java.awt.image.RenderedImage. It allows the use of mathematical formulas without special checks for missing values, and still preserve the lands, clouds, etc. masks in the resulting image. I have never seen yet a lost of information encoded in quiet NaN values (e.g. I have not seen a "NaN for land" mutated to a "NaN for cloud"), except if an arithmetic operation is applied on two different NaN bit patterns. ??? Martin From mvala at redhat.com Wed Jan 9 10:39:21 2019 From: mvala at redhat.com (Michal Vala) Date: Wed, 9 Jan 2019 11:39:21 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: ping On 1/3/19 9:31 PM, Michal Vala wrote: > Hi Martin, > > can we please finish this review? > > On 12/19/18 6:32 PM, Michal Vala wrote: >> >> >> On 12/19/18 4:15 PM, Martin Buchholz wrote: >>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: >>> >>>> Hi Martin, >>>> >>>> It is also useful and conventional to print the seed of the random >>>> so that if necessary it can be reproduced. >>>> >>> >>> For many years, we've been using ThreadLocalRandom for testing, and that >>> does not allow setting a seed. >>> >>> I remain unconvinced that saving a seed has value in the real world.? When >>> a randomized test fails, running it with sufficient iterations has always >>> worked for me. >>> >> >> What's the reason behind using ThreadLocalRandom? >> >> In my opinion, reproducing the issue is key. One failure of randomized test >> run might be caused by one issue, second run due to another issue. How we >> reproduce then and how we know even how many issues we have? When we're >> running random tests until it pass, it might even hide the issue. >> >> They sure have good value on reveal the issue, but then we have to know how to >> reproduce and what we're searching for. >> >> If this case would not require ThreadLocalRandom and Random is enough, I'd >> like to use that because of benefits I've mentioned. >> > -- Michal Vala OpenJDK QE Red Hat Czech From christoph.langer at sap.com Wed Jan 9 13:47:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 9 Jan 2019 13:47:41 +0000 Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long} In-Reply-To: <349ea61b-e831-f200-d832-884d5dbc2aba@oracle.com> References: <349ea61b-e831-f200-d832-884d5dbc2aba@oracle.com> Message-ID: <5c10b6d7a0624fd48c294ceabf925c3c@sap.com> Hi Ivan, looks good ?? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Ivan Gerasimov > Sent: Mittwoch, 9. Januar 2019 08:19 > To: core-libs-dev at openjdk.java.net > Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless > string contains parsable {@code int}; should be {@code long} > > Hello! > > The javadoc for Long.parseLong() mistakenly mentions {@code int} while > it should have been {@code long}. > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216413 > WEBREV: http://cr.openjdk.java.net/~igerasim/8216413/00/webrev/ > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov From ivan.gerasimov at oracle.com Wed Jan 9 14:20:23 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 9 Jan 2019 06:20:23 -0800 Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long} In-Reply-To: <5c10b6d7a0624fd48c294ceabf925c3c@sap.com> References: <349ea61b-e831-f200-d832-884d5dbc2aba@oracle.com> <5c10b6d7a0624fd48c294ceabf925c3c@sap.com> Message-ID: <7d9392d5-f63e-01cf-cdb4-3ded7382878e@oracle.com> Thank you Christoph! Pushed. On 1/9/19 5:47 AM, Langer, Christoph wrote: > Hi Ivan, > > looks good ?? > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Ivan Gerasimov >> Sent: Mittwoch, 9. Januar 2019 08:19 >> To: core-libs-dev at openjdk.java.net >> Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless >> string contains parsable {@code int}; should be {@code long} >> >> Hello! >> >> The javadoc for Long.parseLong() mistakenly mentions {@code int} while >> it should have been {@code long}. >> >> Would you please help review a trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216413 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8216413/00/webrev/ >> >> Thanks in advance! >> >> -- >> With kind regards, >> Ivan Gerasimov -- With kind regards, Ivan Gerasimov From james.laskey at oracle.com Wed Jan 9 15:26:04 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 9 Jan 2019 11:26:04 -0400 Subject: RFR - JDK-8215489 Remove String::align Message-ID: <75042FF1-EAEB-484B-A81F-94A04CB0FB8A@oracle.com> Please review the removal of String::align from JDK12. Thank you. ? Jim webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 From sundararajan.athijegannathan at oracle.com Wed Jan 9 15:48:55 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 09 Jan 2019 21:18:55 +0530 Subject: RFR - JDK-8215489 Remove String::align In-Reply-To: <75042FF1-EAEB-484B-A81F-94A04CB0FB8A@oracle.com> References: <75042FF1-EAEB-484B-A81F-94A04CB0FB8A@oracle.com> Message-ID: <5C3617E7.7090706@oracle.com> Looks good. -Sundar On 09/01/19, 8:56 PM, Jim Laskey wrote: > Please review the removal of String::align from JDK12. > > Thank you. > > ? Jim > > > webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 > CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 > From andrew_m_leonard at uk.ibm.com Wed Jan 9 15:46:44 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 9 Jan 2019 15:46:44 +0000 Subject: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? In-Reply-To: <64326404-7984-83d2-60e4-f86c6078d006@gmail.com> References: <64326404-7984-83d2-60e4-f86c6078d006@gmail.com> Message-ID: Thanks Sherman, Yes I agree. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Xueming Shen To: core-libs-dev at openjdk.java.net Date: 08/01/2019 16:50 Subject: Re: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ?? Sent by: "core-libs-dev" Hi Andrew, See [1]/[2] for the background of the fix. I would say jdk11 behavior is correct and expected :-) anyway, it's a behavior change, so probably will not be easily to go back into jdk8. Regards, Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html [2] http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction On 1/7/19 5:50 AM, Andrew Leonard wrote: > Anyone got any views on which "regex" beheviour is correct JDK8 or JDK11 ? > thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Andrew Leonard/UK/IBM > To: "OpenJDK Core Libs Developers" > Date: 03/01/2019 11:20 > Subject: JDK-8215626 : Correct [^..&&..] intersection negation > behaviour JDK8 vs JDK11 ?? > > > Hi, > I'm currently investigating bug JDK-8215626 and have discovered the > problem is in the Pattern interpretation of the [^..&&..] negation when > applied to "intersected" expressions. So I have simplified the bug example > to a more extreme and obvious example: > Input string: "1234 ABCDEFG !$%^& abcdefg" > pattern RegEx: "[^[A-B]&&[^ef]]" > Operation: pattern.matcher(input).replaceAll(""); > > JDK8 output: > 1234 CDEFG !$%^& abcdefg > JDK11 output: > AB > > So from the "spec" : > A character class is a set of characters enclosed within square brackets. > It specifies the characters that will successfully match a single > character from a given input string > Intersection: > To create a single character class matching only the characters common to > all of its nested classes, use &&, as in [0-9&&[345]]. > Negation: > To match all characters except those listed, insert the "^" metacharacter > at the beginning of the character class. > > The way I read the "spec" is the "^" negation negates the whole character > class within the outer square brackets, thus in this example: > "[^[A-B]&&[^ef]]" is equivalent to the negation of "[[A-B]&&[^ef]]" > ie.the negation of the intersect of chars A,B and everything other > than e,f > which is thus the negation of A,B > hence the operation above will remove any character in the input > string other than A,B > Hence, JDK11 in my opinion meets the "spec". It looks as though JDK8 is > applying the ^ negation to just [A-B] and then intersecting it with [^ef], > which to me is the wrong interpretation of the "spec". > > Your thoughts please? > > If JDK11 is correct, and JDK8 wrong, then the next question is do we fix > JDK8? as there's obviously potential "behavioural" impacts to existing > applications....? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From rob.mckenna at oracle.com Wed Jan 9 16:09:15 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 9 Jan 2019 16:09:15 +0000 Subject: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" In-Reply-To: <0a1cd64e-0e76-e97f-a8fc-8199fe495d83@oracle.com> References: <20190108170304.GC3629@vimes> <0a1cd64e-0e76-e97f-a8fc-8199fe495d83@oracle.com> Message-ID: <20190109160915.GA4104@vimes> The parameter can be null, but if you look at the spec for getDomainName it details the behaviour when the result is created with a null value. I would rather avoid changing the spec at this point so I plan to stick with this approach. (I'll switch the "".equals for isEmpty - thanks for that) -Rob On 09/01/19 12:33, vyom tewari wrote: > Hi Rob, > > Thanks for fixing this issue, please use hostname.isEmpty(), instead of > "".equal(hostname). I have a question to you, why we are converting null to > empty string("") in LdapDnsProvider ?. > > If you see the java doc it tells that domainname can be null > > /** > ???? * Construct an LdapDnsProviderResult consisting of a resolved domain > name > ???? * and the ldap server endpoints that serve the domain. > ???? * > ???? * @param domainName??? the resolved domain name; can be null. > > My personal suggestion is not to replace null to empty string("") in > "LdapDnsProviderResult" either throw some exception or just pass whatever > you got in LdapDnsProviderResult constructor. > > Thanks, > > Vyom > > On 08/01/19 10:33 PM, Rob McKenna wrote: > > Hi folks, > > > > I'd like to fix this test failure caused by 8160768. > > > > The problem is that the LdapDnsProviderResult sets the hostname to the > > empty String and gets passed to StartTlsResponseImpl.verify. > > Unfortunately StartTlsResponseImpl.verify only expects null values. > > Since null and the empty String are functionally equivalent I've added a > > check to StartTlsResponseImpl.verify to take the empty String into > > account. > > > > http://cr.openjdk.java.net/~robm/8214440/webrev.01/ > > > > This was caught by an existing test which I managed to miss in my > > testing incantation. > > > > -Rob > > From xuelei.fan at oracle.com Wed Jan 9 16:52:41 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 9 Jan 2019 08:52:41 -0800 Subject: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" In-Reply-To: <20190108170304.GC3629@vimes> References: <20190108170304.GC3629@vimes> Message-ID: <5eac7819-28b6-2d89-9df2-1fb5061b4c1b@oracle.com> The behavior looks similar to the underlying TLS implementation. Looks good to me. Thanks, Xuelei On 1/8/2019 9:03 AM, Rob McKenna wrote: > Hi folks, > > I'd like to fix this test failure caused by 8160768. > > The problem is that the LdapDnsProviderResult sets the hostname to the > empty String and gets passed to StartTlsResponseImpl.verify. > Unfortunately StartTlsResponseImpl.verify only expects null values. > Since null and the empty String are functionally equivalent I've added a > check to StartTlsResponseImpl.verify to take the empty String into > account. > > http://cr.openjdk.java.net/~robm/8214440/webrev.01/ > > This was caught by an existing test which I managed to miss in my > testing incantation. > > -Rob > From sean.mullan at oracle.com Wed Jan 9 17:13:28 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Jan 2019 12:13:28 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <1546993032.2438.12.camel@paratix.ch> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> Message-ID: <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> On 1/8/19 7:17 PM, Philipp Kunz wrote: > Manifest.read throws an exception with the jar file name passed to the > constructor the manifest was constructed with and not passed to the call > to the read that throws the exception because the jarFilename variable > is not reset after successful construction with read and will be used by > subsequent calls to read if read is called (again) after the manifest > has been constructed. The call to the constructor could be in a > different context than the call to read and the jar file name could > therefore be exposed in an unexpected context.?After I first thought it > was just annoying to get an unrelated jar file name in an exception > message I see now a security concern as well. That's a good point (and good catch!). I think we need to adjust the code so that if read is called and it throws an Exception it only contains the jar file name if called by the constructors in which the jar file name is passed as a parameter. Perhaps break up the read method into a private and public one with the private one containing an additional boolean parameter that is set to true if called by the constructor, otherwise it is false. If the boolean parameter is true, the jar file name is put in the exception, otherwise it is not. I also think we should fix this in 12, so I raised the priority to 3. --Sean > > At first glance and in terms of expectable code changes to the > questionable constructor of Manifest the above mentioned seems to be > overlapping with issue JDK-8216362 but then?JDK-8216362 is about the jar > file name missing in an error message when it should be present and not > the other way round. Attached is a patch for JDK-8216362 as it is > described at the moment. > > Philipp > > > On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: >> In this case, the caller is passing in the filename through the public >> JarFile API so as long as it is not modified it should be ok. The >> concerns I raised previously are situations where the caller did not >> pass in the file or the JDK converts a relative path to an absolute >> path, which could reveal sensitive details about the filesystem. >> >> --Sean From giovanni.gatti.pinheiro at gmail.com Wed Jan 9 14:45:08 2019 From: giovanni.gatti.pinheiro at gmail.com (Giovanni Gatti Pinheiro) Date: Wed, 9 Jan 2019 15:45:08 +0100 Subject: [PATCH] JDK-8216140: Correct UnicodeDecoder U+FFFE handling Message-ID: Hello, I?ve crossed this bug on the past and I would like to fix it. You will find the patch with the fix attached to this message. I have few questions around this subject. 1. Where should the test be placed? It is not clear to me which is the standard approach. I?ve spent about 1h searching in the code base where it should be placed without success. Then I?ve tried to ? fix ? the code and to run nio tests expecting to break something (however no test failed). The closest I?ve got from a reasonable place is TestUTF_16 class. In this class, there is a test for ? Reversed BOM in middle of stream Negative test. ? `that is commented out, which is the opposite to what I?m tried to do. 2. What to do with UTF-8/UTF-32? I?ve tested UTF-8/UTF-32 to see how these two implementations handle U+FFFE in the middle of a byte stream. They are both compliant with Unicode specification and it looks like that this bug applies only to UTF-16?s implementation. It?s awkward that these three encodings do not behave the same way, so I would like to confirm with you that I don?t have to do anything special about it. 3. What exactly should I test? Technically I should?ve tested that all Unicode non-characters are not reported as malformed input. Do I have to go that far or just testing U+FFFE is enough? 4. Do I have to sign OCA document to this contribution? It?s really a small fix and I don?t really care about any credit. But still, if I must, just let me know and I will do it ASAP. So, let me know what to do exactly and I will do take care about it. Thank you in advance. Best regards, Giovanni GATTI PINHEIRO -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8216140.patch Type: text/x-patch Size: 2189 bytes Desc: not available URL: From brian.goetz at oracle.com Wed Jan 9 17:46:21 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 9 Jan 2019 12:46:21 -0500 Subject: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec In-Reply-To: References: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> Message-ID: <2bd93497-ec67-8cdb-f0c3-789a67b16247@oracle.com> +1 from me. On 1/7/2019 1:17 PM, Vicente Romero wrote: > I have updated the webrev after additional feedback from the TCK > tester please check last version at [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8215510/webrev.01 > > > On 1/3/19 12:21 PM, Vicente Romero wrote: >> Please review the fix for bug [1] at [2]. Basically the constants API >> introduced as part of JEP-334 [3] were accepting descriptors and >> class names not allowed by the spec. This implementation fixes >> several issues found by TCK tests on JEP-334, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8215510 >> [2] http://cr.openjdk.java.net/~vromero/8215510/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8203252 > From lance.andersen at oracle.com Wed Jan 9 20:42:39 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 9 Jan 2019 15:42:39 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> Message-ID: <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> Here is the webrev for the changes: http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html Best Lance > On Jan 9, 2019, at 12:13 PM, Sean Mullan wrote: > > On 1/8/19 7:17 PM, Philipp Kunz wrote: >> Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful construction with read and will be used by subsequent calls to read if read is called (again) after the manifest has been constructed. The call to the constructor could be in a different context than the call to read and the jar file name could therefore be exposed in an unexpected context. After I first thought it was just annoying to get an unrelated jar file name in an exception message I see now a security concern as well. > > That's a good point (and good catch!). I think we need to adjust the code so that if read is called and it throws an Exception it only contains the jar file name if called by the constructors in which the jar file name is passed as a parameter. Perhaps break up the read method into a private and public one with the private one containing an additional boolean parameter that is set to true if called by the constructor, otherwise it is false. If the boolean parameter is true, the jar file name is put in the exception, otherwise it is not. > > I also think we should fix this in 12, so I raised the priority to 3. > > --Sean >> At first glance and in terms of expectable code changes to the questionable constructor of Manifest the above mentioned seems to be overlapping with issue JDK-8216362 but then JDK-8216362 is about the jar file name missing in an error message when it should be present and not the other way round. Attached is a patch for JDK-8216362 as it is described at the moment. >> Philipp >> On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: >>> In this case, the caller is passing in the filename through the public >>> JarFile API so as long as it is not modified it should be ok. The >>> concerns I raised previously are situations where the caller did not >>> pass in the file or the JDK converts a relative path to an absolute >>> path, which could reveal sensitive details about the filesystem. >>> >>> --Sean Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From sean.mullan at oracle.com Wed Jan 9 20:46:31 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Jan 2019 15:46:31 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> Message-ID: <3e18d2a6-3db5-e6ed-9317-7b089017ab59@oracle.com> Looks good. --Sean On 1/9/19 3:42 PM, Lance Andersen wrote: > Here is the webrev for the changes: > > http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html > > Best > Lance >> On Jan 9, 2019, at 12:13 PM, Sean Mullan > > wrote: >> >> On 1/8/19 7:17 PM, Philipp Kunz wrote: >>> Manifest.read throws an exception with the jar file name passed to >>> the constructor the manifest was constructed with and not passed to >>> the call to the read that throws the exception because the >>> jarFilename variable is not reset after successful construction with >>> read and will be used by subsequent calls to read if read is called >>> (again) after the manifest has been constructed. The call to the >>> constructor could be in a different context than the call to read and >>> the jar file name could therefore be exposed in an unexpected >>> context.?After I first thought it was just annoying to get an >>> unrelated jar file name in an exception message I see now a security >>> concern as well. >> >> That's a good point (and good catch!). I think we need to adjust the >> code so that if read is called and it throws an Exception it only >> contains the jar file name if called by the constructors in which the >> jar file name is passed as a parameter. Perhaps break up the read >> method into a private and public one with the private one containing >> an additional boolean parameter that is set to true if called by the >> constructor, otherwise it is false. If the boolean parameter is true, >> the jar file name is put in the exception, otherwise it is not. >> >> I also think we should fix this in 12, so I raised the priority to 3. >> >> --Sean >>> At first glance and in terms of expectable code changes to the >>> questionable constructor of Manifest the above mentioned seems to be >>> overlapping with issue JDK-8216362 but then?JDK-8216362 is about the >>> jar file name missing in an error message when it should be present >>> and not the other way round. Attached is a patch for JDK-8216362 as >>> it is described at the moment. >>> Philipp >>> On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: >>>> In this case, the caller is passing in the filename through the public >>>> JarFile API so as long as it is not modified it should be ok. The >>>> concerns I raised previously are situations where the caller did not >>>> pass in the file or the JDK converts a relative path to an absolute >>>> path, which could reveal sensitive details about the filesystem. >>>> >>>> --Sean > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Roger.Riggs at oracle.com Wed Jan 9 21:12:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 9 Jan 2019 16:12:21 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <3e18d2a6-3db5-e6ed-9317-7b089017ab59@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> <3e18d2a6-3db5-e6ed-9317-7b089017ab59@oracle.com> Message-ID: +1 On 01/09/2019 03:46 PM, Sean Mullan wrote: > Looks good. > > --Sean > > On 1/9/19 3:42 PM, Lance Andersen wrote: >> Here is the webrev for the changes: >> >> http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html >> >> Best >> Lance >>> On Jan 9, 2019, at 12:13 PM, Sean Mullan >> > wrote: >>> >>> On 1/8/19 7:17 PM, Philipp Kunz wrote: >>>> Manifest.read throws an exception with the jar file name passed to >>>> the constructor the manifest was constructed with and not passed to >>>> the call to the read that throws the exception because the >>>> jarFilename variable is not reset after successful construction >>>> with read and will be used by subsequent calls to read if read is >>>> called (again) after the manifest has been constructed. The call to >>>> the constructor could be in a different context than the call to >>>> read and the jar file name could therefore be exposed in an >>>> unexpected context.?After I first thought it was just annoying to >>>> get an unrelated jar file name in an exception message I see now a >>>> security concern as well. >>> >>> That's a good point (and good catch!). I think we need to adjust the >>> code so that if read is called and it throws an Exception it only >>> contains the jar file name if called by the constructors in which >>> the jar file name is passed as a parameter. Perhaps break up the >>> read method into a private and public one with the private one >>> containing an additional boolean parameter that is set to true if >>> called by the constructor, otherwise it is false. If the boolean >>> parameter is true, the jar file name is put in the exception, >>> otherwise it is not. >>> >>> I also think we should fix this in 12, so I raised the priority to 3. >>> >>> --Sean >>>> At first glance and in terms of expectable code changes to the >>>> questionable constructor of Manifest the above mentioned seems to >>>> be overlapping with issue JDK-8216362 but then?JDK-8216362 is about >>>> the jar file name missing in an error message when it should be >>>> present and not the other way round. Attached is a patch for >>>> JDK-8216362 as it is described at the moment. >>>> Philipp >>>> On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote: >>>>> In this case, the caller is passing in the filename through the >>>>> public >>>>> JarFile API so as long as it is not modified it should be ok. The >>>>> concerns I raised previously are situations where the caller did not >>>>> pass in the file or the JDK converts a relative path to an absolute >>>>> path, which could reveal sensitive details about the filesystem. >>>>> >>>>> --Sean >> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle?Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From john.r.rose at oracle.com Wed Jan 9 22:04:49 2019 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jan 2019 14:04:49 -0800 Subject: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec In-Reply-To: References: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> Message-ID: Nice work. A couple of small points: A qualified class name is one that has a package prefix. So it is surprising that verifyUnqualifiedClassName allows a package prefix. Maybe it needs a different name. The testing looks adequate, but you might consider using a little combinatorial code to generate bad and good class names. Such code could be shared between the unit tests that test x.y names and Lx/y; names. Something like: char goodsep = '.' or '/'; ArrayList badnames, goodnames; ? goodnames.addAll(goodunqnames); badnames.addAll(badunqnames); for (int i = 0; i < 2; i++) { for (String pkg : badpkgnames) { ?prepend pkg+goodsep to each badnames and goodnames and add to badnames... } for (char sep : "./;[".toCharArray()) { for (String pkg : goodpkgnames) { if (sep == goodsep) ?prepend pkg+sep to each goodnames and add to goodnames? else ?prepend pkg+sep to each goodnames and add to badnames? } ?prepend sep to each goodnames and add to badnames? ?appendpend sep to each goodnames and add to badnames? } return List.of(badnames, goodnames); // return for use in unit test > On Jan 7, 2019, at 10:17 AM, Vicente Romero wrote: > > I have updated the webrev after additional feedback from the TCK tester please check last version at [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8215510/webrev.01 > > > On 1/3/19 12:21 PM, Vicente Romero wrote: >> Please review the fix for bug [1] at [2]. Basically the constants API introduced as part of JEP-334 [3] were accepting descriptors and class names not allowed by the spec. This implementation fixes several issues found by TCK tests on JEP-334, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8215510 >> [2] http://cr.openjdk.java.net/~vromero/8215510/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8203252 > From john.r.rose at oracle.com Wed Jan 9 22:36:51 2019 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jan 2019 14:36:51 -0800 Subject: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec In-Reply-To: References: <2af70d93-f3cb-2d7f-ad8f-4a1d73b0856b@oracle.com> Message-ID: On Jan 9, 2019, at 2:04 PM, John Rose wrote: > > you might consider using > a little combinatorial code to generate bad and good class > names P.S. To motivate this suggestion a bit more: I found no problem with your manually-written test vectors of bad and good names, but I also found it difficult to be confident that they covered the ground adequately. Combinatorial logic for generating test vectors is often overkill, but it is easier to be confident about. That in turn makes us more confident that the actual code itself is free of bugs. Also, when I use such tactics in my own test development, I often find more bugs in my code, than with my first cut tests, which are small ad hoc test vectors. I won't promise the same for you, but it's a possibility. From ivan.gerasimov at oracle.com Wed Jan 9 23:23:48 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 9 Jan 2019 15:23:48 -0800 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format Message-ID: Hello! String representation of UUID should conform to RFC4122 , i.e. each its part has to be of the fixed size. Unfortunately, the UUID.fromString() method does not keep up to this requirement: - First, it permits the leading zeroes of any part to be omitted; - Second, it permits some of the UUID parts to be larger then allowed. In such a case, the value is effectively clipped with & 0x..FFFF. While some existing application may depend on the former case -- i.e. be able to parse UUID with stripped leading zeroes, the later case is likely to be an error. In the past, the check on the input has already been strengthened with JDK-8006627 . I propose we go further and make UUID.fromString() to reject such string representations that contain too large individual parts. If people agree on the proposal, I'll file CSR to fix the change of behavior. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From philipp.kunz at paratix.ch Wed Jan 9 23:34:39 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 10 Jan 2019 00:34:39 +0100 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> Message-ID: <1547076879.2438.16.camel@paratix.ch> Better late than too late: Would it be an option to catch the exception in JarFile.getManifestFromReference and throw another one with the name and the caught exception as a cause? Because this is the only code that calls that particular constructor that I know of. JarVerifier could be a candidate or SignatureFileVerifier. And JarSigner but JarSigner could not invoke it like it is now because not visible. I'm not aware of future plans but if JarFile.getManifestFromReference is the only code using jar file names in exception messages, we might as well leave Manifest alone. Most minor, where is throw new IOException("invalid manifest format(" i guess there should be a space before the opening bracket at the end of the string on line?321 to be consistent with the other messages. On Wed, 2019-01-09 at 15:42 -0500, Lance Andersen wrote: > Here is the webrev for the changes: > ?http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html > From lance.andersen at oracle.com Wed Jan 9 23:53:47 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 9 Jan 2019 18:53:47 -0500 Subject: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest In-Reply-To: <1547076879.2438.16.camel@paratix.ch> References: <1546900778.2438.5.camel@paratix.ch> <483DCF44-9164-4152-AFFF-CE421B367214@oracle.com> <1546928657.2438.8.camel@paratix.ch> <12BF3CDB-8007-4643-84AF-96ACA34E7592@oracle.com> <5cf79fc7-a151-7d0d-c3db-d6f76a271388@oracle.com> <1e05a898-6d42-0e7e-c216-338f45be21fb@oracle.com> <1546993032.2438.12.camel@paratix.ch> <54dd33d7-5925-82a6-01ae-1f98982aafc9@oracle.com> <06CB698C-06CE-48B6-B52B-B14493E308AE@oracle.com> <1547076879.2438.16.camel@paratix.ch> Message-ID: > On Jan 9, 2019, at 6:34 PM, Philipp Kunz wrote: > > > Better late than too late: Would it be an option to catch the exception in JarFile.getManifestFromReference and throw another one with the name and the caught exception as a cause? Because this is the only code that calls that particular constructor that I know of. JarVerifier could be a candidate or SignatureFileVerifier. And JarSigner but JarSigner could not invoke it like it is now because not visible. I'm not aware of future plans but if JarFile.getManifestFromReference is the only code using jar file names in exception messages, we might as well leave Manifest alone. I would prefer to leave it as it is for now. > > Most minor, where is throw new IOException("invalid manifest format(" i guess there should be a space before the opening bracket at the end of the string on line 321 to be consistent with the other messages. I will fix before I push > > > On Wed, 2019-01-09 at 15:42 -0500, Lance Andersen wrote: >> Here is the webrev for the changes: >> >> http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Thu Jan 10 07:08:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 9 Jan 2019 23:08:38 -0800 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: References: Message-ID: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> Hi Ivan, How does this bug relate to the recent discussion of "JDK-8165199: UUID.fromString(str) compliance checking?": http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html Cheers, -Joe On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: > Hello! > > String representation of UUID should conform to RFC4122 > , i.e. each its part has to be of > the fixed size. > > Unfortunately, the UUID.fromString() method does not keep up to this > requirement: > - First, it permits the leading zeroes of any part to be omitted; > - Second, it permits some of the UUID parts to be larger then > allowed.? In such a case, the value is effectively clipped with & > 0x..FFFF. > While some existing application may depend on the former case -- i.e. > be able to parse UUID with stripped leading zeroes, the later case is > likely to be an error. > > In the past, the check on the input has already been strengthened with > JDK-8006627 . > > I propose we go further and make UUID.fromString() to reject such > string representations that contain too large individual parts. > > If people agree on the proposal, I'll file CSR to fix the change of > behavior. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 > WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ > > Thanks in advance! > From ivan.gerasimov at oracle.com Thu Jan 10 07:27:03 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 9 Jan 2019 23:27:03 -0800 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> References: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> Message-ID: <9824a63d-dfd0-cb89-b67c-190df8c047ff@oracle.com> Hi Joe! From what I see, the discussion was about possibility to only accept input strings with precisely sized parts, i.e. that matches "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{12}". And I'm proposing to only reject input with too large individual parts, i.e. accept any input that matches " \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,12}". Currently, if one part is too large, we already "clip" it, using only lower bits, so behavior looks buggy. Instead, it seems better to report the issue throwing an exception. With kind regards, Ivan On 1/9/19 11:08 PM, Joe Darcy wrote: > Hi Ivan, > > How does this bug relate to the recent discussion of "JDK-8165199: > UUID.fromString(str) compliance checking?": > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html > > > Cheers, > > -Joe > > On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: >> Hello! >> >> String representation of UUID should conform to RFC4122 >> , i.e. each its part has to be >> of the fixed size. >> >> Unfortunately, the UUID.fromString() method does not keep up to this >> requirement: >> - First, it permits the leading zeroes of any part to be omitted; >> - Second, it permits some of the UUID parts to be larger then >> allowed. In such a case, the value is effectively clipped with & >> 0x..FFFF. >> While some existing application may depend on the former case -- i.e. >> be able to parse UUID with stripped leading zeroes, the later case is >> likely to be an error. >> >> In the past, the check on the input has already been strengthened >> with JDK-8006627 . >> >> I propose we go further and make UUID.fromString() to reject such >> string representations that contain too large individual parts. >> >> If people agree on the proposal, I'll file CSR to fix the change of >> behavior. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ >> >> Thanks in advance! >> > -- With kind regards, Ivan Gerasimov From takiguc at linux.vnet.ibm.com Thu Jan 10 07:47:43 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 10 Jan 2019 16:47:43 +0900 Subject: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) Message-ID: Hello. Could you review the fix ? And please push this to jdk12 if possible. Bug: https://bugs.openjdk.java.net/browse/JDK-8211841 Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From Alan.Bateman at oracle.com Thu Jan 10 08:00:11 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jan 2019 08:00:11 +0000 Subject: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) In-Reply-To: References: Message-ID: <720e6f1c-7a70-e85a-20fb-6b5acb6f251e@oracle.com> On 10/01/2019 07:47, Ichiroh Takiguchi wrote: > Hello. > Could you review the fix ? > And please push this to jdk12 if possible. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 > Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ If I read this correctly then the wildcard import is to import the IBM* charsets without enumerating them as that would not compile on other platforms. Looks okay and the import of sun.nio.cs.HistoricallyNamedCharset can be removed - I can do that when sponsoring it, if you are okay that change. -Alan From takiguc at linux.vnet.ibm.com Thu Jan 10 12:05:49 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 10 Jan 2019 21:05:49 +0900 Subject: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) In-Reply-To: <720e6f1c-7a70-e85a-20fb-6b5acb6f251e@oracle.com> References: <720e6f1c-7a70-e85a-20fb-6b5acb6f251e@oracle.com> Message-ID: Hello Alan. I appreciate your suggestion. Could you review the fix again ? (Additionally, I removed sun.nio.cs.Surrogate import from IBM970_OLD.java) Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.01/ I tested new fix on AIX and Linux amd64 platform. It worked fine on both platform. Thanks, Ichiroh Takiguchi On 2019-01-10 17:00, Alan Bateman wrote: > On 10/01/2019 07:47, Ichiroh Takiguchi wrote: >> Hello. >> Could you review the fix ? >> And please push this to jdk12 if possible. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 >> Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ > If I read this correctly then the wildcard import is to import the > IBM* charsets without enumerating them as that would not compile on > other platforms. Looks okay and the import of > sun.nio.cs.HistoricallyNamedCharset can be removed - I can do that > when sponsoring it, if you are okay that change. > > -Alan From fujie at loongson.cn Thu Jan 10 14:44:06 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 10 Jan 2019 22:44:06 +0800 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code Message-ID: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> Hi all, My name is Jie Fu, a JVM developer at Loongson working on the MIPS port of OpenJDK. I hope this is the right place to discuss the issue. test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed with "java -Xcomp RuntimeThreadInheritanceLeak". The failure was caused by the lost of an OopMap item for "loaderRef" which was optimized out by the JIT with the liveness analysis optimization. For more details, see [1]. It seems that RuntimeThreadInheritanceLeak.java is only suitable for testing interpreters which is not adapted to JITs at all. Different behaviors performed by the interpreter and JITs with the same test case really confused us a lot. And I think it's worth making the test also suitable for JITs. A tiny change can fix this issue --------------------------------- diff -r 02e648ae46c3 test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java --- a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Wed Jan 09 01:06:19 2019 +0100 +++ b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Thu Jan 10 20:49:22 2019 +0800 @@ -106,7 +106,10 @@ * context class loader-- by giving it a chance to pass away. */ Thread.sleep(2000); - System.gc(); + while (loaderRef.get() != null) { + System.gc(); + Thread.sleep(100); + } System.err.println( "waiting to be notified of loader being weakly reachable..."); --------------------------------- Could you please review it and tell me if it's OK to file a bug on JBS. Thanks. [1] https://github.com/DamonFool/MyBlog/blob/master/JVM/RuntimeThreadInheritanceLeak.md Best Regards, Jie From Roger.Riggs at oracle.com Thu Jan 10 16:04:45 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 10 Jan 2019 11:04:45 -0500 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <9824a63d-dfd0-cb89-b67c-190df8c047ff@oracle.com> References: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> <9824a63d-dfd0-cb89-b67c-190df8c047ff@oracle.com> Message-ID: <06dd30e3-be81-d097-2c6e-6c28aacc0431@oracle.com> Hi, If we're going to break some apps that use non-conforming strings, perhaps we should go fully strict and make sure they are all fixed at the same time. (Unless we have some stats on the distribution of non-conforming apps that mitigates that). Roger On 01/10/2019 02:27 AM, Ivan Gerasimov wrote: > Hi Joe! > > From what I see, the discussion was about possibility to only accept > input strings with precisely sized parts, i.e. that matches > "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- > \p{XDigit}{12}". > > And I'm proposing to only reject input with too large individual > parts, i.e. accept any input that matches > " \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- > \p{XDigit}{1,12}". > > Currently, if one part is too large, we already "clip" it, using only > lower bits, so behavior looks buggy. > > Instead, it seems better to report the issue throwing an exception. > > With kind regards, > Ivan > > On 1/9/19 11:08 PM, Joe Darcy wrote: >> Hi Ivan, >> >> How does this bug relate to the recent discussion of "JDK-8165199: >> UUID.fromString(str) compliance checking?": >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html >> >> >> Cheers, >> >> -Joe >> >> On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> String representation of UUID should conform to RFC4122 >>> , i.e. each its part has to be >>> of the fixed size. >>> >>> Unfortunately, the UUID.fromString() method does not keep up to this >>> requirement: >>> - First, it permits the leading zeroes of any part to be omitted; >>> - Second, it permits some of the UUID parts to be larger then >>> allowed.? In such a case, the value is effectively clipped with & >>> 0x..FFFF. >>> While some existing application may depend on the former case -- >>> i.e. be able to parse UUID with stripped leading zeroes, the later >>> case is likely to be an error. >>> >>> In the past, the check on the input has already been strengthened >>> with JDK-8006627 . >>> >>> I propose we go further and make UUID.fromString() to reject such >>> string representations that contain too large individual parts. >>> >>> If people agree on the proposal, I'll file CSR to fix the change of >>> behavior. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ >>> >>> Thanks in advance! >>> >> > From ivan.gerasimov at oracle.com Thu Jan 10 16:50:52 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 10 Jan 2019 08:50:52 -0800 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <06dd30e3-be81-d097-2c6e-6c28aacc0431@oracle.com> References: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> <9824a63d-dfd0-cb89-b67c-190df8c047ff@oracle.com> <06dd30e3-be81-d097-2c6e-6c28aacc0431@oracle.com> Message-ID: Hi Roger! On 1/10/19 8:04 AM, Roger Riggs wrote: > Hi, > > If we're going to break some apps that use non-conforming strings, > perhaps we should go fully strict and make sure they are all fixed at > the same time. > (Unless we have some stats on the distribution of non-conforming apps > that mitigates that). > That's my point: While going fully strict may break some applications out there, rejecting only obviously incorrect input will likely affect only those applications with a bug. It can be thought as a first step toward full conformance to the RFC. For now, reject only the most incorrect inputs, and leave the final step, if desired, to JDK-8165199 . With kind regards, Ivan > Roger > > > On 01/10/2019 02:27 AM, Ivan Gerasimov wrote: >> Hi Joe! >> >> From what I see, the discussion was about possibility to only accept >> input strings with precisely sized parts, i.e. that matches >> "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- >> \p{XDigit}{12}". >> >> And I'm proposing to only reject input with too large individual >> parts, i.e. accept any input that matches >> " \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- >> \p{XDigit}{1,12}". >> >> Currently, if one part is too large, we already "clip" it, using only >> lower bits, so behavior looks buggy. >> >> Instead, it seems better to report the issue throwing an exception. >> >> With kind regards, >> Ivan >> >> On 1/9/19 11:08 PM, Joe Darcy wrote: >>> Hi Ivan, >>> >>> How does this bug relate to the recent discussion of "JDK-8165199: >>> UUID.fromString(str) compliance checking?": >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html >>> >>> >>> Cheers, >>> >>> -Joe >>> >>> On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> String representation of UUID should conform to RFC4122 >>>> , i.e. each its part has to be >>>> of the fixed size. >>>> >>>> Unfortunately, the UUID.fromString() method does not keep up to >>>> this requirement: >>>> - First, it permits the leading zeroes of any part to be omitted; >>>> - Second, it permits some of the UUID parts to be larger then >>>> allowed. In such a case, the value is effectively clipped with & >>>> 0x..FFFF. >>>> While some existing application may depend on the former case -- >>>> i.e. be able to parse UUID with stripped leading zeroes, the later >>>> case is likely to be an error. >>>> >>>> In the past, the check on the input has already been strengthened >>>> with JDK-8006627 . >>>> >>>> I propose we go further and make UUID.fromString() to reject such >>>> string representations that contain too large individual parts. >>>> >>>> If people agree on the proposal, I'll file CSR to fix the change of >>>> behavior. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ >>>> >>>> Thanks in advance! >>>> >>> >> > > -- With kind regards, Ivan Gerasimov From sergei.tsypanov at yandex.ru Thu Jan 10 19:05:03 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 10 Jan 2019 21:05:03 +0200 Subject: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int) Message-ID: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> Hi, while investigating an issue I've found out that performance of expression (1) can be significantly improved by turning it into (2) ---------------------------------------------------------------------------------------------------- //str is an instance of java.lang.String (1) return new StringBuilder().append(str, beginIndex, endIndex).toString(); ----> (2) String substring = str.substring(beginIndex, endIndex); return new StringBuilder().append(substring).toString(); ---------------------------------------------------------------------------------------------------- Using benchmark [1] I've got the following results: Benchmark (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds 10 avgt 20 21,161 ? 0,545 ns/op StringBuilderAppendBenchmark.appendBounds 100 avgt 20 72,230 ? 3,452 ns/op StringBuilderAppendBenchmark.appendBounds 1000 avgt 20 476,256 ? 12,044 ns/op StringBuilderAppendBenchmark.appendSubString 10 avgt 20 26,023 ? 0,871 ns/op StringBuilderAppendBenchmark.appendSubString 100 avgt 20 38,824 ? 1,185 ns/op StringBuilderAppendBenchmark.appendSubString 1000 avgt 20 214,072 ? 3,372 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 10 avgt 20 80,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 100 avgt 20 320,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 1000 avgt 20 2120,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm 10 avgt 20 96,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm 100 avgt 20 192,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm 1000 avgt 20 1088,000 ? 0,001 B/op The reason for such a difference seems to be @HotSpotIntrinsicCandidate over StringBuilder.append(String), while StringBuilder.append(CharSerquence, int, int) copies chars/bytes one by one. I've prepared a patch [2] and applied it to fresh sources of JDK 11. After rebuild the same benchmark demonstrated severe performance degradation: - before patch Benchmark (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds 10 avgt 20 21,592 ? 0,763 ns/op StringBuilderAppendBenchmark.appendBounds 100 avgt 20 72,241 ? 2,799 ns/op StringBuilderAppendBenchmark.appendBounds 1000 avgt 20 488,106 ? 43,042 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 10 avgt 20 80,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 100 avgt 20 320,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 1000 avgt 20 2132,001 ? 10,691 B/op - after patch Benchmark (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds 10 avgt 20 40,186 ? 1,828 ns/op StringBuilderAppendBenchmark.appendBounds 100 avgt 20 89,031 ? 6,664 ns/op StringBuilderAppendBenchmark.appendBounds 1000 avgt 20 669,934 ? 76,888 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 10 avgt 20 152,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 100 avgt 20 440,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm 1000 avgt 20 2688,001 ? 0,002 B/op As I see the reason of degradation is that patched code now dodges intrinsified StringBuilder.append(String) and calls directly AbstractStringBuilder.append(String) which in spite of utilizing System::arraycopy performes worse than intrinsic. So my question is should I rework the patch somehow to make it perform better or I need to apply the transformation mentioned above ad hoc? Appendix: 1) benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringBuilderAppendBenchmark { @Benchmark @SuppressWarnings("StringBufferReplaceableByString") public String appendSubString(Data data) { String str = data.str; int beginIndex = data.beginIndex; int endIndex = data.endIndex; String substring = str.substring(beginIndex, endIndex); return new StringBuilder().append('L').append(substring).append(';').toString(); } @Benchmark public String appendBounds(Data data) { String str = data.str; int beginIndex = data.beginIndex; int endIndex = data.endIndex; return new StringBuilder().append('L').append(str, beginIndex, endIndex).append(';').toString(); } @State(Scope.Thread) public static class Data { String str; @Param({"10", "100", "1000"}) private int length; private int beginIndex; private int endIndex; @Setup public void setup() { str = randomString(); beginIndex = length / 4; endIndex = length / 4* 3; } private String randomString() { ThreadLocalRandom random = ThreadLocalRandom.current(); char[] chars = "abcdefghijklmnopqrstuvwxyz".toCharArray(); StringBuilder sb = new StringBuilder(length); for (int i = 0; i < length; i++) { char c = chars[random.nextInt(chars.length)]; sb.append(c); } return sb.toString(); } } } 2) patch diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java @@ -626,10 +626,7 @@ s = "null"; } checkRange(start, end, s.length()); - int len = end - start; - ensureCapacityInternal(count + len); - appendChars(s, start, end); - return this; + return append(s.subSequence(start, end).toString()); } /** @@ -1686,27 +1683,6 @@ this.count = count + end - off; } - private final void appendChars(CharSequence s, int off, int end) { - if (isLatin1()) { - byte[] val = this.value; - for (int i = off, j = count; i < end; i++) { - char c = s.charAt(i); - if (StringLatin1.canEncode(c)) { - val[j++] = (byte)c; - } else { - count = j; - inflate(); - StringUTF16.putCharsSB(this.value, j, s, i, end); - count += end - i; - return; - } - } - } else { - StringUTF16.putCharsSB(this.value, count, s, off, end); - } - count += end - off; - } - /* IndexOutOfBoundsException, if out of bounds */ private static void checkRange(int start, int end, int len) { if (start < 0 || start > end || end > len) { From openjdk at icemanx.nl Thu Jan 10 19:30:03 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Thu, 10 Jan 2019 20:30:03 +0100 Subject: 8212620: Provide a mechansim to allow a class/method to request filtering from the stack trace Message-ID: I had an idea that can possibly help solve three issues: * 8212620 Provide a mechansim to allow a class/method to request filtering from the stack trace * 8211152 Improve unclear and incomplete Exception stack trace * 6507809 "Caused by" notation for stack traces unnecessarily hard to read The issue described in all three is that the way stack traces are printed is different from what people want. One solution could be to pull the formatting logic away from Throwable. This can be done by introducing an interface similar to Thread.UncaughtExceptionHandler. For instance: public interface StackTracePrinter { void printStackTrace(Throwable t, PrintStream out); void printStackTrace(Throwable t, PrintWriter out); } Throwable could get a static defaultStackTracePrinter field like Thread.defaultUncaughtExceptionHandler, and Throwable's printStackTrace methods would delegate to this default. There can then be implementation DefaultStackTracePrinter that uses the current format, and different implementations for the three issues. (Small implementation improvement: instead of using PrintStreamOrWriter, WrappedPrintStream and WrappedPrintWriter, the private printStackTrace method could take a lock and a Consumer as arguments. This would then be called as "printStackTrace(s, s::println)".) Unfortunately, getOurStackTrace() will not be available to all implementations, so to prevent having to call getStackTrace() Throwable should get another method List getStackTraceList() that returns List.of(getOurStackTrace()) (possibly cached), or otherwise Collections.unmodifiableList(Arrays.asList(getOurStackTrace())). There is one thing that I haven't been able to figure out though, and that's specifying different StackTracePrinters for different applications in application containers etc. Maybe someone can think of a good mechanism to support this. From goetz.lindenmaier at sap.com Thu Jan 10 21:29:19 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Jan 2019 21:29:19 +0000 Subject: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) In-Reply-To: References: <720e6f1c-7a70-e85a-20fb-6b5acb6f251e@oracle.com> Message-ID: Hi, The change looks good for me, too. I ran the original change through our nightly testing, it's all green. I could sponsor this as well ... Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Ichiroh Takiguchi > Sent: Thursday, January 10, 2019 1:06 PM > To: Alan Bateman > Cc: core-libs-dev > Subject: Re: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java > does not compile (aix) > > Hello Alan. > I appreciate your suggestion. > > Could you review the fix again ? > (Additionally, I removed sun.nio.cs.Surrogate import from > IBM970_OLD.java) > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 > Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.01/ > > I tested new fix on AIX and Linux amd64 platform. > It worked fine on both platform. > > Thanks, > Ichiroh Takiguchi > > On 2019-01-10 17:00, Alan Bateman wrote: > > On 10/01/2019 07:47, Ichiroh Takiguchi wrote: > >> Hello. > >> Could you review the fix ? > >> And please push this to jdk12 if possible. > >> > >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 > >> Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ > > If I read this correctly then the wildcard import is to import the > > IBM* charsets without enumerating them as that would not compile on > > other platforms. Looks okay and the import of > > sun.nio.cs.HistoricallyNamedCharset can be removed - I can do that > > when sponsoring it, if you are okay that change. > > > > -Alan From mandy.chung at oracle.com Thu Jan 10 21:59:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Jan 2019 13:59:42 -0800 Subject: 8212620: Provide a mechansim to allow a class/method to request filtering from the stack trace In-Reply-To: References: Message-ID: <5b1005ff-b3d2-0879-47c4-4080869982a6@oracle.com> On 1/10/19 11:30 AM, Rob Spoor wrote: > I had an idea that can possibly help solve three issues: > * 8212620 > Provide a mechansim to allow a class/method to request filtering from > the stack trace This RFE is not just about stack trace format and a generic stack trace printer has no knowledge if a stack frame is implementation-specific. A library developer may want certain classes or methods to hide from the user (eliminating the implementation details) and remove noise from the stack trace. One idea is some kind of annotation that a library developer can tag the methods to be hidden from stack trace by default. So this proposal does not address the use case of 8212620. > * 8211152 > Improve unclear and incomplete Exception stack trace > * 6507809 > "Caused by" notation for stack traces unnecessarily hard to read > > I didn't spend time on this.? The only thing I would say about these 2 RFEs is that they both propose to change the current stack trace format that will likely break tools parsing the output.?? Keeping the default format unmodified and allowing to plugin a custom formatter is one option to consider. Mandy > The issue described in all three is that the way stack traces are > printed is different from what people want. One solution could be to > pull the formatting logic away from Throwable. This can be done by > introducing an interface similar to Thread.UncaughtExceptionHandler. > For instance: > > ??? public interface StackTracePrinter { > ??????? void printStackTrace(Throwable t, PrintStream out); > ??????? void printStackTrace(Throwable t, PrintWriter out); > ??? } > > Throwable could get a static defaultStackTracePrinter field like > Thread.defaultUncaughtExceptionHandler, and Throwable's > printStackTrace methods would delegate to this default. > > There can then be implementation DefaultStackTracePrinter that uses > the current format, and different implementations for the three > issues. (Small implementation improvement: instead of using > PrintStreamOrWriter, WrappedPrintStream and WrappedPrintWriter, the > private printStackTrace method could take a lock and a > Consumer as arguments. This would then be called as > "printStackTrace(s, s::println)".) > > > Unfortunately, getOurStackTrace() will not be available to all > implementations, so to prevent having to call getStackTrace() > Throwable should get another method List > getStackTraceList() that returns List.of(getOurStackTrace()) (possibly > cached), or otherwise > Collections.unmodifiableList(Arrays.asList(getOurStackTrace())). > > > There is one thing that I haven't been able to figure out though, and > that's specifying different StackTracePrinters for different > applications in application containers etc. Maybe someone can think of > a good mechanism to support this. > From brian.burkhalter at oracle.com Thu Jan 10 22:16:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Jan 2019 14:16:33 -0800 Subject: [13] 8216172: File.renameTo(File dest) should check for NPE at the very beginning Message-ID: https://bugs.openjdk.java.net/browse/JDK-8216172 Proposed simple change included below as diff. All pertinent java/io regression tests pass. Thanks, Brian --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -29,11 +29,11 @@ import java.net.URL; import java.net.MalformedURLException; import java.net.URISyntaxException; +import java.nio.file.FileSystems; +import java.nio.file.Path; +import java.security.SecureRandom; +import java.util.ArrayList; import java.util.List; -import java.util.ArrayList; -import java.security.SecureRandom; -import java.nio.file.Path; -import java.nio.file.FileSystems; import sun.security.action.GetPropertyAction; /** @@ -1395,14 +1395,14 @@ * If parameter dest is null */ public boolean renameTo(File dest) { + if (dest == null) { + throw new NullPointerException(); + } SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkWrite(path); security.checkWrite(dest.path); } - if (dest == null) { - throw new NullPointerException(); - } if (this.isInvalid() || dest.isInvalid()) { return false; } From brian.burkhalter at oracle.com Thu Jan 10 22:21:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Jan 2019 14:21:36 -0800 Subject: [13] 8216172: File.renameTo(File dest) should check for NPE at the very beginning In-Reply-To: References: Message-ID: <9CFCD381-3E1C-42DE-89D9-6C8B7BE9DFC1@oracle.com> Hi Lance, I was originally going to do that but there are other null checks in the same class and I did not know it would be worthwhile. I would think do none or do all. Thanks, Brian > On Jan 10, 2019, at 2:20 PM, Lance Andersen wrote: > > Looks fine Brian. > > One question would it be worth using Objects.requireNonNull(dest)? I have no strong preference, just wondering your thoughts. > > > >> On Jan 10, 2019, at 5:16 PM, Brian Burkhalter > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8216172 > >> >> Proposed simple change included below as diff. All pertinent java/io regression tests pass. >> >> Thanks, >> >> Brian >> >> --- a/src/java.base/share/classes/java/io/File.java >> +++ b/src/java.base/share/classes/java/io/File.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -29,11 +29,11 @@ >> import java.net.URL; >> import java.net.MalformedURLException; >> import java.net.URISyntaxException; >> +import java.nio.file.FileSystems; >> +import java.nio.file.Path; >> +import java.security.SecureRandom; >> +import java.util.ArrayList; >> import java.util.List; >> -import java.util.ArrayList; >> -import java.security.SecureRandom; >> -import java.nio.file.Path; >> -import java.nio.file.FileSystems; >> import sun.security.action.GetPropertyAction; >> >> /** >> @@ -1395,14 +1395,14 @@ >> * If parameter dest is null >> */ >> public boolean renameTo(File dest) { >> + if (dest == null) { >> + throw new NullPointerException(); >> + } >> SecurityManager security = System.getSecurityManager(); >> if (security != null) { >> security.checkWrite(path); >> security.checkWrite(dest.path); >> } >> - if (dest == null) { >> - throw new NullPointerException(); >> - } >> if (this.isInvalid() || dest.isInvalid()) { >> return false; >> } >> > > From lance.andersen at oracle.com Thu Jan 10 22:20:31 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 10 Jan 2019 17:20:31 -0500 Subject: [13] 8216172: File.renameTo(File dest) should check for NPE at the very beginning In-Reply-To: References: Message-ID: Looks fine Brian. One question would it be worth using Objects.requireNonNull(dest)? I have no strong preference, just wondering your thoughts. > On Jan 10, 2019, at 5:16 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8216172 > > Proposed simple change included below as diff. All pertinent java/io regression tests pass. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/io/File.java > +++ b/src/java.base/share/classes/java/io/File.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,11 +29,11 @@ > import java.net.URL; > import java.net.MalformedURLException; > import java.net.URISyntaxException; > +import java.nio.file.FileSystems; > +import java.nio.file.Path; > +import java.security.SecureRandom; > +import java.util.ArrayList; > import java.util.List; > -import java.util.ArrayList; > -import java.security.SecureRandom; > -import java.nio.file.Path; > -import java.nio.file.FileSystems; > import sun.security.action.GetPropertyAction; > > /** > @@ -1395,14 +1395,14 @@ > * If parameter dest is null > */ > public boolean renameTo(File dest) { > + if (dest == null) { > + throw new NullPointerException(); > + } > SecurityManager security = System.getSecurityManager(); > if (security != null) { > security.checkWrite(path); > security.checkWrite(dest.path); > } > - if (dest == null) { > - throw new NullPointerException(); > - } > if (this.isInvalid() || dest.isInvalid()) { > return false; > } > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu Jan 10 22:35:21 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 10 Jan 2019 17:35:21 -0500 Subject: [13] 8216172: File.renameTo(File dest) should check for NPE at the very beginning In-Reply-To: <9CFCD381-3E1C-42DE-89D9-6C8B7BE9DFC1@oracle.com> References: <9CFCD381-3E1C-42DE-89D9-6C8B7BE9DFC1@oracle.com> Message-ID: Hi Brian, Totally understand and agree. All good from my POV :-) Have a good evening Best Lance > On Jan 10, 2019, at 5:21 PM, Brian Burkhalter wrote: > > Hi Lance, > > I was originally going to do that but there are other null checks in the same class and I did not know it would be worthwhile. I would think do none or do all. > > Thanks, > > Brian > >> On Jan 10, 2019, at 2:20 PM, Lance Andersen > wrote: >> >> Looks fine Brian. >> >> One question would it be worth using Objects.requireNonNull(dest)? I have no strong preference, just wondering your thoughts. >> >> >> >>> On Jan 10, 2019, at 5:16 PM, Brian Burkhalter > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8216172 > >>> >>> Proposed simple change included below as diff. All pertinent java/io regression tests pass. >>> >>> Thanks, >>> >>> Brian >>> >>> --- a/src/java.base/share/classes/java/io/File.java >>> +++ b/src/java.base/share/classes/java/io/File.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -29,11 +29,11 @@ >>> import java.net.URL; >>> import java.net.MalformedURLException; >>> import java.net.URISyntaxException; >>> +import java.nio.file.FileSystems; >>> +import java.nio.file.Path; >>> +import java.security.SecureRandom; >>> +import java.util.ArrayList; >>> import java.util.List; >>> -import java.util.ArrayList; >>> -import java.security.SecureRandom; >>> -import java.nio.file.Path; >>> -import java.nio.file.FileSystems; >>> import sun.security.action.GetPropertyAction; >>> >>> /** >>> @@ -1395,14 +1395,14 @@ >>> * If parameter dest is null >>> */ >>> public boolean renameTo(File dest) { >>> + if (dest == null) { >>> + throw new NullPointerException(); >>> + } >>> SecurityManager security = System.getSecurityManager(); >>> if (security != null) { >>> security.checkWrite(path); >>> security.checkWrite(dest.path); >>> } >>> - if (dest == null) { >>> - throw new NullPointerException(); >>> - } >>> if (this.isInvalid() || dest.isInvalid()) { >>> return false; >>> } >>> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Thu Jan 10 23:07:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 09:07:13 +1000 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> Message-ID: <95131763-b234-51ca-fe21-81b208497abc@oracle.com> Hi Jie, On 11/01/2019 12:44 am, Jie Fu wrote: > Hi all, > > My name is Jie Fu, a JVM developer at Loongson working on the MIPS port > of OpenJDK. > I hope this is the right place to discuss the issue. > > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > failed with "java -Xcomp RuntimeThreadInheritanceLeak". > > The failure was caused by the lost of an OopMap item for "loaderRef" > which was optimized out by the JIT with the liveness analysis optimization. > For more details, see [1]. > > It seems that RuntimeThreadInheritanceLeak.java is only suitable for > testing interpreters which is not adapted to JITs at all. > Different behaviors performed by the interpreter and JITs with the same > test case really confused us a lot. > And I think it's worth making the test also suitable for JITs. > > A tiny change can fix this issue > --------------------------------- > diff -r 02e648ae46c3 > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > > --- > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Wed Jan 09 01:06:19 2019 +0100 > +++ > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Thu Jan 10 20:49:22 2019 +0800 > @@ -106,7 +106,10 @@ > ????????????? * context class loader-- by giving it a chance to pass away. > ????????????? */ > ???????????? Thread.sleep(2000); > -??????????? System.gc(); > +??????????? while (loaderRef.get() != null) { > +??????????????? System.gc(); > +??????????????? Thread.sleep(100); > +??????????? } > > ???????????? System.err.println( > ???????????????? "waiting to be notified of loader being weakly > reachable..."); > --------------------------------- > > Could you please review it and tell me if it's OK to file a bug on JBS. > Thanks. For hotspot testing we have certain sets of tests that are run under -Xcomp, but this is obviously not one of them. Did you discover this by chance or because you are attempting to do broad -Xcomp testing? Not every test will work with Xcomp (for various reasons) and we aren't actively trying to make every test pass with Xcomp. But by all means file a bug and fix it. Cheers, David > [1] > https://github.com/DamonFool/MyBlog/blob/master/JVM/RuntimeThreadInheritanceLeak.md > > > > Best Regards, > Jie > > From fujie at loongson.cn Fri Jan 11 01:58:53 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 09:58:53 +0800 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: <95131763-b234-51ca-fe21-81b208497abc@oracle.com> References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> Message-ID: Hi David, Thanks and apologies. This issue was discovered by a broad -Xcomp testing with jtreg on Loongson CPUs (MIPS compatible processors). It was intended to test our MIPS port of OpenJDK. We've found and fixed quite a lot of JIT bugs for our MIPS implementation by this approach. I'll ask Ao Qi to file a bug on JBS and post a webrev soon. Thanks again. Best regards, Jie > For hotspot testing we have certain sets of tests that are run under > -Xcomp, but this is obviously not one of them. Did you discover this > by chance or because you are attempting to do broad -Xcomp testing? > Not every test will work with Xcomp (for various reasons) and we > aren't actively trying to make every test pass with Xcomp. > > But by all means file a bug and fix it. > > Cheers, > David From david.holmes at oracle.com Fri Jan 11 02:13:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 12:13:39 +1000 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> Message-ID: <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> Hi Jie, On 11/01/2019 11:58 am, Jie Fu wrote: > Hi David, > > Thanks and apologies. No apology needed :) > This issue was discovered by a broad -Xcomp testing with jtreg on > Loongson CPUs (MIPS compatible processors). > It was intended to test our MIPS port of OpenJDK. > We've found and fixed quite a lot of JIT bugs for our MIPS > implementation by this approach. Okay, you may well be testing more tests under Xcomp than what we regularly do, so that may well expose a number of tests that may not work at all, or which fail intermittently. I'm trying to find out if there is a relatively easy way to enumerate the tests we do run under -Xcomp. Cheers, David > I'll ask Ao Qi to file a bug on JBS and post a webrev soon. > Thanks again. > > Best regards, > Jie > > >> For hotspot testing we have certain sets of tests that are run under >> -Xcomp, but this is obviously not one of them. Did you discover this >> by chance or because you are attempting to do broad -Xcomp testing? >> Not every test will work with Xcomp (for various reasons) and we >> aren't actively trying to make every test pass with Xcomp. >> >> But by all means file a bug and fix it. >> >> Cheers, >> David > From fujie at loongson.cn Fri Jan 11 02:22:52 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 10:22:52 +0800 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> Message-ID: <8d344a69-d64d-9059-61f0-82e1516841b0@loongson.cn> Thanks David. Hope more cases are suitable for both interpreter and JIT tests. On 2019/1/11 ??10:13, David Holmes wrote: > Hi Jie, > > On 11/01/2019 11:58 am, Jie Fu wrote: >> Hi David, >> >> Thanks and apologies. > > No apology needed :) > >> This issue was discovered by a broad -Xcomp testing with jtreg on >> Loongson CPUs (MIPS compatible processors). >> It was intended to test our MIPS port of OpenJDK. >> We've found and fixed quite a lot of JIT bugs for our MIPS >> implementation by this approach. > > Okay, you may well be testing more tests under Xcomp than what we > regularly do, so that may well expose a number of tests that may not > work at all, or which fail intermittently. I'm trying to find out if > there is a relatively easy way to enumerate the tests we do run under > -Xcomp. > > Cheers, > David > >> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. >> Thanks again. >> >> Best regards, >> Jie >> >> >>> For hotspot testing we have certain sets of tests that are run under >>> -Xcomp, but this is obviously not one of them. Did you discover this >>> by chance or because you are attempting to do broad -Xcomp testing? >>> Not every test will work with Xcomp (for various reasons) and we >>> aren't actively trying to make every test pass with Xcomp. >>> >>> But by all means file a bug and fix it. >>> >>> Cheers, >>> David >> From joe.darcy at oracle.com Fri Jan 11 02:31:06 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 10 Jan 2019 18:31:06 -0800 Subject: latest changes in java.lang.Class In-Reply-To: <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> References: <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> Message-ID: <5C37FFEA.10502@oracle.com> Hello, That does seem to be a bug in the changes I made for JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods The logic in methodToString is used to build messages for exceptions and the omission of the argument information is a likely cause for JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException I'll verify and send out a review for a corrected methodToString if that is the case. Thanks, -Joe On 12/29/2018 11:23 PM, ?????? ??????? wrote: > Hi, > > looking into Class::methodToString I've found some changes done into it recently in JDK 11 repository. > > Currently the method looks like this: > > private String methodToString(String name, Class[] argTypes) { > StringBuilder sb = new StringBuilder(); > sb.append(getName() + "." + name + "("); > if (argTypes != null) { > Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). > collect(Collectors.joining(",")); > } > sb.append(")"); > return sb.toString(); > } > > Here result of Stream.collect() is ignored, i. e. even when condition argTypes != null is true nothing is appended to sb. > It seems in this case we either don?t need this `if` branch or need to append to sb. > > Am I missing something? > > Kind regards, > Sergey Tsypanov From fujie at loongson.cn Fri Jan 11 03:16:22 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 11:16:22 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> <8d344a69-d64d-9059-61f0-82e1516841b0@loongson.cn> Message-ID: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> Hi, Please review this patch for JDK-8216528: --------------------------------- diff -r 02e648ae46c3 test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java --- a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Wed Jan 09 01:06:19 2019 +0100 +++ b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Thu Jan 10 20:49:22 2019 +0800 @@ -106,7 +106,10 @@ ????????????? * context class loader-- by giving it a chance to pass away. ????????????? */ ???????????? Thread.sleep(2000); -??????????? System.gc(); +??????????? while (loaderRef.get() != null) { +??????????????? System.gc(); +??????????????? Thread.sleep(100); +??????????? } ???????????? System.err.println( ???????????????? "waiting to be notified of loader being weakly reachable..."); --------------------------------- The failure was caused by the lost of an OopMap item for "loaderRef" which was optimized out by the JIT with the liveness analysis optimization. Key idea for this patch: 1) "loaderRef" is referenced after "System.gc()" to keep it alive, which prevents its corresponding OopMap being optimized out by JITs. 2) The "System.gc()"+sleep+test pattern is used, which seems more reliable to trigger a GC. Could you please review it and give me some advice? Thanks. Best regards, Jie On 2019/1/11 ??10:40, Ao Qi wrote: > Hi Fu Jie: > > I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528 > > Cheers, > Ao Qi > > On Fri, Jan 11, 2019 at 10:22 AM Jie Fu wrote: >> Thanks David. >> Hope more cases are suitable for both interpreter and JIT tests. >> >> >> On 2019/1/11 ??10:13, David Holmes wrote: >>> Hi Jie, >>> >>> On 11/01/2019 11:58 am, Jie Fu wrote: >>>> Hi David, >>>> >>>> Thanks and apologies. >>> No apology needed :) >>> >>>> This issue was discovered by a broad -Xcomp testing with jtreg on >>>> Loongson CPUs (MIPS compatible processors). >>>> It was intended to test our MIPS port of OpenJDK. >>>> We've found and fixed quite a lot of JIT bugs for our MIPS >>>> implementation by this approach. >>> Okay, you may well be testing more tests under Xcomp than what we >>> regularly do, so that may well expose a number of tests that may not >>> work at all, or which fail intermittently. I'm trying to find out if >>> there is a relatively easy way to enumerate the tests we do run under >>> -Xcomp. >>> >>> Cheers, >>> David >>> >>>> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. >>>> Thanks again. >>>> >>>> Best regards, >>>> Jie >>>> >>>> >>>>> For hotspot testing we have certain sets of tests that are run under >>>>> -Xcomp, but this is obviously not one of them. Did you discover this >>>>> by chance or because you are attempting to do broad -Xcomp testing? >>>>> Not every test will work with Xcomp (for various reasons) and we >>>>> aren't actively trying to make every test pass with Xcomp. >>>>> >>>>> But by all means file a bug and fix it. >>>>> >>>>> Cheers, >>>>> David From fujie at loongson.cn Fri Jan 11 03:24:32 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 11:24:32 +0800 Subject: Fwd: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> Message-ID: <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> I'm sorry to miss the JBS link. JBS:? https://bugs.openjdk.java.net/browse/JDK-8216528 Could you please review it and give me some advice? Thanks. -------- Forwarded Message -------- Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp Date: Fri, 11 Jan 2019 11:16:22 +0800 From: Jie Fu To: David Holmes , core-libs-dev at openjdk.java.net Hi, Please review this patch for JDK-8216528: --------------------------------- diff -r 02e648ae46c3 test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java --- a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Wed Jan 09 01:06:19 2019 +0100 +++ b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Thu Jan 10 20:49:22 2019 +0800 @@ -106,7 +106,10 @@ ????????????? * context class loader-- by giving it a chance to pass away. ????????????? */ ????????????Thread.sleep(2000); -??????????? System.gc(); +??????????? while(loaderRef.get() != null) { +??????????????? System.gc(); +??????????????? Thread.sleep(100); +??????????? } ????????????System.err.println( ???????????????? "waiting to be notified of loader being weakly reachable..."); --------------------------------- The failure was caused by the lost of an OopMap item for "loaderRef" which was optimized out by the JIT with the liveness analysis optimization. Key idea for this patch: 1) "loaderRef" is referenced after "System.gc()" to keep it alive, which prevents its corresponding OopMap being optimized out by JITs. 2) The "System.gc()"+sleep+test pattern is used, which seems more reliable to trigger a GC. Could you please review it and give me some advice? Thanks. Best regards, Jie On 2019/1/11 ??10:40, Ao Qi wrote: > Hi Fu Jie: > > I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528 > > Cheers, > Ao Qi > > On Fri, Jan 11, 2019 at 10:22 AM Jie Fu wrote: >> Thanks David. >> Hope more cases are suitable for both interpreter and JIT tests. >> >> >> On 2019/1/11 ??10:13, David Holmes wrote: >>> Hi Jie, >>> >>> On 11/01/2019 11:58 am, Jie Fu wrote: >>>> Hi David, >>>> >>>> Thanks and apologies. >>> No apology needed :) >>> >>>> This issue was discovered by a broad -Xcomp testing with jtreg on >>>> Loongson CPUs (MIPS compatible processors). >>>> It was intended to test our MIPS port of OpenJDK. >>>> We've found and fixed quite a lot of JIT bugs for our MIPS >>>> implementation by this approach. >>> Okay, you may well be testing more tests under Xcomp than what we >>> regularly do, so that may well expose a number of tests that may not >>> work at all, or which fail intermittently. I'm trying to find out if >>> there is a relatively easy way to enumerate the tests we do run under >>> -Xcomp. >>> >>> Cheers, >>> David >>> >>>> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. >>>> Thanks again. >>>> >>>> Best regards, >>>> Jie >>>> >>>> >>>>> For hotspot testing we have certain sets of tests that are run under >>>>> -Xcomp, but this is obviously not one of them. Did you discover this >>>>> by chance or because you are attempting to do broad -Xcomp testing? >>>>> Not every test will work with Xcomp (for various reasons) and we >>>>> aren't actively trying to make every test pass with Xcomp. >>>>> >>>>> But by all means file a bug and fix it. >>>>> >>>>> Cheers, >>>>> David From david.holmes at oracle.com Fri Jan 11 03:50:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 13:50:55 +1000 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> Message-ID: On 11/01/2019 12:13 pm, David Holmes wrote: > Hi Jie, > > On 11/01/2019 11:58 am, Jie Fu wrote: >> Hi David, >> >> Thanks and apologies. > > No apology needed :) > >> This issue was discovered by a broad -Xcomp testing with jtreg on >> Loongson CPUs (MIPS compatible processors). >> It was intended to test our MIPS port of OpenJDK. >> We've found and fixed quite a lot of JIT bugs for our MIPS >> implementation by this approach. > > Okay, you may well be testing more tests under Xcomp than what we > regularly do, so that may well expose a number of tests that may not > work at all, or which fail intermittently. I'm trying to find out if > there is a relatively easy way to enumerate the tests we do run under > -Xcomp. No easy way but I can tell you we only run a subset of tests in java/lang, java/math and java/util under -Xcomp. David > > Cheers, > David > >> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. >> Thanks again. >> >> Best regards, >> Jie >> >> >>> For hotspot testing we have certain sets of tests that are run under >>> -Xcomp, but this is obviously not one of them. Did you discover this >>> by chance or because you are attempting to do broad -Xcomp testing? >>> Not every test will work with Xcomp (for various reasons) and we >>> aren't actively trying to make every test pass with Xcomp. >>> >>> But by all means file a bug and fix it. >>> >>> Cheers, >>> David >> From fujie at loongson.cn Fri Jan 11 03:56:03 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 11:56:03 +0800 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> Message-ID: Okay, I got it. Thanks David. >> >> Okay, you may well be testing more tests under Xcomp than what we >> regularly do, so that may well expose a number of tests that may not >> work at all, or which fail intermittently. I'm trying to find out if >> there is a relatively easy way to enumerate the tests we do run under >> -Xcomp. > > No easy way but I can tell you we only run a subset of tests in > java/lang, java/math and java/util under -Xcomp. > > David From david.holmes at oracle.com Fri Jan 11 04:16:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 14:16:48 +1000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> Message-ID: <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> Hi Jie, On 11/01/2019 1:24 pm, Jie Fu wrote: > I'm sorry to miss the JBS link. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8216528 > > Could you please review it and give me some advice? > Thanks. I see three choices for you here :) 1. Don't try to run all tests under Xcomp but just stick to the "core" sets of tests already tested by others. 2. Fix the given test as outlined. (I tested it on linux-x64 and it fixed the problem.) 3. Exclude the given test from Xcomp by adding: @requires vm.compMode != "Xcomp" If you chose options 2 or 3 please update the @bug line with 8216528. The core-libs folk may have more to say here and they will need to provide a sponsor for the commit. Thanks, David ----- > > > -------- Forwarded Message -------- > Subject: RFR: JDK-8216528: > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > failing with Xcomp > Date: Fri, 11 Jan 2019 11:16:22 +0800 > From: Jie Fu > To: David Holmes , core-libs-dev at openjdk.java.net > > > > Hi, > > Please review this patch for JDK-8216528: > --------------------------------- > diff -r 02e648ae46c3 > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > --- > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Wed Jan 09 01:06:19 2019 +0100 > +++ > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Thu Jan 10 20:49:22 2019 +0800 > @@ -106,7 +106,10 @@ > ????????????? * context class loader-- by giving it a chance to pass away. > ????????????? */ > ????????????Thread.sleep(2000); > -??????????? System.gc(); > +??????????? while(loaderRef.get() != null) { > +??????????????? System.gc(); > +??????????????? Thread.sleep(100); > +??????????? } > > ????????????System.err.println( > ???????????????? "waiting to be notified of loader being weakly > reachable..."); > --------------------------------- > > The failure was caused by the lost of an OopMap item for "loaderRef" > which was optimized out by the JIT with the liveness analysis optimization. > > Key idea for this patch: > 1) "loaderRef" is referenced after "System.gc()" to keep it alive, which > prevents its corresponding OopMap being optimized out by JITs. > 2) The "System.gc()"+sleep+test pattern is used, which seems more > reliable to trigger a GC. > > Could you please review it and give me some advice? > Thanks. > > Best regards, > Jie > > > On 2019/1/11 ??10:40, Ao Qi wrote: >> Hi Fu Jie: >> >> I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528 >> >> Cheers, >> Ao Qi >> >> On Fri, Jan 11, 2019 at 10:22 AM Jie Fu wrote: >>> Thanks David. >>> Hope more cases are suitable for both interpreter and JIT tests. >>> >>> >>> On 2019/1/11 ??10:13, David Holmes wrote: >>>> Hi Jie, >>>> >>>> On 11/01/2019 11:58 am, Jie Fu wrote: >>>>> Hi David, >>>>> >>>>> Thanks and apologies. >>>> No apology needed :) >>>> >>>>> This issue was discovered by a broad -Xcomp testing with jtreg on >>>>> Loongson CPUs (MIPS compatible processors). >>>>> It was intended to test our MIPS port of OpenJDK. >>>>> We've found and fixed quite a lot of JIT bugs for our MIPS >>>>> implementation by this approach. >>>> Okay, you may well be testing more tests under Xcomp than what we >>>> regularly do, so that may well expose a number of tests that may not >>>> work at all, or which fail intermittently. I'm trying to find out if >>>> there is a relatively easy way to enumerate the tests we do run under >>>> -Xcomp. >>>> >>>> Cheers, >>>> David >>>> >>>>> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. >>>>> Thanks again. >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>> >>>>>> For hotspot testing we have certain sets of tests that are run under >>>>>> -Xcomp, but this is obviously not one of them. Did you discover this >>>>>> by chance or because you are attempting to do broad -Xcomp testing? >>>>>> Not every test will work with Xcomp (for various reasons) and we >>>>>> aren't actively trying to make every test pass with Xcomp. >>>>>> >>>>>> But by all means file a bug and fix it. >>>>>> >>>>>> Cheers, >>>>>> David > From fujie at loongson.cn Fri Jan 11 05:07:53 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 13:07:53 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> Message-ID: <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> Hi David, Thank you very much. I'd like to choose option 2. A test case is more valuable if it can be used for both interpreter and JIT tests. Here is the patch based on your comments. ---------------------------------------------------------------------------------- diff -r 02e648ae46c3 test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java --- a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Wed Jan 09 01:06:19 2019 +0100 +++ b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java Fri Jan 11 12:55:38 2019 +0800 @@ -22,7 +22,7 @@ ? */ ?/* @test - * @bug 4404702 + * @bug 4404702 8216528 ? * @summary When the RMI runtime (lazily) spawns system threads that could ? * outlive the application context in which they were (happened to be) ? * created, such threads should not inherit (thread local) data specific to @@ -106,7 +106,10 @@ ????????????? * context class loader-- by giving it a chance to pass away. ????????????? */ ???????????? Thread.sleep(2000); -??????????? System.gc(); +??????????? while (loaderRef.get() != null) { +??????????????? System.gc(); +??????????????? Thread.sleep(100); +??????????? } ???????????? System.err.println( ???????????????? "waiting to be notified of loader being weakly reachable..."); ---------------------------------------------------------------------------------- Could you please review it and give me some advice? Thanks. Best regards, Jie On 2019/1/11 ??12:16, David Holmes wrote: > > I see three choices for you here :) > > 1. Don't try to run all tests under Xcomp but just stick to the "core" > sets of tests already tested by others. > > 2. Fix the given test as outlined. (I tested it on linux-x64 and it > fixed the problem.) > > 3. Exclude the given test from Xcomp by adding: @requires vm.compMode > != "Xcomp" > > If you chose options 2 or 3 please update the @bug line with 8216528. > > The core-libs folk may have more to say here and they will need to > provide a sponsor for the commit. > > Thanks, > David > ----- From david.holmes at oracle.com Fri Jan 11 05:33:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 15:33:07 +1000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> Message-ID: <7d0cc496-6e28-f3ea-a490-3f3310d053df@oracle.com> On 11/01/2019 3:07 pm, Jie Fu wrote: > Hi David, > > Thank you very much. I'd like to choose option 2. > A test case is more valuable if it can be used for both interpreter and > JIT tests. > > Here is the patch based on your comments. > ---------------------------------------------------------------------------------- > > diff -r 02e648ae46c3 > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > > --- > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Wed Jan 09 01:06:19 2019 +0100 > +++ > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Fri Jan 11 12:55:38 2019 +0800 > @@ -22,7 +22,7 @@ > ? */ > > ?/* @test > - * @bug 4404702 > + * @bug 4404702 8216528 > ? * @summary When the RMI runtime (lazily) spawns system threads that > could > ? * outlive the application context in which they were (happened to be) > ? * created, such threads should not inherit (thread local) data > specific to > @@ -106,7 +106,10 @@ > ????????????? * context class loader-- by giving it a chance to pass away. > ????????????? */ > ???????????? Thread.sleep(2000); > -??????????? System.gc(); > +??????????? while (loaderRef.get() != null) { > +??????????????? System.gc(); > +??????????????? Thread.sleep(100); > +??????????? } > > ???????????? System.err.println( > ???????????????? "waiting to be notified of loader being weakly > reachable..."); > ---------------------------------------------------------------------------------- > > > Could you please review it and give me some advice? Not sure what "advice" you are looking for? I have reviewed it - looks fine to me (and I tested it). But I want someone from core-libs to also review it and hopefully sponsor it. Thanks, David > Thanks. > > Best regards, > Jie > > > On 2019/1/11 ??12:16, David Holmes wrote: >> >> I see three choices for you here :) >> >> 1. Don't try to run all tests under Xcomp but just stick to the "core" >> sets of tests already tested by others. >> >> 2. Fix the given test as outlined. (I tested it on linux-x64 and it >> fixed the problem.) >> >> 3. Exclude the given test from Xcomp by adding: @requires vm.compMode >> != "Xcomp" >> >> If you chose options 2 or 3 please update the @bug line with 8216528. >> >> The core-libs folk may have more to say here and they will need to >> provide a sponsor for the commit. >> >> Thanks, >> David >> ----- > From fujie at loongson.cn Fri Jan 11 05:42:09 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 13:42:09 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <7d0cc496-6e28-f3ea-a490-3f3310d053df@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d0cc496-6e28-f3ea-a490-3f3310d053df@oracle.com> Message-ID: <307c5866-cbc1-07f9-d6b5-b95e61ea1ab6@loongson.cn> Thanks David. Could someone from core-libs help to review it? Thanks. On 2019/1/11 ??1:33, David Holmes wrote: > On 11/01/2019 3:07 pm, Jie Fu wrote: >> Hi David, >> >> Thank you very much. I'd like to choose option 2. >> A test case is more valuable if it can be used for both interpreter >> and JIT tests. >> >> Here is the patch based on your comments. >> ---------------------------------------------------------------------------------- >> >> diff -r 02e648ae46c3 >> test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> >> --- >> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> Wed Jan 09 01:06:19 2019 +0100 >> +++ >> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> Fri Jan 11 12:55:38 2019 +0800 >> @@ -22,7 +22,7 @@ >> ?? */ >> >> ??/* @test >> - * @bug 4404702 >> + * @bug 4404702 8216528 >> ?? * @summary When the RMI runtime (lazily) spawns system threads >> that could >> ?? * outlive the application context in which they were (happened to be) >> ?? * created, such threads should not inherit (thread local) data >> specific to >> @@ -106,7 +106,10 @@ >> ?????????????? * context class loader-- by giving it a chance to pass >> away. >> ?????????????? */ >> ????????????? Thread.sleep(2000); >> -??????????? System.gc(); >> +??????????? while (loaderRef.get() != null) { >> +??????????????? System.gc(); >> +??????????????? Thread.sleep(100); >> +??????????? } >> >> ????????????? System.err.println( >> ????????????????? "waiting to be notified of loader being weakly >> reachable..."); >> ---------------------------------------------------------------------------------- >> >> >> Could you please review it and give me some advice? > > Not sure what "advice" you are looking for? > > I have reviewed it - looks fine to me (and I tested it). > > But I want someone from core-libs to also review it and hopefully > sponsor it. > > Thanks, > David > >> Thanks. >> >> Best regards, >> Jie >> >> >> On 2019/1/11 ??12:16, David Holmes wrote: >>> >>> I see three choices for you here :) >>> >>> 1. Don't try to run all tests under Xcomp but just stick to the >>> "core" sets of tests already tested by others. >>> >>> 2. Fix the given test as outlined. (I tested it on linux-x64 and it >>> fixed the problem.) >>> >>> 3. Exclude the given test from Xcomp by adding: @requires >>> vm.compMode != "Xcomp" >>> >>> If you chose options 2 or 3 please update the @bug line with 8216528. >>> >>> The core-libs folk may have more to say here and they will need to >>> provide a sponsor for the commit. >>> >>> Thanks, >>> David >>> ----- >> From joe.darcy at oracle.com Fri Jan 11 06:13:43 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Jan 2019 22:13:43 -0800 Subject: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException Message-ID: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> Hello, Please review the changes to fix: ??? JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException ??? http://cr.openjdk.java.net/~darcy/8213299.0/ For background, in the changes made for ??? JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods the revised logic in methodToString which is used to build messages for exceptions mistakenly omits adding information about method parameters. The HotSpot test EmptyClassInBootClassPath.java examines information about the exception messages and fails due to this omission. Thanks to Sergei Tsypanov for noticing the root cause of this issue. Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/Class.java 2019-01-10 21:28:40.586005000 -0800 +++ new/src/java.base/share/classes/java/lang/Class.java 2019-01-10 21:28:40.338005000 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -3420,8 +3420,8 @@ ???????? StringBuilder sb = new StringBuilder(); ???????? sb.append(getName() + "." + name + "("); ???????? if (argTypes != null) { -??????????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). -??????????????? collect(Collectors.joining(",")); +??????????? sb.append(Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). +??? ??? ????? collect(Collectors.joining(","))); ???????? } ???????? sb.append(")"); ???????? return sb.toString(); --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-01-10 21:28:41.210005000 -0800 +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-01-10 21:28:40.954005000 -0800 @@ -85,7 +85,6 @@ ?runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 macosx-x64 ?runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 -runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java 8213299 generic-all ?runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all ?runtime/handshake/HandshakeWalkSuspendExitTest.java 8214174 generic-all ?runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 From david.holmes at oracle.com Fri Jan 11 06:31:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 16:31:17 +1000 Subject: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException In-Reply-To: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> References: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> Message-ID: <93d9c722-80f8-e891-6e5d-ff3371d8f2ca@oracle.com> Looks good Joe! Thanks, David On 11/01/2019 4:13 pm, Joe Darcy wrote: > Hello, > > Please review the changes to fix: > > ??? JDK-8213299: > runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java > failed with java.lang.NoSuchMethodException > ??? http://cr.openjdk.java.net/~darcy/8213299.0/ > > For background, in the changes made for > > ??? JDK-6304578: (reflect) toGenericString fails to print bounds of > type variables on generic methods > > the revised logic in methodToString which is used to build messages for > exceptions mistakenly omits adding information about method parameters. > The HotSpot test EmptyClassInBootClassPath.java examines information > about the exception messages and fails due to this omission. > > Thanks to Sergei Tsypanov for noticing the root cause of this issue. > > Patch below. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/lang/Class.java 2019-01-10 > 21:28:40.586005000 -0800 > +++ new/src/java.base/share/classes/java/lang/Class.java 2019-01-10 > 21:28:40.338005000 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1994, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -3420,8 +3420,8 @@ > ???????? StringBuilder sb = new StringBuilder(); > ???????? sb.append(getName() + "." + name + "("); > ???????? if (argTypes != null) { > -??????????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : > c.getName();}). > -??????????????? collect(Collectors.joining(",")); > +??????????? sb.append(Stream.of(argTypes).map(c -> {return (c == null) > ? "null" : c.getName();}). > +??? ??? ????? collect(Collectors.joining(","))); > ???????? } > ???????? sb.append(")"); > ???????? return sb.toString(); > --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-01-10 > 21:28:41.210005000 -0800 > +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-01-10 > 21:28:40.954005000 -0800 > @@ -85,7 +85,6 @@ > > ?runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 macosx-x64 > ?runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 > -runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java > 8213299 generic-all > ?runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all > ?runtime/handshake/HandshakeWalkSuspendExitTest.java 8214174 generic-all > ?runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 > From goetz.lindenmaier at sap.com Fri Jan 11 08:53:30 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Jan 2019 08:53:30 +0000 Subject: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) In-Reply-To: References: <720e6f1c-7a70-e85a-20fb-6b5acb6f251e@oracle.com> Message-ID: Hi, Our nightly tests with the updated patch are green, too, So I pushed it to 12: http://hg.openjdk.java.net/jdk/jdk12/rev/6b37a7ba9b66 Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Lindenmaier, Goetz > Sent: Thursday, January 10, 2019 10:29 PM > To: 'Ichiroh Takiguchi' ; Alan Bateman > > Cc: core-libs-dev > Subject: [CAUTION] RE: [12] JDK-8211841 [testbug] > sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) > > Hi, > > The change looks good for me, too. > I ran the original change through our nightly testing, it's > all green. > > I could sponsor this as well ... > > Best regards, > Goetz. > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Ichiroh Takiguchi > > Sent: Thursday, January 10, 2019 1:06 PM > > To: Alan Bateman > > Cc: core-libs-dev > > Subject: Re: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java > > does not compile (aix) > > > > Hello Alan. > > I appreciate your suggestion. > > > > Could you review the fix again ? > > (Additionally, I removed sun.nio.cs.Surrogate import from > > IBM970_OLD.java) > > > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 > > Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.01/ > > > > I tested new fix on AIX and Linux amd64 platform. > > It worked fine on both platform. > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-01-10 17:00, Alan Bateman wrote: > > > On 10/01/2019 07:47, Ichiroh Takiguchi wrote: > > >> Hello. > > >> Could you review the fix ? > > >> And please push this to jdk12 if possible. > > >> > > >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211841 > > >> Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ > > > If I read this correctly then the wildcard import is to import the > > > IBM* charsets without enumerating them as that would not compile on > > > other platforms. Looks okay and the import of > > > sun.nio.cs.HistoricallyNamedCharset can be removed - I can do that > > > when sponsoring it, if you are okay that change. > > > > > > -Alan From adam.farley at uk.ibm.com Fri Jan 11 12:46:01 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 11 Jan 2019 12:46:01 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields Message-ID: Hi All, I posit that you shouldn't be able to change the contents of a a final field. However, if you use Field.setAccessible(true) before calling Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows you to set the (reflected) value of a static final field. This seems wrong to me, so here's a change to fix it. webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8216558 Opinions invited. Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From forax at univ-mlv.fr Fri Jan 11 12:56:35 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Jan 2019 13:56:35 +0100 (CET) Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: Message-ID: <1786999976.1322496.1547211395973.JavaMail.zimbra@u-pem.fr> It's not wrong, it's part of the spec. while most the semantics of the method handle is based on the bytecode semantics, the method unreflect* semantics are based on the java.lang.reflect semantics, so if field.set(object, value) is able to change the value of the field then unreflectSetter(field).invokeExact(object, value) has to change the value of the field too. regards, R?mi (with my JSR 292 Expert hat) ----- Mail original ----- > De: "Adam Farley8" > ?: "core-libs-dev" > Envoy?: Vendredi 11 Janvier 2019 13:46:01 > Objet: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields > Hi All, > > I posit that you shouldn't be able to change the contents of a a final > field. > > However, if you use Field.setAccessible(true) before calling > Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows > you to set the (reflected) value of a static final field. > > This seems wrong to me, so here's a change to fix it. > > webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8216558 > > Opinions invited. > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Fri Jan 11 13:02:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 23:02:06 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: Message-ID: On 11/01/2019 10:46 pm, Adam Farley8 wrote: > Hi All, > > I posit that you shouldn't be able to change the contents of a a final > field. Nice in theory, but not true in practice. > However, if you use Field.setAccessible(true) before calling > Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows > you to set the (reflected) value of a static final field. > > This seems wrong to me, so here's a change to fix it. See: https://docs.oracle.com/javase/10/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,java.lang.Object) "If the underlying field is final, the method throws an IllegalAccessException unless setAccessible(true) has succeeded for this Field object and the field is non-static. Setting a final field in this way is meaningful only during deserialization or reconstruction of instances of classes with blank final fields, before they are made available for access by other parts of a program. Use in any other context may have unpredictable effects, including cases in which other parts of a program continue to use the original value of this field. " the same semantics are supported by MH/VH. But note this requires the field to be non-static - if you can set a static final field this way then that may be a bug (they can still be set via native methods of course). David ----- > webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8216558 > > Opinions invited. > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From forax at univ-mlv.fr Fri Jan 11 13:11:48 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Jan 2019 14:11:48 +0100 (CET) Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: Message-ID: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "Adam Farley8" , "core-libs-dev" > Envoy?: Vendredi 11 Janvier 2019 14:02:06 > Objet: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields > On 11/01/2019 10:46 pm, Adam Farley8 wrote: >> Hi All, >> >> I posit that you shouldn't be able to change the contents of a a final >> field. > > Nice in theory, but not true in practice. > >> However, if you use Field.setAccessible(true) before calling >> Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows >> you to set the (reflected) value of a static final field. >> >> This seems wrong to me, so here's a change to fix it. > > See: > > https://docs.oracle.com/javase/10/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,java.lang.Object) > > "If the underlying field is final, the method throws an > IllegalAccessException unless setAccessible(true) has succeeded for this > Field object and the field is non-static. Setting a final field in this > way is meaningful only during deserialization or reconstruction of > instances of classes with blank final fields, before they are made > available for access by other parts of a program. Use in any other > context may have unpredictable effects, including cases in which other > parts of a program continue to use the original value of this field. " > > the same semantics are supported by MH/VH. No VH doesn't support setAccessible (don't ask me why) ... > > But note this requires the field to be non-static - if you can set a > static final field this way then that may be a bug (they can still be > set via native methods of course). > > David R?mi > ----- > >> webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8216558 >> >> Opinions invited. >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Fri Jan 11 14:14:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2019 14:14:58 +0000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> Message-ID: <7f158a34-1754-968c-7d2d-32eefd704a4d@oracle.com> On 11/01/2019 04:16, David Holmes wrote: > > I see three choices for you here :) > > 1. Don't try to run all tests under Xcomp but just stick to the "core" > sets of tests already tested by others. > > 2. Fix the given test as outlined. (I tested it on linux-x64 and it > fixed the problem.) > > 3. Exclude the given test from Xcomp by adding: @requires vm.compMode > != "Xcomp" > > If you chose options 2 or 3 please update the @bug line with 8216528. > > The core-libs folk may have more to say here and they will need to > provide a sponsor for the commit. Jie has been discussing another one on beans-dev in the last few days. #1 would likely avoid at least some whack-a-mole but it might be beneficial to others to have more tests capable of running with -Xcomp. I assume trying more test areas will lead to #3, if nothing else but to exclude tests that run too slowing in that mode. In any case, the patch to the RMI test looks okay. -Alan From adam.farley at uk.ibm.com Fri Jan 11 14:38:46 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 11 Jan 2019 14:38:46 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> Message-ID: Hi All, First; thanks for responding so quickly. :) Second, it sounds like changing the contents of a final field is acceptable under the spec, but *not* changing the contents of a static final field. The test case uploaded to the bug uses a static final field for the test, so I think we can agree that the ability to create a setter for a static final field is still a bug. It sounds like the same fix could work if we check for "static" when we check for "final", with a modified message. As Field.set (post-setAccessible) fails to set the value of a static final field, I think we can agree that unreflectSetter should fail to create a setter MethodHandle for this same field. Best Regards Adam Farley IBM Runtimes Remi Forax wrote on 11/01/2019 13:11:48: > From: Remi Forax > To: David Holmes > Cc: Adam Farley8 , core-libs-dev dev at openjdk.java.net> > Date: 11/01/2019 13:11 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > > ----- Mail original ----- > > De: "David Holmes" > > ?: "Adam Farley8" , "core-libs-dev" libs-dev at openjdk.java.net> > > Envoy?: Vendredi 11 Janvier 2019 14:02:06 > > Objet: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > On 11/01/2019 10:46 pm, Adam Farley8 wrote: > >> Hi All, > >> > >> I posit that you shouldn't be able to change the contents of a a final > >> field. > > > > Nice in theory, but not true in practice. > > > >> However, if you use Field.setAccessible(true) before calling > >> Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows > >> you to set the (reflected) value of a static final field. > >> > >> This seems wrong to me, so here's a change to fix it. > > > > See: > > > > INVALID URI REMOVED > u=https-3A__docs.oracle.com_javase_10_docs_api_java_lang_reflect_Field.html-23set-28java.lang.Object-2Cjava.lang.Object-29&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=aBMrDjHarHyUonopC18wEF8NpJy49nWWHAa5zLG7DPA&s=IjUETWTkkQMUCoCFwBXi- > o8mQuUKzUKO550ntJT6f6c&e= > > > > "If the underlying field is final, the method throws an > > IllegalAccessException unless setAccessible(true) has succeeded for this > > Field object and the field is non-static. Setting a final field in this > > way is meaningful only during deserialization or reconstruction of > > instances of classes with blank final fields, before they are made > > available for access by other parts of a program. Use in any other > > context may have unpredictable effects, including cases in which other > > parts of a program continue to use the original value of this field. " > > > > the same semantics are supported by MH/VH. > > No VH doesn't support setAccessible (don't ask me why) ... > > > > > But note this requires the field to be non-static - if you can set a > > static final field this way then that may be a bug (they can still be > > set via native methods of course). > > > > David > > R?mi > > > ----- > > > >> webrev: INVALID URI REMOVED > u=http-3A__cr.openjdk.java.net_-7Eafarley_8216558_webrev_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=aBMrDjHarHyUonopC18wEF8NpJy49nWWHAa5zLG7DPA&s=her2- > KtbTJb51VZ58GcKJXMpC6zPiEWqkWeJU9zu-IQ&e= > >> bug: INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8216558&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=aBMrDjHarHyUonopC18wEF8NpJy49nWWHAa5zLG7DPA&s=xxfE7kYjXorAaobSj5gl8uwHLfJMcWYG5IXcrNH- > wR4&e= > >> > >> Opinions invited. > >> > >> Best Regards > >> > >> Adam Farley > >> IBM Runtimes > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From fujie at loongson.cn Fri Jan 11 15:00:39 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Jan 2019 23:00:39 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <7f158a34-1754-968c-7d2d-32eefd704a4d@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <7f158a34-1754-968c-7d2d-32eefd704a4d@oracle.com> Message-ID: <731ebce9-f8fa-884d-1682-c914741f1633@loongson.cn> Thanks Alan. On 2019?01?11? 22:14, Alan Bateman wrote: > On 11/01/2019 04:16, David Holmes wrote: >> >> I see three choices for you here :) >> >> 1. Don't try to run all tests under Xcomp but just stick to the >> "core" sets of tests already tested by others. >> >> 2. Fix the given test as outlined. (I tested it on linux-x64 and it >> fixed the problem.) >> >> 3. Exclude the given test from Xcomp by adding: @requires vm.compMode >> != "Xcomp" >> >> If you chose options 2 or 3 please update the @bug line with 8216528. >> >> The core-libs folk may have more to say here and they will need to >> provide a sponsor for the commit. > Jie has been discussing another one on beans-dev in the last few days. > #1 would likely avoid at least some whack-a-mole but it might be > beneficial to others to have more tests capable of running with > -Xcomp. I assume trying more test areas will lead to #3, if nothing > else but to exclude tests that run too slowing in that mode. In any > case, the patch to the RMI test looks okay. > > -Alan From amaembo at gmail.com Fri Jan 11 15:05:25 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 11 Jan 2019 22:05:25 +0700 Subject: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int) In-Reply-To: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> References: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> Message-ID: Hello! Your benchmark tests only one of many possible cases. What if string contains non-latin1 characters? What if many strings are appended to the same string builder? What if you append only one character from the long string? Performance fixes in such widely used class could be introduced only after investigating all possible use scenarios. Also not only cpu time, but also memory allocations should be measured. With best regards, Tagir Valeev. ??, 11 ???. 2019 ?., 2:35 ?????? ??????? sergei.tsypanov at yandex.ru: > Hi, > > while investigating an issue I've found out that performance of expression > (1) can be significantly improved by turning it into (2) > > > ---------------------------------------------------------------------------------------------------- > > //str is an instance of java.lang.String > > (1) return new StringBuilder().append(str, beginIndex, > endIndex).toString(); > > ----> > > (2) String substring = str.substring(beginIndex, endIndex); > > return new StringBuilder().append(substring).toString(); > > > ---------------------------------------------------------------------------------------------------- > > Using benchmark [1] I've got the following results: > > Benchmark > (length) Mode Cnt Score Error Units > StringBuilderAppendBenchmark.appendBounds > 10 avgt 20 21,161 ? 0,545 ns/op > StringBuilderAppendBenchmark.appendBounds > 100 avgt 20 72,230 ? 3,452 ns/op > StringBuilderAppendBenchmark.appendBounds > 1000 avgt 20 476,256 ? 12,044 ns/op > > StringBuilderAppendBenchmark.appendSubString > 10 avgt 20 26,023 ? 0,871 ns/op > StringBuilderAppendBenchmark.appendSubString > 100 avgt 20 38,824 ? 1,185 ns/op > StringBuilderAppendBenchmark.appendSubString > 1000 avgt 20 214,072 ? 3,372 ns/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 10 avgt 20 80,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 100 avgt 20 320,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 1000 avgt 20 2120,001 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > 10 avgt 20 96,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > 100 avgt 20 192,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > 1000 avgt 20 1088,000 ? 0,001 B/op > > > The reason for such a difference seems to be @HotSpotIntrinsicCandidate > over StringBuilder.append(String), > while StringBuilder.append(CharSerquence, int, int) copies chars/bytes one > by one. > > I've prepared a patch [2] and applied it to fresh sources of JDK 11. > After rebuild the same benchmark demonstrated severe performance > degradation: > > - before patch > > Benchmark > (length) Mode Cnt Score Error Units > StringBuilderAppendBenchmark.appendBounds > 10 avgt 20 21,592 ? 0,763 ns/op > StringBuilderAppendBenchmark.appendBounds > 100 avgt 20 72,241 ? 2,799 ns/op > StringBuilderAppendBenchmark.appendBounds > 1000 avgt 20 488,106 ? 43,042 ns/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 10 avgt 20 80,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 100 avgt 20 320,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 1000 avgt 20 2132,001 ? 10,691 B/op > > - after patch > > Benchmark > (length) Mode Cnt Score Error Units > StringBuilderAppendBenchmark.appendBounds > 10 avgt 20 40,186 ? 1,828 ns/op > StringBuilderAppendBenchmark.appendBounds > 100 avgt 20 89,031 ? 6,664 ns/op > StringBuilderAppendBenchmark.appendBounds > 1000 avgt 20 669,934 ? 76,888 ns/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 10 avgt 20 152,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 100 avgt 20 440,000 ? 0,001 B/op > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > 1000 avgt 20 2688,001 ? 0,002 B/op > > As I see the reason of degradation is that patched code now dodges > intrinsified StringBuilder.append(String) and calls directly > AbstractStringBuilder.append(String) which in spite of utilizing > System::arraycopy performes worse than intrinsic. > > So my question is should I rework the patch somehow to make it perform > better or I need to apply the transformation mentioned above ad hoc? > > > Appendix: > > 1) benchmark > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringBuilderAppendBenchmark { > > @Benchmark > @SuppressWarnings("StringBufferReplaceableByString") > public String appendSubString(Data data) { > String str = data.str; > int beginIndex = data.beginIndex; > int endIndex = data.endIndex; > > String substring = str.substring(beginIndex, endIndex); > > return new > StringBuilder().append('L').append(substring).append(';').toString(); > } > > @Benchmark > public String appendBounds(Data data) { > String str = data.str; > int beginIndex = data.beginIndex; > int endIndex = data.endIndex; > > return new StringBuilder().append('L').append(str, beginIndex, > endIndex).append(';').toString(); > } > > @State(Scope.Thread) > public static class Data { > String str; > > @Param({"10", "100", "1000"}) > private int length; > > private int beginIndex; > private int endIndex; > > @Setup > public void setup() { > str = randomString(); > beginIndex = length / 4; > endIndex = length / 4* 3; > } > > private String randomString() { > ThreadLocalRandom random = ThreadLocalRandom.current(); > char[] chars = "abcdefghijklmnopqrstuvwxyz".toCharArray(); > > StringBuilder sb = new StringBuilder(length); > for (int i = 0; i < length; i++) { > char c = chars[random.nextInt(chars.length)]; > sb.append(c); > } > return sb.toString(); > } > } > > } > > > 2) patch > > diff --git > a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > @@ -626,10 +626,7 @@ > s = "null"; > } > checkRange(start, end, s.length()); > - int len = end - start; > - ensureCapacityInternal(count + len); > - appendChars(s, start, end); > - return this; > + return append(s.subSequence(start, end).toString()); > } > > /** > @@ -1686,27 +1683,6 @@ > this.count = count + end - off; > } > > - private final void appendChars(CharSequence s, int off, int end) { > - if (isLatin1()) { > - byte[] val = this.value; > - for (int i = off, j = count; i < end; i++) { > - char c = s.charAt(i); > - if (StringLatin1.canEncode(c)) { > - val[j++] = (byte)c; > - } else { > - count = j; > - inflate(); > - StringUTF16.putCharsSB(this.value, j, s, i, end); > - count += end - i; > - return; > - } > - } > - } else { > - StringUTF16.putCharsSB(this.value, count, s, off, end); > - } > - count += end - off; > - } > - > /* IndexOutOfBoundsException, if out of bounds */ > private static void checkRange(int start, int end, int len) { > if (start < 0 || start > end || end > len) { > > > > From Roger.Riggs at oracle.com Fri Jan 11 16:22:03 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 11 Jan 2019 11:22:03 -0500 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> Message-ID: <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> Hi, The proposed patch changes the test in a way that is unintended. Adding the infinite loop of gc() and sleep, will change the timeout behavior from the existing timeout of TIMEOUT to the jtreg default timeout of the whole test. Further, it renders the check at lines 114-120 irrelevant since loaderRef.get() will have returned null and the ref will have been enqueued by then. While it is true that calling gc() only once is unreliable, a better fix is to put the code from 108-120 in a loop with a fixed number of durations and add Reachability.reachabilityFence(loaderRef) to ensure the ref is not ignored. Regards, Roger On 01/11/2019 12:07 AM, Jie Fu wrote: > Hi David, > > Thank you very much. I'd like to choose option 2. > A test case is more valuable if it can be used for both interpreter > and JIT tests. > > Here is the patch based on your comments. > ---------------------------------------------------------------------------------- > > diff -r 02e648ae46c3 > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > --- > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Wed Jan 09 01:06:19 2019 +0100 > +++ > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > Fri Jan 11 12:55:38 2019 +0800 > @@ -22,7 +22,7 @@ > ? */ > > ?/* @test > - * @bug 4404702 > + * @bug 4404702 8216528 > ? * @summary When the RMI runtime (lazily) spawns system threads that > could > ? * outlive the application context in which they were (happened to be) > ? * created, such threads should not inherit (thread local) data > specific to > @@ -106,7 +106,10 @@ > ????????????? * context class loader-- by giving it a chance to pass > away. > ????????????? */ > ???????????? Thread.sleep(2000); > -??????????? System.gc(); > +??????????? while (loaderRef.get() != null) { > +??????????????? System.gc(); > +??????????????? Thread.sleep(100); > +??????????? } > > ???????????? System.err.println( > ???????????????? "waiting to be notified of loader being weakly > reachable..."); > ---------------------------------------------------------------------------------- > > > Could you please review it and give me some advice? > Thanks. > > Best regards, > Jie > > > On 2019/1/11 ??12:16, David Holmes wrote: >> >> I see three choices for you here :) >> >> 1. Don't try to run all tests under Xcomp but just stick to the >> "core" sets of tests already tested by others. >> >> 2. Fix the given test as outlined. (I tested it on linux-x64 and it >> fixed the problem.) >> >> 3. Exclude the given test from Xcomp by adding: @requires vm.compMode >> != "Xcomp" >> >> If you chose options 2 or 3 please update the @bug line with 8216528. >> >> The core-libs folk may have more to say here and they will need to >> provide a sponsor for the commit. >> >> Thanks, >> David >> ----- > From mandy.chung at oracle.com Fri Jan 11 18:07:33 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2019 10:07:33 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> Message-ID: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> Hi Adam, This is indeed a bug.??? I suggest to do the check in the checkAccess method closes to where it performs the instance final field check.? Please also add a test case. Mandy On 1/11/19 6:38 AM, Adam Farley8 wrote: > Hi All, > > First; thanks for responding so quickly. :) > > Second, it sounds like changing the contents of a final field is > acceptable under the spec, but *not* changing the contents of a static > final field. > > The test case uploaded to the bug uses a static final field for the test, > so I think we can agree that the ability to create a setter for a static > final field is still a bug. > > It sounds like the same fix could work if we check for "static" when we > check for "final", with a modified message. > > As Field.set (post-setAccessible) fails to set the value of a static final > field, I think we can agree that unreflectSetter should fail to create a > setter MethodHandle for this same field. > > Best Regards > > Adam Farley > IBM Runtimes > From brent.christian at oracle.com Fri Jan 11 18:35:00 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 11 Jan 2019 10:35:00 -0800 Subject: RFR 8216401 : Allow "file:" URLs in Class-Path of local JARs Message-ID: <20fe33cd-74b6-bdd1-7b2c-6c0a5ce23e2c@oracle.com> Hi, Please review my change for 8216401[1]. Webrev: http://cr.openjdk.java.net/~bchristi/8216401/webrev-01/ The Class-Path section of the JAR spec[2] states that entries must be relative URLs, however this hasn't been enforced for most of Java's history. There is now code to enforce this, though it is disabled by default for compatibility. It has come to light that there are some widely-used libraries that misuse the Class-Path attribute, by including absolute "file:" URL entries. In the interest of compatibility with this long-standing behavior, "file:" entries in the Class-Path of JARs loaded from the local disk should be allowed. This change will not affect the current default behavior, but hopefully in the near future, the Class-Path enforcement code can be enabled by default, and the change be reflected in the JAR spec[3]. Automated build+test passes cleanly. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8216401 2. https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute 3. https://bugs.openjdk.java.net/browse/JDK-8211941 From openjdk at icemanx.nl Fri Jan 11 19:01:01 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Fri, 11 Jan 2019 20:01:01 +0100 Subject: 8212620: Provide a mechansim to allow a class/method to request filtering from the stack trace In-Reply-To: <5b1005ff-b3d2-0879-47c4-4080869982a6@oracle.com> References: <5b1005ff-b3d2-0879-47c4-4080869982a6@oracle.com> Message-ID: On 10/01/2019 22:59, Mandy Chung wrote: > > > On 1/10/19 11:30 AM, Rob Spoor wrote: >> I had an idea that can possibly help solve three issues: >> * 8212620 >> Provide a mechansim to allow a class/method to request filtering from >> the stack trace > > This RFE is not just about stack trace format and a generic stack trace > printer has no knowledge if a stack frame is implementation-specific. A > library developer may want certain classes or methods to hide from the > user (eliminating the implementation details) and remove noise from the > stack trace. > > One idea is some kind of annotation that a library developer can tag the > methods to be hidden from stack trace by default. > > So this proposal does not address the use case of 8212620. I may have RFE 8212620 differently. My proposal would also allow stack trace elements to be filtered out of stack traces, by providing a filtering StackTracePrinter. This would be initiated from the caller (or system if the default is replaced). I now see that 8212620 is about letting the called method or class itself determine that it should show up in stack traces. Both solutions could give the same end result, and could probably even be mixed. > >> * 8211152 >> Improve unclear and incomplete Exception stack trace >> * 6507809 >> "Caused by" notation for stack traces unnecessarily hard to read >> >> > > I didn't spend time on this.? The only thing I would say about these 2 > RFEs is that they both propose to change the current stack trace format > that will likely break tools parsing the output.?? Keeping the default > format unmodified and allowing to plugin a custom formatter is one > option to consider. > > Mandy > >> The issue described in all three is that the way stack traces are >> printed is different from what people want. One solution could be to >> pull the formatting logic away from Throwable. This can be done by >> introducing an interface similar to Thread.UncaughtExceptionHandler. >> For instance: >> >> ??? public interface StackTracePrinter { >> ??????? void printStackTrace(Throwable t, PrintStream out); >> ??????? void printStackTrace(Throwable t, PrintWriter out); >> ??? } >> >> Throwable could get a static defaultStackTracePrinter field like >> Thread.defaultUncaughtExceptionHandler, and Throwable's >> printStackTrace methods would delegate to this default. >> >> There can then be implementation DefaultStackTracePrinter that uses >> the current format, and different implementations for the three >> issues. (Small implementation improvement: instead of using >> PrintStreamOrWriter, WrappedPrintStream and WrappedPrintWriter, the >> private printStackTrace method could take a lock and a >> Consumer as arguments. This would then be called as >> "printStackTrace(s, s::println)".) >> >> >> Unfortunately, getOurStackTrace() will not be available to all >> implementations, so to prevent having to call getStackTrace() >> Throwable should get another method List >> getStackTraceList() that returns List.of(getOurStackTrace()) (possibly >> cached), or otherwise >> Collections.unmodifiableList(Arrays.asList(getOurStackTrace())). >> >> >> There is one thing that I haven't been able to figure out though, and >> that's specifying different StackTracePrinters for different >> applications in application containers etc. Maybe someone can think of >> a good mechanism to support this. From mandy.chung at oracle.com Fri Jan 11 19:07:14 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2019 11:07:14 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> Message-ID: This issue requires a spec change and it's a behavioral change. Field::set on a static final field throws IAE.? Although there are few cases in the world that hack around it, I think the compatibility risk is low in this change. I added a suggested fix in the JBS issue. Mandy On 1/11/19 10:07 AM, Mandy Chung wrote: > Hi Adam, > > This is indeed a bug.??? I suggest to do the check in the checkAccess > method closes to where it performs the instance final field check.? > Please also add a test case. > > Mandy > > On 1/11/19 6:38 AM, Adam Farley8 wrote: >> Hi All, >> >> First; thanks for responding so quickly. :) >> >> Second, it sounds like changing the contents of a final field is >> acceptable under the spec, but *not* changing the contents of a static >> final field. >> >> The test case uploaded to the bug uses a static final field for the >> test, >> so I think we can agree that the ability to create a setter for a static >> final field is still a bug. >> >> It sounds like the same fix could work if we check for "static" when we >> check for "final", with a modified message. >> >> As Field.set (post-setAccessible) fails to set the value of a static >> final >> field, I think we can agree that unreflectSetter should fail to create a >> setter MethodHandle for this same field. >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> From stuart.marks at oracle.com Fri Jan 11 19:08:29 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Jan 2019 11:08:29 -0800 Subject: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException In-Reply-To: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> References: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> Message-ID: <8175ebfe-2951-6c71-29ee-f09a6b4da4f3@oracle.com> 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();}). > +??? ??? ????? collect(Collectors.joining(","))); Since argTypes is an array, I usually prefer Arrays.stream() over Stream.of(). The issue is that Stream.of() is varargs, and while this case isn't formally ambiguous, it can create a question in the reader's mind about whether the stream consists of the array elements or of just one element that's the array itself. The statement lambda can probably be replaced with an expression lambda. I think it makes the ternary easier to read. Also, indentation. sb.append(Arrays.stream(argTypes) .map(c -> (c == null) ? "null" : c.getName()) .collect(Collectors.joining(","))); I'm not sure it's worth tracking this, but I could file a bug if you'd like. s'marks From naoto.sato at oracle.com Fri Jan 11 19:15:49 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 11 Jan 2019 11:15:49 -0800 Subject: [13] RFR: Correct UnicodeDecoder U+FFFE handling Message-ID: <9fb04cbc-5843-aefd-5612-631fbc37ab6e@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216140 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216140/webrev.00/ This issue was previously discussed in https://bugs.openjdk.java.net/browse/JDK-8150449 and was closed as "not an issue" for JDK8. Unicode Consortium then made a corrigendum to Unicode 7 that recommends passing through of the code point. To conform to the standard, the offending test/error return has been removed, based on the recommendation in the previous consideration on 8150449. Naoto From andy.herrick at oracle.com Fri Jan 11 19:41:08 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 11 Jan 2019 14:41:08 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) Message-ID: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This webrev corresponds to the second EA build, Build 8 (2019/1/8), posted at http://jdk.java.net/jpackage/ This update renames the package used to "jdk.jpackage", removes the Single Instance Service (and CLI option --singleton), adds several other CLI options, adds more automated tests, and contains fixes to the following issues (since update 1 on 11/09/2018): JDK-8212164???? resolve jre.list and jre.module.list JDK-8212936???? Makefile and other improvements for jpackager JDK-8213385???? jpackager Command-Line Argument File. JDK-8213392???? Enhance --help and --version JDK-8213425???? Analyze output from Source code scanner and fix where needed. JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk JDK-8213748???? jpackager native launcher for macosx, linux. JDK-8213756???? SingleInstance runtime improvements JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails JDK-8213963???? Flatten out jpackager packages and resources. JDK-8214021???? Create additional automated tests for jpackager JDK-8214051???? rename jpackager tool to jpackage JDK-8214070???? Analyze and Fix issues reported by Parfait JDK-8214143???? Reduce Resource files JDK-8214495???? Change behavior of --license-file JDK-8214575???? Exe installers will install application over existing installation JDK-8214899???? rename papplauncher and it's library and move src to appropriate places JDK-8214982???? jpackage causes failures in existing HelpFlagsTest and VersionCheck tests JDK-8215020???? create-jre-installer exe fails when --runtime-image is specified. JDK-8215036???? Create initial set of tests for jpackage create-installer mode JDK-8215453???? remove unused BundlerParams and fix misleading messages JDK-8215515???? Add a command line option to override internal resources. JDK-8215900???? Without --files args, only jars in the top level of --input are added to class-path JDK-8215903???? modify behavior of retaining temporary output dir JDK-8216190???? Remove Single Instance Service support from jpackage JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs JDK-8216373???? temporary build-root left behind when using secondary launcher(s) JDK-8216492???? Update copyright of all new jpackage files to 2019 Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 Note: SingleInstanceService API was removed (see https://bugs.openjdk.java.net/browse/JDK-8216190). An example stand alone implementation can be found at: http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java please send feedback to core-libs-dev at openjdk.java.net /Andy Herrick From Roger.Riggs at oracle.com Fri Jan 11 21:28:42 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 11 Jan 2019 16:28:42 -0500 Subject: [13] RFR: Correct UnicodeDecoder U+FFFE handling In-Reply-To: <9fb04cbc-5843-aefd-5612-631fbc37ab6e@oracle.com> References: <9fb04cbc-5843-aefd-5612-631fbc37ab6e@oracle.com> Message-ID: <25727d9f-c5be-ead6-e356-2b11b871ef81@oracle.com> Hi Naoto, Looks fine. I don't think it needs to be run in 'othervm' since it does not pollute the VM it is running in. It might run a few milliseconds faster without that.? No updated webrev needed. Regards, Roger On 01/11/2019 02:15 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8216140 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8216140/webrev.00/ > > This issue was previously discussed in > https://bugs.openjdk.java.net/browse/JDK-8150449 and was closed as > "not an issue" for JDK8. Unicode Consortium then made a corrigendum to > Unicode 7 that recommends passing through of the code point. To > conform to the standard, the offending test/error return has been > removed, based on the recommendation in the previous consideration on > 8150449. > > Naoto From david.holmes at oracle.com Fri Jan 11 22:38:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 08:38:59 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> Message-ID: There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field is final? Same for findSetter? This issue seems to be much bigger than just a simple bug fix. A CSR request will need to be filed. David ----- On 12/01/2019 5:07 am, Mandy Chung wrote: > This issue requires a spec change and it's a behavioral change. > Field::set on a static final field throws IAE.? Although there are few > cases in the world that hack around it, I think the compatibility risk > is low in this change. > > I added a suggested fix in the JBS issue. > > Mandy > > On 1/11/19 10:07 AM, Mandy Chung wrote: >> Hi Adam, >> >> This is indeed a bug.??? I suggest to do the check in the checkAccess >> method closes to where it performs the instance final field check. >> Please also add a test case. >> >> Mandy >> >> On 1/11/19 6:38 AM, Adam Farley8 wrote: >>> Hi All, >>> >>> First; thanks for responding so quickly. :) >>> >>> Second, it sounds like changing the contents of a final field is >>> acceptable under the spec, but *not* changing the contents of a static >>> final field. >>> >>> The test case uploaded to the bug uses a static final field for the >>> test, >>> so I think we can agree that the ability to create a setter for a static >>> final field is still a bug. >>> >>> It sounds like the same fix could work if we check for "static" when we >>> check for "final", with a modified message. >>> >>> As Field.set (post-setAccessible) fails to set the value of a static >>> final >>> field, I think we can agree that unreflectSetter should fail to create a >>> setter MethodHandle for this same field. >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> > From mandy.chung at oracle.com Fri Jan 11 22:38:26 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2019 14:38:26 -0800 Subject: RFR 8216401 : Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <20fe33cd-74b6-bdd1-7b2c-6c0a5ce23e2c@oracle.com> References: <20fe33cd-74b6-bdd1-7b2c-6c0a5ce23e2c@oracle.com> Message-ID: <1614cecc-a8f5-4ab4-5327-726b25fc34a3@oracle.com> On 1/11/19 10:35 AM, Brent Christian wrote: > Hi, > > Please review my change for 8216401[1]. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8216401/webrev-01/ > This looks fine to me. Mandy From mandy.chung at oracle.com Fri Jan 11 22:47:29 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2019 14:47:29 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> Message-ID: On 1/11/19 2:38 PM, David Holmes wrote: > There seem to be a number of spec issues around this. Shouldn't > findStaticSetter say something about what happens when the field is > final? Same for findSetter? This issue seems to be much bigger than > just a simple bug fix. > I don't see any issue with the spec for findSetter and findStaticSetter.? findSetter returns a method handle equivalent to `putField` bytecode and it throws IAE when access checking is performed since it's final and not writeable.? Similiarly for findStaticSetter. > A CSR request will need to be filed. > Of course, as this is a spec change. Mandy > David > ----- > > On 12/01/2019 5:07 am, Mandy Chung wrote: >> This issue requires a spec change and it's a behavioral change. >> Field::set on a static final field throws IAE.? Although there are >> few cases in the world that hack around it, I think the compatibility >> risk is low in this change. >> >> I added a suggested fix in the JBS issue. >> >> Mandy >> >> On 1/11/19 10:07 AM, Mandy Chung wrote: >>> Hi Adam, >>> >>> This is indeed a bug.??? I suggest to do the check in the >>> checkAccess method closes to where it performs the instance final >>> field check. Please also add a test case. >>> >>> Mandy >>> >>> On 1/11/19 6:38 AM, Adam Farley8 wrote: >>>> Hi All, >>>> >>>> First; thanks for responding so quickly. :) >>>> >>>> Second, it sounds like changing the contents of a final field is >>>> acceptable under the spec, but *not* changing the contents of a static >>>> final field. >>>> >>>> The test case uploaded to the bug uses a static final field for the >>>> test, >>>> so I think we can agree that the ability to create a setter for a >>>> static >>>> final field is still a bug. >>>> >>>> It sounds like the same fix could work if we check for "static" >>>> when we >>>> check for "final", with a modified message. >>>> >>>> As Field.set (post-setAccessible) fails to set the value of a >>>> static final >>>> field, I think we can agree that unreflectSetter should fail to >>>> create a >>>> setter MethodHandle for this same field. >>>> >>>> Best Regards >>>> >>>> Adam Farley >>>> IBM Runtimes >>>> >> From david.holmes at oracle.com Fri Jan 11 22:52:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 08:52:35 +1000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> Message-ID: Hi Roger, On 12/01/2019 2:22 am, Roger Riggs wrote: > Hi, > > The proposed patch changes the test in a way that is unintended. > > Adding the infinite loop of gc() and sleep, will change the timeout > behavior > from the existing timeout of TIMEOUT to the jtreg default timeout of the > whole test. Partially true. If the new loop gets stuck then yes the jtreg default timeout will apply - I don't see that is necessarily a bad thing. The existing timeout only applies to the refQueue.remove operation itself, you don't know how much time was spent before you got there, nor how much will be spent after in the dumpThreads() calls - so the jtreg timeout can still come into affect. > Further, it renders the check at lines 114-120 irrelevant since > loaderRef.get() > will have returned null and the ref will have been enqueued by then. I wouldn't say irrelevant as it double-checks the interaction between the ref.get() and the queue.remove() - the result of one should imply the result of the other, but if enqueuing had a bug .... > While it is true that calling gc() only once is unreliable, a better fix > is to > put the code from 108-120 in a loop with a fixed number of durations That would also work - say 5 loops and reduce TIMEOUT to 4000. > and add Reachability.reachabilityFence(loaderRef) to ensure the ref is > not ignored. Adding ReachabilityFence, alone, may solve the observed problem given one gc() seems to be working in practice (and because we don't actually have the leaked loaders anymore because those threads (sun.misc.GC threads) don't exist anymore). Cheers, David > Regards, Roger > > > On 01/11/2019 12:07 AM, Jie Fu wrote: >> Hi David, >> >> Thank you very much. I'd like to choose option 2. >> A test case is more valuable if it can be used for both interpreter >> and JIT tests. >> >> Here is the patch based on your comments. >> ---------------------------------------------------------------------------------- >> >> diff -r 02e648ae46c3 >> test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> >> --- >> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> Wed Jan 09 01:06:19 2019 +0100 >> +++ >> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> Fri Jan 11 12:55:38 2019 +0800 >> @@ -22,7 +22,7 @@ >> ? */ >> >> ?/* @test >> - * @bug 4404702 >> + * @bug 4404702 8216528 >> ? * @summary When the RMI runtime (lazily) spawns system threads that >> could >> ? * outlive the application context in which they were (happened to be) >> ? * created, such threads should not inherit (thread local) data >> specific to >> @@ -106,7 +106,10 @@ >> ????????????? * context class loader-- by giving it a chance to pass >> away. >> ????????????? */ >> ???????????? Thread.sleep(2000); >> -??????????? System.gc(); >> +??????????? while (loaderRef.get() != null) { >> +??????????????? System.gc(); >> +??????????????? Thread.sleep(100); >> +??????????? } >> >> ???????????? System.err.println( >> ???????????????? "waiting to be notified of loader being weakly >> reachable..."); >> ---------------------------------------------------------------------------------- >> >> >> Could you please review it and give me some advice? >> Thanks. >> >> Best regards, >> Jie >> >> >> On 2019/1/11 ??12:16, David Holmes wrote: >>> >>> I see three choices for you here :) >>> >>> 1. Don't try to run all tests under Xcomp but just stick to the >>> "core" sets of tests already tested by others. >>> >>> 2. Fix the given test as outlined. (I tested it on linux-x64 and it >>> fixed the problem.) >>> >>> 3. Exclude the given test from Xcomp by adding: @requires vm.compMode >>> != "Xcomp" >>> >>> If you chose options 2 or 3 please update the @bug line with 8216528. >>> >>> The core-libs folk may have more to say here and they will need to >>> provide a sponsor for the commit. >>> >>> Thanks, >>> David >>> ----- >> > From david.holmes at oracle.com Fri Jan 11 23:03:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 09:03:45 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> Message-ID: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> On 12/01/2019 8:47 am, Mandy Chung wrote: > On 1/11/19 2:38 PM, David Holmes wrote: >> There seem to be a number of spec issues around this. Shouldn't >> findStaticSetter say something about what happens when the field is >> final? Same for findSetter? This issue seems to be much bigger than >> just a simple bug fix. >> > > I don't see any issue with the spec for findSetter and > findStaticSetter.? findSetter returns a method handle equivalent to > `putField` bytecode and it throws IAE when access checking is performed > since it's final and not writeable.? Similiarly for findStaticSetter. Well that is what it does, but it doesn't explicitly mention final fields and the @throws information for IAE: IllegalAccessException - if access checking fails, or if the field is static doesn't convey anything about getting IAE for a final field. Perhaps it is implicit in the "this behaves like bytecode" but it is very obscure. >> 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? If these methods produce MH that obey bytecode semantics then the fact the Field had setAccessible(true) called on it is not relevant - the JVMS knows nothing about setAccessible. The only issue I see is the implementation not throwing IAE when the Field represents a final field, because it examines the "accessibility" state. (And that should apply whether the field is static or not.) David ----- > Mandy > >> David >> ----- >> >> On 12/01/2019 5:07 am, Mandy Chung wrote: >>> This issue requires a spec change and it's a behavioral change. >>> Field::set on a static final field throws IAE.? Although there are >>> few cases in the world that hack around it, I think the compatibility >>> risk is low in this change. >>> >>> I added a suggested fix in the JBS issue. >>> >>> Mandy >>> >>> On 1/11/19 10:07 AM, Mandy Chung wrote: >>>> Hi Adam, >>>> >>>> This is indeed a bug.??? I suggest to do the check in the >>>> checkAccess method closes to where it performs the instance final >>>> field check. Please also add a test case. >>>> >>>> Mandy >>>> >>>> On 1/11/19 6:38 AM, Adam Farley8 wrote: >>>>> Hi All, >>>>> >>>>> First; thanks for responding so quickly. :) >>>>> >>>>> Second, it sounds like changing the contents of a final field is >>>>> acceptable under the spec, but *not* changing the contents of a static >>>>> final field. >>>>> >>>>> The test case uploaded to the bug uses a static final field for the >>>>> test, >>>>> so I think we can agree that the ability to create a setter for a >>>>> static >>>>> final field is still a bug. >>>>> >>>>> It sounds like the same fix could work if we check for "static" >>>>> when we >>>>> check for "final", with a modified message. >>>>> >>>>> As Field.set (post-setAccessible) fails to set the value of a >>>>> static final >>>>> field, I think we can agree that unreflectSetter should fail to >>>>> create a >>>>> setter MethodHandle for this same field. >>>>> >>>>> Best Regards >>>>> >>>>> Adam Farley >>>>> IBM Runtimes >>>>> >>> > From david.holmes at oracle.com Fri Jan 11 23:08:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 09:08:11 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> Message-ID: <9056ac10-b718-25dc-8d8a-9835cd1c0c4c@oracle.com> On 11/01/2019 11:11 pm, Remi Forax wrote: > > > ----- Mail original ----- >> De: "David Holmes" >> ?: "Adam Farley8" , "core-libs-dev" >> Envoy?: Vendredi 11 Janvier 2019 14:02:06 >> Objet: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields > >> On 11/01/2019 10:46 pm, Adam Farley8 wrote: >>> Hi All, >>> >>> I posit that you shouldn't be able to change the contents of a a final >>> field. >> >> Nice in theory, but not true in practice. >> >>> However, if you use Field.setAccessible(true) before calling >>> Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows >>> you to set the (reflected) value of a static final field. >>> >>> This seems wrong to me, so here's a change to fix it. >> >> See: >> >> https://docs.oracle.com/javase/10/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,java.lang.Object) >> >> "If the underlying field is final, the method throws an >> IllegalAccessException unless setAccessible(true) has succeeded for this >> Field object and the field is non-static. Setting a final field in this >> way is meaningful only during deserialization or reconstruction of >> instances of classes with blank final fields, before they are made >> available for access by other parts of a program. Use in any other >> context may have unpredictable effects, including cases in which other >> parts of a program continue to use the original value of this field. " >> >> the same semantics are supported by MH/VH. > > No VH doesn't support setAccessible (don't ask me why) ... I must correct myself. Of course MH and VH should not support setAccessible. MH and VH represent bytecode semantics and bytecode knows nothing about setAccessible. That said bytecode semantics for final fields are tricky if strictly followed, as we should allow MH/VH to set a final field if called from the / of the target class - as that is what putfield/putstatic would do. David ----- > >> >> But note this requires the field to be non-static - if you can set a >> static final field this way then that may be a bug (they can still be >> set via native methods of course). >> >> David > > R?mi > >> ----- >> >>> webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8216558 >>> >>> Opinions invited. >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mandy.chung at oracle.com Sat Jan 12 00:13:31 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2019 16:13:31 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> Message-ID: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> On 1/11/19 3:03 PM, David Holmes wrote: > On 12/01/2019 8:47 am, Mandy Chung wrote: >> On 1/11/19 2:38 PM, David Holmes wrote: >>> There seem to be a number of spec issues around this. Shouldn't >>> findStaticSetter say something about what happens when the field is >>> final? Same for findSetter? This issue seems to be much bigger than >>> just a simple bug fix. >>> >> >> I don't see any issue with the spec for findSetter and >> findStaticSetter.? findSetter returns a method handle equivalent to >> `putField` bytecode and it throws IAE when access checking is >> performed since it's final and not writeable.? Similiarly for >> findStaticSetter. > > Well that is what it does, but it doesn't explicitly mention final > fields and the @throws information for IAE: > > ??? IllegalAccessException - if access checking fails, or if the field > is static > > doesn't convey anything about getting IAE for a final field. Perhaps > it is implicit in the "this behaves like bytecode" but it is very > obscure. > I assume you agree that there is no spec issue w.r.t. findSetter or findStaticSetter while you may find it obscure. >>> 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? I expect Adam will send a revised webrev to include the proposed spec change. > If these methods produce MH that obey bytecode semantics then the fact > the Field had setAccessible(true) called on it is not relevant - the > JVMS knows nothing about setAccessible. The only issue I see is the > implementation not throwing IAE when the Field represents a final > field, because it examines the "accessibility" state. (And that should > apply whether the field is static or not.) This is the current implementation matching the specification: ??? If the field's accessible flag is not set, access checking is performed immediately on behalf of the lookup class. I think it's intended to match Field::setAccessible behavior but Field::setAccessible has no effect in suppressing the language access check in static final field.? Hence I agree with Adam's fix changes that the access check should be performed for static final field even its accessible flag is set. Mandy From fujie at loongson.cn Sat Jan 12 00:25:13 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 12 Jan 2019 08:25:13 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> Message-ID: Thanks David and Roger. On 2019?01?12? 06:52, David Holmes wrote: > Hi Roger, > > On 12/01/2019 2:22 am, Roger Riggs wrote: >> Hi, >> >> The proposed patch changes the test in a way that is unintended. >> >> Adding the infinite loop of gc() and sleep, will change the timeout >> behavior >> from the existing timeout of TIMEOUT to the jtreg default timeout of >> the whole test. > > Partially true. If the new loop gets stuck then yes the jtreg default > timeout will apply - I don't see that is necessarily a bad thing. The > existing timeout only applies to the refQueue.remove operation itself, > you don't know how much time was spent before you got there, nor how > much will be spent after in the dumpThreads() calls - so the jtreg > timeout can still come into affect. > >> Further, it renders the check at lines 114-120 irrelevant since >> loaderRef.get() >> will have returned null and the ref will have been enqueued by then. > > I wouldn't say irrelevant as it double-checks the interaction between > the ref.get() and the queue.remove() - the result of one should imply > the result of the other, but if enqueuing had a bug .... > >> While it is true that calling gc() only once is unreliable, a better >> fix is to >> put the code from 108-120 in a loop with a fixed number of durations > > That would also work - say 5 loops and reduce TIMEOUT to 4000. > >> and add Reachability.reachabilityFence(loaderRef) to ensure the ref >> is not ignored. > > Adding ReachabilityFence, alone, may solve the observed problem given > one gc() seems to be working in practice (and because we don't > actually have the leaked loaders anymore because those threads > (sun.misc.GC threads) don't exist anymore). > > Cheers, > David > >> Regards, Roger From david.holmes at oracle.com Sat Jan 12 00:53:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 10:53:54 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> Message-ID: <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> On 12/01/2019 10:13 am, Mandy Chung wrote: > On 1/11/19 3:03 PM, David Holmes wrote: >> On 12/01/2019 8:47 am, Mandy Chung wrote: >>> On 1/11/19 2:38 PM, David Holmes wrote: >>>> There seem to be a number of spec issues around this. Shouldn't >>>> findStaticSetter say something about what happens when the field is >>>> final? Same for findSetter? This issue seems to be much bigger than >>>> just a simple bug fix. >>>> >>> >>> I don't see any issue with the spec for findSetter and >>> findStaticSetter.? findSetter returns a method handle equivalent to >>> `putField` bytecode and it throws IAE when access checking is >>> performed since it's final and not writeable.? Similiarly for >>> findStaticSetter. >> >> Well that is what it does, but it doesn't explicitly mention final >> fields and the @throws information for IAE: >> >> ??? IllegalAccessException - if access checking fails, or if the field >> is static >> >> doesn't convey anything about getting IAE for a final field. Perhaps >> it is implicit in the "this behaves like bytecode" but it is very >> obscure. >> > > I assume you agree that there is no spec issue w.r.t. findSetter or > findStaticSetter while you may find it obscure. I think the implicit reliance on bytecode behaviour is a problem when it involves final fields - see 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? > > I expect Adam will send a revised webrev to include the proposed spec > change. >> If these methods produce MH that obey bytecode semantics then the fact >> the Field had setAccessible(true) called on it is not relevant - the >> JVMS knows nothing about setAccessible. The only issue I see is the >> implementation not throwing IAE when the Field represents a final >> field, because it examines the "accessibility" state. (And that should >> apply whether the field is static or not.) > > This is the current implementation matching the specification: > ??? If the field's accessible flag is not set, access checking is > performed immediately on behalf of the lookup class. > > I think it's intended to match Field::setAccessible behavior but > Field::setAccessible has no effect in suppressing the language access > check in static final field.? Hence I agree with Adam's fix changes that > the access check should be performed for static final field even its > accessible flag is set. 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 bytecode does not know about setAccessible and final fields. I can see an argument to be made for the case where setAccessible(true) has been called to disable language level access checks, and you want the MH to follow the same access rules. But that does not to me imply that the ability to write to a final field should be part of that. If that is intended then it needs to be very, very clearly spelt out. And as per my other email there is already a problem with the bytecode equivalence of MH semantics and final fields, because you can set final fields in or (though only once). I don't think MH captures that - nor can it. Which means we can't defer to bytecode semantics here but rather have to very clearly define how MH interact with final fields. David > Mandy From christoph.langer at sap.com Sat Jan 12 13:02:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 12 Jan 2019 13:02:17 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> Message-ID: <5d28b0715d2041ff892a3c44e024f120@sap.com> Hi Alan, as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 And here is an updated webrev for the change: http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/ I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be created. Please kindly review this. Thank you and best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 8. Januar 2019 09:27 > To: 'Alan Bateman' ; Volker Simonis > > Cc: nio-dev ; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Alan, Volker, > > thanks for bringing up these discussion points. I agree that we shall carefully > revisit that. > > First of all, I'd like to point out that PosixFileAttributeView::readAttributes > won't ever throw UOE with the proposed changes to zipfs. It should always > return an object of type PosixFileAttributes which will be an incarnation of > ZipFileSystem.Entry. > > The returned PosixFileAttributes(ZipFileSystem.Entry) object now > implements 3 additional methods: owner(), group() and permissions(). I can > see that UOE should only be thrown if something is not supported by an > implementation at all. So it perfectly fits to owner() and group() because this > is simply not implemented in zipfs (yet...). As for permissions, I then agree, > UOE probably isn't the right thing to do because permissions will now be > supported by zipfs. > Still, we need to distinguish between the case where no permission > information is present vs. an empty set of permissions that was explicitly > stored. You brought up IOException as an alternative. But I think this is not > really feasible for the following main reason: IOE is no RuntimeException, so > it has to be declared for a method when it is thrown. > PosixFileAttributes::permissions, however, does not declare IOE so far. And I > don't think we can/want to modify the PosixFileAttributes interface for the > sake of that zipfs implementation change. > > I think, we should look into using/returning null for "no permission > information present". > > With that, the point is: What happens if we pass null to another > PosixFileAttributeView::setPermissions implementation (or to > Files::setPosixFilePermissions, which ends up there). For zipfs, with the > proposed changeset, this would work perfectly fine. We translate the null > value into (int)-1 for the "posixPerms" field of "Entry" and will then not set > permission information in the zip file. But other places in the JDK that > implement PosixFileAttributeView need some rework. Those are: > src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix > src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile > AttributeViewImpl > > And we should amend the specs/doc for the following methods to define > the handling of the null value as a noop: > PosixFileAttributeView::setPermissions > PosixFileAttributes::permissions > Files::setPosixFilePermissions > Files::getPosixFilePermissions > > In the implementation I can see that we modify the aforementioned places > to handle null by translating it to (int)-1 in > UnixFileModeAttribute::toUnixMode and then using this value as noop in > 'setMode' resp. 'fchmod'. > > Do you think this is the right way to go? Should we maybe do the spec > update of the permission methods in a separate change? > > Best regards > Christoph > > > -----Original Message----- > > From: Alan Bateman > > Sent: Montag, 7. Januar 2019 21:46 > > To: Volker Simonis > > Cc: Langer, Christoph ; nio-dev > dev at openjdk.java.net>; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs > > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > > > On 07/01/2019 19:26, Volker Simonis wrote: > > > : > > > We considered this, but it is problematic because it is perfectly > > > valid to have a file with external file attributes where none of the > > > Posix attributes is actually set (i.e. an empty set of Posix files > > > attributes). This wouldn't be distinguishable from the case where a > > > file has no external file attributes. So it seems we have to resort to > > > throwing an IOE? > > > > > Maybe although it would be a bit awkward to deal with. The issues around > > this remind me a bit about mounting fat32 file systems on Linux or Unix > > systems where the fields in the stat structure are populated with > > default values. PosixFileAttributeView::readAttributes is? essentially > > the equivalent of a stat call. This might be something to look at for > > the file owner at least. > > > > -Alan From lance.andersen at oracle.com Sat Jan 12 14:00:49 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 12 Jan 2019 09:00:49 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <83AAC895-7B27-4874-B9A8-F08C89962F53@oracle.com> Hi Christoph > On Jan 12, 2019, at 8:02 AM, Langer, Christoph wrote: > > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > And here is an updated webrev for the change: http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/ > > I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be > created. I think the above should be addressed via JDK-8182117 which I will be addressing and keep this focused on the POSIX file permission enhancements as I think it should be in its own CSR. Best Lance > > Please kindly review this. > > Thank you and best regards > Christoph > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Dienstag, 8. Januar 2019 09:27 >> To: 'Alan Bateman' ; Volker Simonis >> >> Cc: nio-dev ; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs >> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions >> >> Hi Alan, Volker, >> >> thanks for bringing up these discussion points. I agree that we shall carefully >> revisit that. >> >> First of all, I'd like to point out that PosixFileAttributeView::readAttributes >> won't ever throw UOE with the proposed changes to zipfs. It should always >> return an object of type PosixFileAttributes which will be an incarnation of >> ZipFileSystem.Entry. >> >> The returned PosixFileAttributes(ZipFileSystem.Entry) object now >> implements 3 additional methods: owner(), group() and permissions(). I can >> see that UOE should only be thrown if something is not supported by an >> implementation at all. So it perfectly fits to owner() and group() because this >> is simply not implemented in zipfs (yet...). As for permissions, I then agree, >> UOE probably isn't the right thing to do because permissions will now be >> supported by zipfs. >> Still, we need to distinguish between the case where no permission >> information is present vs. an empty set of permissions that was explicitly >> stored. You brought up IOException as an alternative. But I think this is not >> really feasible for the following main reason: IOE is no RuntimeException, so >> it has to be declared for a method when it is thrown. >> PosixFileAttributes::permissions, however, does not declare IOE so far. And I >> don't think we can/want to modify the PosixFileAttributes interface for the >> sake of that zipfs implementation change. >> >> I think, we should look into using/returning null for "no permission >> information present". >> >> With that, the point is: What happens if we pass null to another >> PosixFileAttributeView::setPermissions implementation (or to >> Files::setPosixFilePermissions, which ends up there). For zipfs, with the >> proposed changeset, this would work perfectly fine. We translate the null >> value into (int)-1 for the "posixPerms" field of "Entry" and will then not set >> permission information in the zip file. But other places in the JDK that >> implement PosixFileAttributeView need some rework. Those are: >> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix >> src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile >> AttributeViewImpl >> >> And we should amend the specs/doc for the following methods to define >> the handling of the null value as a noop: >> PosixFileAttributeView::setPermissions >> PosixFileAttributes::permissions >> Files::setPosixFilePermissions >> Files::getPosixFilePermissions >> >> In the implementation I can see that we modify the aforementioned places >> to handle null by translating it to (int)-1 in >> UnixFileModeAttribute::toUnixMode and then using this value as noop in >> 'setMode' resp. 'fchmod'. >> >> Do you think this is the right way to go? Should we maybe do the spec >> update of the permission methods in a separate change? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Montag, 7. Januar 2019 21:46 >>> To: Volker Simonis >>> Cc: Langer, Christoph ; nio-dev >> dev at openjdk.java.net>; OpenJDK Dev list >> dev at openjdk.java.net>; Java Core Libs >>> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions >>> >>> On 07/01/2019 19:26, Volker Simonis wrote: >>>> : >>>> We considered this, but it is problematic because it is perfectly >>>> valid to have a file with external file attributes where none of the >>>> Posix attributes is actually set (i.e. an empty set of Posix files >>>> attributes). This wouldn't be distinguishable from the case where a >>>> file has no external file attributes. So it seems we have to resort to >>>> throwing an IOE? >>>> >>> Maybe although it would be a bit awkward to deal with. The issues around >>> this remind me a bit about mounting fat32 file systems on Linux or Unix >>> systems where the fields in the stat structure are populated with >>> default values. PosixFileAttributeView::readAttributes is essentially >>> the equivalent of a stat call. This might be something to look at for >>> the file owner at least. >>> >>> -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Sat Jan 12 14:00:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Jan 2019 14:00:40 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> On 12/01/2019 13:02, Langer, Christoph wrote: > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I will try to get time next week to reply to you on this. Part of the issue with your current approach is that it breaks PosixFileAttribtues. There are also issues trying to force the API to optionally support a subset of POSIX attributes on some zip entries and not on others. So several issues that will need consideration. -Alan From lance.andersen at oracle.com Sat Jan 12 20:13:10 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 12 Jan 2019 15:13:10 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory Message-ID: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> 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 nio/file/DirectoryStream/Basic.java. Webrev can be found: http://cr.openjdk.java.net/~lancea/8211919/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From vladimir.kozlov at oracle.com Sun Jan 13 02:46:57 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 12 Jan 2019 18:46:57 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug Message-ID: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> 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 CheckAccessClassInPackagePermissions.java test. -- Thanks, Vladimir From Alan.Bateman at oracle.com Sun Jan 13 10:07:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2019 10:07:27 +0000 Subject: RFR 8216401 : Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <20fe33cd-74b6-bdd1-7b2c-6c0a5ce23e2c@oracle.com> References: <20fe33cd-74b6-bdd1-7b2c-6c0a5ce23e2c@oracle.com> Message-ID: On 11/01/2019 18:35, Brent Christian wrote: > Hi, > > Please review my change for 8216401[1]. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8216401/webrev-01/ > > The Class-Path section of the JAR spec[2] states that entries must be > relative URLs, however this hasn't been enforced for most of Java's > history.? There is now code to enforce this, though it is disabled by > default for compatibility. > > It has come to light that there are some widely-used libraries that > misuse the Class-Path attribute, by including absolute "file:" URL > entries.? In the interest of compatibility with this long-standing > behavior, "file:" entries in the Class-Path of JARs loaded from the > local disk should be allowed. > > This change will not affect the current default behavior, but > hopefully in the near future, the Class-Path enforcement code can be > enabled by default, and the change be reflected in the JAR spec[3]. The changes to URLClassPath look okay. When it comes to enabling the checking by default then we should do it as early as possible in a release to get as much testing as possible. We've seen this attribute been misused by tools that add it with a value of an absolute URLs or even file paths rather than URLs. It's possible these tools are inserting file paths with Windows drive letters that might fall foul of the checking. Also there might be cases where there is subtle redirects to HTTP servers to fetch dependences, something that should never have worked but there may be environments that depend on this broken behavior. -Alan From aoqi at loongson.cn Fri Jan 11 02:40:56 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 11 Jan 2019 10:40:56 +0800 Subject: [PATCH] test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failed in JITed code In-Reply-To: <8d344a69-d64d-9059-61f0-82e1516841b0@loongson.cn> References: <3b25822e-559c-35f9-6a03-1a2c782d517f@loongson.cn> <95131763-b234-51ca-fe21-81b208497abc@oracle.com> <85e07cf7-bee3-f364-4a52-9e91607f35e3@oracle.com> <8d344a69-d64d-9059-61f0-82e1516841b0@loongson.cn> Message-ID: Hi Fu Jie: I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528 Cheers, Ao Qi On Fri, Jan 11, 2019 at 10:22 AM Jie Fu wrote: > > Thanks David. > Hope more cases are suitable for both interpreter and JIT tests. > > > On 2019/1/11 ??10:13, David Holmes wrote: > > Hi Jie, > > > > On 11/01/2019 11:58 am, Jie Fu wrote: > >> Hi David, > >> > >> Thanks and apologies. > > > > No apology needed :) > > > >> This issue was discovered by a broad -Xcomp testing with jtreg on > >> Loongson CPUs (MIPS compatible processors). > >> It was intended to test our MIPS port of OpenJDK. > >> We've found and fixed quite a lot of JIT bugs for our MIPS > >> implementation by this approach. > > > > Okay, you may well be testing more tests under Xcomp than what we > > regularly do, so that may well expose a number of tests that may not > > work at all, or which fail intermittently. I'm trying to find out if > > there is a relatively easy way to enumerate the tests we do run under > > -Xcomp. > > > > Cheers, > > David > > > >> I'll ask Ao Qi to file a bug on JBS and post a webrev soon. > >> Thanks again. > >> > >> Best regards, > >> Jie > >> > >> > >>> For hotspot testing we have certain sets of tests that are run under > >>> -Xcomp, but this is obviously not one of them. Did you discover this > >>> by chance or because you are attempting to do broad -Xcomp testing? > >>> Not every test will work with Xcomp (for various reasons) and we > >>> aren't actively trying to make every test pass with Xcomp. > >>> > >>> But by all means file a bug and fix it. > >>> > >>> Cheers, > >>> David > >> From Alan.Bateman at oracle.com Sun Jan 13 19:50:51 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2019 19:50:51 +0000 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: References: Message-ID: <93e1de35-3117-d896-3290-ba7f04831a25@oracle.com> On 11/01/2019 19:41, Andy Herrick wrote: > This is the second update to the Request For Review of the > implementation of the Java Packager Tool (jpackager) as described in > JEP 343: Packaging Tool > You're making great progress. Is the table of CLI options in the JEP in sync with the this update? -Alan From andy.herrick at oracle.com Mon Jan 14 03:20:05 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 13 Jan 2019 19:20:05 -0800 (PST) Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: <93e1de35-3117-d896-3290-ba7f04831a25@oracle.com> References: <93e1de35-3117-d896-3290-ba7f04831a25@oracle.com> Message-ID: yes On 1/13/2019 2:50 PM, Alan Bateman wrote: > On 11/01/2019 19:41, Andy Herrick wrote: >> This is the second update to the Request For Review of the >> implementation of the Java Packager Tool (jpackager) as described in >> JEP 343: Packaging Tool >> > You're making great progress. Is the table of CLI options in the JEP > in sync with the this update? > > -Alan From christoph.langer at sap.com Mon Jan 14 07:52:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Jan 2019 07:52:46 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> Message-ID: Hi Alan, > I will try to get time next week to reply to you on this. Part of the > issue with your current approach is that it breaks PosixFileAttribtues. > There are also issues trying to force the API to optionally support a > subset of POSIX attributes on some zip entries and not on others. So > several issues that will need consideration. Thanks in advance for your work. Well, I can see that we could also support users/groups with zip files, which is also implemented in InfoZIP. Or we might add a Sub-Interface like PosixPermissionAttributes/PosixPermissionAttributesView. However, in any case, we have to find a way to deal with the optionality of any POSIX attributes in zip files. So, let's see what you come up with ?? /Christoph From Alan.Bateman at oracle.com Mon Jan 14 08:00:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 08:00:28 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <83AAC895-7B27-4874-B9A8-F08C89962F53@oracle.com> Message-ID: 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 for JDK-8182117. So, feel free to take > this over into your work. Seeing how things are going with this POSIX > permission topic, I?m sure you?ll be done with a patch for 8182117 > much earlier than me ??. > > The history on zipfs is that it started out as an example/demo provider to demonstrate the service provider mechanism. The implementation improved over time and also started to get some traction and users, e.g. with javac. So it "promoted" from a demo to a supported provider and has been maintained as such for a few releases. Prior to modules there wasn't anywhere to document it. In its example state we had a docs page that documents the "encoding" and "create" settings but that's not the right place now. So JDK-8182117 is just about expanding the javadoc in module-info.java from what used to be a separate document. I suspect it will also need a section showing how to create a file system from a URI or by opening a file as a file system. The POSIX file permissions is another matter of course as that ends up trying to use APIs in ways that they were not intended. APIs such as BasicFileAttributes allow for some optionally with custom providers that aren't support all features but PosixFileAttributes does not allow for this. I plan to find time this week to suggest some options to explore that would avoid trying to twist existing APIs in ways that they weren't intended. Once we converge on an approach then the module-info will be the right place to document how optionally permissions can be accessed. -Alan From tobias.hartmann at oracle.com Mon Jan 14 10:04:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Jan 2019 11:04:45 +0100 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: 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 done by > JDK-8199755: "Update Graal". > > Ran CheckAccessClassInPackagePermissions.java test. > From Alan.Bateman at oracle.com Mon Jan 14 10:27:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 10:27:23 +0000 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: 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 CheckAccessClassInPackagePermissions.java test. > cc'ing security-dev as that is where is the security policy file is maintained. One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of classes in the listed packages. I ask because the module definition doesn't export some of these packages to jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. -Alan From kustaa.nyholm at sparetimelabs.com Mon Jan 14 10:27:35 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Mon, 14 Jan 2019 12:27:35 +0200 Subject: jpackage custom resources not found Message-ID: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> 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 \ --add-modules java.base,java.desktop \ --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ --output . \ --name EazyCNC \ --main-jar EazyCNC.jar \ --class eazycnc.Main \ But I keep getting these messages: Using default package resource [icon] (add package/macosx/EazyCNC.icns to the class path to customize) Preparing Info.plist: /Users/nyholku/EazyCNC-Project/./EazyCNC.app/Contents/Info.plist Using default package resource [Application Info.plist] (add package/macosx/Info.plist to the class path to customize) Using default package resource [Java Runtime Info.plist] (add package/macosx/Runtime-Info.plist to the class path to customize) even though the resources exist (and worked with JDK8 javapackager): ls /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist wbr Kusti From andy.herrick at oracle.com Mon Jan 14 13:35:42 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 14 Jan 2019 08:35:42 -0500 Subject: jpackage custom resources not found In-Reply-To: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> Message-ID: 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 trying to use has changed twice (once from javafxpackager in JDK8 to jpackage in EA1 and again from EA1 to EA2). With the current EA2, you need to add option "--resource-dir '/Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx'" ( or use a patch relative to the current directory) to say where to load custom resources from. With the first EA you needed to put resources in "./package/macosx".? It was looking for custom resources in "package/" relative to the current working directory, not the input directory (as in javafxpackager) /Andy On 1/14/2019 5:27 AM, Kustaa Nyholm wrote: > 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 \ > --add-modules java.base,java.desktop \ > --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ > --output . \ > --name EazyCNC \ > --main-jar EazyCNC.jar \ > --class eazycnc.Main \ > > > But I keep getting these messages: > > Using default package resource [icon] (add package/macosx/EazyCNC.icns to the class path to customize) > Preparing Info.plist: /Users/nyholku/EazyCNC-Project/./EazyCNC.app/Contents/Info.plist > Using default package resource [Application Info.plist] (add package/macosx/Info.plist to the class path to customize) > Using default package resource [Java Runtime Info.plist] (add package/macosx/Runtime-Info.plist to the class path to customize) > > > even though the resources exist (and worked with JDK8 javapackager): > > ls /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist > /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist > > wbr Kusti > > > > From kustaa.nyholm at sparetimelabs.com Mon Jan 14 14:02:42 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Mon, 14 Jan 2019 16:02:42 +0200 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> Message-ID: 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: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/jpackage Reason: image not found so I copied that over from 13 -> 11 and now I get: Error occurred during initialization of boot layer java.lang.module.FindException: Module jdk.jpackage not found I tried to copy that over to 11/legal but that did not solve the problem, am I doomed to fail if I try to mix and match jpackage from 13 with my 11 installation? wbr Kusti > On 14 Jan 2019, at 15.35, Andy Herrick wrote: > > 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 trying to use has changed twice (once from javafxpackager in JDK8 to jpackage in EA1 and again from EA1 to EA2). > > With the current EA2, you need to add option "--resource-dir '/Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx'" > > ( or use a patch relative to the current directory) to say where to load custom resources from. > > With the first EA you needed to put resources in "./package/macosx". It was looking for custom resources in "package/" relative to the current working directory, not the input directory (as in javafxpackager) > > /Andy > > On 1/14/2019 5:27 AM, Kustaa Nyholm wrote: >> 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 \ >> --add-modules java.base,java.desktop \ >> --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ >> --output . \ >> --name EazyCNC \ >> --main-jar EazyCNC.jar \ >> --class eazycnc.Main \ >> >> >> But I keep getting these messages: >> >> Using default package resource [icon] (add package/macosx/EazyCNC.icns to the class path to customize) >> Preparing Info.plist: /Users/nyholku/EazyCNC-Project/./EazyCNC.app/Contents/Info.plist >> Using default package resource [Application Info.plist] (add package/macosx/Info.plist to the class path to customize) >> Using default package resource [Java Runtime Info.plist] (add package/macosx/Runtime-Info.plist to the class path to customize) >> >> >> even though the resources exist (and worked with JDK8 javapackager): >> >> ls /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >> /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >> >> wbr Kusti >> >> >> >> From magnus.ihse.bursie at oracle.com Mon Jan 14 14:02:20 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 Jan 2019 15:02:20 +0100 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> Message-ID: <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> 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 well.) /Magnus > >> I doubt if I could have permission to file the issue/bug report >> anywhere, could anyone kindly give a guidance? Thanks. > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8215976 > > to cover this and linked to the discussion threads. > > The appropriate owners still need to review this, but I'm not sure who > that may be these days. > > Cheers, > David > ----- > >> >> Regards >> Patrick >> >> -----Original Message----- >> From: core-libs-dev On >> Behalf Of Patrick Zhang >> Sent: Thursday, December 6, 2018 4:28 PM >> To: core-libs-dev at openjdk.java.net; David Holmes >> >> Cc: Florian Weimer >> Subject: RE: OpenJDK fails to build with GCC when the >> #include inside zip.cpp comes from a non-sysroot path >> >> To All, >> Who could help sponsor this simple patch (may require a wide range of >> building tests)? Thanks in advance. >> >> Regards >> Patrick >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, December 3, 2018 8:11 AM >> To: Patrick Zhang ; Florian Weimer >> >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: OpenJDK fails to build with GCC when the >> #include inside zip.cpp comes from a non-sysroot path >> >> Hi Patrick, >> >> On 30/11/2018 11:41 pm, Patrick Zhang wrote: >>> Thanks Florian, the "-isystem /usr/include" is helpful to my case, I >>> see gcc.gnu.org says that "it gets the same special treatment that >>> is applied to the standard system directories". As such the issue >>> gets hidden (error suppressed). >>> >>> Hi David, >>> Thanks for your suggestion. My intention was to limit the influence >>> range as far as I could since I don't have other systems except >>> CentOS/Fedora to verify (even just smoke test) all paths. >> >> You'd need some assistance testing a wider range of platforms but >> that can be arranged. >> >>> In addition, if we make below update, does it mean the macro " >>> _REENTRANT " can be removed too? This is probably the only place >>> where _REENTRANT gets used AFAIK. >> _REENTRANT is also examined by system headers. It's probably legacy >> but would require more investigation. >> >> Cheers, >> David >> >>> #ifdef _MSC_VER // Windows >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >>> >>> Regards >>> Patrick >>> >>> -----Original Message----- >>> From: Florian Weimer >>> Sent: Thursday, November 29, 2018 8:02 PM >>> To: David Holmes >>> Cc: Patrick Zhang ; >>> jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>> Subject: Re: OpenJDK fails to build with GCC when the #include >>> inside zip.cpp comes from a non-sysroot path >>> >>> * David Holmes: >>> >>>> This should really be being discussed on core-libs-dev. >>> >>> Okay, moving the conversation. >>> >>>>> diff -r 70a423caee44 >>>>> src/share/native/com/sun/java/util/jar/pack/zip.cpp >>>>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct >>>>> 09 08:33:33 2018 +0100 >>>>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov >>>>> 28 22:13:12 2018 -0500 >>>>> @@ -415,9 +415,7 @@ >>>>> ??????? ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>>>> ??? } >>>>> ??? -#ifdef _REENTRANT // solaris >>>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>>>> +#if !defined(_REENTRANT) // linux >>>>> ??? #define gmtime_r(t, s) gmtime(t) >>>>> ??? #endif >>>>> ??? /* >>>> >>>> Under the theme "two wrongs don't make a right" the use of _REENTRANT >>>> here is totally inappropriate AFAICS. It seems to be a misguided >>>> attempt at determining whether we need the thread-safe gmtime_r or >>>> not >>>> - and the answer to that should always be yes IMHO. >>>> >>>> We define _REENTRANT for: >>>> - linux >>>> - gcc >>>> - xlc >>>> >>>> So the original code will define: >>>> >>>> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >>>> >>>> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >>>> >>>> But Solaris has gmtime_r anyway. So the existing code seems a really >>>> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >>>> (where gmtime is already thread-safe). So it seems to me that all we >>>> should need here is: >>>> >>>> -#ifdef _REENTRANT // solaris >>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>>> +#ifdef _MSC_VER // Windows >>>> ?? #define gmtime_r(t, s) gmtime(t) >>>> ?? #endif >>> >>> That looks much cleaner. >>> >>> Thanks, >>> Florian >>> From christoph.langer at sap.com Mon Jan 14 14:13:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Jan 2019 14:13:50 +0000 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> Message-ID: 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 chance to improve the text of the comment ? // (1) assume all path from zip file itself is "normalized" -> (1) assume each path from zip file is "normalized" line 432: I think the word "also" can be removed src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java: line 95: Could you please also fix the indentation of @Override (4 instead of 3 spaces) test/jdk/jdk/nio/zipfs/Basic.java: line 45: I think you should remove 8211385 from the @bug tag, since you removed the DirectoryStream tests from this file test/jdk/jdk/nio/zipfs/ZipFsDirectoryStreamTests.java I think you should add a @bug tag for both, 8211385 and 8211919 line 53: UNZIPFS_MAP: not needed line 70: ; not needed in try statement line 72: jarFile should be createad outside of try block line 97: spelling: "filter" line 106: space before + missing line 144: ";" is not needed and bracket of try could be closed on this line line 170: Spelling: use "a" instead of "an" ? line 187: "an" instead of "a" ? line 205: same ("an" instead of "a") line 215: the assert for IllegalStateException could be dropped here, as it is a superclass of ClosedDirectoryStreamException which is asserted in line 219? Unless you want to use this as a test for ClosedDirectoryStreamException class hierarchy... line 238: I think this commented debug code should be removed. line 306: Looks like the matcher instance is not needed line 309: you could use an import java.util.zip.ZipException? line 314: The check should rather be: if (ds.iterator().hasNext()) throw... Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Samstag, 12. Januar 2019 21:13 > To: core-libs-dev ; nio-dev dev at openjdk.java.net> > Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths > that are relative to the directory > > 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 nio/file/DirectoryStream/Basic.java. > > Webrev can be found: > http://cr.openjdk.java.net/~lancea/8211919/webrev.00/ > > Best > Lance > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From andy.herrick at oracle.com Mon Jan 14 14:34:50 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 14 Jan 2019 09:34:50 -0500 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> Message-ID: <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> 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: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/jpackage > Reason: image not found > > so I copied that over from 13 -> 11 and now I get: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module jdk.jpackage not found > > I tried to copy that over to 11/legal but that did not solve the problem, > am I doomed to fail if I try to mix and match jpackage from 13 with my 11 installation? yes, like other jdk tools, jpackage is dependent on the java it is shipped with. You need to restore /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/ to it's original state and run jpackage from jdk-13.internal with the option: "--runtime-image /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/" that way you can use jpackage from JDK-13 to package an app with JDK-11.0.1. I also noticed you used modular option "--add-modules java.base,java.desktop" with (possibly) a non-modular app.? Unless EazyCNC.jar is a modular jar, this may be ignored and the app will be bundled with the entire contents of JDK-11.0.1. you can avoid that by running jlink first, and creating a minimal jdk-11.0.1 runtime image for your app, or by building EazyCNC.jar as a modular app (or as a modular jar which you may have already done for all I know) > set -v > rm -rf output/EazyCNC min11 > > /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/jlink > --add-modules java.base,java.desktop --output min11 > > ${JDK13_HOME}/jpackage create-image \ > --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ > --output output \ > --name EazyCNC \ > --main-jar EazyCNC.jar \ > --class eazycnc.Main \ > --runtime-image min11 \ > --build-root build-jpackager \ > --verbose \ /Andy > > wbr Kusti > > > >> On 14 Jan 2019, at 15.35, Andy Herrick wrote: >> >> 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 trying to use has changed twice (once from javafxpackager in JDK8 to jpackage in EA1 and again from EA1 to EA2). >> >> With the current EA2, you need to add option "--resource-dir '/Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx'" >> >> ( or use a patch relative to the current directory) to say where to load custom resources from. >> >> With the first EA you needed to put resources in "./package/macosx". It was looking for custom resources in "package/" relative to the current working directory, not the input directory (as in javafxpackager) >> >> /Andy >> >> On 1/14/2019 5:27 AM, Kustaa Nyholm wrote: >>> 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 \ >>> --add-modules java.base,java.desktop \ >>> --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ >>> --output . \ >>> --name EazyCNC \ >>> --main-jar EazyCNC.jar \ >>> --class eazycnc.Main \ >>> >>> >>> But I keep getting these messages: >>> >>> Using default package resource [icon] (add package/macosx/EazyCNC.icns to the class path to customize) >>> Preparing Info.plist: /Users/nyholku/EazyCNC-Project/./EazyCNC.app/Contents/Info.plist >>> Using default package resource [Application Info.plist] (add package/macosx/Info.plist to the class path to customize) >>> Using default package resource [Java Runtime Info.plist] (add package/macosx/Runtime-Info.plist to the class path to customize) >>> >>> >>> even though the resources exist (and worked with JDK8 javapackager): >>> >>> ls /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >>> /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >>> >>> wbr Kusti >>> >>> >>> >>> From stokito at gmail.com Mon Jan 14 14:57:50 2019 From: stokito at gmail.com (Sergey Ponomarev) Date: Mon, 14 Jan 2019 16:57:50 +0200 Subject: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int) In-Reply-To: References: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> Message-ID: 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 such intrinsic for the append(str, beginIndex, endIndex) and it gives a good tool to make performance improvements. But if even with the patch proposed by Sergey we'll get an improvement then I'll ask you to accept the patch even if it allocates an additional object. For those cases which you Tagir mentioned I'm pretty sure that performance will be anyway better than now. On Fri, 11 Jan 2019 at 17:06, Tagir Valeev wrote: > Hello! > > Your benchmark tests only one of many possible cases. What if string > contains non-latin1 characters? What if many strings are appended to the > same string builder? What if you append only one character from the long > string? Performance fixes in such widely used class could be introduced > only after investigating all possible use scenarios. Also not only cpu > time, but also memory allocations should be measured. > > With best regards, > Tagir Valeev. > > ??, 11 ???. 2019 ?., 2:35 ?????? ??????? sergei.tsypanov at yandex.ru: > > > Hi, > > > > while investigating an issue I've found out that performance of > expression > > (1) can be significantly improved by turning it into (2) > > > > > > > ---------------------------------------------------------------------------------------------------- > > > > //str is an instance of java.lang.String > > > > (1) return new StringBuilder().append(str, beginIndex, > > endIndex).toString(); > > > > ----> > > > > (2) String substring = str.substring(beginIndex, endIndex); > > > > return new StringBuilder().append(substring).toString(); > > > > > > > ---------------------------------------------------------------------------------------------------- > > > > Using benchmark [1] I've got the following results: > > > > Benchmark > > (length) Mode Cnt Score Error Units > > StringBuilderAppendBenchmark.appendBounds > > 10 avgt 20 21,161 ? 0,545 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 100 avgt 20 72,230 ? 3,452 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 1000 avgt 20 476,256 ? 12,044 ns/op > > > > StringBuilderAppendBenchmark.appendSubString > > 10 avgt 20 26,023 ? 0,871 ns/op > > StringBuilderAppendBenchmark.appendSubString > > 100 avgt 20 38,824 ? 1,185 ns/op > > StringBuilderAppendBenchmark.appendSubString > > 1000 avgt 20 214,072 ? 3,372 ns/op > > > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 10 avgt 20 80,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 100 avgt 20 320,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 1000 avgt 20 2120,001 ? 0,001 B/op > > > > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > > 10 avgt 20 96,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > > 100 avgt 20 192,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm > > 1000 avgt 20 1088,000 ? 0,001 B/op > > > > > > The reason for such a difference seems to be @HotSpotIntrinsicCandidate > > over StringBuilder.append(String), > > while StringBuilder.append(CharSerquence, int, int) copies chars/bytes > one > > by one. > > > > I've prepared a patch [2] and applied it to fresh sources of JDK 11. > > After rebuild the same benchmark demonstrated severe performance > > degradation: > > > > - before patch > > > > Benchmark > > (length) Mode Cnt Score Error Units > > StringBuilderAppendBenchmark.appendBounds > > 10 avgt 20 21,592 ? 0,763 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 100 avgt 20 72,241 ? 2,799 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 1000 avgt 20 488,106 ? 43,042 ns/op > > > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 10 avgt 20 80,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 100 avgt 20 320,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 1000 avgt 20 2132,001 ? 10,691 B/op > > > > - after patch > > > > Benchmark > > (length) Mode Cnt Score Error Units > > StringBuilderAppendBenchmark.appendBounds > > 10 avgt 20 40,186 ? 1,828 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 100 avgt 20 89,031 ? 6,664 ns/op > > StringBuilderAppendBenchmark.appendBounds > > 1000 avgt 20 669,934 ? 76,888 ns/op > > > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 10 avgt 20 152,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 100 avgt 20 440,000 ? 0,001 B/op > > StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm > > 1000 avgt 20 2688,001 ? 0,002 B/op > > > > As I see the reason of degradation is that patched code now dodges > > intrinsified StringBuilder.append(String) and calls directly > > AbstractStringBuilder.append(String) which in spite of utilizing > > System::arraycopy performes worse than intrinsic. > > > > So my question is should I rework the patch somehow to make it perform > > better or I need to apply the transformation mentioned above ad hoc? > > > > > > Appendix: > > > > 1) benchmark > > > > @BenchmarkMode(Mode.AverageTime) > > @OutputTimeUnit(TimeUnit.NANOSECONDS) > > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > > public class StringBuilderAppendBenchmark { > > > > @Benchmark > > @SuppressWarnings("StringBufferReplaceableByString") > > public String appendSubString(Data data) { > > String str = data.str; > > int beginIndex = data.beginIndex; > > int endIndex = data.endIndex; > > > > String substring = str.substring(beginIndex, endIndex); > > > > return new > > StringBuilder().append('L').append(substring).append(';').toString(); > > } > > > > @Benchmark > > public String appendBounds(Data data) { > > String str = data.str; > > int beginIndex = data.beginIndex; > > int endIndex = data.endIndex; > > > > return new StringBuilder().append('L').append(str, beginIndex, > > endIndex).append(';').toString(); > > } > > > > @State(Scope.Thread) > > public static class Data { > > String str; > > > > @Param({"10", "100", "1000"}) > > private int length; > > > > private int beginIndex; > > private int endIndex; > > > > @Setup > > public void setup() { > > str = randomString(); > > beginIndex = length / 4; > > endIndex = length / 4* 3; > > } > > > > private String randomString() { > > ThreadLocalRandom random = ThreadLocalRandom.current(); > > char[] chars = "abcdefghijklmnopqrstuvwxyz".toCharArray(); > > > > StringBuilder sb = new StringBuilder(length); > > for (int i = 0; i < length; i++) { > > char c = chars[random.nextInt(chars.length)]; > > sb.append(c); > > } > > return sb.toString(); > > } > > } > > > > } > > > > > > 2) patch > > > > diff --git > > a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > > b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > > --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > > +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > > @@ -626,10 +626,7 @@ > > s = "null"; > > } > > checkRange(start, end, s.length()); > > - int len = end - start; > > - ensureCapacityInternal(count + len); > > - appendChars(s, start, end); > > - return this; > > + return append(s.subSequence(start, end).toString()); > > } > > > > /** > > @@ -1686,27 +1683,6 @@ > > this.count = count + end - off; > > } > > > > - private final void appendChars(CharSequence s, int off, int end) { > > - if (isLatin1()) { > > - byte[] val = this.value; > > - for (int i = off, j = count; i < end; i++) { > > - char c = s.charAt(i); > > - if (StringLatin1.canEncode(c)) { > > - val[j++] = (byte)c; > > - } else { > > - count = j; > > - inflate(); > > - StringUTF16.putCharsSB(this.value, j, s, i, end); > > - count += end - i; > > - return; > > - } > > - } > > - } else { > > - StringUTF16.putCharsSB(this.value, count, s, off, end); > > - } > > - count += end - off; > > - } > > - > > /* IndexOutOfBoundsException, if out of bounds */ > > private static void checkRange(int start, int end, int len) { > > if (start < 0 || start > end || end > len) { > > > > > > > > > -- Sergey Ponomarev , skype:stokito From swpalmer at gmail.com Mon Jan 14 15:03:39 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 14 Jan 2019 10:03:39 -0500 Subject: Modular Applications - Regression In-Reply-To: <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> Message-ID: 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 dependency chain, including every transitive dependency, to be 100% modular? I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. Am I correct that this is the current state of things when trying to create a Java module? I feel I must be missing something because I?m not seeing the expected complaints over the app-breaking regression of the removed modules no longer being available as modules. Is it just that nobody is making modular apps yet? Regards, Scott > On Jan 14, 2019, at 9:34 AM, Andy Herrick wrote: > ? > you can avoid that by running jlink first, and creating a minimal jdk-11.0.1 runtime image for your app, or by building EazyCNC.jar as a modular app (or as a modular jar which you may have already done for all I know) From kustaa.nyholm at sparetimelabs.com Mon Jan 14 15:13:03 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Mon, 14 Jan 2019 17:13:03 +0200 Subject: Modular Applications - Regression In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> Message-ID: <80A0DA4A-DDA2-47E6-8B38-FB081A6339FF@sparetimelabs.com> 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 does not include the whole +200 MB JDK and still works. More over, first attempts complained about missing modules at runtime and started to work when those were specified in build time (my .app is now around 80MB) so I guess the modularity really works for my case and I've paid absolute no attention to making my own code/jar whatever modular. Just mentioning this as a point of reference. The reason I mention the all this experimenting is that possibly the jar of my code that I'm linking with has been somehow 'modularised' by some tool this chain of tools that I've been using. Or not. cheers Kusti > On 14 Jan 2019, at 17.03, Scott Palmer wrote: > > 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 dependency chain, including every transitive dependency, to be 100% modular? > > I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. > > Am I correct that this is the current state of things when trying to create a Java module? I feel I must be missing something because I?m not seeing the expected complaints over the app-breaking regression of the removed modules no longer being available as modules. Is it just that nobody is making modular apps yet? > > Regards, > > Scott > > >> On Jan 14, 2019, at 9:34 AM, Andy Herrick wrote: >> ? > >> you can avoid that by running jlink first, and creating a minimal jdk-11.0.1 runtime image for your app, or by building EazyCNC.jar as a modular app (or as a modular jar which you may have already done for all I know) > From Alan.Bateman at oracle.com Mon Jan 14 15:33:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 15:33:05 +0000 Subject: Modular Applications - Regression In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> Message-ID: 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 modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name. > > I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1]. -Alan [1] https://github.com/eclipse-ee4j/jaf/issues/13 From Roger.Riggs at oracle.com Mon Jan 14 15:48:37 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 14 Jan 2019 10:48:37 -0500 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> Message-ID: 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 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 well.) > > /Magnus > >> >>> I doubt if I could have permission to file the issue/bug report >>> anywhere, could anyone kindly give a guidance? Thanks. >> >> I have filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8215976 >> >> to cover this and linked to the discussion threads. >> >> The appropriate owners still need to review this, but I'm not sure >> who that may be these days. >> >> Cheers, >> David >> ----- >> >>> >>> Regards >>> Patrick >>> >>> -----Original Message----- >>> From: core-libs-dev On >>> Behalf Of Patrick Zhang >>> Sent: Thursday, December 6, 2018 4:28 PM >>> To: core-libs-dev at openjdk.java.net; David Holmes >>> >>> Cc: Florian Weimer >>> Subject: RE: OpenJDK fails to build with GCC when the >>> #include inside zip.cpp comes from a non-sysroot path >>> >>> To All, >>> Who could help sponsor this simple patch (may require a wide range >>> of building tests)? Thanks in advance. >>> >>> Regards >>> Patrick >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Monday, December 3, 2018 8:11 AM >>> To: Patrick Zhang ; Florian Weimer >>> >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: OpenJDK fails to build with GCC when the >>> #include inside zip.cpp comes from a non-sysroot path >>> >>> Hi Patrick, >>> >>> On 30/11/2018 11:41 pm, Patrick Zhang wrote: >>>> Thanks Florian, the "-isystem /usr/include" is helpful to my case, >>>> I see gcc.gnu.org says that "it gets the same special treatment >>>> that is applied to the standard system directories". As such the >>>> issue gets hidden (error suppressed). >>>> >>>> Hi David, >>>> Thanks for your suggestion. My intention was to limit the influence >>>> range as far as I could since I don't have other systems except >>>> CentOS/Fedora to verify (even just smoke test) all paths. >>> >>> You'd need some assistance testing a wider range of platforms but >>> that can be arranged. >>> >>>> In addition, if we make below update, does it mean the macro " >>>> _REENTRANT " can be removed too? This is probably the only place >>>> where _REENTRANT gets used AFAIK. >>> _REENTRANT is also examined by system headers. It's probably legacy >>> but would require more investigation. >>> >>> Cheers, >>> David >>> >>>> #ifdef _MSC_VER // Windows >>>> #define gmtime_r(t, s) gmtime(t) >>>> #endif >>>> >>>> Regards >>>> Patrick >>>> >>>> -----Original Message----- >>>> From: Florian Weimer >>>> Sent: Thursday, November 29, 2018 8:02 PM >>>> To: David Holmes >>>> Cc: Patrick Zhang ; >>>> jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>> Subject: Re: OpenJDK fails to build with GCC when the #include >>>> inside zip.cpp comes from a non-sysroot path >>>> >>>> * David Holmes: >>>> >>>>> This should really be being discussed on core-libs-dev. >>>> >>>> Okay, moving the conversation. >>>> >>>>>> diff -r 70a423caee44 >>>>>> src/share/native/com/sun/java/util/jar/pack/zip.cpp >>>>>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct >>>>>> 09 08:33:33 2018 +0100 >>>>>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov >>>>>> 28 22:13:12 2018 -0500 >>>>>> @@ -415,9 +415,7 @@ >>>>>> ??????? ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>>>>> ??? } >>>>>> ??? -#ifdef _REENTRANT // solaris >>>>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>>>>> +#if !defined(_REENTRANT) // linux >>>>>> ??? #define gmtime_r(t, s) gmtime(t) >>>>>> ??? #endif >>>>>> ??? /* >>>>> >>>>> Under the theme "two wrongs don't make a right" the use of _REENTRANT >>>>> here is totally inappropriate AFAICS. It seems to be a misguided >>>>> attempt at determining whether we need the thread-safe gmtime_r or >>>>> not >>>>> - and the answer to that should always be yes IMHO. >>>>> >>>>> We define _REENTRANT for: >>>>> - linux >>>>> - gcc >>>>> - xlc >>>>> >>>>> So the original code will define: >>>>> >>>>> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >>>>> >>>>> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >>>>> >>>>> But Solaris has gmtime_r anyway. So the existing code seems a really >>>>> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >>>>> (where gmtime is already thread-safe). So it seems to me that all we >>>>> should need here is: >>>>> >>>>> -#ifdef _REENTRANT // solaris >>>>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>>>> +#ifdef _MSC_VER // Windows >>>>> ?? #define gmtime_r(t, s) gmtime(t) >>>>> ?? #endif >>>> >>>> That looks much cleaner. >>>> >>>> Thanks, >>>> Florian >>>> > From swpalmer at gmail.com Mon Jan 14 16:14:21 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 14 Jan 2019 11:14:21 -0500 Subject: Modular Applications - Regression In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> Message-ID: <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> > 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 the module system facilitates top-down migration where you can migrate to modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name. Sorry, I?m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.) However, a workflow that will run perfectly fine with JDK 9 & 10 can?t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation). > >> >> I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. > The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1]. This issue breaks many cases where jlink used to work. This is why I refer to the current state of things as a regression. It?s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist. Even if you modularize your library or application - you can?t run jlink on it if the dependency chain ever leads to an automatic module. Therefore jpackage and jlink tools can?t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation. Somehow java.activation became un-modularized in the process of removing it from the JDK. So more to the point - very few application modules are suitable for jlink input. The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX). Even that can?t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation Is that correct? Scott > > -Alan > > [1] https://github.com/eclipse-ee4j/jaf/issues/13 From Roger.Riggs at oracle.com Mon Jan 14 16:56:48 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 14 Jan 2019 11:56:48 -0500 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" Message-ID: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> 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 in some cases the child does terminate with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. The Process implementation on Unix closes the streams after sending the SIGTERM signal and has since (forever...).? But this behavior is not documented. This test of destroy() is invalid and should be removed. Since both Mac OS and Windows already skip the testing of destroy() the test is simplified to remove it from all cases. A separate issue[2] has been created to consider documenting the Process implementations' closing of the streams. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8080569 [2] https://bugs.openjdk.java.net/browse/JDK-8216990 From vladimir.kozlov at oracle.com Mon Jan 14 17:06:42 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jan 2019 09:06:42 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: <138390b2-7542-619c-eef1-b775e5bb2064@oracle.com> 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 default.policy after changes in jdk.internal.vm.compiler.management files done by >> JDK-8199755: "Update Graal". >> >> Ran CheckAccessClassInPackagePermissions.java test. >> From adam.farley at uk.ibm.com Mon Jan 14 17:10:32 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 14 Jan 2019 17:10:32 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: 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 spec > > change. I've updated the webrev to include Mandy's MemberName.isStatic code, but I've kept the modifier analysis near the surface to avoid domino effects on other code. This way we can modify the setter method's output with minimal risk. As for the CSR process, I'm unfamiliar with it. I've modified the comment for the unreflectSetter method in the webrev. Do let me know if more needs to be done. > >> If these methods produce MH that obey bytecode semantics then the fact > >> the Field had setAccessible(true) called on it is not relevant - the > >> JVMS knows nothing about setAccessible. The only issue I see is the > >> implementation not throwing IAE when the Field represents a final > >> field, because it examines the "accessibility" state. (And that should > >> apply whether the field is static or not.) > > > > This is the current implementation matching the specification: > > If the field's accessible flag is not set, access checking is > > performed immediately on behalf of the lookup class. > > > > I think it's intended to match Field::setAccessible behavior but > > Field::setAccessible has no effect in suppressing the language access > > check in static final field. Hence I agree with Adam's fix changes that > > the access check should be performed for static final field even its > > accessible flag is set. > > 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 bytecode does not know about setAccessible and > final fields. I can see an argument to be made for the case where > setAccessible(true) has been called to disable language level access > checks, and you want the MH to follow the same access rules. But that > does not to me imply that the ability to write to a final field should > be part of that. If that is intended then it needs to be very, very > clearly spelt out. > > And as per my other email there is already a problem with the bytecode > equivalence of MH semantics and final fields, because you can set final > fields in or (though only once). I don't think MH > captures that - nor can it. Which means we can't defer to bytecode > semantics here but rather have to very clearly define how MH interact > with final fields. > > David > > > Mandy > Adam Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From vladimir.kozlov at oracle.com Mon Jan 14 17:39:10 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jan 2019 09:39:10 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: 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 by JDK-8199755: "Update >> Graal". >> >> Ran CheckAccessClassInPackagePermissions.java test. >> > cc'ing security-dev as that is where is the security policy file is maintained. > > One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of classes > in the listed packages. I ask because the module definition doesn't export some of these packages to > jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. I verified that all listed packages are used by compiler.management and I listed only needed in default.policy. I used CheckAccessClassInPackagePermissions.java test to find which permissions are needed. Thanks, Vladimir > > -Alan From mandy.chung at oracle.com Mon Jan 14 18:29:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Jan 2019 10:29:39 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: 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 >>> jdk.internal.vm.compiler.management files done by JDK-8199755: >>> "Update Graal". >>> >>> Ran CheckAccessClassInPackagePermissions.java test. >>> >> cc'ing security-dev as that is where is the security policy file is >> maintained. >> >> One thing is double check is that code in >> jdk.internal.vm.compiler.management really needs to access members of >> classes in the listed packages. I ask because the module definition >> doesn't export some of these packages to >> jdk.internal.vm.compiler.management so they aren't accessible even >> when not running with a security manager. > > I verified that all listed packages are used by compiler.management > and I listed only needed in default.policy. I used > CheckAccessClassInPackagePermissions.java test to find which > permissions are needed. > I reviewed the change and the list matches the list of qualified exports from jdk.internal.vm.compiler to jdk.internal.vm.compiler.management. The security team has been looking into removing the private VM call out to ClassLoader::checkPackageAccess.? When that's removed, we would not need to maintain these accessClassInPackage permission to access any new qualified exports. Mandy From vladimir.kozlov at oracle.com Mon Jan 14 18:31:07 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jan 2019 10:31:07 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: <2ad1f183-f3fd-eb0e-f56b-64c5746c6c08@oracle.com> 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/ >>>> 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 CheckAccessClassInPackagePermissions.java test. >>>> >>> cc'ing security-dev as that is where is the security policy file is maintained. >>> >>> One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of >>> classes in the listed packages. I ask because the module definition doesn't export some of these packages to >>> jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. >> >> I verified that all listed packages are used by compiler.management and I listed only needed in default.policy. I used >> CheckAccessClassInPackagePermissions.java test to find which permissions are needed. >> > > I reviewed the change and the list matches the list of qualified exports from jdk.internal.vm.compiler to > jdk.internal.vm.compiler.management. > > The security team has been looking into removing the private VM call out to ClassLoader::checkPackageAccess.? When > that's removed, we would not need to maintain these accessClassInPackage permission to access any new qualified exports. > > Mandy From lance.andersen at oracle.com Mon Jan 14 18:46:19 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 14 Jan 2019 13:46:19 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> Message-ID: 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 I discovered: > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java: > in the comments: > line 426: Maybe you could take the chance to improve the text of the comment ? > // (1) assume all path from zip file itself is "normalized" -> (1) assume each path from zip file is "normalized" > line 432: I think the word "also" can be removed > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java: > line 95: Could you please also fix the indentation of @Override (4 instead of 3 spaces) > done > test/jdk/jdk/nio/zipfs/Basic.java: > line 45: I think you should remove 8211385 from the @bug tag, since you removed the DirectoryStream tests from this file done > > test/jdk/jdk/nio/zipfs/ZipFsDirectoryStreamTests.java > I think you should add a @bug tag for both, 8211385 and 8211919 done > line 53: UNZIPFS_MAP: not needed I removed it though I had added it as I have some additional tests to add later which will need it. > line 70: ; not needed in try statement done (thought I got all of these earlier, guess not) > line 72: jarFile should be createad outside of try block Utils.createJarFile throws an IOException which is why it is there vs introducing a 2nd try block. > line 97: spelling: ?filter? fixed though was ?DirectoryStream.Filter? which I changed to DirectoryStream filter > line 106: space before + missing fixed > line 144: ";" is not needed and bracket of try could be closed on this line fixed > line 170: Spelling: use "a" instead of "an" ? > line 187: "an" instead of "a" ? > line 205: same ("an" instead of "a?) ?a? vs "an" is always fun, should be addressed. > line 215: the assert for IllegalStateException could be dropped here, as it is a superclass of ClosedDirectoryStreamException which is asserted in line 219? Unless you want to use this as a test for ClosedDirectoryStreamException class hierarchy? Well the spec expects IllegalStateException. ClosedDirectoryStreamException is thrown by ZipFS so I also included this for now as a sanity check in case someone was already catching this. I am happy to remove it though > line 238: I think this commented debug code should be removed. done, thought I did that earlier > line 306: Looks like the matcher instance is not needed true and removed > line 309: you could use an import java.util.zip.ZipException? done, still getting used to Intellij vs Netbeans which I like better for import handling > line 314: The check should rather be: if (ds.iterator().hasNext()) throw? The check is fine as it is but I changed it to make it clearer similar to DirectoryStream/Basic.java Again, thank you for your feedback. Updated webrev is here http://cr.openjdk.java.net/~lancea/8211919/webrev.01/index.html Best Lance > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Lance Andersen >> Sent: Samstag, 12. Januar 2019 21:13 >> To: core-libs-dev ; nio-dev > dev at openjdk.java.net> >> Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths >> that are relative to the directory >> >> 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 nio/file/DirectoryStream/Basic.java. >> >> Webrev can be found: >> http://cr.openjdk.java.net/~lancea/8211919/webrev.00/ >> >> Best >> Lance >> >> >> >> Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Mon Jan 14 18:48:16 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 14 Jan 2019 13:48:16 -0500 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" In-Reply-To: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> References: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> Message-ID: <6326626E-9270-43C5-B3A8-74AB12414011@oracle.com> 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 SIGTERM. The child is started and then sent SIGTERM. > The child should not terminate. However, there is a race in which in some cases the child does terminate > with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. > > The Process implementation on Unix closes the streams after sending the SIGTERM signal > and has since (forever...). But this behavior is not documented. > > This test of destroy() is invalid and should be removed. Since both Mac OS and Windows > already skip the testing of destroy() the test is simplified to remove it from all cases. > > A separate issue[2] has been created to consider documenting the > Process implementations' closing of the streams. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8080569 > [2] https://bugs.openjdk.java.net/browse/JDK-8216990 > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brent.christian at oracle.com Mon Jan 14 18:56:27 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 14 Jan 2019 10:56:27 -0800 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" In-Reply-To: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> References: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> Message-ID: 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 a boolean argument * the killProc() code could be moved into runTest() -Brent On 1/14/19 8: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 SIGTERM.? The child > is started and then sent SIGTERM. > The child should not terminate.? However, there is a race in which in > some cases the child does terminate > with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. > > The Process implementation on Unix closes the streams after sending the > SIGTERM signal > and has since (forever...).? But this behavior is not documented. > > This test of destroy() is invalid and should be removed. Since both Mac > OS and Windows > already skip the testing of destroy() the test is simplified to remove > it from all cases. > > A separate issue[2] has been created to consider documenting the > Process implementations' closing of the streams. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8080569 > [2] https://bugs.openjdk.java.net/browse/JDK-8216990 > From joe.darcy at oracle.com Mon Jan 14 19:04:12 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Jan 2019 11:04:12 -0800 Subject: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException In-Reply-To: <8175ebfe-2951-6c71-29ee-f09a6b4da4f3@oracle.com> References: <5e5ae7b3-af70-81d4-0bc1-c56fd2b20165@oracle.com> <8175ebfe-2951-6c71-29ee-f09a6b4da4f3@oracle.com> Message-ID: 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();}). >> +??? ??? ????? collect(Collectors.joining(","))); > > Since argTypes is an array, I usually prefer Arrays.stream() over > Stream.of(). The issue is that Stream.of() is varargs, and while this > case isn't formally ambiguous, it can create a question in the > reader's mind about whether the stream consists of the array elements > or of just one element that's the array itself. > > The statement lambda can probably be replaced with an expression > lambda. I think it makes the ternary easier to read. Also, indentation. > > ??? sb.append(Arrays.stream(argTypes) > ??????????????????? .map(c -> (c == null) ? "null" : c.getName()) > ??????????????????? .collect(Collectors.joining(","))); > > I'm not sure it's worth tracking this, but I could file a bug if you'd > like. Once JDK-8213299 hits the JDK 13 repo, I'd be open to doing a refactoring. I've filed JDK-8217000: Refactor Class::methodToString . Thanks, -Joe From Alan.Bateman at oracle.com Mon Jan 14 19:05:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 19:05:41 +0000 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> Message-ID: <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> 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 nio/file/DirectoryStream/Basic.java. > > Webrev can be found: http://cr.openjdk.java.net/~lancea/8211919/webrev.00/ > Lance -the relative path case looks right now but I think there are issues with the absolute path case. Try an example such as "/META-INF/../META-INF" to see what I mean. -Alan From ecki at zusammenkunft.net Mon Jan 14 19:37:07 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 14 Jan 2019 19:37:07 +0000 Subject: Modular Applications - Regression In-Reply-To: <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> , <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> Message-ID: 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, 2019 8:16 PM An: Alan Bateman Cc: core-libs-dev Betreff: 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 the module system facilitates top-down migration where you can migrate to modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name. Sorry, I?m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.) However, a workflow that will run perfectly fine with JDK 9 & 10 can?t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation). > >> >> I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. > The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1]. This issue breaks many cases where jlink used to work. This is why I refer to the current state of things as a regression. It?s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist. Even if you modularize your library or application - you can?t run jlink on it if the dependency chain ever leads to an automatic module. Therefore jpackage and jlink tools can?t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation. Somehow java.activation became un-modularized in the process of removing it from the JDK. So more to the point - very few application modules are suitable for jlink input. The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX). Even that can?t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation Is that correct? Scott > > -Alan > > [1] https://github.com/eclipse-ee4j/jaf/issues/13 From Roger.Riggs at oracle.com Mon Jan 14 20:05:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 14 Jan 2019 15:05:18 -0500 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" In-Reply-To: References: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> Message-ID: <393a04ae-3b7d-13c3-ca02-1fdd5105f154@oracle.com> 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 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 a boolean argument > ??? * the killProc() code could be moved into runTest() > > -Brent > > On 1/14/19 8: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 SIGTERM. The >> child is started and then sent SIGTERM. >> The child should not terminate.? However, there is a race in which in >> some cases the child does terminate >> with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. >> >> The Process implementation on Unix closes the streams after sending >> the SIGTERM signal >> and has since (forever...).? But this behavior is not documented. >> >> This test of destroy() is invalid and should be removed. Since both >> Mac OS and Windows >> already skip the testing of destroy() the test is simplified to >> remove it from all cases. >> >> A separate issue[2] has been created to consider documenting the >> Process implementations' closing of the streams. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8080569 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216990 >> From lance.andersen at oracle.com Mon Jan 14 20:18:22 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 14 Jan 2019 15:18:22 -0500 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" In-Reply-To: <393a04ae-3b7d-13c3-ca02-1fdd5105f154@oracle.com> References: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> <393a04ae-3b7d-13c3-ca02-1fdd5105f154@oracle.com> Message-ID: <6630C181-4FE8-49E6-BC0C-26D19969CBB9@oracle.com> 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, Brent Christian wrote: >> 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 a boolean argument >> * the killProc() code could be moved into runTest() >> >> -Brent >> >> On 1/14/19 8: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 SIGTERM. The child is started and then sent SIGTERM. >>> The child should not terminate. However, there is a race in which in some cases the child does terminate >>> with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. >>> >>> The Process implementation on Unix closes the streams after sending the SIGTERM signal >>> and has since (forever...). But this behavior is not documented. >>> >>> This test of destroy() is invalid and should be removed. Since both Mac OS and Windows >>> already skip the testing of destroy() the test is simplified to remove it from all cases. >>> >>> A separate issue[2] has been created to consider documenting the >>> Process implementations' closing of the streams. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ >>> >>> Thanks, Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8080569 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8216990 >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From swpalmer at gmail.com Mon Jan 14 20:21:40 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 14 Jan 2019 15:21:40 -0500 Subject: Modular Applications - Regression In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> Message-ID: <0755158B-6C23-47D3-882B-6D46A16FC5AA@gmail.com> 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 of the modules you need is JAXB or JAX-WS and you already had this working with Java 9 or 10, you have to make a lot of changes. You can?t build a JRE image with jlink that contains the new replacements for JAXB or JAX-WS. You can include JAXB or JAX-WS on the classpath, but you can?t go back to how it worked with JDK 9 & 10. Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, or java.activation modules can?t be made to work anymore without resorting to hacks like running jlink to pull the .jmod files for those modules from JDK 10 and the rest of the runtime from JDK 11. Scott > On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels wrote: > > 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, 2019 8:16 PM > An: Alan Bateman > Cc: core-libs-dev > Betreff: 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 the module system facilitates top-down migration where you can migrate to modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name. > > Sorry, I?m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.) However, a workflow that will run perfectly fine with JDK 9 & 10 can?t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation). > >> >>> >>> I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. >> The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1]. > > This issue breaks many cases where jlink used to work. This is why I refer to the current state of things as a regression. It?s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist. > > Even if you modularize your library or application - you can?t run jlink on it if the dependency chain ever leads to an automatic module. Therefore jpackage and jlink tools can?t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation. Somehow java.activation became un-modularized in the process of removing it from the JDK. > > So more to the point - very few application modules are suitable for jlink input. The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX). Even that can?t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation > > Is that correct? > > Scott > >> >> -Alan >> >> [1] https://github.com/eclipse-ee4j/jaf/issues/13 > From brent.christian at oracle.com Mon Jan 14 21:04:49 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 14 Jan 2019 13:04:49 -0800 Subject: RFR 8080569: (process) java/lang/ProcessBuilder/DestroyTest.java fails with "Process terminated prematurely" In-Reply-To: <393a04ae-3b7d-13c3-ca02-1fdd5105f154@oracle.com> References: <5c857994-bde3-59fc-49ec-ddc4631f71e4@oracle.com> <393a04ae-3b7d-13c3-ca02-1fdd5105f154@oracle.com> Message-ID: 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 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 a boolean argument >> ??? * the killProc() code could be moved into runTest() >> >> -Brent >> >> On 1/14/19 8: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 SIGTERM. The >>> child is started and then sent SIGTERM. >>> The child should not terminate.? However, there is a race in which in >>> some cases the child does terminate >>> with SIGPIPE (not SIGTERM) as a result of destroy() closing the streams. >>> >>> The Process implementation on Unix closes the streams after sending >>> the SIGTERM signal >>> and has since (forever...).? But this behavior is not documented. >>> >>> This test of destroy() is invalid and should be removed. Since both >>> Mac OS and Windows >>> already skip the testing of destroy() the test is simplified to >>> remove it from all cases. >>> >>> A separate issue[2] has been created to consider documenting the >>> Process implementations' closing of the streams. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-destroytest-8080569-2/ >>> >>> Thanks, Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8080569 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8216990 >>> > From ecki at zusammenkunft.net Mon Jan 14 21:11:02 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 14 Jan 2019 22:11:02 +0100 Subject: Modular Applications - Regression In-Reply-To: <0755158B-6C23-47D3-882B-6D46A16FC5AA@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> <0755158B-6C23-47D3-882B-6D46A16FC5AA@gmail.com> Message-ID: <5c3cfae7.1c69fb81.33142.c0c5@mx.google.com> 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 produce a minimized Image (and still have a classpath used). Given the uncertainity involved in static scanning I would not want jlink to do jdeps work automatically, so there is not much else you can do besided providing the modules list yourself, or what would be your idea to make this work? (Actually when aiming for small Images, I would even specify the modules in a mp path scenario, only because a third party module Imports a JDK module does not mean it needs it at runtime for the specific case) Gruss Bernd -- http://bernd.eckenfels.net Von: Scott Palmer Gesendet: Montag, 14. Januar 2019 21:21 An: Bernd Eckenfels Cc: core-libs-dev Betreff: 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 of the modules you need is JAXB or JAX-WS and you already had this working with Java 9 or 10, you have to make a lot of changes. You can?t build a JRE image with jlink that contains the new replacements for JAXB or JAX-WS. You can include JAXB or JAX-WS on the classpath, but you can?t go back to how it worked with JDK 9 & 10. Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, or java.activation modules can?t be made to work anymore without resorting to hacks like running jlink to pull the .jmod files for those modules from JDK 10 and the rest of the runtime from JDK 11. Scott > On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels wrote: > > 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, 2019 8:16 PM > An: Alan Bateman > Cc: core-libs-dev > Betreff: 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 the module system facilitates top-down migration where you can migrate to modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name. > > Sorry, I?m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.) However, a workflow that will run perfectly fine with JDK 9 & 10 can?t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation). > >> >>> >>> I don?t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to. In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available. Many dependency chains lead to java.activation. >> The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1]. > > This issue breaks many cases where jlink used to work. This is why I refer to the current state of things as a regression. It?s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist. > > Even if you modularize your library or application - you can?t run jlink on it if the dependency chain ever leads to an automatic module. Therefore jpackage and jlink tools can?t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation. Somehow java.activation became un-modularized in the process of removing it from the JDK. > > So more to the point - very few application modules are suitable for jlink input. The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX). Even that can?t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation > > Is that correct? > > Scott > >> >> -Alan >> >> [1] https://github.com/eclipse-ee4j/jaf/issues/13 > From sergei.tsypanov at yandex.ru Mon Jan 14 21:22:43 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 14 Jan 2019 23:22:43 +0200 Subject: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int) References: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> Message-ID: <5311541547500963@iva1-a2ffb02749cf.qloud-c.yandex.net> 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 (excluding StringBu***er and String) we have those: - jdk.internal.jline.extra.EditingHistory$PersistentLine - jdk.internal.jline.extra.EditingHistory$NarrowingHistoryLine - jdk.nashorn.internal.runtime.ConsString - org.graalvm.compiler.phases.ClassTypeSequence - org.graalvm.compiler.phases.LazyName and MethodDebugValueName - com.sun.tools.javac.util.Name All of them delegate the method, affected in my patch, either to String or another CharSequence which I'm sure is an instance of java.lang.String in 99 cases out of a hundred. As for other questions of yours: - indeed, there can be a case when a single char of a long String is appended to SB using SB::append(CharSequence, int, int). Proposed patch will create a new String consisted of that character, so no memory would leak. In this case I agree that performance effect of the patch would be negligible, I guess this is what you wanted to point out. This case however seems to be less probable than the opposite case when we have more than 1 character. - there also can be a case when many String instances are appended to the same SB. Proposed patch won't affect other append calls, just SB::append(CharSequence, int, int). I think this is useful optimisation as it provides better performance without changing lots of code and seems to be not breaking anything. P. S. I've tried to modify the patch to make it call SB::append(String), see [3]. It's results seems to be even more interesting: First let's look into C2 [4]. Here patched version again loses, but not dramatically. But on C1 [5] patched version wins at least in avgt mode! The reason for memory loss is missing scalar replacement of allocated sub-string. And again on C2 intrinsification doesn't work in patced version event when it calls SB::append(String) from StringBuilder itself. Appendix 1. Benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringBuilderAppendBenchmark { @Benchmark @SuppressWarnings("StringBufferReplaceableByString") public String appendSubString(Data data) { String englishStr = data.latinStr; String nonLatinStr = data.nonLatinStr; int beginIndex = data.beginIndex; int endIndex = data.endIndex; String substring = data.appendNonLatin ? nonLatinStr.substring(beginIndex, endIndex) : englishStr.substring(beginIndex, endIndex); return new StringBuilder().append('L').append(substring).append(';').toString(); } @Benchmark public String appendBounds(Data data) { String englishStr = data.latinStr; String nonLatinStr = data.nonLatinStr; int beginIndex = data.beginIndex; int endIndex = data.endIndex; String appended = data.appendNonLatin ? nonLatinStr : englishStr; return new StringBuilder().append('L').append(appended, beginIndex, endIndex).append(';').toString(); } @State(Scope.Thread) public static class Data { String latinStr; String nonLatinStr; @Param({"true", "false"}) boolean appendNonLatin; @Param({"10", "100", "1000"}) private int length; private int beginIndex; private int endIndex; private ThreadLocalRandom random = ThreadLocalRandom.current(); @Setup public void setup() { latinStr = randomString("abcdefghijklmnopqrstuvwxyz"); nonLatinStr = randomString("????????????????????????????????"); beginIndex = length / 4; endIndex = length / 4 * 3; } private String randomString(String alphabet) { char[] chars = alphabet.toCharArray(); StringBuilder sb = new StringBuilder(length); for (int i = 0; i < length; i++) { char c = chars[random.nextInt(chars.length)]; sb.append(c); } return sb.toString(); } } } ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2. Results for StringBuilder: JDK 11.0.1, OpenJDK 64-Bit Server VM, 11.0.1+13-Ubuntu-3ubuntu116.04ppa1 Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 100 39,092 ? 0,558 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 100 96,113 ? 0,739 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 100 653,716 ? 82,838 ns/op StringBuilderAppendBenchmark.appendSubString true 10 avgt 100 27,052 ? 0,513 ns/op StringBuilderAppendBenchmark.appendSubString true 100 avgt 100 46,154 ? 6,511 ns/op StringBuilderAppendBenchmark.appendSubString true 1000 avgt 100 226,889 ? 5,857 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 100 26,044 ? 0,291 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 100 64,630 ? 0,565 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 100 314,778 ? 11,625 ns/op StringBuilderAppendBenchmark.appendSubString false 10 avgt 100 22,899 ? 0,365 ns/op StringBuilderAppendBenchmark.appendSubString false 100 avgt 100 25,075 ? 0,166 ns/op StringBuilderAppendBenchmark.appendSubString false 1000 avgt 100 88,880 ? 0,258 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 100 184,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 100 688,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 100 5192,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 10 avgt 100 128,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 100 avgt 100 360,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 1000 avgt 100 2608,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 100 104,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 100 344,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 100 2144,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 10 avgt 100 96,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 100 avgt 100 192,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 1000 avgt 100 1088,000 ? 0,001 B/op -XX:TieredStopAtLevel=1 Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 100 99,823 ? 1,956 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 100 395,615 ? 4,098 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 100 3198,072 ? 39,497 ns/op StringBuilderAppendBenchmark.appendSubString true 10 avgt 100 94,530 ? 4,256 ns/op StringBuilderAppendBenchmark.appendSubString true 100 avgt 100 148,147 ? 0,853 ns/op StringBuilderAppendBenchmark.appendSubString true 1000 avgt 100 640,169 ? 1,821 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 100 79,023 ? 14,429 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 100 298,557 ? 9,347 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 100 2433,623 ? 32,966 ns/op StringBuilderAppendBenchmark.appendSubString false 10 avgt 100 54,906 ? 0,112 ns/op StringBuilderAppendBenchmark.appendSubString false 100 avgt 100 86,471 ? 0,453 ns/op StringBuilderAppendBenchmark.appendSubString false 1000 avgt 100 251,550 ? 0,998 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 100 184,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 100 688,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 100 5192,005 ? 0,003 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 10 avgt 100 256,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 100 avgt 100 904,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm true 1000 avgt 100 6752,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 100 104,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 100 344,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 100 2144,004 ? 0,003 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 10 avgt 100 152,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 100 avgt 100 440,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendSubString:?gc.alloc.rate.norm false 1000 avgt 100 2688,000 ? 0,001 B/op ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 3. New patch diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java @@ -626,10 +626,7 @@ s = "null"; } checkRange(start, end, s.length()); - int len = end - start; - ensureCapacityInternal(count + len); - appendChars(s, start, end); - return this; + return append(s.subSequence(start, end).toString()); } /** @@ -1592,7 +1589,7 @@ * @param dstBegin the char index, not offset of byte[] * @param coder the coder of dst[] */ - void getBytes(byte dst[], int dstBegin, byte coder) { + void getBytes(byte[] dst, int dstBegin, byte coder) { if (this.coder == coder) { System.arraycopy(value, 0, dst, dstBegin << coder, count << coder); } else { // this.coder == LATIN && coder == UTF16 @@ -1686,29 +1683,8 @@ this.count = count + end - off; } - private final void appendChars(CharSequence s, int off, int end) { - if (isLatin1()) { - byte[] val = this.value; - for (int i = off, j = count; i < end; i++) { - char c = s.charAt(i); - if (StringLatin1.canEncode(c)) { - val[j++] = (byte)c; - } else { - count = j; - inflate(); - StringUTF16.putCharsSB(this.value, j, s, i, end); - count += end - i; - return; - } - } - } else { - StringUTF16.putCharsSB(this.value, count, s, off, end); - } - count += end - off; - } - /* IndexOutOfBoundsException, if out of bounds */ - private static void checkRange(int start, int end, int len) { + protected static void checkRange(int start, int end, int len) { if (start < 0 || start > end || end > len) { throw new IndexOutOfBoundsException( "start " + start + ", end " + end + ", length " + len); diff --git a/src/java.base/share/classes/java/lang/StringBuilder.java b/src/java.base/share/classes/java/lang/StringBuilder.java --- a/src/java.base/share/classes/java/lang/StringBuilder.java +++ b/src/java.base/share/classes/java/lang/StringBuilder.java @@ -210,8 +210,11 @@ */ @Override public StringBuilder append(CharSequence s, int start, int end) { - super.append(s, start, end); - return this; + if (s == null) { + s = "null"; + } + checkRange(start, end, s.length()); + return append(s.subSequence(start, end).toString()); } @Override ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 4. Comparison of original and patched versions for C2 Original JDK 11.0.1, OpenJDK 64-Bit Server VM, 11.0.1+13-Ubuntu-3ubuntu116.04ppa1 Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 50 48,047 ? 1,123 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 50 147,212 ? 7,504 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 50 1042,751 ? 68,417 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 50 22,323 ? 0,513 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 50 74,883 ? 3,260 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 50 466,711 ? 25,859 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 50 184,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 50 688,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 50 5192,002 ? 0,002 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 50 80,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 50 320,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 50 2144,001 ? 0,001 B/op Patched JDK 11-internal, OpenJDK 64-Bit Server VM, 11-internal+0-adhoc.sergei.jdk11 Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 50 62,194 ? 1,955 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 50 172,281 ? 1,865 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 50 1132,282 ? 8,697 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 50 38,363 ? 0,815 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 50 85,648 ? 1,087 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 50 505,787 ? 6,477 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 50 256,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 50 904,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 50 6752,002 ? 0,002 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 50 152,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 50 440,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 50 2688,001 ? 0,001 B/op ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 5. Comparison of original and patched versions for C1 Original Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 50 117,387 ? 1,886 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 50 506,864 ? 10,523 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 50 4172,215 ? 62,144 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 50 65,084 ? 1,547 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 50 350,656 ? 5,061 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 50 2944,915 ? 43,500 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 50 184,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 50 688,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 50 5192,006 ? 0,007 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 50 104,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 50 344,001 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 50 2144,004 ? 0,005 B/op Patched Benchmark (appendNonLatin) (length) Mode Cnt Score Error Units StringBuilderAppendBenchmark.appendBounds true 10 avgt 50 109,806 ? 1,013 ns/op StringBuilderAppendBenchmark.appendBounds true 100 avgt 50 212,775 ? 8,061 ns/op StringBuilderAppendBenchmark.appendBounds true 1000 avgt 50 1308,307 ? 17,675 ns/op StringBuilderAppendBenchmark.appendBounds false 10 avgt 50 69,315 ? 1,788 ns/op StringBuilderAppendBenchmark.appendBounds false 100 avgt 50 122,495 ? 5,311 ns/op StringBuilderAppendBenchmark.appendBounds false 1000 avgt 50 665,867 ? 31,839 ns/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 10 avgt 50 256,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 100 avgt 50 904,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm true 1000 avgt 50 6752,002 ? 0,002 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 10 avgt 50 152,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 100 avgt 50 440,000 ? 0,001 B/op StringBuilderAppendBenchmark.appendBounds:?gc.alloc.rate.norm false 1000 avgt 50 2688,001 ? 0,001 B/op From Alan.Bateman at oracle.com Mon Jan 14 21:35:14 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 21:35:14 +0000 Subject: Modular Applications - Regression In-Reply-To: <0755158B-6C23-47D3-882B-6D46A16FC5AA@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <5728cff8-2289-400a-32ce-a205554bd103@oracle.com> <7351D445-BE00-4685-A61C-50C153EE047B@gmail.com> <0755158B-6C23-47D3-882B-6D46A16FC5AA@gmail.com> Message-ID: <3a429b23-122c-1143-0fcf-f532d969d78b@oracle.com> 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 JDK 9 & 10? > The split package issue in the JAXB implementation was fixed in JAXB 2.4.0, at least according to its release notes [1]. Sorry, I don't know the status of JAX-WS. Your frustration with JAF is understandable but it needs action in the Eclipse project that maintains it, it's not something that we maintain here. -Alan [1] https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html#a-2-4-0 From lance.andersen at oracle.com Tue Jan 15 00:13:18 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 14 Jan 2019 19:13:18 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> Message-ID: <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> > 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 DirectoryStream tests similar to the tests in nio/file/DirectoryStream/Basic.java. >> >> Webrev can be found: http://cr.openjdk.java.net/~lancea/8211919/webrev.00/ >> > Lance -the relative path case looks right now but I think there are issues with the absolute path case. Try an example such as "/META-INF/../META-INF" to see what I mean. Thank you Alan pointing out this example which the previous fix also did not address. I updated the change which addresses the above example as well as the relative path Please see http://cr.openjdk.java.net/~lancea/8211919/webrev.02/index.html Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From takiguc at linux.vnet.ibm.com Tue Jan 15 00:51:10 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 15 Jan 2019 09:51:10 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> Message-ID: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> 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, Ltd. On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > Hello Alan. > > I opened JDK-8215333 for Charset filtering issue [1]. > I cannot wait until JDK-8215333 is closed. > Is it possible to put IBM-29626C charset with standard way ? > > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > > Thanks, > Ichiroh Takiguchi > > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> Hello Roger, Magnus and Alan. >> I may need to put alias information into charsets file. >> stdcs-xxx cannot handle this information... >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> I appreciate if you give me further suggestions. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> It is a nice feature that charsets are selected at build time using >>>>> the stdcs-xxx files. >>>>> This change breaks that pattern and embeds os specific information >>>>> in more than one place. >>>>> That does not seem like an improvement.? Is there any alternative? >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>> My reading of the patch is that the "os" key is to avoid generating >>> it >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>> non-AIX platforms. The general direction is welcome but I think >>> further work and discussion will be needed to get the right set of >>> changes to support filtering in the build. It can probably be >>> separated from the changes to add IBM-29626C to AIX's java.base. >>> >>> -Alan From john.r.rose at oracle.com Tue Jan 15 01:47:40 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 14 Jan 2019 17:47:40 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: 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 bytecode does not know about setAccessible and final fields. The "bytecode behavior" of an unreflectSetter MH is clearly documented by appealing to a call to Field::set. That is a pre-existing specification that proves that the observed behavior for statics is a bug, and for non-statics is a feature. No CSR is needed, and, David, you are simply looking in the wrong places. I admit that the right place is tricky to find. > I can see an argument to be made for the case where setAccessible(true) has been called to disable language level access checks, and you want the MH to follow the same access rules. But that does not to me imply that the ability to write to a final field should be part of that. If that is intended then it needs to be very, very clearly spelt out. Yes, the documentation should be improved, so that email threads like this won't be necessary to tease out the meaning of the spec. I placed a proposal for *clarifying* (not *changing*) it in the bug comments. > And as per my other email there is already a problem with the bytecode equivalence of MH semantics and final fields, because you can set final fields in or (though only once). I don't think MH captures that - nor can it. That's true. The most it can do is capture the effect, if any, of setAcc(true) on a reflected Field. > Which means we can't defer to bytecode semantics here but rather have to very clearly define how MH interact with final fields. And that's already done, except for the "clearly" part. Thanks for raising this issue! ? John diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -421,6 +421,10 @@ * because the desired class member is missing, or because the * desired class member is not accessible to the lookup class, or * because the lookup object is not trusted enough to access the member. + * In the case of a field setter function on a {@code final} field, + * finality enforcement is treated as a kind of access control, + * and the lookup will fail, except in special cases of + * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. * In any of these cases, a {@code ReflectiveOperationException} will be * thrown from the attempted lookup. The exact class will be one of * the following: @@ -1436,6 +1440,7 @@ * @return a method handle which can store values into the field * @throws NoSuchFieldException if the field does not exist * @throws IllegalAccessException if access checking fails, or if the field is {@code static} + * or {@code final} * @exception SecurityException if a security manager is present and it * refuses access * @throws NullPointerException if any argument is null @@ -1559,6 +1564,7 @@ * @return a method handle which can store values into the field * @throws NoSuchFieldException if the field does not exist * @throws IllegalAccessException if access checking fails, or if the field is not {@code static} + * or is {@code final} * @exception SecurityException if a security manager is present and it * refuses access * @throws NullPointerException if any argument is null @@ -1868,19 +1874,29 @@ /** * Produces a method handle giving write access to a reflected field. * The type of the method handle will have a void return type. - * If the field is static, the method handle will take a single + * If the field is {@code static}, the method handle will take a single * argument, of the field's value type, the value to be stored. * Otherwise, the two arguments will be the instance containing * the field, and the value to be stored. - * If the field's {@code accessible} flag is not set, + * If the {@code Field} object's {@code accessible} flag is not set, * access checking is performed immediately on behalf of the lookup class. *

- * If the field is static, and + * If the field is {@code final}, write access will not be + * allowed and access checking will fail, except under certain + * narrow circumstances documented for {@link Field#set Field.set}. + * A method handle is returned only if a corresponding call to + * the {@code Field} object's {@code set} method could return + * normally. In particular, fields which are both {@code static} + * and {@code final} may never be set. + *

+ * If the field is {@code static}, and * if the returned method handle is invoked, the field's class will * be initialized, if it has not already been initialized. * @param f the reflected field * @return a method handle which can store values into the reflected field - * @throws IllegalAccessException if access checking fails + * @throws IllegalAccessException if access checking fails, + * or if the field is {@code final} and write access + * is not enabled on the {@code Field} object * @throws NullPointerException if the argument is null */ public MethodHandle unreflectSetter(Field f) throws IllegalAccessException { From david.holmes at oracle.com Tue Jan 15 02:01:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 12:01:43 +1000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: <533f5361-5f70-6059-f41f-c23d245943d6@oracle.com> 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". I'm not reading any final field semantics into >> the existing text, because bytecode does not know about setAccessible >> and final fields. > > The "bytecode behavior" of an unreflectSetter MH is clearly documented > by appealing to a call to Field::set. ?That is a pre-existing specification > that proves that the observed behavior for statics is a bug, and for > non-statics is a feature. ?No CSR is needed, and, David, you are simply > looking in the wrong places. ?I admit that the right place is tricky to > find. Thanks John - yes I missed that and thought it appealed to direct bytecode (putField/putStatic etc). Cheers, David ----- > >> I can see an argument to be made for the case where >> setAccessible(true) has been called to disable language level access >> checks, and you want the MH to follow the same access rules. But that >> does not to me imply that the ability to write to a final field should >> be part of that. If that is intended then it needs to be very, very >> clearly spelt out. > > Yes, the documentation should be improved, so that email threads like > this won't be necessary to tease out the meaning of the spec. ?I placed > a proposal for *clarifying* (not *changing*) it in the bug comments. > >> And as per my other email there is already a problem with the bytecode >> equivalence of MH semantics and final fields, because you can set >> final fields in or (though only once). I don't think >> MH captures that - nor can it. > > That's true. ?The most it can do is capture the effect, if any, of > setAcc(true) on a reflected Field. > >> Which means we can't defer to bytecode semantics here but rather have >> to very clearly define how MH interact with final fields. > > And that's already done, except for the "clearly" part. > > Thanks for raising this issue! > > ? John > > diff --git > a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > @@ -421,6 +421,10 @@ > ? ? ? * because the desired class member is missing, or because the > ? ? ? * desired class member is not accessible to the lookup class, or > ? ? ? * because the lookup object is not trusted enough to access the > member. > + ? ? * In the case of a field setter function on a {@code final} field, > + ? ? * finality enforcement is treated as a kind of access control, > + ? ? * and the lookup will fail, except in special cases of > + ? ? * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. > ? ? ? * In any of these cases, a {@code ReflectiveOperationException} > will be > ? ? ? * thrown from the attempted lookup. ?The exact class will be one of > ? ? ? * the following: > @@ -1436,6 +1440,7 @@ > ? ? ? ? ? * @return a method handle which can store values into the field > ? ? ? ? ? * @throws NoSuchFieldException if the field does not exist > ? ? ? ? ? * @throws IllegalAccessException if access checking fails, or > if the field is {@code static} > + ? ? ? ? * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?or {@code final} > ? ? ? ? ? * @exception SecurityException if a security manager is > present and it > ? ? ? ? ? * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? href="MethodHandles.Lookup.html#secmgr">refuses access > ? ? ? ? ? * @throws NullPointerException if any argument is null > @@ -1559,6 +1564,7 @@ > ? ? ? ? ? * @return a method handle which can store values into the field > ? ? ? ? ? * @throws NoSuchFieldException if the field does not exist > ? ? ? ? ? * @throws IllegalAccessException if access checking fails, or > if the field is not {@code static} > + ? ? ? ? * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?or is {@code final} > ? ? ? ? ? * @exception SecurityException if a security manager is > present and it > ? ? ? ? ? * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? href="MethodHandles.Lookup.html#secmgr">refuses access > ? ? ? ? ? * @throws NullPointerException if any argument is null > @@ -1868,19 +1874,29 @@ > ? ? ? ? ?/** > ? ? ? ? ? * Produces a method handle giving write access to a reflected > field. > ? ? ? ? ? * The type of the method handle will have a void return type. > - ? ? ? ? * If the field is static, the method handle will take a single > + ? ? ? ? * If the field is {@code static}, the method handle will take > a single > ? ? ? ? ? * argument, of the field's value type, the value to be stored. > ? ? ? ? ? * Otherwise, the two arguments will be the instance containing > ? ? ? ? ? * the field, and the value to be stored. > - ? ? ? ? * If the field's {@code accessible} flag is not set, > + ? ? ? ? * If the {@code Field} object's {@code accessible} flag is not > set, > ? ? ? ? ? * access checking is performed immediately on behalf of the > lookup class. > ? ? ? ? ? *

> - ? ? ? ? * If the field is static, and > + ? ? ? ? * If the field is {@code final}, write access will not be > + ? ? ? ? * allowed and access checking will fail, except under certain > + ? ? ? ? * narrow circumstances documented for {@link Field#set Field.set}. > + ? ? ? ? * A method handle is returned only if a corresponding call to > + ? ? ? ? * the {@code Field} object's {@code set} method could return > + ? ? ? ? * normally. ?In particular, fields which are both {@code static} > + ? ? ? ? * and {@code final} may never be set. > + ? ? ? ? *

> + ? ? ? ? * If the field is {@code static}, and > ? ? ? ? ? * if the returned method handle is invoked, the field's class > will > ? ? ? ? ? * be initialized, if it has not already been initialized. > ? ? ? ? ? * @param f the reflected field > ? ? ? ? ? * @return a method handle which can store values into the > reflected field > - ? ? ? ? * @throws IllegalAccessException if access checking fails > + ? ? ? ? * @throws IllegalAccessException if access checking fails, > + ? ? ? ? * ? ? ? ? or if the field is {@code final} and write access > + ? ? ? ? * ? ? ? ? is not enabled on the {@code Field} object > ? ? ? ? ? * @throws NullPointerException if the argument is null > ? ? ? ? ? */ > ? ? ? ? ?public MethodHandle unreflectSetter(Field f) throws > IllegalAccessException { > From joe.darcy at oracle.com Tue Jan 15 02:07:47 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Jan 2019 18:07:47 -0800 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString Message-ID: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> 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 -0800 +++ new/src/java.base/share/classes/java/lang/Class.java 2019-01-14 18:05:21.938000999 -0800 @@ -272,8 +272,9 @@ ???????????? TypeVariable[] typeparms = component.getTypeParameters(); ???????????? if (typeparms.length > 0) { - sb.append(Stream.of(typeparms).map(Class::typeVarBounds). -????????????????????????? collect(Collectors.joining(",", "<", ">"))); +??????????????? sb.append(Arrays.stream(typeparms) +????????????????????????? .map(Class::typeVarBounds) +????????????????????????? .collect(Collectors.joining(",", "<", ">"))); ???????????? } ???????????? for (int i = 0; i < arrayDepth; i++) @@ -289,8 +290,9 @@ ???????????? return typeVar.getName(); ???????? } else { ???????????? return typeVar.getName() + " extends " + -??????????????? Stream.of(bounds).map(Type::getTypeName). -??????????????? collect(Collectors.joining(" & ")); +??????????????? Arrays.stream(bounds) +??????????????? .map(Type::getTypeName) +??????????????? .collect(Collectors.joining(" & ")); ???????? } ???? } @@ -3419,8 +3421,9 @@ ???????? StringBuilder sb = new StringBuilder(); ???????? sb.append(getName() + "." + name + "("); ???????? if (argTypes != null) { -??????????? sb.append(Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). -????????????????????? collect(Collectors.joining(","))); +??????????? sb.append(Arrays.stream(argTypes) +????????????????????? .map(c -> (c == null) ? "null" : c.getName()) +????????????????????? .collect(Collectors.joining(","))); ???????? } ???????? sb.append(")"); ???????? return sb.toString(); From joe.darcy at oracle.com Tue Jan 15 03:41:43 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Jan 2019 19:41:43 -0800 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> Message-ID: 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 +++ new/src/java.base/share/classes/java/lang/reflect/Executable.java 2019-01-14 19:39:53.559000999 -0800 @@ -113,14 +113,16 @@ ???????????? specificToStringHeader(sb); ???????????? sb.append('('); - sb.append(Stream.of(parameterTypes).map(Type::getTypeName). -????????????????????? collect(Collectors.joining(","))); +??????????? sb.append(Arrays.stream(parameterTypes) +??? ??? ????? .map(Type::getTypeName) +????????????????????? .collect(Collectors.joining(","))); ???????????? sb.append(')'); ???????????? if (exceptionTypes.length > 0) { - sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). -????????????????????????? collect(Collectors.joining(",", " throws ", ""))); +??????????????? sb.append(Arrays.stream(exceptionTypes) +??? ??? ??? ? .map(Type::getTypeName) +????????????????????????? .collect(Collectors.joining(",", " throws ", ""))); ???????????? } ???????????? return sb.toString(); ???????? } catch (Exception e) { @@ -140,8 +142,9 @@ ???????????? return typeVar.getName(); ???????? } else { ???????????? return typeVar.getName() + " extends " + -??????????????? Stream.of(bounds).map(Type::getTypeName). -??????????????? collect(Collectors.joining(" & ")); +??????????????? Arrays.stream(bounds) +??? ??? .map(Type::getTypeName) +??????????????? .collect(Collectors.joining(" & ")); ???????? } ???? } @@ -153,8 +156,9 @@ ???????????? TypeVariable[] typeparms = getTypeParameters(); ???????????? if (typeparms.length > 0) { - sb.append(Stream.of(typeparms).map(Executable::typeVarBounds). -????????????????????????? collect(Collectors.joining(",", "<", "> "))); +??????????????? sb.append(Arrays.stream(typeparms) +??? ??? ??? ? .map(Executable::typeVarBounds) +????????????????????????? .collect(Collectors.joining(",", "<", "> "))); ???????????? } ???????????? specificToGenericStringHeader(sb); @@ -173,8 +177,9 @@ ???????????? Type[] exceptionTypes = getGenericExceptionTypes(); ???????????? if (exceptionTypes.length > 0) { - sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). -????????????????????????? collect(Collectors.joining(",", " throws ", ""))); +??????????????? sb.append(Arrays.stream(exceptionTypes) +??? ??? ??? ? .map(Type::getTypeName) +????????????????????????? .collect(Collectors.joining(",", " throws ", ""))); ???????????? } ???????????? return sb.toString(); ???????? } catch (Exception e) { Thanks, -Joe On 1/14/2019 6:07 PM, Joe Darcy wrote: > 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 -0800 > +++ new/src/java.base/share/classes/java/lang/Class.java 2019-01-14 > 18:05:21.938000999 -0800 > @@ -272,8 +272,9 @@ > > ???????????? TypeVariable[] typeparms = component.getTypeParameters(); > ???????????? if (typeparms.length > 0) { > - sb.append(Stream.of(typeparms).map(Class::typeVarBounds). > -????????????????????????? collect(Collectors.joining(",", "<", ">"))); > +??????????????? sb.append(Arrays.stream(typeparms) > +????????????????????????? .map(Class::typeVarBounds) > +????????????????????????? .collect(Collectors.joining(",", "<", ">"))); > ???????????? } > > ???????????? for (int i = 0; i < arrayDepth; i++) > @@ -289,8 +290,9 @@ > ???????????? return typeVar.getName(); > ???????? } else { > ???????????? return typeVar.getName() + " extends " + > -??????????????? Stream.of(bounds).map(Type::getTypeName). > -??????????????? collect(Collectors.joining(" & ")); > +??????????????? Arrays.stream(bounds) > +??????????????? .map(Type::getTypeName) > +??????????????? .collect(Collectors.joining(" & ")); > ???????? } > ???? } > > @@ -3419,8 +3421,9 @@ > ???????? StringBuilder sb = new StringBuilder(); > ???????? sb.append(getName() + "." + name + "("); > ???????? if (argTypes != null) { > -??????????? sb.append(Stream.of(argTypes).map(c -> {return (c == > null) ? "null" : c.getName();}). > -????????????????????? collect(Collectors.joining(","))); > +??????????? sb.append(Arrays.stream(argTypes) > +????????????????????? .map(c -> (c == null) ? "null" : c.getName()) > +????????????????????? .collect(Collectors.joining(","))); > ???????? } > ???????? sb.append(")"); > ???????? return sb.toString(); > From kustaa.nyholm at sparetimelabs.com Tue Jan 15 05:08:32 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Tue, 15 Jan 2019 07:08:32 +0200 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> Message-ID: <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> 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: /Users/nyholku/EazyCNC-Project/abuildroot MacBook-Pro:EazyCNC-Project nyholku$ ls /Users/nyholku/EazyCNC-Project/abuildroot ls: /Users/nyholku/EazyCNC-Project/abuildroot: No such file or directory Also, what is 'Runtime-Info.plist.template' and why would I want it? I take it jpackage is not going to build the .dmg and I have to this with standard MacOs tools? Ok I already do that as the old javapackager generated .dmg did not have the properties I liked and now way to influence those. 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 PACKAGER=/Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/Home/bin/jpackage ${PACKAGER} --version ${PACKAGER} \ create-image \ --force \ --build-root abuildroot \ --verbose \ --add-modules java.base,java.desktop,java.management,java.sql,java.instrument,java.compiler \ --input buildtest \ --output . \ --name EazyCNC \ --main-jar EazyCNC.jar \ --class eazycnc.Main \ --jvm-args '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+PrintGC' \ --resource-dir 'javapackager-resources/package/macosx' 'buildtest' is a flat directory that contains all my jars, I will next figure out if has to be flat or what ever other ways I can use to organise it better or specify the jars more rationally but as a starting point that produces correct .app above seems to work for my case. wbr Kusti > On 14 Jan 2019, at 15.35, Andy Herrick wrote: > > 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 trying to use has changed twice (once from javafxpackager in JDK8 to jpackage in EA1 and again from EA1 to EA2). > > With the current EA2, you need to add option "--resource-dir '/Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx'" > > ( or use a patch relative to the current directory) to say where to load custom resources from. > > With the first EA you needed to put resources in "./package/macosx". It was looking for custom resources in "package/" relative to the current working directory, not the input directory (as in javafxpackager) > > /Andy > > On 1/14/2019 5:27 AM, Kustaa Nyholm wrote: >> 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 \ >> --add-modules java.base,java.desktop \ >> --input /Users/nyholku/EazyCNC-Project/javapackager-resources \ >> --output . \ >> --name EazyCNC \ >> --main-jar EazyCNC.jar \ >> --class eazycnc.Main \ >> >> >> But I keep getting these messages: >> >> Using default package resource [icon] (add package/macosx/EazyCNC.icns to the class path to customize) >> Preparing Info.plist: /Users/nyholku/EazyCNC-Project/./EazyCNC.app/Contents/Info.plist >> Using default package resource [Application Info.plist] (add package/macosx/Info.plist to the class path to customize) >> Using default package resource [Java Runtime Info.plist] (add package/macosx/Runtime-Info.plist to the class path to customize) >> >> >> even though the resources exist (and worked with JDK8 javapackager): >> >> ls /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >> /Users/nyholku/EazyCNC-Project/javapackager-resources/package/macosx/Info.plist >> >> wbr Kusti >> >> >> >> From mik3hall at gmail.com Tue Jan 15 05:36:00 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 Jan 2019 23:36:00 -0600 Subject: jpackage custom resources not found In-Reply-To: <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> Message-ID: > 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 > > PACKAGER=/Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/Home/bin/jpackage > FWIW, for OS X I just set this in my .bash_profile jdkhome=`/usr/libexec/java_home` alias jpackage=${jdkhome}"/bin/jpackage" alias jlink=${jdkhome}"/bin/jlink" That way you aren?t dependent on a hard-coded jdk version name. I think for some of what this does you need jlink as well and neither of these commands (jpackage,jlink) appear to point anywhere after a drag and drop install into JavaVirtualMachines. jshell does seem correct and I think it was also introduced with jlink in java 9 so I?m not sure why both aren?t pointing correctly. I think I asked about this before and it was indicated to be Apple who owned the library holding the symbolic links for these commands and it was up to them to have them pointing correctly? From kustaa.nyholm at sparetimelabs.com Tue Jan 15 05:50:34 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Tue, 15 Jan 2019 07:50:34 +0200 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> Message-ID: > 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 line tools from the command line. And especially in situation like this in which I need to use jdk13ea to package a jdk11 application I want to be very sure that I know and control explicitly what is used. Much easier for *me* to patch a few scripts/ant scripts if they brake than to track down how something fails subtly and mysteriously when I install something new that screws up things that rely on the shell resolving to the correct version of some tool. But that is just me I guess ;) wbr Kusti From christoph.langer at sap.com Tue Jan 15 08:10:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Jan 2019 08:10:26 +0000 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> Message-ID: Hi Lance, > Thank you for the feedback, please see below Welcome, thanks for addressing my findings ?? > line 97: spelling: ?filter? > fixed though was ?DirectoryStream.Filter? which I changed to > DirectoryStream filter Hm, not quite yet... What I mean is still in line 96: * Iterator correctly indicates whether the filer has been matched -> I think you mean filter instead of filer here. > line 309: you could use an import java.util.zip.ZipException? > done, still getting used to Intellij vs Netbeans which I like better for import > handling I'm currently using Eclipse though I should try IntelliJ, too. As for imports, I would also think the org.testng.* imports should go after the java.* imports. But not sure if there's some official style guide for that. Overall, looks good to me now. (The latest webrev, that addresses Alan's point, too) Best regards Christoph From patrick at os.amperecomputing.com Tue Jan 15 08:57:13 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Tue, 15 Jan 2019 08:57:13 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> Message-ID: Hi Roger, Thanks for your review firstly. Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). <> Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). FYI. I sent out an almost same patch early on 3 Jan. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html <> Regards Patrick From: Roger Riggs Sent: Monday, January 14, 2019 11:49 PM To: Patrick Zhang Cc: core-libs-dev Subject: 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 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 well.) /Magnus I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- Regards Patrick -----Original Message----- From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang Sent: Thursday, December 6, 2018 4:28 PM To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com Cc: Florian Weimer mailto:fweimer at redhat.com Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes mailto:david.holmes at oracle.com Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com Cc: mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). Hi David, Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David #ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif Regards Patrick -----Original Message----- From: Florian Weimer mailto:fweimer at redhat.com Sent: Thursday, November 29, 2018 8:02 PM To: David Holmes mailto:david.holmes at oracle.com Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path * David Holmes: This should really be being discussed on core-libs-dev. Okay, moving the conversation. diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 @@ -415,9 +415,7 @@ ??????? ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); ??? } ??? -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#if !defined(_REENTRANT) // linux ??? #define gmtime_r(t, s) gmtime(t) ??? #endif ??? /* Under the theme "two wrongs don't make a right" the use of _REENTRANT here is totally inappropriate AFAICS. It seems to be a misguided attempt at determining whether we need the thread-safe gmtime_r or not - and the answer to that should always be yes IMHO. We define _REENTRANT for: - linux - gcc - xlc So the original code will define: extern "C" struct tm *gmtime_r(const time_t *, struct tm *); for linux (and AIX with xlc?) but not Solaris, OS X or Windows. But Solaris has gmtime_r anyway. So the existing code seems a really convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where gmtime is already thread-safe). So it seems to me that all we should need here is: -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#ifdef _MSC_VER // Windows ?? #define gmtime_r(t, s) gmtime(t) ?? #endif That looks much cleaner. Thanks, Florian From Alan.Bateman at oracle.com Tue Jan 15 09:07:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2019 09:07:39 +0000 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> Message-ID: <5789840d-4f64-1e34-4259-23ad9c500165@oracle.com> On 15/01/2019 00:13, Lance Andersen wrote: > : > > Thank you Alan pointing out this example which the previous fix also > did not address. ?I updated the change which addresses the above > example as well as the relative path > > Please see http://cr.openjdk.java.net/~lancea/8211919/webrev.02/index.html > Good, this looks right now. Are you planning to re-visit the 1-4 comments at L426-433, just asking because point 4 is confusing as there isn't any code here that cares if the path starts with "./" or "." I don't have time right now to study all the test cases in ZipFsDirectoryStreamTests so I only skimmed through it. I assume all the places that catch IOException and print the stack trace should be cleaned up to not catch the exception as you want the test to fail if it can't open the zip file. Also I assume "Zipfs" can be dropped from the name to be consistent with the existing test classes. A minor nit is that the really long lines will be annoying for future side-by-side reviews of changes to this test. -Alan From patrick at os.amperecomputing.com Tue Jan 15 09:24:01 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Tue, 15 Jan 2019 09:24:01 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> Message-ID: In case the attachment may get dropped by mailing system, I paste the udiffs in text here. ./src/jdk.pack/share/native/common-unpack/zip.cpp rev 53300 : 8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files ________________________________ @@ -414,13 +414,13 @@ return y < 1980 ? dostime(1980, 1, 1, 0, 0, 0) : (((uLong)y - 1980) << 25) | ((uLong)n << 21) | ((uLong)d << 16) | ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +// Linux, Solaris, OS X, etc have gmtime_r for _REENTRANT, +// while gmtime for Windows is already thread-safe +#ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif /* * Return the Unix time in DOS format */ Regards Patrick -----Original Message----- From: core-libs-dev On Behalf Of Patrick Zhang Sent: Tuesday, January 15, 2019 4:57 PM To: Roger Riggs Cc: core-libs-dev Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Roger, Thanks for your review firstly. Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). <> Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). FYI. I sent out an almost same patch early on 3 Jan. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html <> Regards Patrick From: Roger Riggs > Sent: Monday, January 14, 2019 11:49 PM To: Patrick Zhang > Cc: core-libs-dev > Subject: 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 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 well.) /Magnus I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- Regards Patrick -----Original Message----- From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang Sent: Thursday, December 6, 2018 4:28 PM To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com Cc: Florian Weimer mailto:fweimer at redhat.com Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes mailto:david.holmes at oracle.com Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com Cc: mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). Hi David, Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David #ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif Regards Patrick -----Original Message----- From: Florian Weimer mailto:fweimer at redhat.com Sent: Thursday, November 29, 2018 8:02 PM To: David Holmes mailto:david.holmes at oracle.com Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path * David Holmes: This should really be being discussed on core-libs-dev. Okay, moving the conversation. diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 @@ -415,9 +415,7 @@ ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#if !defined(_REENTRANT) // linux #define gmtime_r(t, s) gmtime(t) #endif /* Under the theme "two wrongs don't make a right" the use of _REENTRANT here is totally inappropriate AFAICS. It seems to be a misguided attempt at determining whether we need the thread-safe gmtime_r or not - and the answer to that should always be yes IMHO. We define _REENTRANT for: - linux - gcc - xlc So the original code will define: extern "C" struct tm *gmtime_r(const time_t *, struct tm *); for linux (and AIX with xlc?) but not Solaris, OS X or Windows. But Solaris has gmtime_r anyway. So the existing code seems a really convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where gmtime is already thread-safe). So it seems to me that all we should need here is: -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif That looks much cleaner. Thanks, Florian From mik3hall at gmail.com Tue Jan 15 10:57:20 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 04:57:20 -0600 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> Message-ID: > On Jan 14, 2019, at 11:50 PM, Kustaa Nyholm wrote: > > > >> 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 > line tools from the command line. And especially in situation like this in which > I need to use jdk13ea to package a jdk11 application I want to be very sure > that I know and control explicitly what is used. > > Much easier for *me* to patch a few scripts/ant scripts if they brake than to track down > how something fails subtly and mysteriously when I install something new that screws > up things that rely on the shell resolving to the correct version of some tool. /usr/libexec/java_home will get the latest jdk by default I think. I also have many installed. You can specify release version anyhow with something like? /usr/libexec/java_home -v 11 ?exec java -version It used to be like -v 1.8 but I think that changed with 9? Usually the latest jdk with the command would be the one you?d want? Or the one you?d want to know if it was broke. True, you probably don?t need the jlink command correct for this. jpackage probably api invokes it. jpackage so far seems to just have too many parameters to really use command line anyhow > > > But that is just me I guess ;) > Everyone has their preferences for how they do things. From david.holmes at oracle.com Tue Jan 15 11:53:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 21:53:09 +1000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> Message-ID: <1ec59bf0-04f3-6527-6fe4-0b0f538f9d7f@oracle.com> Hi Patrick, On 15/01/2019 7:24 pm, Patrick Zhang wrote: > In case the attachment may get dropped by mailing system, I paste the udiffs in text here. Yes attachments are generally dropped. > ./src/jdk.pack/share/native/common-unpack/zip.cpp > > rev 53300 : 8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files > > ________________________________ > > @@ -414,13 +414,13 @@ > > return y < 1980 ? dostime(1980, 1, 1, 0, 0, 0) : > > (((uLong)y - 1980) << 25) | ((uLong)n << 21) | ((uLong)d << 16) | > > ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); > > } > > -#ifdef _REENTRANT // solaris > > -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); > > -#else > > +// Linux, Solaris, OS X, etc have gmtime_r for _REENTRANT, There is no need to mention _REENTRANT here - it is not relevant. I suggest simply: // Non-windows platforms need gmtime_r for thread-safety, Thanks, David > +// while gmtime for Windows is already thread-safe > > +#ifdef _MSC_VER // Windows > > #define gmtime_r(t, s) gmtime(t) > > #endif > > /* > > * Return the Unix time in DOS format > > */ > > > > > > Regards > > Patrick > > > > -----Original Message----- > From: core-libs-dev On Behalf Of Patrick Zhang > Sent: Tuesday, January 15, 2019 4:57 PM > To: Roger Riggs > Cc: core-libs-dev > Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > > > Hi Roger, > > > > Thanks for your review firstly. > > Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). > > <> > > > > Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). > > > > FYI. I sent out an almost same patch early on 3 Jan. > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html > > <> > > > > Regards > > Patrick > > > > From: Roger Riggs > > > Sent: Monday, January 14, 2019 11:49 PM > > To: Patrick Zhang > > > Cc: core-libs-dev > > > Subject: 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 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 well.) > > > > /Magnus > > > > > > > > > > I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. > > > > I have filed: > > > > https://bugs.openjdk.java.net/browse/JDK-8215976 > > > > to cover this and linked to the discussion threads. > > > > The appropriate owners still need to review this, but I'm not sure who that may be these days. > > > > Cheers, > > David > > ----- > > > > > > > > Regards > > Patrick > > > > -----Original Message----- > > From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang > > Sent: Thursday, December 6, 2018 4:28 PM > > To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com > > Cc: Florian Weimer mailto:fweimer at redhat.com > > Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > > > To All, > > Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. > > > > Regards > > Patrick > > > > -----Original Message----- > > From: David Holmes mailto:david.holmes at oracle.com > > Sent: Monday, December 3, 2018 8:11 AM > > To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com > > Cc: mailto:core-libs-dev at openjdk.java.net > > Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > > > Hi Patrick, > > > > On 30/11/2018 11:41 pm, Patrick Zhang wrote: > > > > Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). > > > > Hi David, > > Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. > > > > You'd need some assistance testing a wider range of platforms but that can be arranged. > > > > > > In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. > > _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. > > > > Cheers, > > David > > > > > > #ifdef _MSC_VER // Windows > > #define gmtime_r(t, s) gmtime(t) > > #endif > > > > Regards > > Patrick > > > > -----Original Message----- > > From: Florian Weimer mailto:fweimer at redhat.com > > Sent: Thursday, November 29, 2018 8:02 PM > > To: David Holmes mailto:david.holmes at oracle.com > > Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; > > mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net > > Subject: Re: OpenJDK fails to build with GCC when the #include > > inside zip.cpp comes from a non-sysroot path > > > > * David Holmes: > > > > > > This should really be being discussed on core-libs-dev. > > > > Okay, moving the conversation. > > > > > > diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp > > --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 > > +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 > > @@ -415,9 +415,7 @@ > > ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); > > } > > -#ifdef _REENTRANT // solaris > > -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else > > +#if !defined(_REENTRANT) // linux > > #define gmtime_r(t, s) gmtime(t) > > #endif > > /* > > > > Under the theme "two wrongs don't make a right" the use of _REENTRANT > > here is totally inappropriate AFAICS. It seems to be a misguided > > attempt at determining whether we need the thread-safe gmtime_r or > > not > > - and the answer to that should always be yes IMHO. > > > > We define _REENTRANT for: > > - linux > > - gcc > > - xlc > > > > So the original code will define: > > > > extern "C" struct tm *gmtime_r(const time_t *, struct tm *); > > > > for linux (and AIX with xlc?) but not Solaris, OS X or Windows. > > > > But Solaris has gmtime_r anyway. So the existing code seems a really > > convoluted hack. AFAICS we have gmtime_r everywhere but Windows > > (where gmtime is already thread-safe). So it seems to me that all we > > should need here is: > > > > -#ifdef _REENTRANT // solaris > > -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else > > +#ifdef _MSC_VER // Windows > > #define gmtime_r(t, s) gmtime(t) > > #endif > > > > That looks much cleaner. > > > > Thanks, > > Florian > > > > From fweimer at redhat.com Tue Jan 15 11:59:28 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 15 Jan 2019 12:59:28 +0100 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> (Joe Darcy's message of "Mon, 14 Jan 2019 18:07:47 -0800") References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> Message-ID: <87tvia5dy7.fsf@oldenburg2.str.redhat.com> * Joe Darcy: > - sb.append(Stream.of(typeparms).map(Class::typeVarBounds). > -????????????????????????? collect(Collectors.joining(",", "<", ">"))); > +??????????????? sb.append(Arrays.stream(typeparms) > +????????????????????????? .map(Class::typeVarBounds) > +????????????????????????? .collect(Collectors.joining(",", "<", ">"))); > ???????????? } I realize that this is a pre-existing issue, but isn't this approach a bit awkward? Creating a temporary string just to put it into a StringBuilder? Thanks, Florian From kustaa.nyholm at sparetimelabs.com Tue Jan 15 12:09:59 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Tue, 15 Jan 2019 14:09:59 +0200 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> Message-ID: <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> > On 15 Jan 2019, at 12.57, Michael Hall wrote: > > Usually the latest jdk with the command would be the one you?d want? Funnily enough, I wanted to quickly test something (jdeps) from the command line, and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal is to move all my stuff to jdk-11 and stay with that for next 5 years or so. For those who are not aware here is tip how to disable a jdk on MacOs: cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/ sudo mv Info.plist Info.plist-disabled i.e. just rename the Info.plist so that it cannot be found by the tools, after that command line tools reverted to jdk-11.0.1 wrb Kusti From goetz.lindenmaier at sap.com Tue Jan 15 12:49:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Jan 2019 12:49:13 +0000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH Message-ID: Hi, As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to LIBPATH anyways, so we can remove the special case for AIX. Please review this small cleanup. http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ Best regards, Goetz. (I posted this to hotspot-runtime-dev before, but seems to be placed better here) http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-January/032109.html From magnus.ihse.bursie at oracle.com Tue Jan 15 13:09:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 14:09:10 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: References: Message-ID: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> Hi Andy, This is looking really sweet from a build perspective! Just a few minor nits: * In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval $(call SetupBuildLauncher, jpackage ....") two spaces. * In Lib-jdk.jpackage.gmk, I think there's still room to prune some more unnecessary compiler flags and parameters to SetupJdkExecutable: 65 CFLAGS_linux := -fPIC, \ 66 CFLAGS_solaris := -KPIC, \ 67 CFLAGS_macosx := -fPIC, \ ?I wonder if these really are needed. Normally, only shared libraries neeed PIC code. (And for those we set it automatically.) 69 LDFLAGS_windows := -nologo, \ This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. (Also in the second block, for jpackageapplauncherw). 72 LIBS_solaris := -lc, \ Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, and is always included. 75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \ This is setup by default by SetupJdkExecutable, so you can remove it. (Also in the second block, for jpackageapplauncherw). Finally, I do believe that the setups of jpackageapplauncher and jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they are not "really" launchers in our normal sense, but they are at least more launchers than they are libraries. As we've talked about privately, in the future I'd like to see Windows too use the SetupBuildLauncher method for creating the launcher, but this is clearly good enough for inclusion in the mainline. I also have a question about test/jdk/tools/jpackage/resources/license.txt. What is it used for? And why the odd (incorrect?) spelling of license? /Magnus On 2019-01-11 20:41, Andy Herrick wrote: > This is the second update to the Request For Review of the > implementation of the Java Packager Tool (jpackager) as described in > JEP 343: Packaging Tool > > > > This webrev corresponds to the second EA build, Build 8 (2019/1/8), > posted at http://jdk.java.net/jpackage/ > > This update renames the package used to "jdk.jpackage", removes the > Single Instance Service (and CLI option --singleton), adds several > other CLI options, adds more automated tests, and contains fixes to > the following issues (since update 1 on 11/09/2018): > > JDK-8212164???? resolve jre.list and jre.module.list > JDK-8212936???? Makefile and other improvements for jpackager > JDK-8213385???? jpackager Command-Line Argument File. > JDK-8213392???? Enhance --help and --version > JDK-8213425???? Analyze output from Source code scanner and fix where > needed. > JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk > JDK-8213748???? jpackager native launcher for macosx, linux. > JDK-8213756???? SingleInstance runtime improvements > JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails > JDK-8213963???? Flatten out jpackager packages and resources. > JDK-8214021???? Create additional automated tests for jpackager > JDK-8214051???? rename jpackager tool to jpackage > JDK-8214070???? Analyze and Fix issues reported by Parfait > JDK-8214143???? Reduce Resource files > JDK-8214495???? Change behavior of --license-file > JDK-8214575???? Exe installers will install application over existing > installation > JDK-8214899???? rename papplauncher and it's library and move src to > appropriate places > JDK-8214982???? jpackage causes failures in existing HelpFlagsTest and > VersionCheck tests > JDK-8215020???? create-jre-installer exe fails when --runtime-image is > specified. > JDK-8215036???? Create initial set of tests for jpackage > create-installer mode > JDK-8215453???? remove unused BundlerParams and fix misleading messages > JDK-8215515???? Add a command line option to override internal resources. > JDK-8215900???? Without --files args, only jars in the top level of > --input are added to class-path > JDK-8215903???? modify behavior of retaining temporary output dir > JDK-8216190???? Remove Single Instance Service support from jpackage > JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs > JDK-8216373???? temporary build-root left behind when using secondary > launcher(s) > JDK-8216492???? Update copyright of all new jpackage files to 2019 > > Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 > > Note: SingleInstanceService API was removed (see > https://bugs.openjdk.java.net/browse/JDK-8216190). > An example stand alone implementation can be found at: > http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java > > please send feedback to core-libs-dev at openjdk.java.net > > /Andy Herrick > From andy.herrick at oracle.com Tue Jan 15 14:11:52 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 15 Jan 2019 09:11:52 -0500 Subject: jpackage custom resources not found In-Reply-To: <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> Message-ID: <5eadaaa5-35b8-63df-34d7-38e5590b6771@oracle.com> On 1/15/2019 12:08 AM, Kustaa Nyholm wrote: > 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: /Users/nyholku/EazyCNC-Project/abuildroot > MacBook-Pro:EazyCNC-Project nyholku$ ls /Users/nyholku/EazyCNC-Project/abuildroot > ls: /Users/nyholku/EazyCNC-Project/abuildroot: No such file or directory On Mac and Linux, no resources are added to the --build-root dir when running in mode "create-image", so no dir is created.? It is a probably a bug that the verbose statement "Kept ..." is printed when that dir is non-existent. > Also, what is 'Runtime-Info.plist.template' and why would I want it? The default 'Runtime-Info.plist.template' in jpackage macosx resources is: > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > ??????? CFBundleDevelopmentRegion > ??????? English > ??????? CFBundleExecutable > ??????? libjli.dylib > ??????? CFBundleIdentifier > ??????? CF_BUNDLE_IDENTIFIER > ??????? CFBundleInfoDictionaryVersion > ??????? 7.0 > ??????? CFBundleName > ??????? CF_BUNDLE_NAME > ??????? CFBundlePackageType > ??????? BNDL > ??????? CFBundleShortVersionString > CF_BUNDLE_SHORT_VERSION_STRING > ??????? CFBundleSignature > ??????? ???? > ??????? CFBundleVersion > ??????? CF_BUNDLE_VERSION > > The values for the keys CF_BUNDLE_IDENTIFIER, CF_BUNDLE_NAME, CF_BUNDLE_VERSION, and CF_BUNDLE_SHORT_VERSION_STRING, are then replaced from the information available to jpackage, to create the apps Contents/Info.plist . > > I take it jpackage is not going to build the .dmg and I have to this with standard MacOs tools? > Ok I already do that as the old javapackager generated .dmg did not have the properties I liked > and now way to influence those. Running jpackage in "create-image" mode only creates the application , to create an installer (pkg or dmg on Mac) use mode "create-installer" You can do this all in one step "${PACKAGER} create-installer dmg " or in multiple steps using the --app-image option in the create-installer mode to point to an image created by running jpackage in the create-image mode.? By using two steps you may be able to customize the .dmg by modifying the image created by the first step.?? You may also be able to influence the properties you like by using --resource-dir to override resources used bu the installer (note --build-root dir will be created and kept in create-installer mode even on Mac) /Andy > > 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 > > PACKAGER=/Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/Home/bin/jpackage > > ${PACKAGER} --version > > ${PACKAGER} \ > create-image \ > --force \ > --build-root abuildroot \ > --verbose \ > --add-modules java.base,java.desktop,java.management,java.sql,java.instrument,java.compiler \ > --input buildtest \ > --output . \ > --name EazyCNC \ > --main-jar EazyCNC.jar \ > --class eazycnc.Main \ > --jvm-args '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+PrintGC' \ > --resource-dir 'javapackager-resources/package/macosx' > > > 'buildtest' is a flat directory that contains all my jars, I will next > figure out if has to be flat or what ever other ways I can use to > organise it better or specify the jars more rationally but as a starting > point that produces correct .app above seems to work for my case. > > wbr Kusti > > From kustaa.nyholm at sparetimelabs.com Tue Jan 15 14:23:18 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Tue, 15 Jan 2019 16:23:18 +0200 Subject: jpackage custom resources not found In-Reply-To: <5eadaaa5-35b8-63df-34d7-38e5590b6771@oracle.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <5eadaaa5-35b8-63df-34d7-38e5590b6771@oracle.com> Message-ID: <0C3BF4C6-A9B8-45D8-8570-D5FA842ABA66@sparetimelabs.com> > On 15 Jan 2019, at 16.11, Andy Herrick wrote: > > You can do this all in one step "${PACKAGER} create-installer dmg " Thank you for you help, I appreciate it. I tested above and it fails with what looks suspiciously same error I was experiencing with javapackager and jpackager, see below. I suspect this is related to High Sierra as I did not have these problems in my Yosemite machine. This is really not an issue for me because IIRC the resulting DMG did not have the version number of the application in the applications name which is what I prefer so I had to unpack the DMG anyway, change the file name and recreate the DMD thus I have all that machinery in place and it is actually simpler to start from the .app and not .dmg. Also IIRC there was an issue with the volume icon back then, obviously I've not checked if the is the case with jpackage. wbr Kusti [exec] Building DMG package for EazyCNC [exec] Building PKG package for EazyCNC [exec] Using custom package resource [icon] (loaded from EazyCNC.icns) [exec] Preparing Info.plist: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app/Contents/Info.plist [exec] Using custom package resource [Application Info.plist] (loaded from Info.plist) [exec] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) [exec] Using custom package resource [pkg background image] (loaded from EazyCNC-background.png) [exec] Preparing distribution.dist: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/distribution.dist [exec] no default package resource [script to run after application image is populated] (add EazyCNC-post-image.sh to the resource-dir to customize) [exec] Running [pkgbuild, --component, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app, --install-location, /Applications, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages/EazyCNC-app.pkg] [exec] pkgbuild: Adding component at /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app [exec] pkgbuild: Wrote package to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages/EazyCNC-app.pkg [exec] Running [productbuild, --resources, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config, --distribution, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/distribution.dist, --package-path, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC-1.0.pkg] [exec] productbuild: Wrote product to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC-1.0.pkg [exec] Using custom package resource [dmg background] (loaded from EazyCNC-background.png) [exec] Using custom package resource [volume icon] (loaded from EazyCNC-volume.icns) [exec] no default package resource [script to run after application image is populated] (add EazyCNC-post-image.sh to the resource-dir to customize) [exec] Preparing dmg setup: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt [exec] Using custom package resource [DMG setup script] (loaded from EazyCNC-dmg-setup.scpt) [exec] Creating DMG file: /Users/nyholku/EazyCNC-Project/./EazyCNC-1.0.dmg [exec] Running [/usr/bin/hdiutil, create, -quiet, -srcfolder, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625, -volname, EazyCNC, -ov, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/EazyCNC-tmp.dmg, -fs, HFS+, -format, UDRW] [exec] Running [/usr/bin/hdiutil, attach, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/EazyCNC-tmp.dmg, -quiet, -mountroot, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images] [exec] Running [osascript, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt] [exec] /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can?t be completed because there is already an item with that name. (-48) [exec] java.io.IOException: Exec failed with code 1 command [[osascript, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt] in unspecified directory [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:245) [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:216) [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:211) [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:316) [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:83) [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:477) [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:738) [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) [exec] at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) [exec] at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) [exec] jdk.jpackage.internal.PackagerException: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle. [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:744) [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) [exec] at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) [exec] at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) From andy.herrick at oracle.com Tue Jan 15 14:40:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 15 Jan 2019 09:40:46 -0500 Subject: jpackage custom resources not found In-Reply-To: <0C3BF4C6-A9B8-45D8-8570-D5FA842ABA66@sparetimelabs.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <5eadaaa5-35b8-63df-34d7-38e5590b6771@oracle.com> <0C3BF4C6-A9B8-45D8-8570-D5FA842ABA66@sparetimelabs.com> Message-ID: <889efe0a-a17b-217f-81cb-1207fecafbe7@oracle.com> I am running High Sierra too (10.13.3), and don't see this error with a simple test app. can you share with me the command options used, also if you specify --resource-dir what is in the directory pointed to ? /Andy On 1/15/2019 9:23 AM, Kustaa Nyholm wrote: > >> On 15 Jan 2019, at 16.11, Andy Herrick wrote: >> >> You can do this all in one step "${PACKAGER} create-installer dmg " > Thank you for you help, I appreciate it. > > I tested above and it fails with what looks suspiciously same error I was experiencing with > javapackager and jpackager, see below. I suspect this is related to High Sierra > as I did not have these problems in my Yosemite machine. > > This is really not an issue for me because IIRC the resulting DMG did > not have the version number of the application in the applications name > which is what I prefer so I had to unpack the DMG anyway, change the > file name and recreate the DMD thus I have all that machinery in place > and it is actually simpler to start from the .app and not .dmg. > > Also IIRC there was an issue with the volume icon back then, obviously > I've not checked if the is the case with jpackage. > > > wbr Kusti > > > [exec] Building DMG package for EazyCNC > [exec] Building PKG package for EazyCNC > [exec] Using custom package resource [icon] (loaded from EazyCNC.icns) > [exec] Preparing Info.plist: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app/Contents/Info.plist > [exec] Using custom package resource [Application Info.plist] (loaded from Info.plist) > [exec] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) > [exec] Using custom package resource [pkg background image] (loaded from EazyCNC-background.png) > [exec] Preparing distribution.dist: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/distribution.dist > [exec] no default package resource [script to run after application image is populated] (add EazyCNC-post-image.sh to the resource-dir to customize) > [exec] Running [pkgbuild, --component, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app, --install-location, /Applications, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages/EazyCNC-app.pkg] > [exec] pkgbuild: Adding component at /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC.app > [exec] pkgbuild: Wrote package to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages/EazyCNC-app.pkg > [exec] Running [productbuild, --resources, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config, --distribution, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/distribution.dist, --package-path, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/packages, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC-1.0.pkg] > [exec] productbuild: Wrote product to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625/EazyCNC-1.0.pkg > [exec] Using custom package resource [dmg background] (loaded from EazyCNC-background.png) > [exec] Using custom package resource [volume icon] (loaded from EazyCNC-volume.icns) > [exec] no default package resource [script to run after application image is populated] (add EazyCNC-post-image.sh to the resource-dir to customize) > [exec] Preparing dmg setup: /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt > [exec] Using custom package resource [DMG setup script] (loaded from EazyCNC-dmg-setup.scpt) > [exec] Creating DMG file: /Users/nyholku/EazyCNC-Project/./EazyCNC-1.0.dmg > [exec] Running [/usr/bin/hdiutil, create, -quiet, -srcfolder, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/image-15938535375331734625, -volname, EazyCNC, -ov, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/EazyCNC-tmp.dmg, -fs, HFS+, -format, UDRW] > [exec] Running [/usr/bin/hdiutil, attach, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images/EazyCNC-tmp.dmg, -quiet, -mountroot, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/images] > [exec] Running [osascript, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt] > [exec] /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can?t be completed because there is already an item with that name. (-48) > [exec] java.io.IOException: Exec failed with code 1 command [[osascript, /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/jdk.jpackage14173979925146552856/config/EazyCNC-dmg-setup.scpt] in unspecified directory > [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:245) > [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:216) > [exec] at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:211) > [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:316) > [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:83) > [exec] at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:477) > [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:738) > [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) > [exec] at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) > [exec] at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > [exec] jdk.jpackage.internal.PackagerException: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle. > [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:744) > [exec] at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) > [exec] at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) > [exec] at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > > > From Roger.Riggs at oracle.com Tue Jan 15 15:03:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 15 Jan 2019 10:03:34 -0500 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: References: Message-ID: <20a50ba9-90f1-919a-474f-a230e9e85905@oracle.com> Hi Goetz, Looks fine. Removing unnecessary special case code is great! Thanks, Roger On 01/15/2019 07:49 AM, Lindenmaier, Goetz wrote: > Hi, > > > > As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to LIBPATH anyways, so we can remove the special case for AIX. > > > > Please review this small cleanup. > > http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ > > > > Best regards, > > Goetz. > > > > (I posted this to hotspot-runtime-dev before, but seems to be placed better here) > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-January/032109.html > From rachel at strangenoises.org Tue Jan 15 15:18:41 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Tue, 15 Jan 2019 15:18:41 +0000 Subject: jpackage custom resources not found In-Reply-To: <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> Message-ID: surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you can put in a convenient system variable perhaps, or symlink it into your path somewhere. -- Rachel On 15/01/2019 12:09, Kustaa Nyholm wrote: > >> On 15 Jan 2019, at 12.57, Michael Hall wrote: >> >> Usually the latest jdk with the command would be the one you?d want? > Funnily enough, I wanted to quickly test something (jdeps) from the command line, > and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal > is to move all my stuff to jdk-11 and stay with that for next 5 years or so. > > For those who are not aware here is tip how to disable a jdk on MacOs: > > cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/ > sudo mv Info.plist Info.plist-disabled > > i.e. just rename the Info.plist so that it cannot be found by the tools, > after that command line tools reverted to jdk-11.0.1 > > wrb Kusti > > From Roger.Riggs at oracle.com Tue Jan 15 15:26:26 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 15 Jan 2019 10:26:26 -0500 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> Message-ID: <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> Hi Patrick, Attaching just the patch file that is text works fine and it can be applied directly using patch. I don't find a patch in your emails that I can apply directly (or am using the wrong tool). The allowed attachment types are occasionally mentioned.? [1] Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html On 01/15/2019 03:57 AM, Patrick Zhang wrote: > An attachment in the email has been found to contain executable code and has been removed. > > File removed : jdk-8215976.webrev.01.zip, zip,01/totalchangedlines,list,html,html,html,html,html,html,html,html,html,html,html,js > > ---------------------------------------------------------------------- > Hi Roger, > > Thanks for your review firstly. > Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). > <> > > Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). > > FYI. I sent out an almost same patch early on 3 Jan. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html > <> > > Regards > Patrick > > From: Roger Riggs > Sent: Monday, January 14, 2019 11:49 PM > To: Patrick Zhang > Cc: core-libs-dev > Subject: 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 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 well.) > > /Magnus > > > > > I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8215976 > > to cover this and linked to the discussion threads. > > The appropriate owners still need to review this, but I'm not sure who that may be these days. > > Cheers, > David > ----- > > > > Regards > Patrick > > -----Original Message----- > From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang > Sent: Thursday, December 6, 2018 4:28 PM > To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com > Cc: Florian Weimer mailto:fweimer at redhat.com > Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > To All, > Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. > > Regards > Patrick > > -----Original Message----- > From: David Holmes mailto:david.holmes at oracle.com > Sent: Monday, December 3, 2018 8:11 AM > To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com > Cc: mailto:core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > Hi Patrick, > > On 30/11/2018 11:41 pm, Patrick Zhang wrote: > > Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). > > Hi David, > Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. > > You'd need some assistance testing a wider range of platforms but that can be arranged. > > > In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. > _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. > > Cheers, > David > > > #ifdef _MSC_VER // Windows > #define gmtime_r(t, s) gmtime(t) > #endif > > Regards > Patrick > > -----Original Message----- > From: Florian Weimer mailto:fweimer at redhat.com > Sent: Thursday, November 29, 2018 8:02 PM > To: David Holmes mailto:david.holmes at oracle.com > Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; > mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include > inside zip.cpp comes from a non-sysroot path > > * David Holmes: > > > This should really be being discussed on core-libs-dev. > > Okay, moving the conversation. > > > diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp > --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 > +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 > @@ -415,9 +415,7 @@ > ??????? ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); > ??? } > ??? -#ifdef _REENTRANT // solaris > -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else > +#if !defined(_REENTRANT) // linux > ??? #define gmtime_r(t, s) gmtime(t) > ??? #endif > ??? /* > > Under the theme "two wrongs don't make a right" the use of _REENTRANT > here is totally inappropriate AFAICS. It seems to be a misguided > attempt at determining whether we need the thread-safe gmtime_r or > not > - and the answer to that should always be yes IMHO. > > We define _REENTRANT for: > - linux > - gcc > - xlc > > So the original code will define: > > extern "C" struct tm *gmtime_r(const time_t *, struct tm *); > > for linux (and AIX with xlc?) but not Solaris, OS X or Windows. > > But Solaris has gmtime_r anyway. So the existing code seems a really > convoluted hack. AFAICS we have gmtime_r everywhere but Windows > (where gmtime is already thread-safe). So it seems to me that all we > should need here is: > > -#ifdef _REENTRANT // solaris > -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else > +#ifdef _MSC_VER // Windows > ?? #define gmtime_r(t, s) gmtime(t) > ?? #endif > > That looks much cleaner. > > Thanks, > Florian > > From Alan.Bateman at oracle.com Tue Jan 15 15:43:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2019 15:43:24 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> On 15/01/2019 00:51, Ichiroh Takiguchi wrote: > 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. This looks okay, assuming it's `hg copy` of EUR_JP.template to create IBM29626C.java.template rather than a `hg mv` (the webrev makes it look like a move/rename). -Alan From goetz.lindenmaier at sap.com Tue Jan 15 15:55:33 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Jan 2019 15:55:33 +0000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <20a50ba9-90f1-919a-474f-a230e9e85905@oracle.com> References: <20a50ba9-90f1-919a-474f-a230e9e85905@oracle.com> Message-ID: Hi Roger, thanks for the review! Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Roger Riggs > Sent: Dienstag, 15. Januar 2019 16:04 > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to > LIBPATH > > Hi Goetz, > > Looks fine. > > Removing unnecessary special case code is great! > > Thanks, Roger > > > On 01/15/2019 07:49 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli > though has been moved from lib/jli/ to lib/. The path to lib/ is added to > LIBPATH anyways, so we can remove the special case for AIX. > > > > > > > > Please review this small cleanup. > > > > http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > (I posted this to hotspot-runtime-dev before, but seems to be placed better > here) > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019- > January/032109.html > > From Roger.Riggs at oracle.com Tue Jan 15 16:01:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 15 Jan 2019 11:01:38 -0500 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> Message-ID: Hi, I'd suggest using 2002, 2019, for the copyright, since much of the code in the new file comes from an older source. $.02, Roger On 01/15/2019 10:43 AM, Alan Bateman wrote: > On 15/01/2019 00:51, Ichiroh Takiguchi wrote: >> 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. > This looks okay, assuming it's `hg copy` of EUR_JP.template to create > IBM29626C.java.template rather than a `hg mv` (the webrev makes it > look like a move/rename). > > -Alan From mik3hall at gmail.com Tue Jan 15 16:04:11 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 10:04:11 -0600 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> Message-ID: > On Jan 15, 2019, at 9:18 AM, Rachel Greenham wrote: > > surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you can put in a convenient system variable perhaps, or symlink it into your path somewhere. > > -- > Rachel > > On 15/01/2019 12:09, Kustaa Nyholm wrote: >> >>> On 15 Jan 2019, at 12.57, Michael Hall wrote: >>> >>> Usually the latest jdk with the command would be the one you?d want? >> Funnily enough, I wanted to quickly test something (jdeps) from the command line, >> and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal >> is to move all my stuff to jdk-11 and stay with that for next 5 years or so. >> >> For those who are not aware here is tip how to disable a jdk on MacOs: >> >> cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/ >> sudo mv Info.plist Info.plist-disabled >> >> i.e. just rename the Info.plist so that it cannot be found by the tools, >> after that command line tools reverted to jdk-11.0.1 >> >> wrb Kusti >> >> > What advantage does this have over JavaVirtualMachines and /usr/libexec/java_home? There is a currently active JDK, from JavaVirtualMachines. I move the jdk-13 to my ~/Documents folder. Then? java -version openjdk version "12-internal" 2019-03-19 OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) is the current in the JavaVirtualMachines directory. Now I run jpackage like so? ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version jpackage version 13-internal Which is a little disappointing for the purposes of this demo. It was supposed to totally fail. I was told jpackage was only meant to work with jdk-13 but it clearly at least somewhat works with jdk-12. Still, this is not actually correct. I believe it is using the JavaVirtualMachines jdk-12 for any java and not the jdk-13 it is included with. You could probably get around that by setting JAVA_HOME and maybe setting the PATH environment variable. This is what I just did on an Ubunutu image on VirtualBox. However, it was not the Mac way from the very beginning. Why bother to do this when you can simply use the provided JavaVirtualMachines and /usr/libexec/java_home on OS X. As was pointed out in the prior posts. What advantage does another directory give you? What is being interfered with by using the JavaVirtualMachines directory? With /usr/libexec/java_home you can get any other java to use any of the other included jdk?s and an application can be made to use an embedded jre/jdk of whatever version. From andy.herrick at oracle.com Tue Jan 15 16:19:04 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 15 Jan 2019 11:19:04 -0500 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> Message-ID: On 1/15/2019 11:04 AM, Michael Hall wrote: > java -version > openjdk version "12-internal" 2019-03-19 > OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) > OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) This is the first jpackage EA build that was based on JDK12. The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds). Real JDK12 builds will not have jpackage. Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK. /Andy From rachel at strangenoises.org Tue Jan 15 16:25:40 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Tue, 15 Jan 2019 16:25:40 +0000 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> Message-ID: <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> ... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to be the default, you *only* want it to run jpackage *itself*, in create-image using --runtime-image pointing to your already jlinked runtime image using your usual JDK; then in create-installer, using --app-image to point to the image created in create-image. In all other respects you build your application with your usual JDK, this one is *just* for running jpackage, and only exists at all because jpackage isn't ready to go in the JDK proper yet. That's how it's working for me anyway. :-) I wonder if it would be easier if, while we're in this packager gap, to provide jpackage as a jlinked app image rather than a full jdk? Is that possible? -- Rachel On 15/01/2019 16:04, Michael Hall wrote: >> On Jan 15, 2019, at 9:18 AM, Rachel Greenham wrote: >> >> surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you can put in a convenient system variable perhaps, or symlink it into your path somewhere. >> >> -- >> Rachel >> >> On 15/01/2019 12:09, Kustaa Nyholm wrote: >>>> On 15 Jan 2019, at 12.57, Michael Hall wrote: >>>> >>>> Usually the latest jdk with the command would be the one you?d want? >>> Funnily enough, I wanted to quickly test something (jdeps) from the command line, >>> and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal >>> is to move all my stuff to jdk-11 and stay with that for next 5 years or so. >>> >>> For those who are not aware here is tip how to disable a jdk on MacOs: >>> >>> cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/ >>> sudo mv Info.plist Info.plist-disabled >>> >>> i.e. just rename the Info.plist so that it cannot be found by the tools, >>> after that command line tools reverted to jdk-11.0.1 >>> >>> wrb Kusti >>> >>> > What advantage does this have over JavaVirtualMachines and /usr/libexec/java_home? There is a currently active JDK, from JavaVirtualMachines. > I move the jdk-13 to my ~/Documents folder. Then? > > java -version > openjdk version "12-internal" 2019-03-19 > OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) > OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) > > is the current in the JavaVirtualMachines directory. > > Now I run jpackage like so? > > ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version > jpackage version 13-internal > > Which is a little disappointing for the purposes of this demo. It was supposed to totally fail. I was told jpackage was only meant to work with jdk-13 but it clearly at least somewhat works with jdk-12. > Still, this is not actually correct. I believe it is using the JavaVirtualMachines jdk-12 for any java and not the jdk-13 it is included with. You could probably get around that by setting JAVA_HOME and maybe setting the PATH environment variable. This is what I just did on an Ubunutu image on VirtualBox. However, it was not the Mac way from the very beginning. Why bother to do this when you can simply use the provided JavaVirtualMachines and /usr/libexec/java_home on OS X. As was pointed out in the prior posts. What advantage does another directory give you? What is being interfered with by using the JavaVirtualMachines directory? With /usr/libexec/java_home you can get any other java to use any of the other included jdk?s and an application can be made to use an embedded jre/jdk of whatever version. > From mik3hall at gmail.com Tue Jan 15 16:25:59 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 10:25:59 -0600 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> Message-ID: <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> > On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: > > > On 1/15/2019 11:04 AM, Michael Hall wrote: >> java -version >> openjdk version "12-internal" 2019-03-19 >> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) >> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) > > This is the first jpackage EA build that was based on JDK12. > The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds). > > Real JDK12 builds will not have jpackage. Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK. Yes, I had installed that version as well. The first EA. So removing the jdk-13 fell back to that one. ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version jpackage version 13-internal Shows the second EA jpackage can be explicitly invoked against a current jdk-12. But I understand it isn?t supported that way so why normally do it? Thanks for the additional information on the upcoming command availability. From mik3hall at gmail.com Tue Jan 15 16:33:40 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 10:33:40 -0600 Subject: jpackage custom resources not found In-Reply-To: <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> Message-ID: <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> > On Jan 15, 2019, at 10:25 AM, Rachel Greenham wrote: > > ... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to be the default, you *only* want it to run jpackage *itself*, in create-image using --runtime-image pointing to your already jlinked runtime image using your usual JDK; then in create-installer, using --app-image to point to the image created in create-image. In all other respects you build your application with your usual JDK, this one is *just* for running jpackage, and only exists at all because jpackage isn't ready to go in the JDK proper yet. > > Ah, well I had also sort of thought it would be a good idea to try my own app on something more bleeding edge. There are some things broken I need to address. But unless you have problems with something in the new release on default command line usage it seems you can easily control version in other scenarios. > That's how it's working for me anyway. :-) The above currently works for me. Different people have different preferences for how things work. > > I wonder if it would be easier if, while we're in this packager gap, to provide jpackage as a jlinked app image rather than a full jdk? Is that possible? Not sure on that. > > -- > Rachel From andy.herrick at oracle.com Tue Jan 15 16:35:11 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 15 Jan 2019 11:35:11 -0500 Subject: jpackage custom resources not found In-Reply-To: <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> Message-ID: <41061077-fef7-6233-0b17-657d18b3942a@oracle.com> On 1/15/2019 11:25 AM, Michael Hall wrote: >> On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: >> >> >> On 1/15/2019 11:04 AM, Michael Hall wrote: >>> java -version >>> openjdk version "12-internal" 2019-03-19 >>> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) >>> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) >> This is the first jpackage EA build that was based on JDK12. >> The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds). >> >> Real JDK12 builds will not have jpackage. Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK. > Yes, I had installed that version as well. The first EA. > So removing the jdk-13 fell back to that one. > > ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version > jpackage version 13-internal > > Shows the second EA jpackage can be explicitly invoked against a current jdk-12. But I understand it isn?t supported that way so why normally do it? Actually, once jpackage is invoked the path is not used. jpackage itself will run with the jre it comes with.? Without -- runtime-image specified, jpackage will package the app with runtime image it comes with.? If --runtime-image is specified, it will package the app with the specified runtime. /Andy > Thanks for the additional information on the upcoming command availability. > From mik3hall at gmail.com Tue Jan 15 16:43:01 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 10:43:01 -0600 Subject: jpackage custom resources not found In-Reply-To: <41061077-fef7-6233-0b17-657d18b3942a@oracle.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> <41061077-fef7-6233-0b17-657d18b3942a@oracle.com> Message-ID: <38C922AA-FEF7-474D-90E6-BE27CB72DA2C@gmail.com> > On Jan 15, 2019, at 10:35 AM, Andy Herrick wrote: > > > On 1/15/2019 11:25 AM, Michael Hall wrote: >>> On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: >>> >>> >>> On 1/15/2019 11:04 AM, Michael Hall wrote: >>>> java -version >>>> openjdk version "12-internal" 2019-03-19 >>>> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) >>>> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) >>> This is the first jpackage EA build that was based on JDK12. >>> The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds). >>> >>> Real JDK12 builds will not have jpackage. Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK. >> Yes, I had installed that version as well. The first EA. >> So removing the jdk-13 fell back to that one. >> >> ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version >> jpackage version 13-internal >> >> Shows the second EA jpackage can be explicitly invoked against a current jdk-12. But I understand it isn?t supported that way so why normally do it? > > Actually, once jpackage is invoked the path is not used. jpackage itself will run with the jre it comes with. Without -- runtime-image specified, jpackage will package the app with runtime image it comes with. If --runtime-image is specified, it will package the app with the specified runtime. > Thats interesting too. How does it manage to do that, to run with the JRE it?s packaged with if the command is invoked command line by absolute path? If nothing has been done to make the wrapping JDK an available JRE/JDK? Not in JavaVirtualMachines, no JAVA_HOME set, no JRE set up at all. From rachel at strangenoises.org Tue Jan 15 16:55:06 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Tue, 15 Jan 2019 16:55:06 +0000 Subject: jpackage custom resources not found In-Reply-To: <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> Message-ID: My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), and if you want to play with jdk13-ea in its own right, should probably get a fresh one to do just that, as the one used in these jpackage builds is not necessarily always going to be the most up to date, and also may have changes needed by jpackage that haven't been accepted upstream yet. In fact the latter seems almost likely to me as otherwise why not just include jpackage in the ea builds now? From my point of view, it's easy enough to do this, and the only downside is needing to exec it as its own process rather than invoke in-process via ToolProvider from my usual buildsystem jdk, which I intend to move to doing later when it is finally part of the JDK I'm actually building with. Wastes disk space too, but don't care about that, have plenty. :-) -- Rachel On 15/01/2019 16:33, Michael Hall wrote: >> On Jan 15, 2019, at 10:25 AM, Rachel Greenham wrote: >> >> ... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to be the default, you *only* want it to run jpackage *itself*, in create-image using --runtime-image pointing to your already jlinked runtime image using your usual JDK; then in create-installer, using --app-image to point to the image created in create-image. In all other respects you build your application with your usual JDK, this one is *just* for running jpackage, and only exists at all because jpackage isn't ready to go in the JDK proper yet. >> >> > Ah, well I had also sort of thought it would be a good idea to try my own app on something more bleeding edge. There are some things broken I need to address. But unless you have problems with something in the new release on default command line usage it seems you can easily control version in other scenarios. > > >> That's how it's working for me anyway. :-) > The above currently works for me. Different people have different preferences for how things work. > >> I wonder if it would be easier if, while we're in this packager gap, to provide jpackage as a jlinked app image rather than a full jdk? Is that possible? > Not sure on that. > >> -- >> Rachel From mik3hall at gmail.com Tue Jan 15 17:36:32 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 11:36:32 -0600 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> Message-ID: <1CFC23CE-FEB6-492E-9539-667F751EB757@gmail.com> > On Jan 15, 2019, at 10:55 AM, Rachel Greenham wrote: > > My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), True, which is a little different in and of itself, providing a JDK for a single command. I?m not that familiar yet with what jlink can do. How would it?s being a launchable app help in testing a command line tool? Is there some new magic way I haven?t heard of yet that jlink provides so that invoking something command line launches an app with the enclosing JDK? > and if you want to play with jdk13-ea in its own right, should probably get a fresh one to do just that, as the one used in these jpackage builds is not necessarily always going to be the most up to date, and also may have changes needed by jpackage that haven't been accepted upstream yet. In fact the latter seems almost likely to me as otherwise why not just include jpackage in the ea builds now? This could be true. So far I?ve assumed any issues I?ve seen are general JDK changes and not build specific. But sometime that could be a bad assumption. > > From my point of view, it's easy enough to do this, and the only downside is needing to exec it as its own process rather than invoke in-process via ToolProvider from my usual buildsystem jdk, which I intend to move to doing later when it is finally part of the JDK I'm actually building with. Wastes disk space too, but don't care about that, have plenty. :-) I think you talked about some of what you?re doing in earlier posts. I might have to look at those closer. I had disk space concerns installing VirtualBox with Ubunutu and Windows 10. But so far I still have enough. Other than that I?m pretty happy I stumbled on VirtualBox. I can finally make some of my stuff crossplatform and with jpackage I might even get reasonable app?s for each platform. From rachel at strangenoises.org Tue Jan 15 18:48:05 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Tue, 15 Jan 2019 18:48:05 +0000 Subject: jpackage custom resources not found In-Reply-To: <1CFC23CE-FEB6-492E-9539-667F751EB757@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> <1CFC23CE-FEB6-492E-9539-667F751EB757@gmail.com> Message-ID: <8f83f0f5-98eb-385c-32ea-8fc019f4cf62@strangenoises.org> On 15/01/2019 17:36, Michael Hall wrote: >> On Jan 15, 2019, at 10:55 AM, Rachel Greenham wrote: >> >> My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), > True, which is a little different in and of itself, providing a JDK for a single command. I?m not that familiar yet with what jlink can do. How would it?s being a launchable app help in testing a command line tool? Is there some new magic way I haven?t heard of yet that jlink provides so that invoking something command line launches an app with the enclosing JDK? you could create the jlinked app from the jdk they provide, something like (using the jlink in that jdk): jlink --add-modules jdk.jpackage --output jpackage This gives you a trimmed-down jre with just the modules that jdk.jpackage depends on. In bin is a jpackage executable. So you'd call jpackage/bin/jpackage . There's a bunch of other executables there (including java and javac) but they're only there because they belong in dependent modules. Assuming it has everything it needs, it would probably be functionally the same to use that or to use the jpackage in that jdk, but it's a third of the size, and providing it in that manner may better communicate that that's all that it's for, and not to try to use it as a complete jdk in its own right. I imagine you could also just remove the other binaries in bin so it could be safely added to your PATH and not be interfering with your using jdk. Caveat: I haven't tested any of that, except the jlink itself, and seeing the resulting jpackage give me its --help output. :-) Just explaining what jlink is for in this context. -- Rachel From lance.andersen at oracle.com Tue Jan 15 18:59:17 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 15 Jan 2019 13:59:17 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <5789840d-4f64-1e34-4259-23ad9c500165@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> <5789840d-4f64-1e34-4259-23ad9c500165@oracle.com> Message-ID: > On Jan 15, 2019, at 4:07 AM, Alan Bateman wrote: > > On 15/01/2019 00:13, Lance Andersen wrote: >> : >> >> Thank you Alan pointing out this example which the previous fix also did not address. I updated the change which addresses the above example as well as the relative path >> >> Please see http://cr.openjdk.java.net/~lancea/8211919/webrev.02/index.html >> > Good, this looks right now. Are you planning to re-visit the 1-4 comments at L426-433, just asking because point 4 is confusing as there isn't any code here that cares if the path starts with "./" or ?" > OK thank you. I made a ?minor update to the comments and removed ?4" > I don't have time right now to study all the test cases in ZipFsDirectoryStreamTests so I only skimmed through it. I assume all the places that catch IOException and print the stack trace should be cleaned up to not catch the exception as you want the test to fail if it can't open the zip file. I addressed this in each test > Also I assume "Zipfs" can be dropped from the name to be consistent with the existing test classes. Well I did that intentionally as one of the drawbacks with Intellij is running the tests within Intellij it gets awkward with too many tests using the same name. However for now I dropped the ZipFs from the test name > A minor nit is that the really long lines will be annoying for future side-by-side reviews of changes to this test. I pulled it into netbeans which makes it easier to see the width issues. Not sure if there is a way to enable similar functionality in Intellij? Updated webrev is at http://cr.openjdk.java.net/~lancea/8211919/webrev.03/index.html Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Tue Jan 15 19:00:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 15 Jan 2019 14:00:30 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> Message-ID: <70CBF256-F140-41FF-A18B-434AF697415C@oracle.com> Hi Christoph > On Jan 15, 2019, at 3:10 AM, Langer, Christoph wrote: > > Hi Lance, > >> Thank you for the feedback, please see below > Welcome, thanks for addressing my findings ?? > >> line 97: spelling: ?filter? >> fixed though was ?DirectoryStream.Filter? which I changed to >> DirectoryStream filter > > Hm, not quite yet... What I mean is still in line 96: > * Iterator correctly indicates whether the filer has been matched > -> I think you mean filter instead of filer here. > OK fixed >> line 309: you could use an import java.util.zip.ZipException? >> done, still getting used to Intellij vs Netbeans which I like better for import >> handling > I'm currently using Eclipse though I should try IntelliJ, too. As for imports, I would also think the org.testng.* imports should go after the java.* imports. But not sure if there's some official style guide for that. Well the ordering was done via Intellij so I am going to leave that for now. > > Overall, looks good to me now. (The latest webrev, that addresses Alan's point, too) Thank you. Best Lance > > Best regards > Christoph > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Tue Jan 15 20:48:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 15 Jan 2019 15:48:59 -0500 Subject: RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent Message-ID: Please review a doc-only change to serial filter descriptions to use the term "system-wide" to describe the scope of configurable filters. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-system-wide-8202675/ CSR: ? https://bugs.openjdk.java.net/browse/JDK-8216289 Thanks, Roger From Alan.Bateman at oracle.com Tue Jan 15 20:52:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2019 20:52:18 +0000 Subject: RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent In-Reply-To: References: Message-ID: <44f23ec3-e984-50f8-7ee6-418eb1bb9589@oracle.com> On 15/01/2019 20:48, Roger Riggs wrote: > Please review a doc-only change to serial filter descriptions to use > the term > "system-wide" to describe the scope of configurable filters. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-system-wide-8202675/ > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8216289 This looks okay. -Alan From lance.andersen at oracle.com Tue Jan 15 20:54:39 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 15 Jan 2019 15:54:39 -0500 Subject: RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent In-Reply-To: References: Message-ID: <004ECE88-A222-4FF0-87DD-B6D9B722C812@oracle.com> Looks fine Roger and aligns with the CSR as expected :-) > On Jan 15, 2019, at 3:48 PM, Roger Riggs wrote: > > Please review a doc-only change to serial filter descriptions to use the term > "system-wide" to describe the scope of configurable filters. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-system-wide-8202675/ > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8216289 > > Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Tue Jan 15 20:55:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2019 20:55:15 +0000 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> <5789840d-4f64-1e34-4259-23ad9c500165@oracle.com> Message-ID: <4abe80c0-9f76-077b-f9e8-469796800d89@oracle.com> On 15/01/2019 18:59, Lance Andersen wrote: > > OK thank you. ?I made a ?minor update to the comments and removed ?4" Looks good. I also skimmed the update test and it looks okay too except setUp and tearDown where it still catches exception so the methods succeed when they fail. Maybe setUp could be changed to not catch the IOException. No need for a new webrev if you do that. -Alan From mik3hall at gmail.com Tue Jan 15 21:00:41 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 15:00:41 -0600 Subject: jpackage custom resources not found In-Reply-To: <8f83f0f5-98eb-385c-32ea-8fc019f4cf62@strangenoises.org> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <8c0a05a7-1594-4963-73e8-a274ae95dad3@strangenoises.org> <76960B09-81EA-42CF-90F0-5CA963CCAEF4@gmail.com> <1CFC23CE-FEB6-492E-9539-667F751EB757@gmail.com> <8f83f0f5-98eb-385c-32ea-8fc019f4cf62@strangenoises.org> Message-ID: <0020F425-5954-433A-B572-9C7D8684EBEE@gmail.com> > On Jan 15, 2019, at 12:48 PM, Rachel Greenham wrote: > > On 15/01/2019 17:36, Michael Hall wrote: >>> On Jan 15, 2019, at 10:55 AM, Rachel Greenham wrote: >>> >>> My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), >> True, which is a little different in and of itself, providing a JDK for a single command. I?m not that familiar yet with what jlink can do. How would it?s being a launchable app help in testing a command line tool? Is there some new magic way I haven?t heard of yet that jlink provides so that invoking something command line launches an app with the enclosing JDK? > > you could create the jlinked app from the jdk they provide, something like (using the jlink in that jdk): > > jlink --add-modules jdk.jpackage --output jpackage > > This gives you a trimmed-down jre with just the modules that jdk.jpackage depends on. In bin is a jpackage executable. So you'd call jpackage/bin/jpackage . There's a bunch of other executables there (including java and javac) but they're only there because they belong in dependent modules. > > Assuming it has everything it needs, it would probably be functionally the same to use that or to use the jpackage in that jdk, but it's a third of the size, and providing it in that manner may better communicate that that's all that it's for, and not to try to use it as a complete jdk in its own right. I imagine you could also just remove the other binaries in bin so it could be safely added to your PATH and not be interfering with your using jdk. > > Caveat: I haven't tested any of that, except the jlink itself, and seeing the resulting jpackage give me its --help output. :-) Just explaining what jlink is for in this context. > > -- > Rachel Thanks for the answer. I still have to do more with these tools including jlink myself. Mike Hall From david.holmes at oracle.com Tue Jan 15 21:12:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2019 07:12:21 +1000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <20a50ba9-90f1-919a-474f-a230e9e85905@oracle.com> References: <20a50ba9-90f1-919a-474f-a230e9e85905@oracle.com> Message-ID: +1 Thanks, David On 16/01/2019 1:03 am, Roger Riggs wrote: > Hi Goetz, > > Looks fine. > > Removing unnecessary special case code is great! > > Thanks, Roger > > > On 01/15/2019 07:49 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> >> >> As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. >> libjli though has been moved from lib/jli/ to lib/. The path to lib/ >> is added to LIBPATH anyways, so we can remove the special case for AIX. >> >> >> >> Please review this small cleanup. >> >> http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ >> >> >> >> Best regards, >> >> ?? Goetz. >> >> >> >> (I posted this to hotspot-runtime-dev before, but seems to be placed >> better here) >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-January/032109.html >> >> > From lance.andersen at oracle.com Tue Jan 15 21:27:02 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 15 Jan 2019 16:27:02 -0500 Subject: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory In-Reply-To: <4abe80c0-9f76-077b-f9e8-469796800d89@oracle.com> References: <9C1A347C-D6B5-4DED-AE3D-C882A484E2D7@oracle.com> <084f22c5-0434-868f-133a-a0092ea1c794@oracle.com> <0DC4AF88-FE45-43CE-A346-75D901705326@oracle.com> <5789840d-4f64-1e34-4259-23ad9c500165@oracle.com> <4abe80c0-9f76-077b-f9e8-469796800d89@oracle.com> Message-ID: > On Jan 15, 2019, at 3:55 PM, Alan Bateman wrote: > > > > On 15/01/2019 18:59, Lance Andersen wrote: >> >> OK thank you. I made a ?minor update to the comments and removed ?4" > Looks good. I also skimmed the update test and it looks okay too except setUp and tearDown where it still catches exception so the methods succeed when they fail. Maybe setUp could be changed to not catch the IOException. No need for a new webrev if you do that. OK, I made that change. I also made 1 more change as I added back: -------- private static final Map UNZIPFS_MAP = Map.of(); -------- And all tests use that to open the jar files vs.ZIPFS_MAP which sets create=true so that the test do not create the jar if it does not already exist http://cr.openjdk.java.net/~lancea/8211919/webrev.04/index.html has the update if you want to look at it. I will push tomorrow Thank you for the review! Best Lance > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Tue Jan 15 23:19:42 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 15 Jan 2019 15:19:42 -0800 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> Message-ID: <4be24258-d644-04a0-6667-e5e425059692@oracle.com> On 1/14/19 7:41 PM, Joe Darcy wrote: > PS And for good measure, made analogous changes in Executable.java: > > ??? http://cr.openjdk.java.net/~darcy/8217000.1/ Thanks for following up on this. Overall, looks good. One point: 114 sb.append('('); 115 116 sb.append(Arrays.stream(parameterTypes) 117 .map(Type::getTypeName) 118 .collect(Collectors.joining(","))); 119 120 sb.append(')'); I think you can use the 3-arg form of joining() here, since the prefix and suffix are included even if the stream is empty. s'marks From swpalmer at gmail.com Wed Jan 16 00:55:55 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 15 Jan 2019 19:55:55 -0500 Subject: jpackage custom resources not found In-Reply-To: <38C922AA-FEF7-474D-90E6-BE27CB72DA2C@gmail.com> References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> <41061077-fef7-6233-0b17-657d18b3942a@oracle.com> <38C922AA-FEF7-474D-90E6-BE27CB72DA2C@gmail.com> Message-ID: > On Jan 15, 2019, at 11:43 AM, Michael Hall wrote: >> On Jan 15, 2019, at 10:35 AM, Andy Herrick wrote: >> On 1/15/2019 11:25 AM, Michael Hall wrote: >>>> On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: >>>> >>>> On 1/15/2019 11:04 AM, Michael Hall wrote: >>>>> java -version >>>>> openjdk version "12-internal" 2019-03-19 >>>>> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) >>>>> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) >>>> This is the first jpackage EA build that was based on JDK12. >>>> The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds). >>>> >>>> Real JDK12 builds will not have jpackage. Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK. >>> Yes, I had installed that version as well. The first EA. >>> So removing the jdk-13 fell back to that one. >>> >>> ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version >>> jpackage version 13-internal >>> >>> Shows the second EA jpackage can be explicitly invoked against a current jdk-12. But I understand it isn?t supported that way so why normally do it? >> >> Actually, once jpackage is invoked the path is not used. jpackage itself will run with the jre it comes with. Without -- runtime-image specified, jpackage will package the app with runtime image it comes with. If --runtime-image is specified, it will package the app with the specified runtime. >> > Thats interesting too. How does it manage to do that, to run with the JRE it?s packaged with if the command is invoked command line by absolute path? I believe that is how all the commands in the bin folder of the JDK work - intentionally. > If nothing has been done to make the wrapping JDK an available JRE/JDK? Not in JavaVirtualMachines, no JAVA_HOME set, no JRE set up at all. You are explicitly invoking commands of that JDK. What would you expect if you ran ?~/Documents/jdk-13.jdk/Contents/home/bin/java? ? Regards, Scott From patrick at os.amperecomputing.com Wed Jan 16 02:23:15 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Wed, 16 Jan 2019 02:23:15 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> Message-ID: Re-generated the patch in pure text using ?hg export -o? instead of webrev, perhaps this could work (see attached please). Comments had been updated as well according to David?s input. Thanks Regards Patrick From: Roger Riggs Sent: Tuesday, January 15, 2019 11:26 PM To: Patrick Zhang Cc: core-libs-dev Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, Attaching just the patch file that is text works fine and it can be applied directly using patch. I don't find a patch in your emails that I can apply directly (or am using the wrong tool). The allowed attachment types are occasionally mentioned. [1] Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html On 01/15/2019 03:57 AM, Patrick Zhang wrote: An attachment in the email has been found to contain executable code and has been removed. File removed : jdk-8215976.webrev.01.zip, zip,01/totalchangedlines,list,html,html,html,html,html,html,html,html,html,html,html,js ---------------------------------------------------------------------- Hi Roger, Thanks for your review firstly. Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). <> Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). FYI. I sent out an almost same patch early on 3 Jan. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html <> Regards Patrick From: Roger Riggs Sent: Monday, January 14, 2019 11:49 PM To: Patrick Zhang Cc: core-libs-dev Subject: 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 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 well.) /Magnus I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- Regards Patrick -----Original Message----- From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang Sent: Thursday, December 6, 2018 4:28 PM To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com Cc: Florian Weimer mailto:fweimer at redhat.com Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes mailto:david.holmes at oracle.com Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com Cc: mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). Hi David, Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David #ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif Regards Patrick -----Original Message----- From: Florian Weimer mailto:fweimer at redhat.com Sent: Thursday, November 29, 2018 8:02 PM To: David Holmes mailto:david.holmes at oracle.com Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path * David Holmes: This should really be being discussed on core-libs-dev. Okay, moving the conversation. diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 @@ -415,9 +415,7 @@ ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#if !defined(_REENTRANT) // linux #define gmtime_r(t, s) gmtime(t) #endif /* Under the theme "two wrongs don't make a right" the use of _REENTRANT here is totally inappropriate AFAICS. It seems to be a misguided attempt at determining whether we need the thread-safe gmtime_r or not - and the answer to that should always be yes IMHO. We define _REENTRANT for: - linux - gcc - xlc So the original code will define: extern "C" struct tm *gmtime_r(const time_t *, struct tm *); for linux (and AIX with xlc?) but not Solaris, OS X or Windows. But Solaris has gmtime_r anyway. So the existing code seems a really convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where gmtime is already thread-safe). So it seems to me that all we should need here is: -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif That looks much cleaner. Thanks, Florian From patrick at os.amperecomputing.com Wed Jan 16 02:30:13 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Wed, 16 Jan 2019 02:30:13 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> Message-ID: Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. # HG changeset patch # User patrickz # Date 1546508379 -28800 # Thu Jan 03 17:39:39 2019 +0800 # Node ID 0a90eb1de8e4e6c87a6643072e00645d5dde9da2 # Parent 0b2574a2a6c7816e6a7b6fc05de18318a2b6e561 8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files diff -r 0b2574a2a6c7 -r 0a90eb1de8e4 src/jdk.pack/share/native/common-unpack/zip.cpp --- a/src/jdk.pack/share/native/common-unpack/zip.cpp Tue Jan 15 08:03:30 2019 +0100 +++ b/src/jdk.pack/share/native/common-unpack/zip.cpp Thu Jan 03 17:39:39 2019 +0800 @@ -416,9 +416,11 @@ ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +/* + * For thread-safe reasons, non-Windows platforms need gmtime_r + * while Windows can directly use gmtime that is already thread-safe. + */ +#ifdef _MSC_VER #define gmtime_r(t, s) gmtime(t) #endif /* Regards Patrick -----Original Message----- From: core-libs-dev On Behalf Of Patrick Zhang Sent: Wednesday, January 16, 2019 10:23 AM To: Roger Riggs ; David Holmes Cc: core-libs-dev Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Re-generated the patch in pure text using ?hg export -o? instead of webrev, perhaps this could work (see attached please). Comments had been updated as well according to David?s input. Thanks Regards Patrick From: Roger Riggs Sent: Tuesday, January 15, 2019 11:26 PM To: Patrick Zhang Cc: core-libs-dev Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, Attaching just the patch file that is text works fine and it can be applied directly using patch. I don't find a patch in your emails that I can apply directly (or am using the wrong tool). The allowed attachment types are occasionally mentioned. [1] Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html On 01/15/2019 03:57 AM, Patrick Zhang wrote: An attachment in the email has been found to contain executable code and has been removed. File removed : jdk-8215976.webrev.01.zip, zip,01/totalchangedlines,list,html,html,html,html,html,html,html,html,html,html,html,js ---------------------------------------------------------------------- Hi Roger, Thanks for your review firstly. Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). <> Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration of gmtime_r can be near to where it gets used (line 436 in the patch). FYI. I sent out an almost same patch early on 3 Jan. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057679.html <> Regards Patrick From: Roger Riggs Sent: Monday, January 14, 2019 11:49 PM To: Patrick Zhang Cc: core-libs-dev Subject: 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 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 well.) /Magnus I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. I have filed: https://bugs.openjdk.java.net/browse/JDK-8215976 to cover this and linked to the discussion threads. The appropriate owners still need to review this, but I'm not sure who that may be these days. Cheers, David ----- Regards Patrick -----Original Message----- From: core-libs-dev mailto:core-libs-dev-bounces at openjdk.java.net On Behalf Of Patrick Zhang Sent: Thursday, December 6, 2018 4:28 PM To: mailto:core-libs-dev at openjdk.java.net; David Holmes mailto:david.holmes at oracle.com Cc: Florian Weimer mailto:fweimer at redhat.com Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes mailto:david.holmes at oracle.com Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang mailto:patrick at os.amperecomputing.com; Florian Weimer mailto:fweimer at redhat.com Cc: mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). Hi David, Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David #ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif Regards Patrick -----Original Message----- From: Florian Weimer mailto:fweimer at redhat.com Sent: Thursday, November 29, 2018 8:02 PM To: David Holmes mailto:david.holmes at oracle.com Cc: Patrick Zhang mailto:patrick at os.amperecomputing.com; mailto:jdk-dev at openjdk.java.net; mailto:core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path * David Holmes: This should really be being discussed on core-libs-dev. Okay, moving the conversation. diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 @@ -415,9 +415,7 @@ ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#if !defined(_REENTRANT) // linux #define gmtime_r(t, s) gmtime(t) #endif /* Under the theme "two wrongs don't make a right" the use of _REENTRANT here is totally inappropriate AFAICS. It seems to be a misguided attempt at determining whether we need the thread-safe gmtime_r or not - and the answer to that should always be yes IMHO. We define _REENTRANT for: - linux - gcc - xlc So the original code will define: extern "C" struct tm *gmtime_r(const time_t *, struct tm *); for linux (and AIX with xlc?) but not Solaris, OS X or Windows. But Solaris has gmtime_r anyway. So the existing code seems a really convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where gmtime is already thread-safe). So it seems to me that all we should need here is: -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +#ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif That looks much cleaner. Thanks, Florian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gmtime.txt URL: From joe.darcy at oracle.com Wed Jan 16 03:05:05 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Jan 2019 19:05:05 -0800 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: <4be24258-d644-04a0-6667-e5e425059692@oracle.com> References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> <4be24258-d644-04a0-6667-e5e425059692@oracle.com> Message-ID: Good catch on the 3-argument joining in this case; I'll push with that amendment. Thanks for the review, -Joe On 1/15/2019 3:19 PM, Stuart Marks wrote: > > > On 1/14/19 7:41 PM, Joe Darcy wrote: >> PS And for good measure, made analogous changes in Executable.java: >> >> ???? http://cr.openjdk.java.net/~darcy/8217000.1/ > > Thanks for following up on this. Overall, looks good. One point: > > ?114???????????? sb.append('('); > ?115 > ?116???????????? sb.append(Arrays.stream(parameterTypes) > ?117?????????????????????? .map(Type::getTypeName) > ?118?????????????????????? .collect(Collectors.joining(","))); > ?119 > ?120???????????? sb.append(')'); > > I think you can use the 3-arg form of joining() here, since the prefix > and suffix are included even if the stream is empty. > > s'marks From mik3hall at gmail.com Wed Jan 16 04:29:11 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Jan 2019 22:29:11 -0600 Subject: jpackage custom resources not found In-Reply-To: References: <3B6069E2-12F5-4914-9C18-5B409715E683@sparetimelabs.com> <1DB18219-1191-4D6E-9EF5-96C45D3E2B1C@sparetimelabs.com> <904AE29D-DB68-4239-8698-D823ABB79239@sparetimelabs.com> <5F29F458-0936-404C-B99A-A581A110D83D@gmail.com> <41061077-fef7-6233-0b17-657d18b3942a@oracle.com> <38C922AA-FEF7-474D-90E6-BE27CB72DA2C@gmail.com> Message-ID: <61341A06-F557-4F13-97AE-87FA3786635E@gmail.com> > On Jan 15, 2019, at 6:55 PM, Scott Palmer wrote: > > > You are explicitly invoking commands of that JDK. What would you expect if you ran ?~/Documents/jdk-13.jdk/Contents/home/bin/java? ? You are explicitly invoking a binary executable. I would of expected it to try and run against whatever the current default JDK is. In this case jdk-12. But you are correct I tried it with java -version and it did in fact say jdk-13. I didn?t know that it included code to check and see if it was included with some JDK other than the default. There is some magic. From matthias.baesken at sap.com Wed Jan 16 08:42:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 08:42:46 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows Message-ID: Hello, please review this small adjustment to parse_manifest.c . It adds support for extended - length paths (on Window) . (see https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation For extended length paths ) Additionally , some small memory leaks are fixed in find_file . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217093 http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.0/ Best rergards, Matthias From Alan.Bateman at oracle.com Wed Jan 16 08:50:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 08:50:37 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: Message-ID: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> On 16/01/2019 08:42, Baesken, Matthias wrote: > Hello, please review this small adjustment to parse_manifest.c . > It adds support for extended - length paths (on Window) . > > (see https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation > For extended length paths ) > > Additionally , some small memory leaks are fixed in find_file . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8217093 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.0/ > If I read this correctly then it will prepend \\?\ which is consistent with what we do in other areas of the platform when presented with a long file name. Have you looked at moving open_jarfile to a platform specific source file?, in this case it might be better if the WIndows specific code were in src/java.base/windows/native/libjli for example. -Alan From matthias.baesken at sap.com Wed Jan 16 09:07:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 09:07:35 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> Message-ID: Hi Alan, I thought having UNIX+Windows code in this case together at one place would be okay . However, if you prefer separating it, should I put it here ? src/java.base/windows/native/libjli/java_md.c Or do you have a better suggestion ? Best regards, Matthias > From: Alan Bateman > Sent: Mittwoch, 16. Januar 2019 09:51 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 16/01/2019 08:42, Baesken, Matthias wrote: > > Hello, please review this small adjustment to parse_manifest.c . > > It adds support for extended - length paths (on Window) . > > > > (see https://docs.microsoft.com/en-us/windows/desktop/fileio/naming- > a-file#maximum-path-length-limitation > > For extended length paths ) > > > > Additionally , some small memory leaks are fixed in find_file . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8217093 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.0/ > > > If I read this correctly then it will prepend \\?\ which is consistent > with what we do in other areas of the platform when presented with a > long file name. Have you looked at moving open_jarfile to a platform > specific source file?, in this case it might be better if the WIndows > specific code were in src/java.base/windows/native/libjli for example. > > -Alan From forax at univ-mlv.fr Wed Jan 16 09:21:26 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Jan 2019 10:21:26 +0100 (CET) Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> <4be24258-d644-04a0-6667-e5e425059692@oracle.com> Message-ID: <148940069.658971.1547630486633.JavaMail.zimbra@u-pem.fr> Hi Joe, in j.l.Class, in methodToString, can you change sb.append(getName() + "." + name + "("); to sb.append(getName()).append(".").append(name).append('('); because using the concatenation inside a StringBuilder creates another StringBuilder (java.lang doesn't use the StringConcatFactory). also return typeVar.getName() + " extends " + Arrays.stream(bounds) .map(Type::getTypeName) .collect(Collectors.joining(" & ")); can be written return Arrays.stream(bounds) .map(Type::getTypeName) .collect(Collectors.joining(" & ", typeVar.getName().concat(" extends "), "")); which also avoid the creation of an intermediary StringBuilder (at the cost of the code being less readable). (in that case, you have also to change the same code in Executable). regards, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "Stuart Marks" > Cc: "core-libs-dev" > Envoy?: Mercredi 16 Janvier 2019 04:05:05 > Objet: Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString > Good catch on the 3-argument joining in this case; I'll push with that > amendment. > > Thanks for the review, > > -Joe > > On 1/15/2019 3:19 PM, Stuart Marks wrote: >> >> >> On 1/14/19 7:41 PM, Joe Darcy wrote: >>> PS And for good measure, made analogous changes in Executable.java: >>> >>> ???? http://cr.openjdk.java.net/~darcy/8217000.1/ >> >> Thanks for following up on this. Overall, looks good. One point: >> >> ?114???????????? sb.append('('); >> ?115 >> ?116???????????? sb.append(Arrays.stream(parameterTypes) >> ?117?????????????????????? .map(Type::getTypeName) >> ?118?????????????????????? .collect(Collectors.joining(","))); >> ?119 >> ?120???????????? sb.append(')'); >> >> I think you can use the 3-arg form of joining() here, since the prefix >> and suffix are included even if the stream is empty. >> > > s'marks From Alan.Bateman at oracle.com Wed Jan 16 09:37:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 09:37:08 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> Message-ID: <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> On 16/01/2019 09:07, Baesken, Matthias wrote: > Hi Alan, I thought having UNIX+Windows code in this case together at one place would be okay . > However, if you prefer separating it, should I put it here ? > > src/java.base/windows/native/libjli/java_md.c > > Or do you have a better suggestion ? > With a few exceptions, the Windows specific code for jli.dll is in src/java.base/windows/native/libji so if it's not too difficult then I think that should be location for the Windows long path support. It's might be parse_manifest_md.c rather than java_md.c as the latter is the platform specific code to go with launcher code in java.c. -Alan From adinn at redhat.com Wed Jan 16 11:23:10 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 16 Jan 2019 11:23:10 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> Message-ID: <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> Hi Alan/Brian, I have finally been able to shelve other commitments and return to this JEP (apologies for the hiatus). https://openjdk.java.net/jeps/8207851 The JEP has been reviewed positively by Stuart Marks (core libs) and Vladimir Kozlov (intrinsics). It has also been warmly welcomed by several potential users in Red Hat and Intel (including, respectively, Jonathan Halliday and Sandya Viswanathan both in cc). I believe I have addressed all outstanding comments on the JEP per se, including those made by Alan. Is it now possible for one of you to endorse the JEP so it can be submitted? I am aware that I still need to address a few details in the draft implementation that are not present in the latest webrev. I believe there are two changes requested by Vladimir: 1. correct the type of cache writeback memory nodes to generic memory 2. use the JVM to inject a flag setting which enables/disables mapping of persistent buffers and also one change requested by Alan: make method MappedByteBuffer.isPersistent private rather than public Is there any other impediment to submitting the JEP and proceeding to code review? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From maurizio.cimadamore at oracle.com Wed Jan 16 12:07:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jan 2019 12:07:34 +0000 Subject: Lazy memory initialization for Unsafe (calloc vs. malloc) In-Reply-To: References: Message-ID: <310950e3-c22f-32ef-d1ce-546ec0af2f7c@oracle.com> Hi Markus, (moving to panama-dev) I've been pointed at your message by a colleague, I believe it is very relevant to the context of the Panama offheap API, since that API is internally using unsafe to allocate native memory. As far as I'm aware, our Scope class is internally just calling Unsafe::allocateMemory, and leaving memory uninitialized, as per malloc (which means it's up to the application to initialize the memory if really necessary). Adding an alternate way to initialize memory doesn't sound bad - but I have some questions over the proposed approach * while adding a new method to Unsafe seems like the most natural path, please be aware that we have committed to reduce the footprint of that API over time; your proposal goes in the opposite direction. That said, we could still have some internal functionality for performing calloc that is only used internally by the Panama offheap API * I'm not an expert in the area, but I'm wondering whether the lazy zeroing scheme is truly cross-platform as opposed to being just a Linux optimization; of course adding a new functionality that adds benefit on a single platform has a different cost compared to adding something that provides advantages across the board Cheers Maurizio On 05/11/2018 19:49, mail.openjdk.java.net at lemmster.de wrote: > Hi, > > lets assume an application A [1] which is optimized for throughput, not > latency. Additionally, A reverts to sun.misc.Unsafe to store gigabytes > of data on off-heap memory to e.g. improved memory utilization and > performance. > > Due to the fact that Unsafe#allocateMemory returns an uninitialized > (malloc) memory region R, app A has to explicitly initialize R by e.g. > calling Unsafe#setMemory?. > > Since app A is optimized for throughput, there is no real need to > eagerly allocate R. Instead - on OSes with an optimistic memory > allocator such as Linux - app A could benefit from lazy allocation. This > would reduce app startup time that - that today is linear in the size of > R - to constant time. Assuming Unsafe (or some other API) would expose > memory allocation with calloc instead of malloc one would get away > without explicitly calling Unsafe#setMemory or implementing (complex) > lazy initialization into A itself. > > > To check this idea, I added sun.misc.Unsafe#callocateMemory (notice the > "c") to a local jdk12 build. It works as intended. Is this feature a > candidate to be added to the JVM, e.g. as part of project Panama or am I > better off rolling my own solution via JNI? > > Thanks > Markus > > ? Lets assume the application logic cannot deal with uninitialized memory. > > [1] https://github.com/tlaplus/tlaplus > > > > > > From takiguc at linux.vnet.ibm.com Wed Jan 16 12:32:06 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 16 Jan 2019 21:32:06 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> Message-ID: <956e5876b1a32bff65931cd844cb86bd@linux.vnet.ibm.com> Hello Alan and Roger. I appreciate your suggestions. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.02/ I used "hg cp" command. If I should use git format, please let me know. I changed Copyright year on IBM29626C.java.template and charsets file. Thanks, Ichiroh Takiguchi On 2019-01-16 01:01, Roger Riggs wrote: > Hi, > > I'd suggest using 2002, 2019, for the copyright, since much of the > code in the new > file comes from an older source. > > $.02, Roger > > > On 01/15/2019 10:43 AM, Alan Bateman wrote: >> On 15/01/2019 00:51, Ichiroh Takiguchi wrote: >>> 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. >> This looks okay, assuming it's `hg copy` of EUR_JP.template to create >> IBM29626C.java.template rather than a `hg mv` (the webrev makes it >> look like a move/rename). >> >> -Alan From thomas.stuefe at gmail.com Wed Jan 16 14:25:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 15:25:58 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Hi Gunter, (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, respectively. Hope this is not too spammy). This looks all very good. I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, so I am not sure if I am allowed to review the JFR parts. That said, here it goes: General remarks: A) we may reduce the number of sent events vastly by only sending updates for threads which actually did IO. I know that would require expanding the ThreadStatisticalInfo to keep JFR-specific counters. But I think the memory overhead of the increased size of ThreadStatisticalInfo would be more than offset by the space saved for noop events. What to you think? (Side note, it would be nice to have generic support for this in the JFR layer. If the JFR layer could remember the last values for an event and omit sending it if nothing changed.) B) You could save a bit of work by folding multiple values into one event. Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you could have ThreadNetworkStatistics with "read" and "write" fields, and thus combine the polling functions for those two. Maybe even combine all four values into a single "ThreadIOStatistics" event. Review: Hook functions: - This is bike shedding, but I would like something like "JVM_On()" more, sounding more "hookish", since the functions do not "xxx" but inform the hotspot of "xxx" having occurred - Also, I wonder whether it would make sense to make the len input 64bit (jlong instead of jint) in case we want to use them to instrument 64bit reads too - If you wanted to minimize the number of new JVM_.. hook functions, you could combine network and file io hooks into one: JVM_OnIORead(.. bool is_socket) JVM_OnIOWrite(.. bool is_socket) or even JVM_OnIO(.., bool is_read, bool is_socket). This would also make the dispatching in src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this is pure aesthetics, I leave it up to you. --- src/hotspot/share/jfr/metadata/metadata.xml All event definitions have one value, called and labeled "Thread". If you keep them separate, does this field name/label make sense? (I am not fluid with JMC so I do not know where exactly this label text would appear). --- src/hotspot/share/jfr/periodic/jfrPeriodic.cpp GrowableArray written(initial_size); GrowableArray thread_ids(initial_size); You could probably save one GrowableArray and some append calls by something like this: struct data { jlong num; trace_id tid; } GrowableArray - Question, I assume you go thru the trouble of storing the values temporarily since you do not want to call JfrEvent::commit inside the Threads_lock? --- src/hotspot/share/runtime/thread.cpp Nice addition to the extended thread dump. --- src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c - There may be a number of unnecessary casts: e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 JVM_callNetworkReadBytes(env, (jint) readBytes); readBytes is already jint. - You could reduce the code by factoring out that frequent if-else statements: 87 if (readBytes > 0) { 88 if (socket) { 89 JVM_callNetworkReadBytes(env, (jint) readBytes); 90 } else { 91 JVM_callFileReadBytes(env, (jint)readBytes); 92 } 93 } like this static void on_io_read(env, jint nread, jboolean socket) { if (socket) { JVM_callNetworkReadBytes(env, nread); } else { JVM_callFileReadBytes(env, nread); } } you could even add the n>0 condition to the function. - Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value of pread64 to 32bit on 64bit platforms. --- src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c Probably philosophical but I would leave peek out of the condition. A read is a read. -- src/java.base/unix/native/libnet/SocketOutputStream.c You could move the call to JVM_callNetworkWriteBytes out of the loop (you did this in other places too). -- src/java.base/windows/native/libnio/ch/DatagramDispatcher.c src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c at various places: 52 DWORD read = 0; 83 if (read > 0) { 84 JVM_callNetworkReadBytes(env, read); 85 } DWORD is unsigned, may overflow jint arg? Moot point if you make it 64bit. ---- src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c Java_java_net_DualStackPlainDatagramSocketImpl_socketSend 462 if (rv > 0) { 463 JVM_callFileWriteBytes(env, rv); 464 } Should this be NetworkWriteBytes? --- src/java.base/windows/native/libnet/SocketOutputStream.c Same here. --- src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, addrlen) == SOCKET_ERROR) { NET_ThrowCurrent(env, "Datagram send failed"); } + if (ret > 0) { + JVM_callFileWriteBytes(env, ret); + } + Same here. --- http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html Java_sun_nio_ch_DatagramChannelImpl_send0 Smae here. --- src/java.base/windows/native/libnio/ch/DatagramDispatcher.c src/java.base/windows/native/libnio/ch/SocketDispatcher.c Same here? --- src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c + written = send(scoutFd, &byte, 1, 0); + + if (written > 0) { + JVM_callFileWriteBytes(env, written); + } ditto :) Thanks for your work! Cheers, Thomas On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: > Hi All, > > Could I please have a review and possibly some opinions on the following > enhancement to JFR and the JDK? > > At SAP we have a per thread IO statistic among our supportability > enhancements which proved to be very helpful for our support engineers. It > might be beneficial for JFR as well and would certainly help us to drive > adoption of OpenJDK. > > The basic idea is simple, we have added fields to the thread class where > the number of bytes read and written from/to file and network are counted > in. The newly created JFR events are written periodically as for example > the ThreadAllocationStatistics event already is. > > In order to collect the data, we have added hooks to the JDK C coding > calling back into the VM. > > I have opened a bug here: > https://bugs.openjdk.java.net/browse/JDK-8216981 > > Here is a webrev: > http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > > There are no tests yet and the code be a bit nicer in places. We will work > on this if/when this feature is deemed acceptable. > > Finally, we have an API in our SAP version of the JDK to access this data > from a Java application. This is used by many SAP applications and I think > we could add an MXBean in a second step, to provide similar functionality. > > Thanks in advance, > Gunter > > > > > From matthias.baesken at sap.com Wed Jan 16 14:43:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 14:43:13 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> Message-ID: Hi Alan , do you think it is good to start a UNIX parse_manifest_md.c too with just a one-liner in it ? Or do you prefer only having the windows - file with the Windows coding and keeping the UNIX one-liner for open_jarfile in parse_manifest.c ? Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Mittwoch, 16. Januar 2019 10:37 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 16/01/2019 09:07, Baesken, Matthias wrote: > > Hi Alan, I thought having UNIX+Windows code in this case together at > one place would be okay . > > However, if you prefer separating it, should I put it here ? > > > > src/java.base/windows/native/libjli/java_md.c > > > > Or do you have a better suggestion ? > > > With a few exceptions, the Windows specific code for jli.dll is in > src/java.base/windows/native/libji so if it's not too difficult then I > think that should be location for the Windows long path support. It's > might be parse_manifest_md.c rather than java_md.c as the latter is the > platform specific code to go with launcher code in java.c. > > -Alan From Alan.Bateman at oracle.com Wed Jan 16 14:59:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 14:59:43 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you summarize the approaches that you have explored? In particular, it would be useful to see a write-up of approaches that don't change the native methods to call JVM_* functions at every I/O call. It would also be useful to understand how it compares to dynamic instrumentation today (once there are suitable java methods to instrument). Maybe someone working on JFR can comment on that too. -Alan On 16/01/2019 14:25, Thomas St?fe wrote: > Hi Gunter, > > (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > respectively. Hope this is not too spammy). > > This looks all very good. > > I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, > so I am not sure if I am allowed to review the JFR parts. > > That said, here it goes: > > General remarks: > > A) we may reduce the number of sent events vastly by only sending updates > for threads which actually did IO. I know that would require expanding the > ThreadStatisticalInfo to keep JFR-specific counters. But I think the memory > overhead of the increased size of ThreadStatisticalInfo would be more than > offset by the space saved for noop events. What to you think? > > (Side note, it would be nice to have generic support for this in the JFR > layer. If the JFR layer could remember the last values for an event and > omit sending it if nothing changed.) > > B) You could save a bit of work by folding multiple values into one event. > Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of > having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you > could have ThreadNetworkStatistics with "read" and "write" fields, and thus > combine the polling functions for those two. Maybe even combine all four > values into a single "ThreadIOStatistics" event. > > Review: > > Hook functions: > > - This is bike shedding, but I would like something like "JVM_On()" > more, sounding more "hookish", since the functions do not "xxx" but inform > the hotspot of "xxx" having occurred > > - Also, I wonder whether it would make sense to make the len input 64bit > (jlong instead of jint) in case we want to use them to instrument 64bit > reads too > > - If you wanted to minimize the number of new JVM_.. hook functions, you > could combine network and file io hooks into one: > > JVM_OnIORead(.. bool is_socket) > JVM_OnIOWrite(.. bool is_socket) > > or even JVM_OnIO(.., bool is_read, bool is_socket). > > This would also make the dispatching in > src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this > is pure aesthetics, I leave it up to you. > > --- > > src/hotspot/share/jfr/metadata/metadata.xml > > All event definitions have one value, called and labeled "Thread". If you > keep them separate, does this field name/label make sense? (I am not fluid > with JMC so I do not know where exactly this label text would appear). > > --- > > src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > > GrowableArray written(initial_size); > GrowableArray thread_ids(initial_size); > > You could probably save one GrowableArray and some append calls by > something like this: > > struct data { jlong num; trace_id tid; } > GrowableArray > > - > > Question, I assume you go thru the trouble of storing the values > temporarily since you do not want to call JfrEvent::commit inside the > Threads_lock? > > --- > > src/hotspot/share/runtime/thread.cpp > > Nice addition to the extended thread dump. > > --- > > src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > > - There may be a number of unnecessary casts: > > e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > > JVM_callNetworkReadBytes(env, (jint) readBytes); > > readBytes is already jint. > > - > > You could reduce the code by factoring out that frequent if-else statements: > > 87 if (readBytes > 0) { > 88 if (socket) { > 89 JVM_callNetworkReadBytes(env, (jint) readBytes); > 90 } else { > 91 JVM_callFileReadBytes(env, (jint)readBytes); > 92 } > 93 } > > like this > > static void on_io_read(env, jint nread, jboolean socket) { > if (socket) { > JVM_callNetworkReadBytes(env, nread); > } else { > JVM_callFileReadBytes(env, nread); > } > } > > you could even add the n>0 condition to the function. > > - > > Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value > of pread64 to 32bit on 64bit platforms. > > --- > > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > > Probably philosophical but I would leave peek out of the condition. A read > is a read. > > -- > > src/java.base/unix/native/libnet/SocketOutputStream.c > > You could move the call to JVM_callNetworkWriteBytes out of the loop (you > did this in other places too). > > -- > > src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > > at various places: > > 52 DWORD read = 0; > > 83 if (read > 0) { > 84 JVM_callNetworkReadBytes(env, read); > 85 } > > DWORD is unsigned, may overflow jint arg? Moot point if you make it 64bit. > > ---- > > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > > Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > > 462 if (rv > 0) { > 463 JVM_callFileWriteBytes(env, rv); > 464 } > > Should this be NetworkWriteBytes? > > --- > > src/java.base/windows/native/libnet/SocketOutputStream.c > > Same here. > > --- > > src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > > > - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > addrlen) == SOCKET_ERROR) > { > NET_ThrowCurrent(env, "Datagram send failed"); > } > > + if (ret > 0) { > + JVM_callFileWriteBytes(env, ret); > + } > + > > Same here. > > --- > > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > > Java_sun_nio_ch_DatagramChannelImpl_send0 > > Smae here. > > --- > > src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > src/java.base/windows/native/libnio/ch/SocketDispatcher.c > > > Same here? > > --- > > src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > > + written = send(scoutFd, &byte, 1, 0); > + > + if (written > 0) { > + JVM_callFileWriteBytes(env, written); > + } > > ditto :) > > Thanks for your work! > > Cheers, Thomas > > > > > On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: > >> Hi All, >> >> Could I please have a review and possibly some opinions on the following >> enhancement to JFR and the JDK? >> >> At SAP we have a per thread IO statistic among our supportability >> enhancements which proved to be very helpful for our support engineers. It >> might be beneficial for JFR as well and would certainly help us to drive >> adoption of OpenJDK. >> >> The basic idea is simple, we have added fields to the thread class where >> the number of bytes read and written from/to file and network are counted >> in. The newly created JFR events are written periodically as for example >> the ThreadAllocationStatistics event already is. >> >> In order to collect the data, we have added hooks to the JDK C coding >> calling back into the VM. >> >> I have opened a bug here: >> https://bugs.openjdk.java.net/browse/JDK-8216981 >> >> Here is a webrev: >> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 >> >> There are no tests yet and the code be a bit nicer in places. We will work >> on this if/when this feature is deemed acceptable. >> >> Finally, we have an API in our SAP version of the JDK to access this data >> from a Java application. This is used by many SAP applications and I think >> we could add an MXBean in a second step, to provide similar functionality. >> >> Thanks in advance, >> Gunter >> >> >> >> >> From Alan.Bateman at oracle.com Wed Jan 16 15:03:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 15:03:41 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> Message-ID: On 16/01/2019 02:30, Patrick Zhang wrote: > Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. I think this patch looks okay and I assume you'll test it in the jdk-submit repo to make sure it builds on all platforms. -Alan From Roger.Riggs at oracle.com Wed Jan 16 15:06:53 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 16 Jan 2019 10:06:53 -0500 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> Message-ID: <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> Hi, I can sponsor this. Let me know when the jdk-submit is complete. Thanks, Roger On 01/16/2019 10:03 AM, Alan Bateman wrote: > On 16/01/2019 02:30, Patrick Zhang wrote: >> Looks .patch didn't work as an attachment, retry with .txt and paste >> the text below as well. Sorry for one more message here. > I think this patch looks okay and I assume you'll test it in the > jdk-submit repo to make sure it builds on all platforms. > > -Alan From Alan.Bateman at oracle.com Wed Jan 16 15:43:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 15:43:12 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> Message-ID: <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> On 16/01/2019 14:43, Baesken, Matthias wrote: > Hi Alan , do you think it is good to start a UNIX parse_manifest_md.c too with just a one-liner in it ? > Or do you prefer only having the windows - file with the Windows coding and keeping the UNIX one-liner for open_jarfile in parse_manifest.c ? > I think this makes sense. -Alan From mark.reinhold at oracle.com Wed Jan 16 17:30:24 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Jan 2019 09:30:24 -0800 Subject: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris) Message-ID: <20190116093024.404956102@eggemoggin.niobe.net> Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ The fix for 8210669 [1] enabled some tests to run that had not been running, and perhaps had never run. Amongst these tests was tools/launcher/Test7029048.java, which is meant to ensure that the Java launcher defends itself against interfering settings of the LD_LIBRARY_PATH environment variable, as implemented in the fix for 7029048 [2]. It took me quite a while to understand exactly what this test was doing, but in the end the root cause was that the test could not distinguish between an LD_LIBRARY_PATH value that?s empty from one that contains just a single path. This is important on Solaris, where the test also checks that setting LD_LIBRARY_PATH_64 does not interfere with the launcher. In this context the environment variable can contain either no path or just one path, depending upon which case is being tested. I fixed this accounting problem and, while I was at it, made a few other changes to clarify the test for future maintainers. In a cruel twist of fate, it turns out that the behavior implemented for 7029048, and verified by this test, is incorrect. On Solaris, if you set LD_LIBRARY_PATH_64 then that completely overrides any setting of LD_LIBRARY_PATH. The launcher tries to defend itself against a setting of LD_LIBRARY_PATH_64 by setting LD_LIBRARY_PATH, but that will have no effect -- it should really set LD_LIBRARY_PATH_64. I?ve filed 8217216 [3] to record this. Passes tiers 1-4 on {linux,macosx,windows}-x64 and solaris-sparcv9. Thanks, - Mark [1] https://bugs.openjdk.java.net/browse/JDK-8210669 [2] https://bugs.openjdk.java.net/browse/JDK-7029048 [3] https://bugs.openjdk.java.net/browse/JDK-8217216 From simpa16_90 at hotmail.com Mon Jan 14 21:36:13 2019 From: simpa16_90 at hotmail.com (Skillzore Gaming) Date: Mon, 14 Jan 2019 21:36:13 +0000 Subject: jpackage usage Message-ID: Hi! I am trying out jpackage from https://jdk.java.net/jpackage/. I have been trying to figure out how to get it to build a working exe file. I have a helloWorld.jar built by gradle which is runnable and runs fine with "java -jar helloWorld.jar". But when I try to use it to build an exe file, the resulting installation (from the built exe file) does not work as expected. I build the exe file with jpackage.exe create-installer exe -n "hello" -j helloWorld.jar -o . -i . -c HelloWorld It installs just fine, but when trying to run the resulting hello.exe nothing happens. I think that I am doing something wrong in the creation of the exe. I am a bit unsure of what the -o, -i and -c parameters are intended to do and that is probably where I fail. Any insight would be appreciated since I am hoping to use this on a larger project later and the interwebs do not have much information on this as of yet. Regards, Simon From andy.herrick at oracle.com Wed Jan 16 19:21:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 16 Jan 2019 14:21:46 -0500 Subject: jpackage usage In-Reply-To: References: Message-ID: <8b48e0d8-032c-5579-30ad-03d4ecbf442f@oracle.com> 1.) using --input (-i) without also using --files (-f) means every file in the input directory (. in this case) will be added to the bundle.? This may be fine if you are in a working directory with just what you want. ) in this case where --input and --output dirs are both the same, running the command twice would bundle up an app containing the installer from the first run as well.? I had never tried having both -i and -o be the same dir - but doing that now gives no problem, I can create an installer, install it, and run the installed app. 2.) If you are getting an installer that installs find, but then app doesn't I would back up and run create-image first and see if the executable runs. Also, if you jar has a Main-Class attribute (and it must since you can run "java -jar helloWorld.jar") you shouldn't really need the -c (--class) option.? Is that really the correct main class (you can try running "java -classpath helloWorld.jar HelloWorld". /Andy On 1/14/2019 4:36 PM, Skillzore Gaming wrote: > Hi! > > I am trying out jpackage from https://jdk.java.net/jpackage/. I have been trying to figure out how to get it to build a working exe file. > I have a helloWorld.jar built by gradle which is runnable and runs fine with "java -jar helloWorld.jar". But when I try to use it to build an exe file, the resulting installation (from the built exe file) does not work as expected. > I build the exe file with > jpackage.exe create-installer exe -n "hello" -j helloWorld.jar -o . -i . -c HelloWorld > > It installs just fine, but when trying to run the resulting hello.exe nothing happens. I think that I am doing something wrong in the creation of the exe. I am a bit unsure of what the -o, -i and -c parameters are intended to do and that is probably where I fail. > Any insight would be appreciated since I am hoping to use this on a larger project later and the interwebs do not have much information on this as of yet. > > Regards, Simon From Roger.Riggs at oracle.com Wed Jan 16 19:45:05 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 16 Jan 2019 14:45:05 -0500 Subject: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris) In-Reply-To: <20190116093024.404956102@eggemoggin.niobe.net> References: <20190116093024.404956102@eggemoggin.niobe.net> Message-ID: Hi Mark, Looks fine. Bump the Copyright to 2019. Thanks, Roger On 01/16/2019 12:30 PM, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 > Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ > > The fix for 8210669 [1] enabled some tests to run that had not been > running, and perhaps had never run. > > Amongst these tests was tools/launcher/Test7029048.java, which is meant > to ensure that the Java launcher defends itself against interfering > settings of the LD_LIBRARY_PATH environment variable, as implemented in > the fix for 7029048 [2]. > > It took me quite a while to understand exactly what this test was doing, > but in the end the root cause was that the test could not distinguish > between an LD_LIBRARY_PATH value that?s empty from one that contains > just a single path. This is important on Solaris, where the test also > checks that setting LD_LIBRARY_PATH_64 does not interfere with the > launcher. In this context the environment variable can contain either > no path or just one path, depending upon which case is being tested. > > I fixed this accounting problem and, while I was at it, made a few other > changes to clarify the test for future maintainers. > > In a cruel twist of fate, it turns out that the behavior implemented for > 7029048, and verified by this test, is incorrect. On Solaris, if you > set LD_LIBRARY_PATH_64 then that completely overrides any setting of > LD_LIBRARY_PATH. The launcher tries to defend itself against a setting > of LD_LIBRARY_PATH_64 by setting LD_LIBRARY_PATH, but that will have no > effect -- it should really set LD_LIBRARY_PATH_64. I?ve filed 8217216 > [3] to record this. > > Passes tiers 1-4 on {linux,macosx,windows}-x64 and solaris-sparcv9. > > Thanks, > - Mark > > > [1] https://bugs.openjdk.java.net/browse/JDK-8210669 > [2] https://bugs.openjdk.java.net/browse/JDK-7029048 > [3] https://bugs.openjdk.java.net/browse/JDK-8217216 From ecki at zusammenkunft.net Wed Jan 16 21:03:15 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 16 Jan 2019 21:03:15 +0000 Subject: jpackage usage In-Reply-To: References: Message-ID: Is this a console application? I think the launcher won?t show that. So the program actually runs, it just not displays a console window. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Skillzore Gaming Gesendet: Mittwoch, Januar 16, 2019 9:15 PM An: core-libs-dev at openjdk.java.net Betreff: jpackage usage Hi! I am trying out jpackage from https://jdk.java.net/jpackage/. I have been trying to figure out how to get it to build a working exe file. I have a helloWorld.jar built by gradle which is runnable and runs fine with "java -jar helloWorld.jar". But when I try to use it to build an exe file, the resulting installation (from the built exe file) does not work as expected. I build the exe file with jpackage.exe create-installer exe -n "hello" -j helloWorld.jar -o . -i . -c HelloWorld It installs just fine, but when trying to run the resulting hello.exe nothing happens. I think that I am doing something wrong in the creation of the exe. I am a bit unsure of what the -o, -i and -c parameters are intended to do and that is probably where I fail. Any insight would be appreciated since I am hoping to use this on a larger project later and the interwebs do not have much information on this as of yet. Regards, Simon From mandy.chung at oracle.com Wed Jan 16 23:52:03 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Jan 2019 15:52:03 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Adam, On 1/14/19 9:10 AM, Adam Farley8 wrote: > As for the CSR process, I'm unfamiliar with it. I've modified the > comment for the unreflectSetter method in the webrev. Do let me know if > more needs to be done. The CSR process is straight-forward.? CSR FAQ [1] may help you get started. As for the fix, John has suggested the spec wording for this issue. It's fine with the unreflectField method to have the explicit check and throw field.makeAccessException(...).?? The exception message could match the proposed spec wording like: ???? if(isSetter && field.isStatic() && field.isFinal()) ? ? ? ?? throw field.makeAccessException("static final field has no write access", this); You have a very long line and the throw statement can start in the next line. In addition, please include a test case for this change. Thanks Mandy [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs From sandhya.viswanathan at intel.com Thu Jan 17 00:00:31 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 17 Jan 2019 00:00:31 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A50345@FMSMSX126.amr.corp.intel.com> It will be wonderful to have persistent MappedByteBuffer feature proposed by Andrew Dinn in JDK 13. To us it looks to be a seamless extension to the existing API, provides a very good building block for persistent memory support in Java in the current Java paradigm and is directly applicable to a class of workloads. Many Big Data frameworks like Apache HBASE use FileChannel map and MappedByteBuffer as the underlying mechanism and so can use the proposed feature to utilize non-volatile memory. We have also reviewed and provided initial feedback to Andrew on the implementation. Best Regards, Sandhya -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Wednesday, January 16, 2019 3:23 AM To: Alan Bateman ; Brian Goetz Cc: core-libs-dev at openjdk.java.net; hotspot compiler ; Jonathan Halliday ; Viswanathan, Sandhya Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory Hi Alan/Brian, I have finally been able to shelve other commitments and return to this JEP (apologies for the hiatus). https://openjdk.java.net/jeps/8207851 The JEP has been reviewed positively by Stuart Marks (core libs) and Vladimir Kozlov (intrinsics). It has also been warmly welcomed by several potential users in Red Hat and Intel (including, respectively, Jonathan Halliday and Sandya Viswanathan both in cc). I believe I have addressed all outstanding comments on the JEP per se, including those made by Alan. Is it now possible for one of you to endorse the JEP so it can be submitted? I am aware that I still need to address a few details in the draft implementation that are not present in the latest webrev. I believe there are two changes requested by Vladimir: 1. correct the type of cache writeback memory nodes to generic memory 2. use the JVM to inject a flag setting which enables/disables mapping of persistent buffers and also one change requested by Alan: make method MappedByteBuffer.isPersistent private rather than public Is there any other impediment to submitting the JEP and proceeding to code review? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mark.reinhold at oracle.com Wed Jan 16 23:57:02 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Jan 2019 15:57:02 -0800 Subject: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris) In-Reply-To: References: <20190116093024.404956102@eggemoggin.niobe.net> Message-ID: <20190116155702.384017964@eggemoggin.niobe.net> 2019/1/16 11:45:05 -0800, roger.riggs at oracle.com: > Looks fine. Thanks! > Bump the Copyright to 2019. Will do. - Mark From naoto.sato at oracle.com Thu Jan 17 00:20:24 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 16 Jan 2019 16:20:24 -0800 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale Message-ID: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216969 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ For parsing the context sensitive month 'M', the logic was to look for the best match for the short name regardless of the styles. Changed the parsing code to take the context into account. Naoto From joe.darcy at oracle.com Thu Jan 17 00:21:17 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Jan 2019 16:21:17 -0800 Subject: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris) In-Reply-To: <20190116093024.404956102@eggemoggin.niobe.net> References: <20190116093024.404956102@eggemoggin.niobe.net> Message-ID: <5C3FCA7D.8000700@oracle.com> Rather than naming the enum for the test cases as "CASE", more conventional naming would be "TestCase" or "Case" for the type itself. -Joe On 1/16/2019 9:30 AM, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 > Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ > > The fix for 8210669 [1] enabled some tests to run that had not been > running, and perhaps had never run. > > Amongst these tests was tools/launcher/Test7029048.java, which is meant > to ensure that the Java launcher defends itself against interfering > settings of the LD_LIBRARY_PATH environment variable, as implemented in > the fix for 7029048 [2]. > > It took me quite a while to understand exactly what this test was doing, > but in the end the root cause was that the test could not distinguish > between an LD_LIBRARY_PATH value that?s empty from one that contains > just a single path. This is important on Solaris, where the test also > checks that setting LD_LIBRARY_PATH_64 does not interfere with the > launcher. In this context the environment variable can contain either > no path or just one path, depending upon which case is being tested. > > I fixed this accounting problem and, while I was at it, made a few other > changes to clarify the test for future maintainers. > > In a cruel twist of fate, it turns out that the behavior implemented for > 7029048, and verified by this test, is incorrect. On Solaris, if you > set LD_LIBRARY_PATH_64 then that completely overrides any setting of > LD_LIBRARY_PATH. The launcher tries to defend itself against a setting > of LD_LIBRARY_PATH_64 by setting LD_LIBRARY_PATH, but that will have no > effect -- it should really set LD_LIBRARY_PATH_64. I?ve filed 8217216 > [3] to record this. > > Passes tiers 1-4 on {linux,macosx,windows}-x64 and solaris-sparcv9. > > Thanks, > - Mark > > > [1] https://bugs.openjdk.java.net/browse/JDK-8210669 > [2] https://bugs.openjdk.java.net/browse/JDK-7029048 > [3] https://bugs.openjdk.java.net/browse/JDK-8217216 From david.holmes at oracle.com Thu Jan 17 00:23:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 10:23:01 +1000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> On 17/01/2019 12:59 am, Alan Bateman wrote: > > Thanks for forwarding as this is a topic that will require a lot of > discussion and agreement from several areas due to potential impact on > long term maintenance and the potential for some of these native methods > to go away. > > Gunter - can you summarize the approaches that you have explored? In > particular, it would be useful to see a write-up of approaches that > don't change the native methods to call JVM_* functions at every I/O > call. Indeed! Under the adage "you shouldn't pay for what you don't use" this seems an unacceptable penalty on I/O operations if you don't want to gather the event info - and possibly excessive even if you do! The dynamic instrumentation approach was adopted because static instrumentation like this was not considered appropriate. David ----- > It would also be useful to understand how it compares to dynamic > instrumentation today (once there are suitable java methods to > instrument). Maybe someone working on JFR can comment on that too. > > -Alan > > On 16/01/2019 14:25, Thomas St?fe wrote: >> Hi Gunter, >> >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, >> respectively. Hope this is not too spammy). >> >> This looks all very good. >> >> I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, >> so I am not sure if I am allowed to review the JFR parts. >> >> That said, here it goes: >> >> General remarks: >> >> A) we may reduce the number of sent events vastly by only sending updates >> for threads which actually did IO. I know that would require expanding >> the >> ThreadStatisticalInfo to keep JFR-specific counters. But I think the >> memory >> overhead of the increased size of ThreadStatisticalInfo would be more >> than >> offset by the space saved for noop events. What to you think? >> >> (Side note, it would be nice to have generic support for this in the JFR >> layer. If the JFR layer could remember the last values for an event and >> omit sending it if nothing changed.) >> >> B) You could save a bit of work by folding multiple values into one >> event. >> Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of >> having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you >> could have ThreadNetworkStatistics with "read" and "write" fields, and >> thus >> combine the polling functions for those two. Maybe even combine all four >> values into a single "ThreadIOStatistics" event. >> >> Review: >> >> Hook functions: >> >> - This is bike shedding, but I would like something like "JVM_On()" >> more, sounding more "hookish", since the functions do not "xxx" but >> inform >> the hotspot of "xxx" having occurred >> >> - Also, I wonder whether it would make sense to make the len input 64bit >> (jlong instead of jint) in case we want to use them to instrument 64bit >> reads too >> >> - If you wanted to minimize the number of new JVM_.. hook functions, you >> could combine network and file io hooks into one: >> >> JVM_OnIORead(.. bool is_socket) >> JVM_OnIOWrite(.. bool is_socket) >> >> or even JVM_OnIO(.., bool is_read, bool is_socket). >> >> This would also make the dispatching in >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this >> is pure aesthetics, I leave it up to you. >> >> --- >> >> src/hotspot/share/jfr/metadata/metadata.xml >> >> All event definitions have one value, called and labeled "Thread". If you >> keep them separate, does this field name/label make sense? (I am not >> fluid >> with JMC so I do not know where exactly this label text would appear). >> >> --- >> >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp >> >> ?? GrowableArray written(initial_size); >> ?? GrowableArray thread_ids(initial_size); >> >> You could probably save one GrowableArray and some append calls by >> something like this: >> >> struct data { jlong num; trace_id tid; } >> GrowableArray >> >> - >> >> Question, I assume you go thru the trouble of storing the values >> temporarily since you do not want to call JfrEvent::commit inside the >> Threads_lock? >> >> --- >> >> src/hotspot/share/runtime/thread.cpp >> >> Nice addition to the extended thread dump. >> >> --- >> >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c >> >> - There may be a number of unnecessary casts: >> >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 >> >> JVM_callNetworkReadBytes(env, (jint) readBytes); >> >> readBytes is already jint. >> >> - >> >> You could reduce the code by factoring out that frequent if-else >> statements: >> >> ?? 87???? if (readBytes > 0) { >> ?? 88???????? if (socket) { >> ?? 89???????????? JVM_callNetworkReadBytes(env, (jint) readBytes); >> ?? 90???????? } else { >> ?? 91???????????? JVM_callFileReadBytes(env, (jint)readBytes); >> ?? 92???????? } >> ?? 93???? } >> >> like this >> >> static void on_io_read(env, jint nread, jboolean socket) { >> ??????????? if (socket) { >> ??????????????? JVM_callNetworkReadBytes(env, nread); >> ??????????? } else { >> ??????????????? JVM_callFileReadBytes(env, nread); >> ??????????? } >> } >> >> you could even add the n>0 condition to the function. >> >> - >> >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value >> of pread64 to 32bit on 64bit platforms. >> >> --- >> >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c >> >> Probably philosophical but I would leave peek out of the condition. A >> read >> is a read. >> >> -- >> >> src/java.base/unix/native/libnet/SocketOutputStream.c >> >> You could move the call to JVM_callNetworkWriteBytes out of the loop (you >> did this in other places too). >> >> -- >> >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c >> >> at various places: >> >> ?? 52???? DWORD read = 0; >> >> ?? 83???? if (read > 0) { >> ?? 84?????? JVM_callNetworkReadBytes(env, read); >> ?? 85???? } >> >> DWORD is unsigned, may overflow jint arg? Moot point if you make it >> 64bit. >> >> ---- >> >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c >> >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend >> >> ? 462???? if (rv > 0) { >> ? 463?????? JVM_callFileWriteBytes(env, rv); >> ? 464???? } >> >> Should this be NetworkWriteBytes? >> >> --- >> >> src/java.base/windows/native/libnet/SocketOutputStream.c >> >> Same here. >> >> --- >> >> src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c >> >> >> -??? if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, >> +??? if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, >> ???????????????? addrlen) == SOCKET_ERROR) >> ????? { >> ????????? NET_ThrowCurrent(env, "Datagram send failed"); >> ????? } >> >> +??? if (ret > 0) { >> +????? JVM_callFileWriteBytes(env, ret); >> +??? } >> + >> >> Same here. >> >> --- >> >> http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html >> >> >> Java_sun_nio_ch_DatagramChannelImpl_send0 >> >> Smae here. >> >> --- >> >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c >> >> >> Same here? >> >> --- >> >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c >> >> +??? written = send(scoutFd, &byte, 1, 0); >> + >> +??? if (written > 0) { >> +??????? JVM_callFileWriteBytes(env, written); >> +??? } >> >> ditto :) >> >> Thanks for your work! >> >> Cheers, Thomas >> >> >> >> >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: >> >>> Hi All, >>> >>> Could I please have a review and possibly some opinions on the following >>> enhancement to JFR and the JDK? >>> >>> At SAP we have a per thread IO statistic among our supportability >>> enhancements which proved to be very helpful for our support >>> engineers. It >>> might be beneficial for JFR as well and would certainly help us to drive >>> adoption of OpenJDK. >>> >>> The basic idea is simple, we have added fields to the thread class where >>> the number of bytes read and written from/to file and network are >>> counted >>> in. The newly created JFR events are written periodically as for example >>> the ThreadAllocationStatistics event already is. >>> >>> In order to collect the data, we have added hooks to the JDK C coding >>> calling back into the VM. >>> >>> I have opened a bug here: >>> https://bugs.openjdk.java.net/browse/JDK-8216981 >>> >>> Here is a webrev: >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 >>> >>> There are no tests yet and the code be a bit nicer in places. We will >>> work >>> on this if/when this feature is deemed acceptable. >>> >>> Finally, we have an API in our SAP version of the JDK to access this >>> data >>> from a Java application. This is used by many SAP applications and I >>> think >>> we could add an MXBean in a second step, to provide similar >>> functionality. >>> >>> Thanks in advance, >>> Gunter >>> >>> >>> >>> >>> > From mark.reinhold at oracle.com Thu Jan 17 00:25:45 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Jan 2019 16:25:45 -0800 Subject: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris) In-Reply-To: <5C3FCA7D.8000700@oracle.com> References: <20190116093024.404956102@eggemoggin.niobe.net> <5C3FCA7D.8000700@oracle.com> Message-ID: <20190116162545.31996065@eggemoggin.niobe.net> 2019/1/16 16:21:17 -0800, joe.darcy at oracle.com: > Rather than naming the enum for the test cases as "CASE", more > conventional naming would be "TestCase" or "Case" for the type itself. Good point. The ALL_CAPS treatment was a holdover from the original. Changed to TestCase. - Mark From swpalmer at gmail.com Thu Jan 17 00:47:37 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 16 Jan 2019 19:47:37 -0500 Subject: Jpackage Windows shortcuts Message-ID: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> Are the flags to create shortcuts in the start menu and on the desktop supposed to be working at this point? I tried them and they had no effect. Scott From nishit.jain at oracle.com Thu Jan 17 07:07:18 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 17 Jan 2019 12:37:18 +0530 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException Message-ID: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> Hi, Please review the fix for 8210583 Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 Issue: Base64.Encoder.encode and Base64.Decoder.decode methods incorrectly throw unspecified exception e.g. NegativeArraySizeException, when the input byte array size is too large such that the calculated output byte size goes beyond the max-integer boundary and wraps around. Fix: Throw an OutOfMemoryError if the output byte array/buffer or memory can not be allocated. There is an unrelated change in encodeToString(byte[]) where a string instance is created using JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string constructor, to save memory. Regards, Nishit Jain From thomas.stuefe at gmail.com Thu Jan 17 07:23:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Jan 2019 08:23:58 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On Thu, Jan 17, 2019 at 1:23 AM David Holmes wrote: > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential impact on > > long term maintenance and the potential for some of these native methods > > to go away. > > > > Gunter - can you summarize the approaches that you have explored? In > > particular, it would be useful to see a write-up of approaches that > > don't change the native methods to call JVM_* functions at every I/O > > call. > > Indeed! Under the adage "you shouldn't pay for what you don't use" this > seems an unacceptable penalty on I/O operations if you don't want to > gather the event info - and possibly excessive even if you do! The > dynamic instrumentation approach was adopted because static > instrumentation like this was not considered appropriate. > > You noticed that all Gunther does is to increment stat counters in the VM, he does not generate JFR events at all? Do you object against keeping these counters (which basically boils down to Thread::current->stat_structure->counter++)? Or do you even object against making upcalls into the jvm? Note that, if deemed necessary, we could omit updating the counters unless JFR or our extended thread dumps are activated (which are the consumers of the counters). In any case, I would have assumed the costs for upcall + counter update to be insignificant compared to the IO calls. We should of course measure that. If you generally object upcalls into the libjvm for statistical/monitoring reasons, this would make matters on a number of fronts more complicated. For instance, it was discussed extending NMT coverage to the JDK - which is already in part reality at Unsafe.AllocateMemory - and this would have to be done with upcalls too. Kind Regards, Thomas David > ----- > > > It would also be useful to understand how it compares to dynamic > > instrumentation today (once there are suitable java methods to > > instrument). Maybe someone working on JFR can comment on that too. > > > > -Alan > > > > On 16/01/2019 14:25, Thomas St?fe wrote: > >> Hi Gunter, > >> > >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > >> respectively. Hope this is not too spammy). > >> > >> This looks all very good. > >> > >> I am not a JFR reviewer (is there such a thing?) but only a JDK > reviewer, > >> so I am not sure if I am allowed to review the JFR parts. > >> > >> That said, here it goes: > >> > >> General remarks: > >> > >> A) we may reduce the number of sent events vastly by only sending > updates > >> for threads which actually did IO. I know that would require expanding > >> the > >> ThreadStatisticalInfo to keep JFR-specific counters. But I think the > >> memory > >> overhead of the increased size of ThreadStatisticalInfo would be more > >> than > >> offset by the space saved for noop events. What to you think? > >> > >> (Side note, it would be nice to have generic support for this in the JFR > >> layer. If the JFR layer could remember the last values for an event and > >> omit sending it if nothing changed.) > >> > >> B) You could save a bit of work by folding multiple values into one > >> event. > >> Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of > >> having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you > >> could have ThreadNetworkStatistics with "read" and "write" fields, and > >> thus > >> combine the polling functions for those two. Maybe even combine all four > >> values into a single "ThreadIOStatistics" event. > >> > >> Review: > >> > >> Hook functions: > >> > >> - This is bike shedding, but I would like something like "JVM_On()" > >> more, sounding more "hookish", since the functions do not "xxx" but > >> inform > >> the hotspot of "xxx" having occurred > >> > >> - Also, I wonder whether it would make sense to make the len input 64bit > >> (jlong instead of jint) in case we want to use them to instrument 64bit > >> reads too > >> > >> - If you wanted to minimize the number of new JVM_.. hook functions, you > >> could combine network and file io hooks into one: > >> > >> JVM_OnIORead(.. bool is_socket) > >> JVM_OnIOWrite(.. bool is_socket) > >> > >> or even JVM_OnIO(.., bool is_read, bool is_socket). > >> > >> This would also make the dispatching in > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But > this > >> is pure aesthetics, I leave it up to you. > >> > >> --- > >> > >> src/hotspot/share/jfr/metadata/metadata.xml > >> > >> All event definitions have one value, called and labeled "Thread". If > you > >> keep them separate, does this field name/label make sense? (I am not > >> fluid > >> with JMC so I do not know where exactly this label text would appear). > >> > >> --- > >> > >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > >> > >> GrowableArray written(initial_size); > >> GrowableArray thread_ids(initial_size); > >> > >> You could probably save one GrowableArray and some append calls by > >> something like this: > >> > >> struct data { jlong num; trace_id tid; } > >> GrowableArray > >> > >> - > >> > >> Question, I assume you go thru the trouble of storing the values > >> temporarily since you do not want to call JfrEvent::commit inside the > >> Threads_lock? > >> > >> --- > >> > >> src/hotspot/share/runtime/thread.cpp > >> > >> Nice addition to the extended thread dump. > >> > >> --- > >> > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > >> > >> - There may be a number of unnecessary casts: > >> > >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > >> > >> JVM_callNetworkReadBytes(env, (jint) readBytes); > >> > >> readBytes is already jint. > >> > >> - > >> > >> You could reduce the code by factoring out that frequent if-else > >> statements: > >> > >> 87 if (readBytes > 0) { > >> 88 if (socket) { > >> 89 JVM_callNetworkReadBytes(env, (jint) readBytes); > >> 90 } else { > >> 91 JVM_callFileReadBytes(env, (jint)readBytes); > >> 92 } > >> 93 } > >> > >> like this > >> > >> static void on_io_read(env, jint nread, jboolean socket) { > >> if (socket) { > >> JVM_callNetworkReadBytes(env, nread); > >> } else { > >> JVM_callFileReadBytes(env, nread); > >> } > >> } > >> > >> you could even add the n>0 condition to the function. > >> > >> - > >> > >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return > value > >> of pread64 to 32bit on 64bit platforms. > >> > >> --- > >> > >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Probably philosophical but I would leave peek out of the condition. A > >> read > >> is a read. > >> > >> -- > >> > >> src/java.base/unix/native/libnet/SocketOutputStream.c > >> > >> You could move the call to JVM_callNetworkWriteBytes out of the loop > (you > >> did this in other places too). > >> > >> -- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > >> > >> at various places: > >> > >> 52 DWORD read = 0; > >> > >> 83 if (read > 0) { > >> 84 JVM_callNetworkReadBytes(env, read); > >> 85 } > >> > >> DWORD is unsigned, may overflow jint arg? Moot point if you make it > >> 64bit. > >> > >> ---- > >> > >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > >> > >> 462 if (rv > 0) { > >> 463 JVM_callFileWriteBytes(env, rv); > >> 464 } > >> > >> Should this be NetworkWriteBytes? > >> > >> --- > >> > >> src/java.base/windows/native/libnet/SocketOutputStream.c > >> > >> Same here. > >> > >> --- > >> > >> src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > >> > >> > >> - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> addrlen) == SOCKET_ERROR) > >> { > >> NET_ThrowCurrent(env, "Datagram send failed"); > >> } > >> > >> + if (ret > 0) { > >> + JVM_callFileWriteBytes(env, ret); > >> + } > >> + > >> > >> Same here. > >> > >> --- > >> > >> > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > >> > >> > >> Java_sun_nio_ch_DatagramChannelImpl_send0 > >> > >> Smae here. > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c > >> > >> > >> Same here? > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > >> > >> + written = send(scoutFd, &byte, 1, 0); > >> + > >> + if (written > 0) { > >> + JVM_callFileWriteBytes(env, written); > >> + } > >> > >> ditto :) > >> > >> Thanks for your work! > >> > >> Cheers, Thomas > >> > >> > >> > >> > >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter > wrote: > >> > >>> Hi All, > >>> > >>> Could I please have a review and possibly some opinions on the > following > >>> enhancement to JFR and the JDK? > >>> > >>> At SAP we have a per thread IO statistic among our supportability > >>> enhancements which proved to be very helpful for our support > >>> engineers. It > >>> might be beneficial for JFR as well and would certainly help us to > drive > >>> adoption of OpenJDK. > >>> > >>> The basic idea is simple, we have added fields to the thread class > where > >>> the number of bytes read and written from/to file and network are > >>> counted > >>> in. The newly created JFR events are written periodically as for > example > >>> the ThreadAllocationStatistics event already is. > >>> > >>> In order to collect the data, we have added hooks to the JDK C coding > >>> calling back into the VM. > >>> > >>> I have opened a bug here: > >>> https://bugs.openjdk.java.net/browse/JDK-8216981 > >>> > >>> Here is a webrev: > >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > >>> > >>> There are no tests yet and the code be a bit nicer in places. We will > >>> work > >>> on this if/when this feature is deemed acceptable. > >>> > >>> Finally, we have an API in our SAP version of the JDK to access this > >>> data > >>> from a Java application. This is used by many SAP applications and I > >>> think > >>> we could add an MXBean in a second step, to provide similar > >>> functionality. > >>> > >>> Thanks in advance, > >>> Gunter > >>> > >>> > >>> > >>> > >>> > > > From david.holmes at oracle.com Thu Jan 17 07:36:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 17:36:56 +1000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <9598aead-7443-10a4-9824-4aa21c1cb101@oracle.com> On 17/01/2019 5:23 pm, Thomas St?fe wrote: > > > On Thu, Jan 17, 2019 at 1:23 AM David Holmes > wrote: > > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential > impact on > > long term maintenance and the potential for some of these native > methods > > to go away. > > > > Gunter - can you summarize the approaches that you have explored? In > > particular, it would be useful to see a write-up of approaches that > > don't change the native methods to call JVM_* functions at every I/O > > call. > > Indeed! Under the adage "you shouldn't pay for what you don't use" this > seems an unacceptable penalty on I/O operations if you don't want to > gather the event info - and possibly excessive even if you do! The > dynamic instrumentation approach was adopted because static > instrumentation like this was not considered appropriate. > > > You noticed that all Gunther does is to increment stat counters in the > VM, he does not generate JFR events at all? > > Do you object against keeping these counters (which basically boils down > to Thread::current->stat_structure->counter++)? Or do you even object > against making upcalls into the jvm? Note that, if deemed necessary, we > could omit updating the counters unless JFR or our extended thread dumps > are activated (which are the consumers of the counters). It is the "call JVM_* functions at every I/O call" that I am concerned about! > In any case, I would have assumed the costs for upcall?+ counter update > to be insignificant compared to the IO calls. We should of course > measure that. It's going to depend on the actual I/O operation of course. > > If you generally object upcalls into the libjvm for > statistical/monitoring reasons, this would make matters on a number of > fronts more complicated. For instance, it was discussed extending NMT > coverage to the JDK - which is already in part reality at > Unsafe.AllocateMemory - and this would have to be done with upcalls too. And it would need to be examined in detail too. Cheers, David ----- > Kind Regards, Thomas > > > David > ----- > > > It would also be useful to understand how it compares to dynamic > > instrumentation today (once there are suitable java methods to > > instrument). Maybe someone working on JFR can comment on that too. > > > > -Alan > > > > On 16/01/2019 14:25, Thomas St?fe wrote: > >> Hi Gunter, > >> > >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > >> respectively. Hope this is not too spammy). > >> > >> This looks all very good. > >> > >> I am not a JFR reviewer (is there such a thing?) but only a JDK > reviewer, > >> so I am not sure if I am allowed to review the JFR parts. > >> > >> That said, here it goes: > >> > >> General remarks: > >> > >> A) we may reduce the number of sent events vastly by only > sending updates > >> for threads which actually did IO. I know that would require > expanding > >> the > >> ThreadStatisticalInfo to keep JFR-specific counters. But I think > the > >> memory > >> overhead of the increased size of ThreadStatisticalInfo would be > more > >> than > >> offset by the space saved for noop events. What to you think? > >> > >> (Side note, it would be nice to have generic support for this in > the JFR > >> layer. If the JFR layer could remember the last values for an > event and > >> omit sending it if nothing changed.) > >> > >> B) You could save a bit of work by folding multiple values into one > >> event. > >> Other events seem to do that too, eg. MetaspaceSummary. E.g: > instead of > >> having ThreadNetworkWriteStatistics and > ThreadNetworkReadStatistics, you > >> could have ThreadNetworkStatistics with "read" and "write" > fields, and > >> thus > >> combine the polling functions for those two. Maybe even combine > all four > >> values into a single "ThreadIOStatistics" event. > >> > >> Review: > >> > >> Hook functions: > >> > >> - This is bike shedding, but I would like something like > "JVM_On()" > >> more, sounding more "hookish", since the functions do not "xxx" but > >> inform > >> the hotspot of "xxx" having occurred > >> > >> - Also, I wonder whether it would make sense to make the len > input 64bit > >> (jlong instead of jint) in case we want to use them to > instrument 64bit > >> reads too > >> > >> - If you wanted to minimize the number of new JVM_.. hook > functions, you > >> could combine network and file io hooks into one: > >> > >> JVM_OnIORead(.. bool is_socket) > >> JVM_OnIOWrite(.. bool is_socket) > >> > >> or even JVM_OnIO(.., bool is_read, bool is_socket). > >> > >> This would also make the dispatching in > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. > But this > >> is pure aesthetics, I leave it up to you. > >> > >> --- > >> > >> src/hotspot/share/jfr/metadata/metadata.xml > >> > >> All event definitions have one value, called and labeled > "Thread". If you > >> keep them separate, does this field name/label make sense? (I am > not > >> fluid > >> with JMC so I do not know where exactly this label text would > appear). > >> > >> --- > >> > >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > >> > >> ?? GrowableArray written(initial_size); > >> ?? GrowableArray thread_ids(initial_size); > >> > >> You could probably save one GrowableArray and some append calls by > >> something like this: > >> > >> struct data { jlong num; trace_id tid; } > >> GrowableArray > >> > >> - > >> > >> Question, I assume you go thru the trouble of storing the values > >> temporarily since you do not want to call JfrEvent::commit > inside the > >> Threads_lock? > >> > >> --- > >> > >> src/hotspot/share/runtime/thread.cpp > >> > >> Nice addition to the extended thread dump. > >> > >> --- > >> > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > >> > >> - There may be a number of unnecessary casts: > >> > >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > >> > >> JVM_callNetworkReadBytes(env, (jint) readBytes); > >> > >> readBytes is already jint. > >> > >> - > >> > >> You could reduce the code by factoring out that frequent if-else > >> statements: > >> > >> ?? 87???? if (readBytes > 0) { > >> ?? 88???????? if (socket) { > >> ?? 89???????????? JVM_callNetworkReadBytes(env, (jint) readBytes); > >> ?? 90???????? } else { > >> ?? 91???????????? JVM_callFileReadBytes(env, (jint)readBytes); > >> ?? 92???????? } > >> ?? 93???? } > >> > >> like this > >> > >> static void on_io_read(env, jint nread, jboolean socket) { > >> ??????????? if (socket) { > >> ??????????????? JVM_callNetworkReadBytes(env, nread); > >> ??????????? } else { > >> ??????????????? JVM_callFileReadBytes(env, nread); > >> ??????????? } > >> } > >> > >> you could even add the n>0 condition to the function. > >> > >> - > >> > >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the > return value > >> of pread64 to 32bit on 64bit platforms. > >> > >> --- > >> > >> > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Probably philosophical but I would leave peek out of the > condition. A > >> read > >> is a read. > >> > >> -- > >> > >> src/java.base/unix/native/libnet/SocketOutputStream.c > >> > >> You could move the call to JVM_callNetworkWriteBytes out of the > loop (you > >> did this in other places too). > >> > >> -- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > >> > >> at various places: > >> > >> ?? 52???? DWORD read = 0; > >> > >> ?? 83???? if (read > 0) { > >> ?? 84?????? JVM_callNetworkReadBytes(env, read); > >> ?? 85???? } > >> > >> DWORD is unsigned, may overflow jint arg? Moot point if you make it > >> 64bit. > >> > >> ---- > >> > >> > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > >> > >> ? 462???? if (rv > 0) { > >> ? 463?????? JVM_callFileWriteBytes(env, rv); > >> ? 464???? } > >> > >> Should this be NetworkWriteBytes? > >> > >> --- > >> > >> src/java.base/windows/native/libnet/SocketOutputStream.c > >> > >> Same here. > >> > >> --- > >> > >> > src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > >> > >> > >> -??? if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> +??? if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> ???????????????? addrlen) == SOCKET_ERROR) > >> ????? { > >> ????????? NET_ThrowCurrent(env, "Datagram send failed"); > >> ????? } > >> > >> +??? if (ret > 0) { > >> +????? JVM_callFileWriteBytes(env, ret); > >> +??? } > >> + > >> > >> Same here. > >> > >> --- > >> > >> > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > > >> > >> > >> Java_sun_nio_ch_DatagramChannelImpl_send0 > >> > >> Smae here. > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c > >> > >> > >> Same here? > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > >> > >> +??? written = send(scoutFd, &byte, 1, 0); > >> + > >> +??? if (written > 0) { > >> +??????? JVM_callFileWriteBytes(env, written); > >> +??? } > >> > >> ditto :) > >> > >> Thanks for your work! > >> > >> Cheers, Thomas > >> > >> > >> > >> > >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter > > wrote: > >> > >>> Hi All, > >>> > >>> Could I please have a review and possibly some opinions on the > following > >>> enhancement to JFR and the JDK? > >>> > >>> At SAP we have a per thread IO statistic among our supportability > >>> enhancements which proved to be very helpful for our support > >>> engineers. It > >>> might be beneficial for JFR as well and would certainly help us > to drive > >>> adoption of OpenJDK. > >>> > >>> The basic idea is simple, we have added fields to the thread > class where > >>> the number of bytes read and written from/to file and network are > >>> counted > >>> in. The newly created JFR events are written periodically as > for example > >>> the ThreadAllocationStatistics event already is. > >>> > >>> In order to collect the data, we have added hooks to the JDK C > coding > >>> calling back into the VM. > >>> > >>> I have opened a bug here: > >>> https://bugs.openjdk.java.net/browse/JDK-8216981 > >>> > >>> Here is a webrev: > >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > >>> > >>> There are no tests yet and the code be a bit nicer in places. > We will > >>> work > >>> on this if/when this feature is deemed acceptable. > >>> > >>> Finally, we have an API in our SAP version of the JDK to access > this > >>> data > >>> from a Java application. This is used by many SAP applications > and I > >>> think > >>> we could add an MXBean in a second step, to provide similar > >>> functionality. > >>> > >>> Thanks in advance, > >>> Gunter > >>> > >>> > >>> > >>> > >>> > > > From Alan.Bateman at oracle.com Thu Jan 17 08:00:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2019 08:00:07 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On 17/01/2019 07:23, Thomas St?fe wrote: > : > > Do you object against keeping these counters (which basically boils > down to Thread::current->stat_structure->counter++)? Or do you even > object against making upcalls into the jvm? Note that, if deemed > necessary, we could omit updating the counters unless JFR or our > extended thread dumps are activated (which are the consumers of the > counters). > > In any case, I would have assumed the costs for upcall?+ counter > update to be insignificant compared to the IO calls. We should of > course measure that. > > If you generally object upcalls into the libjvm for > statistical/monitoring reasons, this would make matters on a number of > fronts more complicated. For instance, it was discussed extending NMT > coverage to the JDK - which is already in part reality at > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > There are many issues here that will need write-up and discussion, maybe a JEP if discussions converge on a proposal to bring into the main line as this is a significant change with implications for many areas of the platform. It also potentially conflicts in direction with some of the other projects in progress (particularly with Loom trying to re-imagine threads, do you really want to collect I/O stats on a per thread basis in the future???). As regards the points to instrument then I think we have to assume that much of the native code that is targeted by the current webrev will go away or change significantly in the future. We've been on that path for some time, e.g. the zip area or the prototype to replace the SocketImpl used for classic networking that eliminates a lot of the native code touched in that area by the webrev. Once Panama is further along then I assume we will want to make use of it in the core libraries and at least initially replace the JNI methods that just wrap syscalls today, and longer term more significant refactoring. My point is that instrumenting native methods may not be the right approach, instead maybe we should be look at instrumenting the I/O paths at the java level as that will likely play better with the VM. There is some support for collecting I/O stats in JFR today and maybe someone working in that area can explain that a bit more and what the issues are. It's impossible to tell from the mail with the webrev what has been explored and not explored. It feels like early stages in a much large project that will need a write up of prototypes before a direction can be proposed. -Alan From gunnar at hibernate.org Thu Jan 17 09:07:41 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 17 Jan 2019 10:07:41 +0100 Subject: Compact Number Formatting and Fraction Digits Message-ID: Hi, I took a look at the compact number formatting recently added in JDK 12. There's setMinimumFractionDigits() to control the number of fractional digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but it also will format 1,000 as 1.0K. Is there a way to have fractional digits but remove trailing zeros, so that 1,500 and 1,000 would be formatted as 1.5K and 1K, respectively? Thanks, --Gunnar From rachel at strangenoises.org Thu Jan 17 09:10:08 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Thu, 17 Jan 2019 09:10:08 +0000 Subject: Jpackage Windows shortcuts In-Reply-To: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> Message-ID: <5c1a0025-42a6-d447-e1d7-4ba9facb588d@strangenoises.org> Does your application's name have spaces in it? I've found they don't work if it does. (Actually the bug is at the create-image step where it squashes those spaces in the filenames of the actual app launcher exe and cfg files; restoring them before doing the create-installer step fixes it for me.) -- Rachel On 17/01/2019 00:47, Scott Palmer wrote: > Are the flags to create shortcuts in the start menu and on the desktop supposed to be working at this point? I tried them and they had no effect. > > Scott From nishit.jain at oracle.com Thu Jan 17 10:13:47 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 17 Jan 2019 15:43:47 +0530 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: References: Message-ID: Hi Gunnar, Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. Regards, Nishit Jain On 17-01-2019 14:37, Gunnar Morling wrote: > Hi, > > I took a look at the compact number formatting recently added in JDK 12. > > There's setMinimumFractionDigits() to control the number of fractional > digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > it also will format 1,000 as 1.0K. Is there a way to have fractional > digits but remove trailing zeros, so that 1,500 and 1,000 would be > formatted as 1.5K and 1K, respectively? > > Thanks, > > --Gunnar From nishit.jain at oracle.com Thu Jan 17 10:57:11 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 17 Jan 2019 16:27:11 +0530 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: References: Message-ID: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> Hi Naoto, Looks good to me. Just a small suggestion. - To improve readability, can we declare "standalone mask" (0x8000) as a static field and use that at all the places? Regards, Nishit Jain On 17-01-2019 05:50, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8216969 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ > > For parsing the context sensitive month 'M', the logic was to look for > the best match for the short name regardless of the styles. Changed > the parsing code to take the context into account. > > Naoto From erik.gahlin at oracle.com Thu Jan 17 12:05:19 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 17 Jan 2019 13:05:19 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <5C406F7F.5000409@oracle.com> On 2019-01-17 09:00, Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: >> : >> >> Do you object against keeping these counters (which basically boils >> down to Thread::current->stat_structure->counter++)? Or do you even >> object against making upcalls into the jvm? Note that, if deemed >> necessary, we could omit updating the counters unless JFR or our >> extended thread dumps are activated (which are the consumers of the >> counters). >> >> In any case, I would have assumed the costs for upcall + counter >> update to be insignificant compared to the IO calls. We should of >> course measure that. >> >> If you generally object upcalls into the libjvm for >> statistical/monitoring reasons, this would make matters on a number >> of fronts more complicated. For instance, it was discussed extending >> NMT coverage to the JDK - which is already in part reality at >> Unsafe.AllocateMemory - and this would have to be done with upcalls too. >> > There are many issues here that will need write-up and discussion, > maybe a JEP if discussions converge on a proposal to bring into the > main line as this is a significant change with implications for many > areas of the platform. It also potentially conflicts in direction with > some of the other projects in progress (particularly with Loom trying > to re-imagine threads, do you really want to collect I/O stats on a > per thread basis in the future???). > > As regards the points to instrument then I think we have to assume > that much of the native code that is targeted by the current webrev > will go away or change significantly in the future. We've been on that > path for some time, e.g. the zip area or the prototype to replace the > SocketImpl used for classic networking that eliminates a lot of the > native code touched in that area by the webrev. Once Panama is further > along then I assume we will want to make use of it in the core > libraries and at least initially replace the JNI methods that just > wrap syscalls today, and longer term more significant refactoring. My > point is that instrumenting native methods may not be the right > approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. > There is some support for collecting I/O stats in JFR today and maybe > someone working in that area can explain that a bit more and what the > issues are. > Today we have File Read, File Write, Socket Read, and Socket Write events. The hook points are added to the JDK using bytecode instrumentation. This happens when you start a JFR recording, so there is no overhead unless you use it. Erik > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. > > -Alan From Alan.Bateman at oracle.com Thu Jan 17 12:53:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2019 12:53:54 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> Message-ID: <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> On 16/01/2019 11:23, Andrew Dinn wrote: > Hi Alan/Brian, > > I have finally been able to shelve other commitments and return to this > JEP (apologies for the hiatus). > > https://openjdk.java.net/jeps/8207851 > > The JEP has been reviewed positively by Stuart Marks (core libs) and > Vladimir Kozlov (intrinsics). It has also been warmly welcomed by > several potential users in Red Hat and Intel (including, respectively, > Jonathan Halliday and Sandya Viswanathan both in cc). I think the proposal is good as a short term/tactical solution, especially as you were able to reduce the API surface down to new FileChannel map modes. I think it can be looked at again once Project Panama is further along and there is some notion of "memory region" that is backed by NVM. I skimmed through the current draft. In the most recent discussion then I think we had converged on "SYNC" rather than "PERSISTENT", the reasoning being that there is persistence already with regular file mapped files, also it aligns with the MAP_SYNC flag to mmap. I don't recall if the discussion on isPersistent concluded, that was more of a naming issue and whether you include an isXXX method or not is not critical to the proposal. The overload of the force method to specify a range is a good addition, irrespective of the JEP. One thing to clarify is the heading "Proposed Restricted Public JDK API Changes". The proposal (and the early webrevs) exposed writebackMemory in the internal Unsafe, not sun.misc.Unsafe, which I think is right. This makes it a JDK internal API so it doesn't need to be in JEP. Did you get any feedback on the Testing section? Given that the feature needs special hardware then it will need commitment to test is on a regular basis. It's a similar issue to the draft "JEP 337: RDMA Network Sockets" where special hardware is needed to full test the feature. In the case of JEP 337 then some testing with emulation is possible. Vladimir and I have reviewed the JEP, it will need an area lead to endorse, I think it can be Brian or Mikael in this case. -Alan From andy.herrick at oracle.com Thu Jan 17 13:17:33 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 17 Jan 2019 08:17:33 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> Message-ID: Simple tests of --win-menu and --win-shortcut options on Windows 7 are working for me.? Shortcuts are created as expected when running either the exe or msi installer generated. Can you share the full OS version and full command you use , perhaps some combination of options is not working. /Andy On 1/16/2019 7:47 PM, Scott Palmer wrote: > Are the flags to create shortcuts in the start menu and on the desktop supposed to be working at this point? I tried them and they had no effect. > > Scott From adinn at redhat.com Thu Jan 17 14:27:44 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 17 Jan 2019 14:27:44 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> Message-ID: <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Hi Alan, Thanks for your response. On 17/01/2019 12:53, Alan Bateman wrote: > I skimmed through the current draft. In the most recent discussion then > I think we had converged on "SYNC" rather than "PERSISTENT", the > reasoning being that there is persistence already with regular file > mapped files, also it aligns with the MAP_SYNC flag to mmap. I don't > recall if the discussion on isPersistent concluded, that was more of a > naming issue and whether you include an isXXX method or not is not > critical to the proposal. The overload of the force method to specify a > range is a good addition, irrespective of the JEP. Ok, thanks. At least sync is now being used consistently in the public API. I will look at renaming internal vars/methods to use sync when I publish the next webrev. > One thing to clarify is the heading "Proposed Restricted Public JDK API > Changes". The proposal (and the early webrevs) exposed writebackMemory > in the internal Unsafe, not sun.misc.Unsafe, which I think is right. > This makes it a JDK internal API so it doesn't need to be in JEP. I am happy to remove it from the JEP if needed. Does it do any harm to leave it? > Did you get any feedback on the Testing section? Given that the feature > needs special hardware then it will need commitment to test is on a > regular basis. It's a similar issue to the draft "JEP 337: RDMA Network > Sockets" where special hardware is needed to full test the feature. In > the case of JEP 337 then some testing with emulation is possible. I believe I received no specific feedback on that topic. Some of the other Red Hat dev teams (i.e. not OpenJDK) and also dev staff at Intel are very keen to base some of their future work on this feature. So, it will certainly get tested /after/ JDK release :-) Red Hat does have the Intel hardware needed to test this feature but, so far, nothing that can be used to test on AArch64. Our OpenJDK team can access this kit for one-off testing but it is not currently available for continuous integration testing. I will propose to my manager that we acquire the relevant kit and ensure that all JDKs which implement this JEP are tested prior to release. We should also be able to test AArch64 using volatile memory to simulate a non-volatile memory device up to the point where the requisite AArch64-based NVM hardware becomes available. I am fairly confident this plan will be agreeable to the overlords whom I humbly serve. Perhaps Intel also could provide help with testing? [Sadhya, is this an option?] My bigger concern was that crash recovery tests may never be 100% reliable. A 100% guarantee requires the ability to engineer a machine crash at a precisely defined critical point of execution and some of the relevant critical locations will be embedded in the middle of JITted code making it hard to provoke the crash. So, the situations where a crash /can/ be engineered may not fully reflect those that occur in live deployments. That said, a dash of artificiality in test code is, perhaps, not so worthy of remark . . . > Vladimir and I have reviewed the JEP, it will need an area lead to > endorse, I think it can be Brian or Mikael in this case. Ok, thanks for the above answers. Looking forward to hearing further from Brian and/or Mikael (Vidstedt, I assume? :-). regards, Andrew Dinn ----------- From mik3hall at gmail.com Thu Jan 17 14:37:06 2019 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 17 Jan 2019 08:37:06 -0600 Subject: jpackage OS X minimum OS version Message-ID: <9D197D13-6C2E-42BC-9B5C-4FCF6A62DB2B@gmail.com> It appears there is a minimum OS version? I created a toy app. From command line? open outputdir/TestApp.app LSOpenURLsWithRole() failed with error -10825 for the file /Users/mjh/HalfPipe/Test/outputdir/TestApp.app. Double click launching? You can?t use this version of the application ?TestApp? with this version of macOS. You have macOS 10.12.6. The application requires macOS 10.13 or later. From swpalmer at gmail.com Thu Jan 17 14:50:17 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Jan 2019 09:50:17 -0500 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: References: Message-ID: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > > Hi Gunnar, > > Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. > > Regards, > Nishit Jain > On 17-01-2019 14:37, Gunnar Morling wrote: >> Hi, >> >> I took a look at the compact number formatting recently added in JDK 12. >> >> There's setMinimumFractionDigits() to control the number of fractional >> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but >> it also will format 1,000 as 1.0K. Is there a way to have fractional >> digits but remove trailing zeros, so that 1,500 and 1,000 would be >> formatted as 1.5K and 1K, respectively? From andy.herrick at oracle.com Thu Jan 17 15:06:28 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 17 Jan 2019 10:06:28 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> References: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> Message-ID: <293257d2-a998-0837-fc0a-d491098078d0@oracle.com> If I remove the line -nologo from lib-jdk.jpackage.gmk: > 69 LDFLAGS_windows := -nologo, \ I get the logo during build (same with console andnon-console version): > Microsoft (R) Incremental Linker Version 14.12.25835.0 > Copyright (C) Microsoft Corporation.? All rights reserved. do I need something to include CXXFLAGS_JDKEXE into LDFLAGS ? (there is no other LDFLAGS line...) here's the non-console APPLAUNCHERWEXE case: > # Build non-console version of launcher > ifeq ($(OPENJDK_TARGET_OS), windows) > > ? $(eval $(call SetupJdkExecutable, BUILD_JPACKAGE_APPLAUNCHERWEXE, \ > ????? NAME := jpackageapplauncherw, \ > ????? OUTPUT_DIR := > $(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources, \ > ????? SYMBOLS_DIR := > $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/jpackageapplauncherw, \ > ????? SRC := $(JPACKAGE_APPLAUNCHEREXE_SRC), \ > ????? TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ > ????? OPTIMIZATION := LOW, \ > ????? CFLAGS := $(CXXFLAGS_JDKEXE), \ > ????? CFLAGS_windows := -EHsc -DUNICODE -D_UNICODE, \ > ????? LDFLAGS_windows := -nologo, \ <------------------------------------- > ????? LIBS := $(LIBCXX), \ > ????? LIBS_windows :=? user32.lib shell32.lib advapi32.lib, \ > ? )) > > ? TARGETS += $(BUILD_JPACKAGE_APPLAUNCHERWEXE) > endif /Andy On 1/15/2019 8:09 AM, Magnus Ihse Bursie wrote: > Hi Andy, > > This is looking really sweet from a build perspective! > > Just a few minor nits: > > * In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval > $(call SetupBuildLauncher, jpackage ....") two spaces. > > * In Lib-jdk.jpackage.gmk, I think there's still room to prune some > more unnecessary compiler flags and parameters to SetupJdkExecutable: > 65 CFLAGS_linux := -fPIC, \ > 66 CFLAGS_solaris := -KPIC, \ > 67 CFLAGS_macosx := -fPIC, \ > ?I wonder if these really are needed. Normally, only shared libraries > neeed PIC code. (And for those we set it automatically.) > > 69 LDFLAGS_windows := -nologo, \ > This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. (Also > in the second block, for jpackageapplauncherw). > > 72 LIBS_solaris := -lc, \ > Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, > and is always included. > > 75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \ > This is setup by default by SetupJdkExecutable, so you can remove it. > (Also in the second block, for jpackageapplauncherw). > > Finally, I do believe that the setups of jpackageapplauncher and > jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not > Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they > are not "really" launchers in our normal sense, but they are at least > more launchers than they are libraries. > > As we've talked about privately, in the future I'd like to see Windows > too use the SetupBuildLauncher method for creating the launcher, but > this is clearly good enough for inclusion in the mainline. > > I also have a question about > test/jdk/tools/jpackage/resources/license.txt. What is it used for? > And why the odd (incorrect?) spelling of license? > > /Magnus > > On 2019-01-11 20:41, Andy Herrick wrote: >> This is the second update to the Request For Review of the >> implementation of the Java Packager Tool (jpackager) as described in >> JEP 343: Packaging Tool >> >> >> >> This webrev corresponds to the second EA build, Build 8 (2019/1/8), >> posted at http://jdk.java.net/jpackage/ >> >> This update renames the package used to "jdk.jpackage", removes the >> Single Instance Service (and CLI option --singleton), adds several >> other CLI options, adds more automated tests, and contains fixes to >> the following issues (since update 1 on 11/09/2018): >> >> JDK-8212164???? resolve jre.list and jre.module.list >> JDK-8212936???? Makefile and other improvements for jpackager >> JDK-8213385???? jpackager Command-Line Argument File. >> JDK-8213392???? Enhance --help and --version >> JDK-8213425???? Analyze output from Source code scanner and fix where >> needed. >> JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk >> JDK-8213748???? jpackager native launcher for macosx, linux. >> JDK-8213756???? SingleInstance runtime improvements >> JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails >> JDK-8213963???? Flatten out jpackager packages and resources. >> JDK-8214021???? Create additional automated tests for jpackager >> JDK-8214051???? rename jpackager tool to jpackage >> JDK-8214070???? Analyze and Fix issues reported by Parfait >> JDK-8214143???? Reduce Resource files >> JDK-8214495???? Change behavior of --license-file >> JDK-8214575???? Exe installers will install application over existing >> installation >> JDK-8214899???? rename papplauncher and it's library and move src to >> appropriate places >> JDK-8214982???? jpackage causes failures in existing HelpFlagsTest >> and VersionCheck tests >> JDK-8215020???? create-jre-installer exe fails when --runtime-image >> is specified. >> JDK-8215036???? Create initial set of tests for jpackage >> create-installer mode >> JDK-8215453???? remove unused BundlerParams and fix misleading messages >> JDK-8215515???? Add a command line option to override internal >> resources. >> JDK-8215900???? Without --files args, only jars in the top level of >> --input are added to class-path >> JDK-8215903???? modify behavior of retaining temporary output dir >> JDK-8216190???? Remove Single Instance Service support from jpackage >> JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs >> JDK-8216373???? temporary build-root left behind when using secondary >> launcher(s) >> JDK-8216492???? Update copyright of all new jpackage files to 2019 >> >> Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 >> >> Note: SingleInstanceService API was removed (see >> https://bugs.openjdk.java.net/browse/JDK-8216190). >> An example stand alone implementation can be found at: >> http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java >> >> please send feedback to core-libs-dev at openjdk.java.net >> >> /Andy Herrick >> > From swpalmer at gmail.com Thu Jan 17 15:37:53 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Jan 2019 10:37:53 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> Message-ID: I'm creating a MSI installer. My application name did have spaces in it. I can confirm that changing the --name parameter to something without spaces avoids the issue, though this is still clearly a bug that needs to be fixed. It also seems that uninstall does not work. When I attempt it I get this error message from Add/Remove Programs: [Window Title] C:\WINDOWS\system32\msiexec.exe [Content] Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item. [OK] I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the real issue is. Maybe a bad message from Windows and the path that can't be accessed is a parameter to msiexec?? I'm using Microsoft Windows [Version 10.0.17134.471] Regards, Scott On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick wrote: > Simple tests of --win-menu and --win-shortcut options on Windows 7 are > working for me. Shortcuts are created as expected when running either > the exe or msi installer generated. > > Can you share the full OS version and full command you use , perhaps > some combination of options is not working. > > /Andy > > > On 1/16/2019 7:47 PM, Scott Palmer wrote: > > Are the flags to create shortcuts in the start menu and on the desktop > supposed to be working at this point? I tried them and they had no effect. > > > > Scott > > From thomas.stuefe at gmail.com Thu Jan 17 15:40:17 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Jan 2019 16:40:17 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: Hi Alan, On Thu, Jan 17, 2019 at 9:00 AM Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > Do you object against keeping these counters (which basically boils down > to Thread::current->stat_structure->counter++)? Or do you even object > against making upcalls into the jvm? Note that, if deemed necessary, we > could omit updating the counters unless JFR or our extended thread dumps > are activated (which are the consumers of the counters). > > In any case, I would have assumed the costs for upcall + counter update to > be insignificant compared to the IO calls. We should of course measure that. > > If you generally object upcalls into the libjvm for statistical/monitoring > reasons, this would make matters on a number of fronts more complicated. > For instance, it was discussed extending NMT coverage to the JDK - which is > already in part reality at Unsafe.AllocateMemory - and this would have to > be done with upcalls too. > > There are many issues here that will need write-up and discussion, maybe a > JEP if discussions converge on a proposal to bring into the main line as > this is a significant change with implications for many areas of the > platform. It also potentially conflicts in direction with some of the other > projects in progress (particularly with Loom trying to re-imagine threads, > do you really want to collect I/O stats on a per thread basis in the > future???). > > I think we are aiming for something pragmatic which works right now, with traditional threads, since per-thread IO is a really interesting statistic in App server contexts. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go away > or change significantly in the future. We've been on that path for some > time, e.g. the zip area or the prototype to replace the SocketImpl used for > classic networking that eliminates a lot of the native code touched in that > area by the webrev. Once Panama is further along then I assume we will want > to make use of it in the core libraries and at least initially replace the > JNI methods that just wrap syscalls today, and longer term more significant > refactoring. My point is that instrumenting native methods may not be the > right approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. There > is some support for collecting I/O stats in JFR today and maybe someone > working in that area can explain that a bit more and what the issues are. > I understand your concerns, thank you for explaining. I have not followed Panama that closely. I had a closer look today and like it, it looks promising and does address a number of real pain points. Sorry for not being up to date. So, your long term goal is to get rid of all native JDK libraries, move all that - partly highly platform dependent - coding up to java and just do downcalls to naked, unadorned system APIs via something like Pinvoke? And your argument is that it makes not much sense to put a lot of work into the native JDK layer since it will vanish long term? Thanks, Thomas > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can be > proposed. > > -Alan > From andy.herrick at oracle.com Thu Jan 17 15:59:57 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 17 Jan 2019 10:59:57 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> Message-ID: <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> yes - seeing several problems when space in app name - filed JDK-8217331 and will address. /Andy On 1/17/2019 10:37 AM, Scott Palmer wrote: > I'm creating a MSI installer. My application name did have spaces in > it. I can confirm that changing the --name parameter to something > without spaces avoids the issue, though this is still clearly a bug > that needs to be fixed. > > It also seems that uninstall does not work.? When I attempt it I get > this error message from Add/Remove Programs: > > [Window Title] > C:\WINDOWS\system32\msiexec.exe > > [Content] > Windows cannot access the specified device, path, or file. You may not > have the appropriate permissions to access the item. > > [OK] > > I can run?C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what > the real issue is. Maybe a bad message from Windows and the path that > can't be accessed is a parameter to msiexec?? > > I'm using?Microsoft Windows [Version 10.0.17134.471] > > Regards, > > Scott > > > On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick > wrote: > > Simple tests of --win-menu and --win-shortcut options on Windows 7 > are > working for me.? Shortcuts are created as expected when running > either > the exe or msi installer generated. > > Can you share the full OS version and full command you use , perhaps > some combination of options is not working. > > /Andy > > > On 1/16/2019 7:47 PM, Scott Palmer wrote: > > Are the flags to create shortcuts in the start menu and on the > desktop supposed to be working at this point? I tried them and > they had no effect. > > > > Scott > From Roger.Riggs at oracle.com Thu Jan 17 16:14:25 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 17 Jan 2019 11:14:25 -0500 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> Message-ID: <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> Hi Nishit, In the test, there are a couple of RuntimeExceptions with messages that start with "As expected"... That's counter intuitive, that a failure of the test is reported with a message saying, its normal! I would use a message like:? "XXException should have been thrown..." The size of Integer.MAX_VALUE - 2 is implementation specific, I think more typically max -8 is used to get the biggest allocation. java/util/Base64.java: Lines 335-342:? This optimization is not mentioned in the bug report and should be a separate review. 245, 686:? in outLength(), the 2nd parameter would be easier to understand as 'throwOOME', meaning to throw OOM if length is too large. The 'withOutputParam' only has any meaning in the context of the caller. And even for the private method write the javadoc describing the behavior. It also makes the call sites clearer, the argument will be true to throw. Thanks, Roger On 01/17/2019 02:07 AM, Nishit Jain wrote: > Hi, > > Please review the fix for 8210583 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 > Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 > > Issue: Base64.Encoder.encode and Base64.Decoder.decode methods > incorrectly throw unspecified exception e.g. > NegativeArraySizeException, when the input byte array size is too > large such that the calculated output byte size goes beyond the > max-integer boundary and wraps around. > > Fix: Throw an OutOfMemoryError if the output byte array/buffer or > memory can not be allocated. There is an unrelated change in > encodeToString(byte[]) where a string instance is created using > JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string > constructor, to save memory. > > Regards, > Nishit Jain From swpalmer at gmail.com Thu Jan 17 16:21:52 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Jan 2019 11:21:52 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> Message-ID: Note that the uninstall is still failing after I removed the spaces from the app name. I didn't mean to imply these issues were related. On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick wrote: > yes - seeing several problems when space in app name - filed JDK-8217331 > and will address. > > /Andy > > On 1/17/2019 10:37 AM, Scott Palmer wrote: > > I'm creating a MSI installer. My application name did have spaces in it. I > can confirm that changing the --name parameter to something without spaces > avoids the issue, though this is still clearly a bug that needs to be fixed. > > It also seems that uninstall does not work. When I attempt it I get this > error message from Add/Remove Programs: > > [Window Title] > C:\WINDOWS\system32\msiexec.exe > > [Content] > Windows cannot access the specified device, path, or file. You may not > have the appropriate permissions to access the item. > > [OK] > > I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the > real issue is. Maybe a bad message from Windows and the path that can't be > accessed is a parameter to msiexec?? > > I'm using Microsoft Windows [Version 10.0.17134.471] > > Regards, > > Scott > > > On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick > wrote: > >> Simple tests of --win-menu and --win-shortcut options on Windows 7 are >> working for me. Shortcuts are created as expected when running either >> the exe or msi installer generated. >> >> Can you share the full OS version and full command you use , perhaps >> some combination of options is not working. >> >> /Andy >> >> >> On 1/16/2019 7:47 PM, Scott Palmer wrote: >> > Are the flags to create shortcuts in the start menu and on the desktop >> supposed to be working at this point? I tried them and they had no effect. >> > >> > Scott >> >> > From naoto.sato at oracle.com Thu Jan 17 16:37:03 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 17 Jan 2019 08:37:03 -0800 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> Message-ID: <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> Hi Nishit, Thanks. Updated: http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ Naoto On 1/17/19 2:57 AM, Nishit Jain wrote: > Hi Naoto, > > Looks good to me. Just a small suggestion. > > - To improve readability, can we declare "standalone mask" (0x8000) as a > static field and use that at all the places? > > Regards, > Nishit Jain > On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8216969 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >> >> For parsing the context sensitive month 'M', the logic was to look for >> the best match for the short name regardless of the styles. Changed >> the parsing code to take the context into account. >> >> Naoto > From volker.simonis at gmail.com Thu Jan 17 17:31:21 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Jan 2019 18:31:21 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On Thu, Jan 17, 2019 at 1:31 PM Alan Bateman wrote: > > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > > > Do you object against keeping these counters (which basically boils > > down to Thread::current->stat_structure->counter++)? Or do you even > > object against making upcalls into the jvm? Note that, if deemed > > necessary, we could omit updating the counters unless JFR or our > > extended thread dumps are activated (which are the consumers of the > > counters). > > > > In any case, I would have assumed the costs for upcall + counter > > update to be insignificant compared to the IO calls. We should of > > course measure that. > > > > If you generally object upcalls into the libjvm for > > statistical/monitoring reasons, this would make matters on a number of > > fronts more complicated. For instance, it was discussed extending NMT > > coverage to the JDK - which is already in part reality at > > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > > > There are many issues here that will need write-up and discussion, maybe > a JEP if discussions converge on a proposal to bring into the main line > as this is a significant change with implications for many areas of the > platform. We could certainly create a new JEP for this feature, but in the end it is rather trivial. In fact it can be expressed in a single sentence: instrument all native IO functions to collect the number of read and written bytes. As stated before, the overhead is minimal (Gunter will provide some concrete benchmarks soon) and could even be dropped to ~zero if you really insist on this (e.g. by wrapping all calls by a switch which is based on a system property). But honestly speaking we don't think this is really necessary. I want to stress the fact that this is not a wacky idea Gunter came up with but a feature which we're using for almost 10 years in our SAP JVM. It is running in all our enterprise scenarios without ever having caused any problems. > It also potentially conflicts in direction with some of the > other projects in progress (particularly with Loom trying to re-imagine > threads, do you really want to collect I/O stats on a per thread basis > in the future???). > Who knows about the future, our trace is quite useful today :) You're right that this may change when Loom becomes available and I think we've faced similar problems when people started using ThreadPools more heavily. We've mitigated this with another SAP JVM specific feature (which we havn't contributed yet) that we've called "Thread Annotations". They could be set from user code and our profiler could then split the collected statistics based on these annotations even if they were all collected for the same native thread. I image we can come up with similar solutions for project Loom in the future, once it becomes available. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go > away or change significantly in the future. But that's actually nice! That will eventually shrink the code proposed by this change to a few places and make the costs of supporting it even smaller. And needless to say that SAP is committed to support and maintain this feature once it gets integrated. > We've been on that path for > some time, e.g. the zip area or the prototype to replace the SocketImpl > used for classic networking that eliminates a lot of the native code > touched in that area by the webrev. Once Panama is further along then I > assume we will want to make use of it in the core libraries and at least > initially replace the JNI methods that just wrap syscalls today, and > longer term more significant refactoring. Again, I think this will make our implementation simpler because we would have to instrument fewer places. > My point is that instrumenting > native methods may not be the right approach, instead maybe we should be > look at instrumenting the I/O paths at the java level as that will > likely play better with the VM. We gathered some experience with Java-level instrumentation during the last years (e.g. Dynatrace, Wiley, etc) and it has not always been positive :) The overhead is certainly higher compared to the native instrumentation at C-level. And it can influence especially JIT optimizations in an unpredictable way. Finally the Java instrumentation is version dependent and puts the burden on instrumenting the "right" places (end especially catching all the right places) on the developer / support engineer. You could of course upload this overhead into another, external project like JFR, but supporting that doesn't come for free either. > There is some support for collecting I/O > stats in JFR today and maybe someone working in that area can explain > that a bit more and what the issues are. > As far as I understand, the corresponding JFR events only sample the time spent in the instrumented calls while we do an exact IO statistics with regard to the bytes read and written. > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. As I wrote before, this is a solution we're using successfully since many years. We're convinced that is is superior to Java-level instrumentation with regards to both, overhead as well as maintainability. > > -Alan From gunter.haug at sap.com Thu Jan 17 15:15:40 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Thu, 17 Jan 2019 15:15:40 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <5C406F7F.5000409@oracle.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <5C406F7F.5000409@oracle.com> Message-ID: <805AF7A7-C1F1-48E4-9831-4740A284C16A@sap.com> > Today we have File Read, File Write, Socket Read, and Socket Write > events. The hook points are added to the JDK using bytecode > instrumentation. This happens when you start a JFR recording, so there > is no overhead unless you use it. > > Erik However, in this context it's worth to note that the information provided by the events Erik describes is quite different from what we have proposed. The existing events are triggered only if the time the IO operation takes, exceeds a threshold (10ms/20ms for profile/default settings respectively). They are aimed for providing information on the time IO operations take and do not provide per thread IO statistics. What we are interested in is per thread information similar to the jdk.ThreadAllocationStatistics event. With respect to performance impact, I was not able to observe a degradation above the measurement noise level in real-world benchmarks. I will try to do measurements with synthetic benchmarks and report back ASAP. Gunter ?On 17.01.19, 13:07, "Erik Gahlin" wrote: On 2019-01-17 09:00, Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: >> : >> >> Do you object against keeping these counters (which basically boils >> down to Thread::current->stat_structure->counter++)? Or do you even >> object against making upcalls into the jvm? Note that, if deemed >> necessary, we could omit updating the counters unless JFR or our >> extended thread dumps are activated (which are the consumers of the >> counters). >> >> In any case, I would have assumed the costs for upcall + counter >> update to be insignificant compared to the IO calls. We should of >> course measure that. >> >> If you generally object upcalls into the libjvm for >> statistical/monitoring reasons, this would make matters on a number >> of fronts more complicated. For instance, it was discussed extending >> NMT coverage to the JDK - which is already in part reality at >> Unsafe.AllocateMemory - and this would have to be done with upcalls too. >> > There are many issues here that will need write-up and discussion, > maybe a JEP if discussions converge on a proposal to bring into the > main line as this is a significant change with implications for many > areas of the platform. It also potentially conflicts in direction with > some of the other projects in progress (particularly with Loom trying > to re-imagine threads, do you really want to collect I/O stats on a > per thread basis in the future???). > > As regards the points to instrument then I think we have to assume > that much of the native code that is targeted by the current webrev > will go away or change significantly in the future. We've been on that > path for some time, e.g. the zip area or the prototype to replace the > SocketImpl used for classic networking that eliminates a lot of the > native code touched in that area by the webrev. Once Panama is further > along then I assume we will want to make use of it in the core > libraries and at least initially replace the JNI methods that just > wrap syscalls today, and longer term more significant refactoring. My > point is that instrumenting native methods may not be the right > approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. > There is some support for collecting I/O stats in JFR today and maybe > someone working in that area can explain that a bit more and what the > issues are. > Today we have File Read, File Write, Socket Read, and Socket Write events. The hook points are added to the JDK using bytecode instrumentation. This happens when you start a JFR recording, so there is no overhead unless you use it. Erik > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. > > -Alan From gunnar at hibernate.org Thu Jan 17 17:42:26 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 17 Jan 2019 18:42:26 +0100 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> References: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> Message-ID: > this could be a good value add to introduce an API [...] Should I file a JDK issue then (not sure I can even)? > Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? That wouldn't achieve that there's no fraction digit(s) in case of trailing 0s. With min and max fraction digits set to 1, there'll always be exactly one fraction digit. So having an API that'd allow to remove trailing 0s would be very welcomed. Btw. another suggestion I'd have is to document guarantees in terms of thread-safety of CompactNumberFormat. It's a common mistake to use SimpleDateFormat concurrently from multiple threads (although its docs even state that this is incorrect). So CNF should at least document its behaviour (or even allow for concurrent access, if feasible). Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : > > Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > > > On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > > > > Hi Gunnar, > > > > Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. > > > > Regards, > > Nishit Jain > > On 17-01-2019 14:37, Gunnar Morling wrote: > >> Hi, > >> > >> I took a look at the compact number formatting recently added in JDK 12. > >> > >> There's setMinimumFractionDigits() to control the number of fractional > >> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >> it also will format 1,000 as 1.0K. Is there a way to have fractional > >> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >> formatted as 1.5K and 1K, respectively? From swpalmer at gmail.com Thu Jan 17 18:15:00 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Jan 2019 13:15:00 -0500 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: References: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> Message-ID: <587A331C-4E0E-4578-9F41-60F347D353AC@gmail.com> On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: >> this could be a good value add to introduce an API [...] > > Should I file a JDK issue then (not sure I can even)? > >> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > > That wouldn't achieve that there's no fraction digit(s) in case of > trailing 0s. Yes it does. I just tried. Don?t set a minimum fraction digits, since you don?t actually want a minimum. Scott > >> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : >> >> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? >> >>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: >>> >>> Hi Gunnar, >>> >>> Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. >>> >>> Regards, >>> Nishit Jain >>>> On 17-01-2019 14:37, Gunnar Morling wrote: >>>> Hi, >>>> >>>> I took a look at the compact number formatting recently added in JDK 12. >>>> >>>> There's setMinimumFractionDigits() to control the number of fractional >>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but >>>> it also will format 1,000 as 1.0K. Is there a way to have fractional >>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be >>>> formatted as 1.5K and 1K, respectively? From gunnar at hibernate.org Thu Jan 17 19:22:12 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 17 Jan 2019 20:22:12 +0100 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: <587A331C-4E0E-4578-9F41-60F347D353AC@gmail.com> References: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> <587A331C-4E0E-4578-9F41-60F347D353AC@gmail.com> Message-ID: > since you don?t actually want a minimum. I'd like to have 1 fractional digit unless it's 0: 1,000 -> 1K (*not* 1.0K) 1,500 -> 1.5K --Gunnar Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer : > > > On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: > > >> this could be a good value add to introduce an API [...] > > > > Should I file a JDK issue then (not sure I can even)? > > > >> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > > > > That wouldn't achieve that there's no fraction digit(s) in case of > > trailing 0s. > > Yes it does. I just tried. Don?t set a minimum fraction digits, since you don?t actually want a minimum. > > Scott > > > > >> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : > >> > >> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > >> > >>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > >>> > >>> Hi Gunnar, > >>> > >>> Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. > >>> > >>> Regards, > >>> Nishit Jain > >>>> On 17-01-2019 14:37, Gunnar Morling wrote: > >>>> Hi, > >>>> > >>>> I took a look at the compact number formatting recently added in JDK 12. > >>>> > >>>> There's setMinimumFractionDigits() to control the number of fractional > >>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >>>> it also will format 1,000 as 1.0K. Is there a way to have fractional > >>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >>>> formatted as 1.5K and 1K, respectively? From Roger.Riggs at oracle.com Thu Jan 17 20:20:36 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 17 Jan 2019 15:20:36 -0500 Subject: RFR [test] 8217340: Compilation failed: tools/launcher/Test7029048.java Message-ID: Please review the addition of an @library /test/lib to ensure the compilation succeeds.? [1] diff --git a/test/jdk/tools/launcher/Test7029048.java b/test/jdk/tools/launcher/Test7029048.java --- a/test/jdk/tools/launcher/Test7029048.java +++ b/test/jdk/tools/launcher/Test7029048.java @@ -23,9 +23,10 @@ ?/** ? * @test - * @bug 7029048 + * @bug 7029048 8217340 ? * @summary Ensure that the launcher defends against user settings of the ? *????????? LD_LIBRARY_PATH environment variable on Unixes + * @library /test/lib ? * @compile -XDignore.symbol.file ExecutionEnvironment.java Test7029048.java ? * @run main Test7029048 ? */ [1] https://bugs.openjdk.java.net/browse/JDK-8217340 Thanks, Roger From lance.andersen at oracle.com Thu Jan 17 20:23:43 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 17 Jan 2019 15:23:43 -0500 Subject: RFR [test] 8217340: Compilation failed: tools/launcher/Test7029048.java In-Reply-To: References: Message-ID: <654D0344-E1CE-4D36-AAE7-20793B8FC49C@oracle.com> +1 > On Jan 17, 2019, at 3:20 PM, Roger Riggs wrote: > > Please review the addition of an @library /test/lib to ensure the compilation succeeds. [1] > > diff --git a/test/jdk/tools/launcher/Test7029048.java b/test/jdk/tools/launcher/Test7029048.java > --- a/test/jdk/tools/launcher/Test7029048.java > +++ b/test/jdk/tools/launcher/Test7029048.java > @@ -23,9 +23,10 @@ > > /** > * @test > - * @bug 7029048 > + * @bug 7029048 8217340 > * @summary Ensure that the launcher defends against user settings of the > * LD_LIBRARY_PATH environment variable on Unixes > + * @library /test/lib > * @compile -XDignore.symbol.file ExecutionEnvironment.java Test7029048.java > * @run main Test7029048 > */ > > [1] https://bugs.openjdk.java.net/browse/JDK-8217340 > > Thanks, Roger > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Thu Jan 17 21:14:35 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 17 Jan 2019 13:14:35 -0800 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> Message-ID: <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> I agree with 'withOutputParam' comment. It does seem to require some explanation. Same for the newly introduced return value -1. The test: 46 // A separate output array is not required, as it is not used and 47 // the exception is thrown beforehand while calculating the size 48 // of the encoded bytes using input array This seems to make an assumption on the implementation. Test should not depend on the internal impl. Naoto On 1/17/19 8:14 AM, Roger Riggs wrote: > Hi Nishit, > > In the test, there are a couple of RuntimeExceptions with messages that > start with "As expected"... > > That's counter intuitive, that a failure of the test is reported with a > message saying, its normal! > I would use a message like:? "XXException should have been thrown..." > > The size of Integer.MAX_VALUE - 2 is implementation specific, > I think more typically max -8 is used to get the biggest allocation. > > java/util/Base64.java: > > Lines 335-342:? This optimization is not mentioned in the bug report and > should be a separate review. > > > 245, 686:? in outLength(), the 2nd parameter would be easier to understand > as 'throwOOME', meaning to throw OOM if length is too large. > The 'withOutputParam' only has any meaning in the context of the caller. > And even for the private method write the javadoc describing the behavior. > > It also makes the call sites clearer, the argument will be true to throw. > > Thanks, Roger > > > On 01/17/2019 02:07 AM, Nishit Jain wrote: >> Hi, >> >> Please review the fix for 8210583 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >> >> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >> incorrectly throw unspecified exception e.g. >> NegativeArraySizeException, when the input byte array size is too >> large such that the calculated output byte size goes beyond the >> max-integer boundary and wraps around. >> >> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >> memory can not be allocated. There is an unrelated change in >> encodeToString(byte[]) where a string instance is created using >> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string >> constructor, to save memory. >> >> Regards, >> Nishit Jain > From mikael.vidstedt at oracle.com Thu Jan 17 22:02:00 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 17 Jan 2019 14:02:00 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java Message-ID: Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 Cheers, Mikael From igor.ignatyev at oracle.com Thu Jan 17 22:07:17 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Jan 2019 14:07:17 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: References: Message-ID: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> Mikael, looks good and trivial to me. -- Igor > On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: > > > Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ > Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 > > Cheers, > Mikael > From philipp.kunz at paratix.ch Thu Jan 17 22:53:05 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 17 Jan 2019 23:53:05 +0100 Subject: Clarification in Attributes equal Message-ID: <1547765585.2438.32.camel@paratix.ch> Hi, In the JavaDoc comment for java.util.jar.Attributes#equals on line 269 it says: [...] Returns true if the given object is also an instance of Attributes [...] but that is not actually true. Passing a LinkedHashMap results also in true returned given equal content of both maps. Comment and implementation don't match perfectly. But which way it should be? Could not be less important probably, so please excuse me if it's like spam. Philipp From mikael.vidstedt at oracle.com Thu Jan 17 23:00:01 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 17 Jan 2019 15:00:01 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> References: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> Message-ID: <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> Thanks Igor! Pushed. Cheers, Mikael > On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: > > Mikael, > > looks good and trivial to me. > > -- Igor > >> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ >> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 >> >> Cheers, >> Mikael >> > From swpalmer at gmail.com Thu Jan 17 23:35:42 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Jan 2019 18:35:42 -0500 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: References: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> <587A331C-4E0E-4578-9F41-60F347D353AC@gmail.com> Message-ID: <1CF65944-BCB1-4179-9A16-8247C113B30B@gmail.com> On Jan 17, 2019, at 2:22 PM, Gunnar Morling wrote: >> since you don?t actually want a minimum. > > I'd like to have 1 fractional digit unless it's 0: > > 1,000 -> 1K (*not* 1.0K) > 1,500 -> 1.5K > > --Gunnar That?s exactly what setting the maximum fraction digits to 1 does. Scott > >> Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer : >> >> >> On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: >> >>>> this could be a good value add to introduce an API [...] >>> >>> Should I file a JDK issue then (not sure I can even)? >>> >>>> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? >>> >>> That wouldn't achieve that there's no fraction digit(s) in case of >>> trailing 0s. >> >> Yes it does. I just tried. Don?t set a minimum fraction digits, since you don?t actually want a minimum. >> >> Scott >> >>> >>>> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : >>>> >>>> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? >>>> >>>>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: >>>>> >>>>> Hi Gunnar, >>>>> >>>>> Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>>> On 17-01-2019 14:37, Gunnar Morling wrote: >>>>>> Hi, >>>>>> >>>>>> I took a look at the compact number formatting recently added in JDK 12. >>>>>> >>>>>> There's setMinimumFractionDigits() to control the number of fractional >>>>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but >>>>>> it also will format 1,000 as 1.0K. Is there a way to have fractional >>>>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be >>>>>> formatted as 1.5K and 1K, respectively? From lance.andersen at oracle.com Thu Jan 17 23:50:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 17 Jan 2019 18:50:30 -0500 Subject: Clarification in Attributes equal In-Reply-To: <1547765585.2438.32.camel@paratix.ch> References: <1547765585.2438.32.camel@paratix.ch> Message-ID: Hi Philipp, I suspect the behavior dates back to the original implementation in JDK 1.2. I am not sure it should be changed at this point though the javadocs should be updated. Best Lance > On Jan 17, 2019, at 5:53 PM, Philipp Kunz wrote: > > Hi, > > In the JavaDoc comment for java.util.jar.Attributes#equals on line 269 > it says: > [...] Returns true if the given object is also an instance of > Attributes [...] > but that is not actually true. Passing a LinkedHashMap results also in > true returned given equal content of both maps. > Comment and implementation don't match perfectly. But which way it > should be? > Could not be less important probably, so please excuse me if it's like > spam. > > Philipp Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From sandhya.viswanathan at intel.com Fri Jan 18 01:13:35 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 18 Jan 2019 01:13:35 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A50E3B@FMSMSX126.amr.corp.intel.com> Hi Andrew, >>> Perhaps Intel also could provide help with testing? [Sadhya, is this an option?] Yes, we can help with testing this feature as needed. Best Regards, Sandhya -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Thursday, January 17, 2019 6:28 AM To: Alan Bateman ; Brian Goetz Cc: core-libs-dev at openjdk.java.net; hotspot compiler ; Jonathan Halliday ; Viswanathan, Sandhya ; Mikael Vidstedt Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory Hi Alan, Thanks for your response. On 17/01/2019 12:53, Alan Bateman wrote: > I skimmed through the current draft. In the most recent discussion > then I think we had converged on "SYNC" rather than "PERSISTENT", the > reasoning being that there is persistence already with regular file > mapped files, also it aligns with the MAP_SYNC flag to mmap. I don't > recall if the discussion on isPersistent concluded, that was more of a > naming issue and whether you include an isXXX method or not is not > critical to the proposal. The overload of the force method to specify > a range is a good addition, irrespective of the JEP. Ok, thanks. At least sync is now being used consistently in the public API. I will look at renaming internal vars/methods to use sync when I publish the next webrev. > One thing to clarify is the heading "Proposed Restricted Public JDK > API Changes". The proposal (and the early webrevs) exposed > writebackMemory in the internal Unsafe, not sun.misc.Unsafe, which I think is right. > This makes it a JDK internal API so it doesn't need to be in JEP. I am happy to remove it from the JEP if needed. Does it do any harm to leave it? > Did you get any feedback on the Testing section? Given that the > feature needs special hardware then it will need commitment to test is > on a regular basis. It's a similar issue to the draft "JEP 337: RDMA > Network Sockets" where special hardware is needed to full test the > feature. In the case of JEP 337 then some testing with emulation is possible. I believe I received no specific feedback on that topic. Some of the other Red Hat dev teams (i.e. not OpenJDK) and also dev staff at Intel are very keen to base some of their future work on this feature. So, it will certainly get tested /after/ JDK release :-) Red Hat does have the Intel hardware needed to test this feature but, so far, nothing that can be used to test on AArch64. Our OpenJDK team can access this kit for one-off testing but it is not currently available for continuous integration testing. I will propose to my manager that we acquire the relevant kit and ensure that all JDKs which implement this JEP are tested prior to release. We should also be able to test AArch64 using volatile memory to simulate a non-volatile memory device up to the point where the requisite AArch64-based NVM hardware becomes available. I am fairly confident this plan will be agreeable to the overlords whom I humbly serve. Perhaps Intel also could provide help with testing? [Sadhya, is this an option?] My bigger concern was that crash recovery tests may never be 100% reliable. A 100% guarantee requires the ability to engineer a machine crash at a precisely defined critical point of execution and some of the relevant critical locations will be embedded in the middle of JITted code making it hard to provoke the crash. So, the situations where a crash /can/ be engineered may not fully reflect those that occur in live deployments. That said, a dash of artificiality in test code is, perhaps, not so worthy of remark . . . > Vladimir and I have reviewed the JEP, it will need an area lead to > endorse, I think it can be Brian or Mikael in this case. Ok, thanks for the above answers. Looking forward to hearing further from Brian and/or Mikael (Vidstedt, I assume? :-). regards, Andrew Dinn ----------- From gunnar at hibernate.org Fri Jan 18 08:14:34 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 18 Jan 2019 09:14:34 +0100 Subject: Compact Number Formatting and Fraction Digits In-Reply-To: <1CF65944-BCB1-4179-9A16-8247C113B30B@gmail.com> References: <48143F49-450C-4751-9A1B-C3D3940E628D@gmail.com> <587A331C-4E0E-4578-9F41-60F347D353AC@gmail.com> <1CF65944-BCB1-4179-9A16-8247C113B30B@gmail.com> Message-ID: Aaah, ok, so I *only* must call setMaximumFractionDigits(). That's the part I had missed so far; thanks! --Gunnar Am Fr., 18. Jan. 2019 um 00:35 Uhr schrieb Scott Palmer : > > > On Jan 17, 2019, at 2:22 PM, Gunnar Morling wrote: > > >> since you don?t actually want a minimum. > > > > I'd like to have 1 fractional digit unless it's 0: > > > > 1,000 -> 1K (*not* 1.0K) > > 1,500 -> 1.5K > > > > --Gunnar > > That?s exactly what setting the maximum fraction digits to 1 does. > > Scott > > > > > >> Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer : > >> > >> > >> On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: > >> > >>>> this could be a good value add to introduce an API [...] > >>> > >>> Should I file a JDK issue then (not sure I can even)? > >>> > >>>> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > >>> > >>> That wouldn't achieve that there's no fraction digit(s) in case of > >>> trailing 0s. > >> > >> Yes it does. I just tried. Don?t set a minimum fraction digits, since you don?t actually want a minimum. > >> > >> Scott > >> > >>> > >>>> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : > >>>> > >>>> Wouldn?t this be accomplished with setMaximumFractionDigits(1) ? > >>>> > >>>>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > >>>>> > >>>>> Hi Gunnar, > >>>>> > >>>>> Currently there is no way to obtain the below expected behavior (to get 1K) when min fraction digit is set to non-zero value. I think that is not even expected when min fraction digits is set, but considering the objective of compact number formatting this could be a good value add to introduce an API which if set, truncates trailing fractional zeros while formatting output. This may need some thought process on its feasibility. > >>>>> > >>>>> Regards, > >>>>> Nishit Jain > >>>>>> On 17-01-2019 14:37, Gunnar Morling wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I took a look at the compact number formatting recently added in JDK 12. > >>>>>> > >>>>>> There's setMinimumFractionDigits() to control the number of fractional > >>>>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >>>>>> it also will format 1,000 as 1.0K. Is there a way to have fractional > >>>>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >>>>>> formatted as 1.5K and 1K, respectively? From rachel at strangenoises.org Fri Jan 18 08:54:42 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Fri, 18 Jan 2019 08:54:42 +0000 Subject: Jpackage Windows shortcuts In-Reply-To: <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> Message-ID: odd, fwiw I didn't have that problem with --create-installer exe. Possibly because I'm doing --create-image as a separate first step? The space-squashing actually happens in that step, and then before either --create-installer I put the spaces back into the exe and cfg filenames ... but possibly miss it *inside* a file and that just hasn't happened to cause me a problem yet? -- Rachel On 17/01/2019 15:59, Andy Herrick wrote: > yes - seeing several problems when space in app name - filed > JDK-8217331 and > will address. > > /Andy > > > On 1/17/2019 10:37 AM, Scott Palmer wrote: >> I'm creating a MSI installer. My application name did have spaces in >> it. I can confirm that changing the --name parameter to something >> without spaces avoids the issue, though this is still clearly a bug >> that needs to be fixed. >> >> It also seems that uninstall does not work.? When I attempt it I get >> this error message from Add/Remove Programs: >> >> [Window Title] >> C:\WINDOWS\system32\msiexec.exe >> >> [Content] >> Windows cannot access the specified device, path, or file. You may >> not have the appropriate permissions to access the item. >> >> [OK] >> >> I can run?C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what >> the real issue is. Maybe a bad message from Windows and the path that >> can't be accessed is a parameter to msiexec?? >> >> I'm using?Microsoft Windows [Version 10.0.17134.471] >> >> Regards, >> >> Scott >> >> >> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick > > wrote: >> >> ??? Simple tests of --win-menu and --win-shortcut options on Windows 7 >> ??? are >> ??? working for me.? Shortcuts are created as expected when running >> ??? either >> ??? the exe or msi installer generated. >> >> ??? Can you share the full OS version and full command you use , perhaps >> ??? some combination of options is not working. >> >> ??? /Andy >> >> >> ??? On 1/16/2019 7:47 PM, Scott Palmer wrote: >> ??? > Are the flags to create shortcuts in the start menu and on the >> ??? desktop supposed to be working at this point? I tried them and >> ??? they had no effect. >> ??? > >> ??? > Scott >> > From rachel at strangenoises.org Fri Jan 18 08:59:49 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Fri, 18 Jan 2019 08:59:49 +0000 Subject: Jpackage Windows shortcuts In-Reply-To: References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> Message-ID: <02bb11d8-637c-64b2-1dc1-a7838d0fec7c@strangenoises.org> FWIW uninstall working for me from Windows 10's "Apps & features" panel. Could it be doing something different when done from "Add/Remove Programs"? And (wild guessing) might that be related to the known bug about old versions not being uninstalled properly during upgrade? (You might already be able to tell Windows isn't my main platform, only having to use it for this! ;-) ) -- Rachel On 17/01/2019 16:21, Scott Palmer wrote: > Note that the uninstall is still failing after I removed the spaces from > the app name. I didn't mean to imply these issues were related. > > On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick > wrote: > >> yes - seeing several problems when space in app name - filed JDK-8217331 >> and will address. >> >> /Andy >> >> On 1/17/2019 10:37 AM, Scott Palmer wrote: >> >> I'm creating a MSI installer. My application name did have spaces in it. I >> can confirm that changing the --name parameter to something without spaces >> avoids the issue, though this is still clearly a bug that needs to be fixed. >> >> It also seems that uninstall does not work. When I attempt it I get this >> error message from Add/Remove Programs: >> >> [Window Title] >> C:\WINDOWS\system32\msiexec.exe >> >> [Content] >> Windows cannot access the specified device, path, or file. You may not >> have the appropriate permissions to access the item. >> >> [OK] >> >> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the >> real issue is. Maybe a bad message from Windows and the path that can't be >> accessed is a parameter to msiexec?? >> >> I'm using Microsoft Windows [Version 10.0.17134.471] >> >> Regards, >> >> Scott >> >> >> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick >> wrote: >> >>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are >>> working for me. Shortcuts are created as expected when running either >>> the exe or msi installer generated. >>> >>> Can you share the full OS version and full command you use , perhaps >>> some combination of options is not working. >>> >>> /Andy >>> >>> >>> On 1/16/2019 7:47 PM, Scott Palmer wrote: >>>> Are the flags to create shortcuts in the start menu and on the desktop >>> supposed to be working at this point? I tried them and they had no effect. >>>> Scott >>> From nishit.jain at oracle.com Fri Jan 18 09:57:14 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 18 Jan 2019 15:27:14 +0530 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> Message-ID: <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> Looks Good. Regards, Nishit Jain On 17-01-2019 22:07, Naoto Sato wrote: > Hi Nishit, > > Thanks. Updated: > > http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ > > Naoto > > On 1/17/19 2:57 AM, Nishit Jain wrote: >> Hi Naoto, >> >> Looks good to me. Just a small suggestion. >> >> - To improve readability, can we declare "standalone mask" (0x8000) >> as a static field and use that at all the places? >> >> Regards, >> Nishit Jain >> On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8216969 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >>> >>> For parsing the context sensitive month 'M', the logic was to look >>> for the best match for the short name regardless of the styles. >>> Changed the parsing code to take the context into account. >>> >>> Naoto >> From nishit.jain at oracle.com Fri Jan 18 11:03:32 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 18 Jan 2019 16:33:32 +0530 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> Message-ID: Hi Roger, Naoto, > The size of Integer.MAX_VALUE - 2 is implementation specific, I think more typically max -8 is used to get the biggest allocation. When Integer.MAX_VALUE - 8 is used, the decode methods do not throw the added OOME, because the computed value does not overflow Integer.MAX_VALUE, so to test the added OOME condition need to use Integer.MAX_VALUE - 2. Updated the webrev with rest of the suggestions http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ Regards, Nishit Jain On 18-01-2019 02:44, Naoto Sato wrote: > I agree with 'withOutputParam' comment. It does seem to require some > explanation. Same for the newly introduced return value -1. > > The test: > ? 46???????? // A separate output array is not required, as it is not > used and > ? 47???????? // the exception is thrown beforehand while calculating > the size > ? 48???????? // of the encoded bytes using input array > > This seems to make an assumption on the implementation. Test should > not depend on the internal impl. > > Naoto > > On 1/17/19 8:14 AM, Roger Riggs wrote: >> Hi Nishit, >> >> In the test, there are a couple of RuntimeExceptions with messages >> that start with "As expected"... >> >> That's counter intuitive, that a failure of the test is reported with >> a message saying, its normal! >> I would use a message like:? "XXException should have been thrown..." >> >> The size of Integer.MAX_VALUE - 2 is implementation specific, >> I think more typically max -8 is used to get the biggest allocation. >> >> java/util/Base64.java: >> >> Lines 335-342:? This optimization is not mentioned in the bug report and >> should be a separate review. >> >> >> 245, 686:? in outLength(), the 2nd parameter would be easier to >> understand >> as 'throwOOME', meaning to throw OOM if length is too large. >> The 'withOutputParam' only has any meaning in the context of the caller. >> And even for the private method write the javadoc describing the >> behavior. >> >> It also makes the call sites clearer, the argument will be true to >> throw. >> >> Thanks, Roger >> >> >> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>> Hi, >>> >>> Please review the fix for 8210583 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>> >>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>> incorrectly throw unspecified exception e.g. >>> NegativeArraySizeException, when the input byte array size is too >>> large such that the calculated output byte size goes beyond the >>> max-integer boundary and wraps around. >>> >>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>> memory can not be allocated. There is an unrelated change in >>> encodeToString(byte[]) where a string instance is created using >>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string >>> constructor, to save memory. >>> >>> Regards, >>> Nishit Jain >> From magnus.ihse.bursie at oracle.com Fri Jan 18 13:29:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Jan 2019 14:29:26 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: <293257d2-a998-0837-fc0a-d491098078d0@oracle.com> References: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> <293257d2-a998-0837-fc0a-d491098078d0@oracle.com> Message-ID: <59337a52-7247-e28a-b448-8e23f12fdec4@oracle.com> On 2019-01-17 16:06, Andy Herrick wrote: > > If I remove the line -nologo from lib-jdk.jpackage.gmk: > >> 69 LDFLAGS_windows := -nologo, \ > I get the logo during build (same with console andnon-console version): >> Microsoft (R) Incremental Linker Version 14.12.25835.0 >> Copyright (C) Microsoft Corporation.? All rights reserved. > do I need something to include CXXFLAGS_JDKEXE into LDFLAGS ? (there > is no other LDFLAGS line...) Ah, good catch. You should add LDFLAGS := $(LDFLAGS_JDKEXE), \ to your setup. /Magnus > here's the non-console APPLAUNCHERWEXE case: > >> # Build non-console version of launcher >> ifeq ($(OPENJDK_TARGET_OS), windows) >> >> ? $(eval $(call SetupJdkExecutable, BUILD_JPACKAGE_APPLAUNCHERWEXE, \ >> ????? NAME := jpackageapplauncherw, \ >> ????? OUTPUT_DIR := >> $(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources, \ >> ????? SYMBOLS_DIR := >> $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/jpackageapplauncherw, \ >> ????? SRC := $(JPACKAGE_APPLAUNCHEREXE_SRC), \ >> ????? TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ >> ????? OPTIMIZATION := LOW, \ >> ????? CFLAGS := $(CXXFLAGS_JDKEXE), \ >> ????? CFLAGS_windows := -EHsc -DUNICODE -D_UNICODE, \ >> ????? LDFLAGS_windows := -nologo, \ >> <------------------------------------- >> ????? LIBS := $(LIBCXX), \ >> ????? LIBS_windows :=? user32.lib shell32.lib advapi32.lib, \ >> ? )) >> >> ? TARGETS += $(BUILD_JPACKAGE_APPLAUNCHERWEXE) >> endif > > /Andy > > > On 1/15/2019 8:09 AM, Magnus Ihse Bursie wrote: >> Hi Andy, >> >> This is looking really sweet from a build perspective! >> >> Just a few minor nits: >> >> * In Launcher-jdk.jpackage.gmk, please indent the else clause >> ("$(eval $(call SetupBuildLauncher, jpackage ....") two spaces. >> >> * In Lib-jdk.jpackage.gmk, I think there's still room to prune some >> more unnecessary compiler flags and parameters to SetupJdkExecutable: >> 65 CFLAGS_linux := -fPIC, \ >> 66 CFLAGS_solaris := -KPIC, \ >> 67 CFLAGS_macosx := -fPIC, \ >> ?I wonder if these really are needed. Normally, only shared libraries >> neeed PIC code. (And for those we set it automatically.) >> >> 69 LDFLAGS_windows := -nologo, \ >> This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. >> (Also in the second block, for jpackageapplauncherw). >> >> 72 LIBS_solaris := -lc, \ >> Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, >> and is always included. >> >> 75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \ >> This is setup by default by SetupJdkExecutable, so you can remove it. >> (Also in the second block, for jpackageapplauncherw). >> >> Finally, I do believe that the setups of jpackageapplauncher and >> jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not >> Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they >> are not "really" launchers in our normal sense, but they are at least >> more launchers than they are libraries. >> >> As we've talked about privately, in the future I'd like to see >> Windows too use the SetupBuildLauncher method for creating the >> launcher, but this is clearly good enough for inclusion in the mainline. >> >> I also have a question about >> test/jdk/tools/jpackage/resources/license.txt. What is it used for? >> And why the odd (incorrect?) spelling of license? >> >> /Magnus >> >> On 2019-01-11 20:41, Andy Herrick wrote: >>> This is the second update to the Request For Review of the >>> implementation of the Java Packager Tool (jpackager) as described in >>> JEP 343: Packaging Tool >>> >>> >>> >>> This webrev corresponds to the second EA build, Build 8 (2019/1/8), >>> posted at http://jdk.java.net/jpackage/ >>> >>> This update renames the package used to "jdk.jpackage", removes the >>> Single Instance Service (and CLI option --singleton), adds several >>> other CLI options, adds more automated tests, and contains fixes to >>> the following issues (since update 1 on 11/09/2018): >>> >>> JDK-8212164???? resolve jre.list and jre.module.list >>> JDK-8212936???? Makefile and other improvements for jpackager >>> JDK-8213385???? jpackager Command-Line Argument File. >>> JDK-8213392???? Enhance --help and --version >>> JDK-8213425???? Analyze output from Source code scanner and fix >>> where needed. >>> JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk >>> JDK-8213748???? jpackager native launcher for macosx, linux. >>> JDK-8213756???? SingleInstance runtime improvements >>> JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails >>> JDK-8213963???? Flatten out jpackager packages and resources. >>> JDK-8214021???? Create additional automated tests for jpackager >>> JDK-8214051???? rename jpackager tool to jpackage >>> JDK-8214070???? Analyze and Fix issues reported by Parfait >>> JDK-8214143???? Reduce Resource files >>> JDK-8214495???? Change behavior of --license-file >>> JDK-8214575???? Exe installers will install application over >>> existing installation >>> JDK-8214899???? rename papplauncher and it's library and move src to >>> appropriate places >>> JDK-8214982???? jpackage causes failures in existing HelpFlagsTest >>> and VersionCheck tests >>> JDK-8215020???? create-jre-installer exe fails when --runtime-image >>> is specified. >>> JDK-8215036???? Create initial set of tests for jpackage >>> create-installer mode >>> JDK-8215453???? remove unused BundlerParams and fix misleading messages >>> JDK-8215515???? Add a command line option to override internal >>> resources. >>> JDK-8215900???? Without --files args, only jars in the top level of >>> --input are added to class-path >>> JDK-8215903???? modify behavior of retaining temporary output dir >>> JDK-8216190???? Remove Single Instance Service support from jpackage >>> JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs >>> JDK-8216373???? temporary build-root left behind when using >>> secondary launcher(s) >>> JDK-8216492???? Update copyright of all new jpackage files to 2019 >>> >>> Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 >>> >>> Note: SingleInstanceService API was removed (see >>> https://bugs.openjdk.java.net/browse/JDK-8216190). >>> An example stand alone implementation can be found at: >>> http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java >>> >>> please send feedback to core-libs-dev at openjdk.java.net >>> >>> /Andy Herrick >>> >> > From Alan.Bateman at oracle.com Fri Jan 18 13:32:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jan 2019 13:32:37 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: On 17/01/2019 14:27, Andrew Dinn wrote: > : >> Vladimir and I have reviewed the JEP, it will need an area lead to >> endorse, I think it can be Brian or Mikael in this case. > Ok, thanks for the above answers. Looking forward to hearing further > from Brian and/or Mikael (Vidstedt, I assume? :-). I had a brief discussion with Brian about this yesterday. He brought up the same concern about using MBB as it's not the right API for this in the longer term.? So this JEP is very much about a short term/tactical solution as we've already concluded here. This leads to the question as to whether this JEP needs to evolve the standard/Java SE API or not. It's convenient for the implementation of course but we should at least explore doing this as a JDK-specific feature. To that end, one approach to explore is allowing the FC.map method accept map modes beyond those defined by MapMode. There is precedence for extensibility in this area already, e.g. FC.open allows you to specify options beyond the standard options specified by the method. It would require MapMode to define a protected constructor and would require a bit of plumbing to support MapMode defined in a JDK-specific module but there are examples to point to. Another approach is aanother class in a JDK-specific module to define the map method. It would require the same plumbing under the covers but would avoid touch the FC spec. -Alan From peter.levart at gmail.com Fri Jan 18 14:11:57 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 18 Jan 2019 15:11:57 +0100 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: Hi Alan, On 1/18/19 2:32 PM, Alan Bateman wrote: > On 17/01/2019 14:27, Andrew Dinn wrote: >> : >>> Vladimir and I have reviewed the JEP, it will need an area lead to >>> endorse, I think it can be Brian or Mikael in this case. >> Ok, thanks for the above answers. Looking forward to hearing further >> from Brian and/or Mikael (Vidstedt, I assume? :-). > I had a brief discussion with Brian about this yesterday. He brought > up the same concern about using MBB as it's not the right API for this > in the longer term.? So this JEP is very much about a short > term/tactical solution as we've already concluded here. This leads to > the question as to whether this JEP needs to evolve the standard/Java > SE API or not. It's convenient for the implementation of course but we > should at least explore doing this as a JDK-specific feature. > > To that end, one approach to explore is allowing the FC.map method > accept map modes beyond those defined by MapMode. There is precedence > for extensibility in this area already, e.g. FC.open allows you to > specify options beyond the standard options specified by the method. > It would require MapMode to define a protected constructor and would > require a bit of plumbing to support MapMode defined in a JDK-specific > module but there are examples to point to. You meant package-private constructor, right? Protected constructor would allow subclassing MapMode by arbitrary user class which is not what would be desirable. So perhaps all that is needed is to declare the static final field in the MapMode class as package-private. That would allow referenceing it in the java.nio.channels package. Then add SharedSecrets mechanism to expose it's value to other needed java.base packages and to the additional module that would expose it publicly... Regards, Peter From andy.herrick at oracle.com Fri Jan 18 14:18:40 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 18 Jan 2019 09:18:40 -0500 Subject: RFR: JDK-8217269: jpackage Makefile improvments Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The webrev includes all the jpackage Makefile Improvements listed in [1], other than what is covered by [4], and also includes fix for white space errors requested in [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8217269 [2] http://cr.openjdk.java.net/~herrick/8217269/webrev.01/ [3] https://bugs.openjdk.java.net/browse/JDK-8216521 [4] https://bugs.openjdk.java.net/browse/JDK-8217317 /Andy From peter.levart at gmail.com Fri Jan 18 14:28:34 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 18 Jan 2019 15:28:34 +0100 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: <708555d0-d3e5-2d2c-f69d-16f76a83f66a@gmail.com> On 1/18/19 3:11 PM, Peter Levart wrote: > You meant package-private constructor, right? Protected constructor > would allow subclassing MapMode by arbitrary user class which is not > what would be desirable. ...unless you actually want users to construct their own MapMode(s), like you mentioned is the case with FileChannel.open() and FileAttribute interface. But there this makes sense because the backend (FileSystem) is also pluggable, so users can define their own FileSystem implementations that consume their own FileAttribute(s)... Are you proposing to add an spi for MappedByteBuffer's here? That would be an overkill for this feature, I think... Regards, Peter From Alan.Bateman at oracle.com Fri Jan 18 14:35:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jan 2019 14:35:54 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> On 12/01/2019 13:02, Langer, Christoph wrote: > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > I don't think zipfs can support PosixFileAttributeView in this way because zip entries can only support a subset of the attributes that the view defines. Retrofitting optionality to allow it be used in a degraded manner would be an incompatible change and of course creates usability issues. The owner, group and permissions methods defined by PosixFileAttributes cannot return null or throw exceptions. I think the approach to explore are: 1. zipfs supports PosixFileAttributeView without subsetting. If readAttribute(file, BasicFileAttributes.class) succeeds then readAttribute(file, PosixFileAttributes.class) should also succeed, even if there aren't permissions encoded in the zip entry's external file attributes. It would mean that owner and group return default values, and permissions may return a default value. It does mean you can't distinguish the default value from "no permissions" but there is precedence for that, e.g. mount a FAT32 file system on Linux or Unix systems and `stat` a file to have the stat structure populated with default uid, gid and mode bits. 2. zipfs defines a new FileAttributeView that defines read and write access to permissions stored in a zip entry's external file attribute. As it's a new view then it can define the behavior for the case that the zip entry doesn't have permissions. Furthermore it does not need to extend BasicFileAttributeView so doesn't need to be concerned with bulk access, nor concerned with group/owner. As you know, the attributes API allows for both type safe and dynamic access so you have a choice as to whether to support both or just dynamic access. With the first then jdk.zipfs would export a package with a public interface that defines the view. If someone wants type safe access to the permissions attribute then you need to import the class. The alternative is to not export any packages but just define the view in the module-info. The view its name and define the name/type of the permissions attribute, it will also define how it behaves when the external attributes aren't populated. In usage terms it means reading the permissions will be something like Files.readAttribute(file, "zip:permissions") and casting the value to Set - not pretty but it avoids depending on a JDK-specific API. I think it would be good to explore these options and maybe we can converge on an approach in the coming weeks. -Alan From mik3hall at gmail.com Fri Jan 18 15:09:27 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 18 Jan 2019 09:09:27 -0600 Subject: jpackage OS X minimum OS version In-Reply-To: <9D197D13-6C2E-42BC-9B5C-4FCF6A62DB2B@gmail.com> References: <9D197D13-6C2E-42BC-9B5C-4FCF6A62DB2B@gmail.com> Message-ID: <8A8F73C0-9744-492E-9C5D-CBA245C6CC94@gmail.com> > On Jan 17, 2019, at 8:37 AM, Michael Hall wrote: > > It appears there is a minimum OS version? I created a toy app. From command line? > > open outputdir/TestApp.app > LSOpenURLsWithRole() failed with error -10825 for the file /Users/mjh/HalfPipe/Test/outputdir/TestApp.app. > > Double click launching? > > You can?t use this version of the application ?TestApp? with this version of macOS. > You have macOS 10.12.6. The application requires macOS 10.13 or later. > I looked at the plist and it does indicate a minimum required OS version of 10.9. I should have been fine with that but before looking I upgraded to 10.14 Mojave. The first error remains. Googling shows it has happened to others, there was some suggestion it was gatekeeper related due to a renamed executable? The second dialog does no longer appear for whatever reason, however the app does not launch. It bounces in the dock for a while and then disappears. I?m new to 10.14 so am not completely sure what Console log messages might mean. At first I thought errors that the application is not signed at all might be the cause and I would need to get an Apple developer ID. However, other apps look like they might put out the same message so maybe it is just a warning and not the cause of failure. Other messages I see are? default 07:42:43.796288 -0600 loginwindow -[PersistentAppsSupport applicationReady:] | App: TestApp, ready, updating active tracking timer default 07:42:43.796399 -0600 loginwindow -[ApplicationManager checkInAppContext:refCon:eventData:] | checked in app : TestApp default 07:42:57.258287 -0600 TestApp TestApp:Failed to launch JVM default 07:42:57.363177 -0600 loginwindow -[PersistentAppsSupport applicationQuit:] | for app:TestApp, _appTrackingState = 2 default 07:42:57.363243 -0600 loginwindow -[PersistentAppsSupport applicationQuit:] | App: TestApp, quit, updating active tracking timer default 08:44:25.006069 -0600 loginwindow -[PersistentAppsSupport applicationReady:] | App: TestApp, ready, updating active tracking timer default 08:44:25.006358 -0600 loginwindow -[ApplicationManager checkInAppContext:refCon:eventData:] | checked in app : TestApp default 08:44:28.198112 -0600 TestApp TestApp:Failed to launch JVM default 08:44:28.219273 -0600 loginwindow -[PersistentAppsSupport applicationQuit:] | for app:TestApp, _appTrackingState = 2 default 08:44:28.219313 -0600 loginwindow -[PersistentAppsSupport applicationQuit:] | App: TestApp, quit, updating active tracking timer Is the source for the launcher anywhere I can see what it doing and maybe do some debug messaging? Do you want any of this bug reported? From Roger.Riggs at oracle.com Fri Jan 18 15:43:03 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 18 Jan 2019 10:43:03 -0500 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> Message-ID: Hi Nishit, Looks good, with a minor fix. ok, the rationale for MAX_VALUE-2 make sense. TestEncodingDecodingLength: Line 61 and 68, ? The error message will be more readable with a ": " before the methodname is appended. Thanks, Roger On 01/18/2019 06:03 AM, Nishit Jain wrote: > Hi Roger, Naoto, > > > The size of Integer.MAX_VALUE - 2 is implementation specific, > I think more typically max -8 is used to get the biggest allocation. > > When Integer.MAX_VALUE - 8 is used, the decode methods do not throw > the added OOME, because the computed value does not overflow > Integer.MAX_VALUE, so to test the added OOME condition need to use > Integer.MAX_VALUE - 2. > > Updated the webrev with rest of the suggestions > > http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ > > Regards, > Nishit Jain > On 18-01-2019 02:44, Naoto Sato wrote: >> I agree with 'withOutputParam' comment. It does seem to require some >> explanation. Same for the newly introduced return value -1. >> >> The test: >> ? 46???????? // A separate output array is not required, as it is not >> used and >> ? 47???????? // the exception is thrown beforehand while calculating >> the size >> ? 48???????? // of the encoded bytes using input array >> >> This seems to make an assumption on the implementation. Test should >> not depend on the internal impl. >> >> Naoto >> >> On 1/17/19 8:14 AM, Roger Riggs wrote: >>> Hi Nishit, >>> >>> In the test, there are a couple of RuntimeExceptions with messages >>> that start with "As expected"... >>> >>> That's counter intuitive, that a failure of the test is reported >>> with a message saying, its normal! >>> I would use a message like:? "XXException should have been thrown..." >>> >>> The size of Integer.MAX_VALUE - 2 is implementation specific, >>> I think more typically max -8 is used to get the biggest allocation. >>> >>> java/util/Base64.java: >>> >>> Lines 335-342:? This optimization is not mentioned in the bug report >>> and >>> should be a separate review. >>> >>> >>> 245, 686:? in outLength(), the 2nd parameter would be easier to >>> understand >>> as 'throwOOME', meaning to throw OOM if length is too large. >>> The 'withOutputParam' only has any meaning in the context of the >>> caller. >>> And even for the private method write the javadoc describing the >>> behavior. >>> >>> It also makes the call sites clearer, the argument will be true to >>> throw. >>> >>> Thanks, Roger >>> >>> >>> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>>> Hi, >>>> >>>> Please review the fix for 8210583 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>>> >>>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>>> incorrectly throw unspecified exception e.g. >>>> NegativeArraySizeException, when the input byte array size is too >>>> large such that the calculated output byte size goes beyond the >>>> max-integer boundary and wraps around. >>>> >>>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>>> memory can not be allocated. There is an unrelated change in >>>> encodeToString(byte[]) where a string instance is created using >>>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string >>>> constructor, to save memory. >>>> >>>> Regards, >>>> Nishit Jain >>> > From mik3hall at gmail.com Fri Jan 18 16:08:38 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 18 Jan 2019 10:08:38 -0600 Subject: jpackage OS X minimum OS version In-Reply-To: <8A8F73C0-9744-492E-9C5D-CBA245C6CC94@gmail.com> References: <9D197D13-6C2E-42BC-9B5C-4FCF6A62DB2B@gmail.com> <8A8F73C0-9744-492E-9C5D-CBA245C6CC94@gmail.com> Message-ID: <88068614-D795-4AA9-94C9-7F5F8E02C86C@gmail.com> > On Jan 18, 2019, at 9:09 AM, Michael Hall wrote: > > > >> On Jan 17, 2019, at 8:37 AM, Michael Hall wrote: >> >> It appears there is a minimum OS version? I created a toy app. From command line? >> >> open outputdir/TestApp.app >> LSOpenURLsWithRole() failed with error -10825 for the file /Users/mjh/HalfPipe/Test/outputdir/TestApp.app. >> >> Double click launching? >> >> You can?t use this version of the application ?TestApp? with this version of macOS. >> You have macOS 10.12.6. The application requires macOS 10.13 or later. >> Sorry for the noise. Might of figured out how to get something to go on. ./TestApp.app/Contents/MacOS/TestApp Exception in thread "main" java.lang.NoClassDefFoundError: jdk/jshell/JShell at us.hall.TestApp.(TestApp.java:15) at us.hall.TestApp.main(TestApp.java:9) Caused by: java.lang.ClassNotFoundException: jdk.jshell.JShell at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ... 2 more 2019-01-18 10:05:44.069 TestApp[3958:78719] TestApp:Failed to launch JVM From huizhe.wang at oracle.com Fri Jan 18 18:05:06 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Jan 2019 10:05:06 -0800 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) Message-ID: <5C421552.4030607@oracle.com> Please review a change to the DOM parser so that it complies with the specification with regard to the ExpandEntityReferences feature. This change corrects the behavior so that the resulting DOM tree includes EntityReference nodes but not the expanded Text nodes when the feature is off. It also means that the DOM parser will not attempt to read entity references if any. JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ Thanks, Joe From swpalmer at gmail.com Fri Jan 18 18:18:26 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 18 Jan 2019 13:18:26 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: <02bb11d8-637c-64b2-1dc1-a7838d0fec7c@strangenoises.org> References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> <02bb11d8-637c-64b2-1dc1-a7838d0fec7c@strangenoises.org> Message-ID: Add/Remove programs is called Apps & Features now, I guess. So we are in the same place. I?m going to reboot, as I have a Windows update to install anyway.. I think maybe the msi database is very confused. Scott > On Jan 18, 2019, at 3:59 AM, Rachel Greenham wrote: > > FWIW uninstall working for me from Windows 10's "Apps & features" panel. Could it be doing something different when done from "Add/Remove Programs"? And (wild guessing) might that be related to the known bug about old versions not being uninstalled properly during upgrade? > > (You might already be able to tell Windows isn't my main platform, only having to use it for this! ;-) ) > > -- > Rachel > > On 17/01/2019 16:21, Scott Palmer wrote: >> Note that the uninstall is still failing after I removed the spaces from >> the app name. I didn't mean to imply these issues were related. >> >> On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick >> wrote: >> >>> yes - seeing several problems when space in app name - filed JDK-8217331 >>> and will address. >>> >>> /Andy >>> >>> On 1/17/2019 10:37 AM, Scott Palmer wrote: >>> >>> I'm creating a MSI installer. My application name did have spaces in it. I >>> can confirm that changing the --name parameter to something without spaces >>> avoids the issue, though this is still clearly a bug that needs to be fixed. >>> >>> It also seems that uninstall does not work. When I attempt it I get this >>> error message from Add/Remove Programs: >>> >>> [Window Title] >>> C:\WINDOWS\system32\msiexec.exe >>> >>> [Content] >>> Windows cannot access the specified device, path, or file. You may not >>> have the appropriate permissions to access the item. >>> >>> [OK] >>> >>> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the >>> real issue is. Maybe a bad message from Windows and the path that can't be >>> accessed is a parameter to msiexec?? >>> >>> I'm using Microsoft Windows [Version 10.0.17134.471] >>> >>> Regards, >>> >>> Scott >>> >>> >>> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick >>> wrote: >>> >>>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are >>>> working for me. Shortcuts are created as expected when running either >>>> the exe or msi installer generated. >>>> >>>> Can you share the full OS version and full command you use , perhaps >>>> some combination of options is not working. >>>> >>>> /Andy >>>> >>>> >>>> On 1/16/2019 7:47 PM, Scott Palmer wrote: >>>>> Are the flags to create shortcuts in the start menu and on the desktop >>>> supposed to be working at this point? I tried them and they had no effect. >>>>> Scott >>>> > From huizhe.wang at oracle.com Fri Jan 18 19:19:34 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Jan 2019 11:19:34 -0800 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <5C421552.4030607@oracle.com> References: <5C421552.4030607@oracle.com> Message-ID: <5C4226C6.40608@oracle.com> Please hold on reviewing the webrevs as the tests passed while the new tests were commented out as Lance pointed out. Thanks, Joe On 1/18/19, 10:05 AM, Joe Wang wrote: > Please review a change to the DOM parser so that it complies with the > specification with regard to the ExpandEntityReferences feature. This > change corrects the behavior so that the resulting DOM tree includes > EntityReference nodes but not the expanded Text nodes when the feature > is off. It also means that the DOM parser will not attempt to read > entity references if any. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ > > Thanks, > Joe From swpalmer at gmail.com Fri Jan 18 20:29:41 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 18 Jan 2019 15:29:41 -0500 Subject: Jpackage Windows shortcuts In-Reply-To: References: <175C4462-221B-49EF-A8A9-33D29EC5B582@gmail.com> <36645023-6ee8-bbd0-424f-6080c5fdf055@oracle.com> <02bb11d8-637c-64b2-1dc1-a7838d0fec7c@strangenoises.org> Message-ID: <70C56029-C1D3-4FF1-99CB-DFEE95EF5FD0@gmail.com> For there record, a reboot fixed my uninstall issues. Scott > On Jan 18, 2019, at 1:18 PM, Scott Palmer wrote: > > Add/Remove programs is called Apps & Features now, I guess. So we are in the same place. I?m going to reboot, as I have a Windows update to install anyway.. I think maybe the msi database is very confused. > > Scott > >> On Jan 18, 2019, at 3:59 AM, Rachel Greenham wrote: >> >> FWIW uninstall working for me from Windows 10's "Apps & features" panel. Could it be doing something different when done from "Add/Remove Programs"? And (wild guessing) might that be related to the known bug about old versions not being uninstalled properly during upgrade? >> >> (You might already be able to tell Windows isn't my main platform, only having to use it for this! ;-) ) >> >> -- >> Rachel >> >> On 17/01/2019 16:21, Scott Palmer wrote: >>> Note that the uninstall is still failing after I removed the spaces from >>> the app name. I didn't mean to imply these issues were related. >>> >>> On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick >>> wrote: >>> >>>> yes - seeing several problems when space in app name - filed JDK-8217331 >>>> and will address. >>>> >>>> /Andy >>>> >>>> On 1/17/2019 10:37 AM, Scott Palmer wrote: >>>> >>>> I'm creating a MSI installer. My application name did have spaces in it. I >>>> can confirm that changing the --name parameter to something without spaces >>>> avoids the issue, though this is still clearly a bug that needs to be fixed. >>>> >>>> It also seems that uninstall does not work. When I attempt it I get this >>>> error message from Add/Remove Programs: >>>> >>>> [Window Title] >>>> C:\WINDOWS\system32\msiexec.exe >>>> >>>> [Content] >>>> Windows cannot access the specified device, path, or file. You may not >>>> have the appropriate permissions to access the item. >>>> >>>> [OK] >>>> >>>> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the >>>> real issue is. Maybe a bad message from Windows and the path that can't be >>>> accessed is a parameter to msiexec?? >>>> >>>> I'm using Microsoft Windows [Version 10.0.17134.471] >>>> >>>> Regards, >>>> >>>> Scott >>>> >>>> >>>> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick >>>> wrote: >>>> >>>>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are >>>>> working for me. Shortcuts are created as expected when running either >>>>> the exe or msi installer generated. >>>>> >>>>> Can you share the full OS version and full command you use , perhaps >>>>> some combination of options is not working. >>>>> >>>>> /Andy >>>>> >>>>> >>>>> On 1/16/2019 7:47 PM, Scott Palmer wrote: >>>>>> Are the flags to create shortcuts in the start menu and on the desktop >>>>> supposed to be working at this point? I tried them and they had no effect. >>>>>> Scott >>>>> >> > From vladimir.x.ivanov at oracle.com Fri Jan 18 23:05:21 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 15:05:21 -0800 Subject: [13] RFR (S): 8213234: Move LambdaForm.Hidden to jdk.internal.vm.annotation Message-ID: <3aba3976-60a0-f36f-92b6-de035b954dd4@oracle.com> http://cr.openjdk.java.net/~vlivanov/8213234/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8213234 Move LambdaForm.Hidden to jdk.internal.vm.annotation, so it can be shared across JDK until a standard solution is provided [1]. Testing: tier1-2 Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8212620 From mandy.chung at oracle.com Fri Jan 18 23:24:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Jan 2019 15:24:39 -0800 Subject: [13] RFR (S): 8213234: Move LambdaForm.Hidden to jdk.internal.vm.annotation In-Reply-To: <3aba3976-60a0-f36f-92b6-de035b954dd4@oracle.com> References: <3aba3976-60a0-f36f-92b6-de035b954dd4@oracle.com> Message-ID: <09d7f573-86d1-49af-8bd5-e75bf377be02@oracle.com> On 1/18/19 3:05 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8213234/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8213234 > > Move LambdaForm.Hidden to jdk.internal.vm.annotation, so it can be > shared across JDK until a standard solution is provided [1]. > Looks good.? The new Hidden.java should have 2019 copyright start year. Mandy From mandy.chung at oracle.com Fri Jan 18 23:30:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Jan 2019 15:30:37 -0800 Subject: Review Request JDK-8213932: [TESTBUG] assertEquals is invoked with the arguments in the wrong order Message-ID: Small test fix.?? SpecialStatic.java is a junit test but passes the expected argument to the wrong argument in assertEquals method.? I took a pass on the java.lang.invoke tests and spotted a couple others. Webrev: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8213932/webrev.00/ Thanks Mandy From naoto.sato at oracle.com Fri Jan 18 23:38:53 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 18 Jan 2019 15:38:53 -0800 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> Message-ID: <54ca4b57-fb08-046f-3e1d-ba2374252906@oracle.com> Looks good, Nishit. Naoto On 1/18/19 3:03 AM, Nishit Jain wrote: > Hi Roger, Naoto, > > > The size of Integer.MAX_VALUE - 2 is implementation specific, > I think more typically max -8 is used to get the biggest allocation. > > When Integer.MAX_VALUE - 8 is used, the decode methods do not throw the > added OOME, because the computed value does not overflow > Integer.MAX_VALUE, so to test the added OOME condition need to use > Integer.MAX_VALUE - 2. > > Updated the webrev with rest of the suggestions > > http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ > > Regards, > Nishit Jain > On 18-01-2019 02:44, Naoto Sato wrote: >> I agree with 'withOutputParam' comment. It does seem to require some >> explanation. Same for the newly introduced return value -1. >> >> The test: >> ? 46???????? // A separate output array is not required, as it is not >> used and >> ? 47???????? // the exception is thrown beforehand while calculating >> the size >> ? 48???????? // of the encoded bytes using input array >> >> This seems to make an assumption on the implementation. Test should >> not depend on the internal impl. >> >> Naoto >> >> On 1/17/19 8:14 AM, Roger Riggs wrote: >>> Hi Nishit, >>> >>> In the test, there are a couple of RuntimeExceptions with messages >>> that start with "As expected"... >>> >>> That's counter intuitive, that a failure of the test is reported with >>> a message saying, its normal! >>> I would use a message like:? "XXException should have been thrown..." >>> >>> The size of Integer.MAX_VALUE - 2 is implementation specific, >>> I think more typically max -8 is used to get the biggest allocation. >>> >>> java/util/Base64.java: >>> >>> Lines 335-342:? This optimization is not mentioned in the bug report and >>> should be a separate review. >>> >>> >>> 245, 686:? in outLength(), the 2nd parameter would be easier to >>> understand >>> as 'throwOOME', meaning to throw OOM if length is too large. >>> The 'withOutputParam' only has any meaning in the context of the caller. >>> And even for the private method write the javadoc describing the >>> behavior. >>> >>> It also makes the call sites clearer, the argument will be true to >>> throw. >>> >>> Thanks, Roger >>> >>> >>> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>>> Hi, >>>> >>>> Please review the fix for 8210583 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>>> >>>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>>> incorrectly throw unspecified exception e.g. >>>> NegativeArraySizeException, when the input byte array size is too >>>> large such that the calculated output byte size goes beyond the >>>> max-integer boundary and wraps around. >>>> >>>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>>> memory can not be allocated. There is an unrelated change in >>>> encodeToString(byte[]) where a string instance is created using >>>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string >>>> constructor, to save memory. >>>> >>>> Regards, >>>> Nishit Jain >>> > From naoto.sato at oracle.com Fri Jan 18 23:45:26 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 18 Jan 2019 15:45:26 -0800 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> Message-ID: <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com> Gentle reminder. Still waiting for reviews from OpenJDK Reviewers. Naoto On 1/18/19 1:57 AM, Nishit Jain wrote: > Looks Good. > > Regards, > Nishit Jain > On 17-01-2019 22:07, Naoto Sato wrote: >> Hi Nishit, >> >> Thanks. Updated: >> >> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ >> >> Naoto >> >> On 1/17/19 2:57 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Looks good to me. Just a small suggestion. >>> >>> - To improve readability, can we declare "standalone mask" (0x8000) >>> as a static field and use that at all the places? >>> >>> Regards, >>> Nishit Jain >>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8216969 >>>> >>>> The proposed changeset is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >>>> >>>> For parsing the context sensitive month 'M', the logic was to look >>>> for the best match for the short name regardless of the styles. >>>> Changed the parsing code to take the context into account. >>>> >>>> Naoto >>> > From alexander.matveev at oracle.com Sat Jan 19 00:24:58 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 18 Jan 2019 16:24:58 -0800 Subject: RFR: JDK-8217269: jpackage Makefile improvments In-Reply-To: References: Message-ID: <9a774fd3-17f2-50d1-1c3c-a7790be673eb@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 1/18/2019 6:18 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The webrev includes all the jpackage Makefile Improvements listed in > [1], other than what is covered by [4], and also includes fix for > white space errors requested in [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217269 > > [2] http://cr.openjdk.java.net/~herrick/8217269/webrev.01/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8216521 > > [4] https://bugs.openjdk.java.net/browse/JDK-8217317 > > /Andy > From joe.darcy at oracle.com Sat Jan 19 00:39:44 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 18 Jan 2019 16:39:44 -0800 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: <54ca4b57-fb08-046f-3e1d-ba2374252906@oracle.com> References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> <54ca4b57-fb08-046f-3e1d-ba2374252906@oracle.com> Message-ID: <79982acc-7016-290a-6b30-67ebf3833805@oracle.com> How long does the regression test take to run on machines that have enough memory? Thanks, -Joe On 1/18/2019 3:38 PM, naoto.sato at oracle.com wrote: > Looks good, Nishit. > > Naoto > > On 1/18/19 3:03 AM, Nishit Jain wrote: >> Hi Roger, Naoto, >> >> ?> The size of Integer.MAX_VALUE - 2 is implementation specific, >> I think more typically max -8 is used to get the biggest allocation. >> >> When Integer.MAX_VALUE - 8 is used, the decode methods do not throw >> the added OOME, because the computed value does not overflow >> Integer.MAX_VALUE, so to test the added OOME condition need to use >> Integer.MAX_VALUE - 2. >> >> Updated the webrev with rest of the suggestions >> >> http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ >> >> Regards, >> Nishit Jain >> On 18-01-2019 02:44, Naoto Sato wrote: >>> I agree with 'withOutputParam' comment. It does seem to require some >>> explanation. Same for the newly introduced return value -1. >>> >>> The test: >>> ? 46???????? // A separate output array is not required, as it is >>> not used and >>> ? 47???????? // the exception is thrown beforehand while calculating >>> the size >>> ? 48???????? // of the encoded bytes using input array >>> >>> This seems to make an assumption on the implementation. Test should >>> not depend on the internal impl. >>> >>> Naoto >>> >>> On 1/17/19 8:14 AM, Roger Riggs wrote: >>>> Hi Nishit, >>>> >>>> In the test, there are a couple of RuntimeExceptions with messages >>>> that start with "As expected"... >>>> >>>> That's counter intuitive, that a failure of the test is reported >>>> with a message saying, its normal! >>>> I would use a message like:? "XXException should have been thrown..." >>>> >>>> The size of Integer.MAX_VALUE - 2 is implementation specific, >>>> I think more typically max -8 is used to get the biggest allocation. >>>> >>>> java/util/Base64.java: >>>> >>>> Lines 335-342:? This optimization is not mentioned in the bug >>>> report and >>>> should be a separate review. >>>> >>>> >>>> 245, 686:? in outLength(), the 2nd parameter would be easier to >>>> understand >>>> as 'throwOOME', meaning to throw OOM if length is too large. >>>> The 'withOutputParam' only has any meaning in the context of the >>>> caller. >>>> And even for the private method write the javadoc describing the >>>> behavior. >>>> >>>> It also makes the call sites clearer, the argument will be true to >>>> throw. >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for 8210583 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>>>> >>>>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>>>> incorrectly throw unspecified exception e.g. >>>>> NegativeArraySizeException, when the input byte array size is too >>>>> large such that the calculated output byte size goes beyond the >>>>> max-integer boundary and wraps around. >>>>> >>>>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>>>> memory can not be allocated. There is an unrelated change in >>>>> encodeToString(byte[]) where a string instance is created using >>>>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of >>>>> string constructor, to save memory. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>> >> From mik3hall at gmail.com Sat Jan 19 00:53:22 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 18 Jan 2019 18:53:22 -0600 Subject: jpackage java.library.path Message-ID: <28D15734-D8B4-4A24-A8ED-1EB8C60AE4E2@gmail.com> 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 for jpackage? From lance.andersen at oracle.com Sat Jan 19 01:01:09 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Jan 2019 20:01:09 -0500 Subject: Review Request JDK-8213932: [TESTBUG] assertEquals is invoked with the arguments in the wrong order In-Reply-To: References: Message-ID: +1 > On Jan 18, 2019, at 6:30 PM, Mandy Chung wrote: > > Small test fix. SpecialStatic.java is a junit test but passes the expected argument to the wrong argument in assertEquals method. I took a pass on the java.lang.invoke tests and spotted a couple others. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8213932/webrev.00/ > > Thanks > Mandy > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mik3hall at gmail.com Sat Jan 19 01:59:49 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 18 Jan 2019 19:59:49 -0600 Subject: jpackage errors Message-ID: Trying for an actual jpackage build of one my applications on OS X I got? java.lang.NoClassDefFoundError: javax/script/ScriptException Remembering that the JDK in use might be incomplete I tried to --runtime-image some older installed JRE?s for 8, 9, and 11. Like? --runtime-image /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk \ All got the same error? Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) Exception: java.nio.file.NoSuchFileException: outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/lib/jli/libjli.dylib java.nio.file.NoSuchFileException: outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/lib/jli/libjli.dylib at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:548) at java.base/sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:258) at java.base/java.nio.file.Files.copy(Files.java:1297) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.copyRuntimeFiles(MacAppImageBuilder.java:413) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.prepareApplicationFiles(MacAppImageBuilder.java:385) at jdk.jpackage/jdk.jpackage.internal.StandardBundlerParam.copyPredefinedRuntimeImage(StandardBundlerParam.java:655) at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.doAppBundle(MacAppBundler.java:347) at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.doBundle(MacAppBundler.java:312) at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.execute(MacAppBundler.java:413) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:738) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) jdk.jpackage.internal.PackagerException: Error: Bundler "Mac Application Image" (mac.app) failed to produce a bundle. at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:744) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) From vladimir.x.ivanov at oracle.com Sat Jan 19 02:16:21 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 18:16:21 -0800 Subject: [13] RFR (S): 8213234: Move LambdaForm.Hidden to jdk.internal.vm.annotation In-Reply-To: <54b6dd72-b1e7-868b-a4d9-2bd49f4dff1e@oracle.com> References: <3aba3976-60a0-f36f-92b6-de035b954dd4@oracle.com> <54b6dd72-b1e7-868b-a4d9-2bd49f4dff1e@oracle.com> Message-ID: <7351f8e2-b812-83fd-8268-912544f90689@oracle.com> Thanks, Mandy & Dean. Updated in-place: http://cr.openjdk.java.net/~vlivanov/8213234/webrev.00/ Javadoc for Hidden now says the following: 30 /** 31 * A method or constructor may be annotated as "hidden" to hint it is desirable 32 * to omit it from stack traces. 33 * 34 * @implNote 35 * This annotation only takes effect for methods or constructors of classes 36 * loaded by the boot loader. Annotations on methods or constructors of classes 37 * loaded outside of the boot loader are ignored. 38 * 39 *

HotSpot JVM provides diagnostic option {@code -XX:+ShowHiddenFrames} to 40 * always show "hidden" frames. 41 */ Best regards, Vladimir Ivanov On 18/01/2019 16:18, dean.long at oracle.com wrote: > Thanks for fixing this. > Some copyright dates weren't updated.? Comment for Hidden.java still > says TODO. > > dl > > On 1/18/19 3:05 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8213234/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8213234 >> >> Move LambdaForm.Hidden to jdk.internal.vm.annotation, so it can be >> shared across JDK until a standard solution is provided [1]. >> >> Testing: tier1-2 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212620 > From lance.andersen at oracle.com Sat Jan 19 12:46:05 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 19 Jan 2019 07:46:05 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> Message-ID: 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 @@ -265,9 +265,10 @@ } /** - * Compares the specified Attributes object with this Map for equality. - * Returns true if the given object is also an instance of Attributes - * and the two Attributes objects represent the same mappings. + * Compares the specified object with this Map for equality. + * Returns true if the given object is also a Map + * and the two objects represent the same Manifest + * attribute name-value mappings. * * @param o the Object to be compared * @return true if the specified Object is equal to this Map ??????? Best, Lance > On Jan 17, 2019, at 6:50 PM, Lance Andersen wrote: > > Hi Philipp, > > I suspect the behavior dates back to the original implementation in JDK 1.2. I am not sure it should be changed at this point though the javadocs should be updated. > > Best > Lance >> On Jan 17, 2019, at 5:53 PM, Philipp Kunz wrote: >> >> Hi, >> >> In the JavaDoc comment for java.util.jar.Attributes#equals on line 269 >> it says: >> [...] Returns true if the given object is also an instance of >> Attributes [...] >> but that is not actually true. Passing a LinkedHashMap results also in >> true returned given equal content of both maps. >> Comment and implementation don't match perfectly. But which way it >> should be? >> Could not be less important probably, so please excuse me if it's like >> spam. >> >> Philipp > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andy.herrick at oracle.com Sat Jan 19 14:19:47 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 19 Jan 2019 09:19:47 -0500 Subject: jpackage errors In-Reply-To: References: Message-ID: <2e3deb0e-1ca1-4793-1500-cefd771bb233@oracle.com> 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 you shar the entire jpackage build command ? /Andy On 1/18/2019 8:59 PM, Michael Hall wrote: > Trying for an actual jpackage build of one my applications on OS X I got? > > java.lang.NoClassDefFoundError: javax/script/ScriptException > > Remembering that the JDK in use might be incomplete I tried to --runtime-image some older installed JRE?s for 8, 9, and 11. > Like? > > --runtime-image /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk \ > > All got the same error? > > Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) > Exception: java.nio.file.NoSuchFileException: outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/lib/jli/libjli.dylib > java.nio.file.NoSuchFileException: outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/lib/jli/libjli.dylib > at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:548) > at java.base/sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:258) > at java.base/java.nio.file.Files.copy(Files.java:1297) > at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.copyRuntimeFiles(MacAppImageBuilder.java:413) > at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.prepareApplicationFiles(MacAppImageBuilder.java:385) > at jdk.jpackage/jdk.jpackage.internal.StandardBundlerParam.copyPredefinedRuntimeImage(StandardBundlerParam.java:655) > at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.doAppBundle(MacAppBundler.java:347) > at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.doBundle(MacAppBundler.java:312) > at jdk.jpackage/jdk.jpackage.internal.MacAppBundler.execute(MacAppBundler.java:413) > at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:738) > at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) > at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > jdk.jpackage.internal.PackagerException: Error: Bundler "Mac Application Image" (mac.app) failed to produce a bundle. > at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:744) > at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:672) > at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > From mik3hall at gmail.com Sat Jan 19 14:28:26 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Jan 2019 08:28:26 -0600 Subject: jpackage errors In-Reply-To: <2e3deb0e-1ca1-4793-1500-cefd771bb233@oracle.com> References: <2e3deb0e-1ca1-4793-1500-cefd771bb233@oracle.com> Message-ID: > 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 haven't used those yet much myself but the error related to the jli dylib was the same for each. When I was trying to figure out why my app was originally not working with 12 I found a jli.dylib in my MacOS directory and I think I tried moving it out. So it might be something I did? But, for right now including the runtime option always fails on copying that file. > > 2.) javax.script.ScriptException is a public API so I don't see why you would get this NoClassDefFoundError, can you shar the entire jpackage build command ? This was just missing an ?add-modules I realized later. I haven?t done that much modular related so far. This error was easily fixed. I?m still not sure on the runtime error though that it accidentally turned up. From mik3hall at gmail.com Sat Jan 19 14:41:19 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Jan 2019 08:41:19 -0600 Subject: jpackage OS X Classes directory Message-ID: 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 adding application specific resources like property files. I?m not sure I ever saw anyone else mention using it. I am currently not finding those files in testing my jpackage app so I assume that is no longer supported? It was copied when I pointed my jpackage input directory to my old application?s Java directory but I am guessing it is no longer in class path. I suppose just jar?ing the resources into a file in the Java directory would be an easy enough fix, although to me maybe slightly less convenient. Is this, in fact, no longer supported? Is there any chance some similar feature might be added? From mik3hall at gmail.com Sat Jan 19 14:49:54 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Jan 2019 08:49:54 -0600 Subject: jpackage java.library.path In-Reply-To: <28D15734-D8B4-4A24-A8ED-1EB8C60AE4E2@gmail.com> References: <28D15734-D8B4-4A24-A8ED-1EB8C60AE4E2@gmail.com> Message-ID: > 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 for jpackage? Most if not all of my native code is OS X related. But out of curiosity how is java.library.path handled for applications on linux and windows? From mik3hall at gmail.com Sat Jan 19 15:06:42 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Jan 2019 09:06:42 -0600 Subject: jpackage errors In-Reply-To: References: <2e3deb0e-1ca1-4793-1500-cefd771bb233@oracle.com> Message-ID: <8FC38BBF-60B0-453F-91D1-E8C797A5F180@gmail.com> > >> 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/Contents/Java \ --output outputdir \ --name HalfPipe \ --main-jar halfpipe.jar \ --class us.hall.hp.common.LoaderLaunchStub \ --mac-bundle-identifier us.hall.HalfPipe \ --add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell \ --jvm-args '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+PrintGC' echo 'copying jni libs' cp ../HalfPipe12.app/Contents/MacOS/libhp.dylib outputdir/HalfPipe.app/Contents/MacOS/libhp.dylib cp ../HalfPipe12.app/Contents/MacOS/libfscript.dylib outputdir/HalfPipe.app/Contents/MacOS/libfscript.dylib cp ../HalfPipe12.app/Contents/MacOS/libAppleScriptEngine.dylib outputdir/HalfPipe.app/Contents/MacOS/libAppleScriptEngine.dylib cp ../HalfPipe12.app/Contents/MacOS/libmacattrs.dylib outputdir/HalfPipe.app/Contents/MacOS/libmacattrs.dylib From swpalmer at gmail.com Sat Jan 19 15:16:10 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 19 Jan 2019 10:16:10 -0500 Subject: jpackage OS X Classes directory In-Reply-To: References: Message-ID: 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 feature where a Classes directory was included in /Contents/Java/Classes. This directory was also automatically added into classpath. I found it convenient for adding application specific resources like property files. I?m not sure I ever saw anyone else mention using it. > > I am currently not finding those files in testing my jpackage app so I assume that is no longer supported? It was copied when I pointed my jpackage input directory to my old application?s Java directory but I am guessing it is no longer in class path. I suppose just jar?ing the resources into a file in the Java directory would be an easy enough fix, although to me maybe slightly less convenient. > > Is this, in fact, no longer supported? Is there any chance some similar feature might be added? From mik3hall at gmail.com Sat Jan 19 15:38:25 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Jan 2019 09:38:25 -0600 Subject: jpackage OS X Classes directory In-Reply-To: References: Message-ID: <4F57E7A6-8E38-481A-845A-817804C4E4B9@gmail.com> > 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 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 adding application specific resources like property files. I?m not sure I ever saw anyone else mention using it. >> >> I am currently not finding those files in testing my jpackage app so I assume that is no longer supported? It was copied when I pointed my jpackage input directory to my old application?s Java directory but I am guessing it is no longer in class path. I suppose just jar?ing the resources into a file in the Java directory would be an easy enough fix, although to me maybe slightly less convenient. >> >> Is this, in fact, no longer supported? Is there any chance some similar feature might be added? There may be no need. At this point I would guess probably not. It was within the application image though? Normal jars go to /Contents/Java AppBundler included the directory. /Contents/Java/Classes which was also automatically added to classpath. You could add property files, html editor kit css files, scripts or whatever, and classloader load them. Since I was a little used to digging into the app?s I found it convenient to use. Again, remembering that for a lot of purposes an OS X application bundle can be treated a lot like a plain old directory itself. From Roger.Riggs at oracle.com Sat Jan 19 18:03:55 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 19 Jan 2019 13:03:55 -0500 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com> Message-ID: <31d211ff-a51b-9c3f-d7b5-3ee18330c74f@oracle.com> 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 ? Calendar.LONG_STANDALONE ? LONG_FORMAT) Thanks, Roger On 01/18/2019 06:45 PM, naoto.sato at oracle.com wrote: > Gentle reminder. Still waiting for reviews from OpenJDK Reviewers. > > Naoto > > On 1/18/19 1:57 AM, Nishit Jain wrote: >> Looks Good. >> >> Regards, >> Nishit Jain >> On 17-01-2019 22:07, Naoto Sato wrote: >>> Hi Nishit, >>> >>> Thanks. Updated: >>> >>> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ >>> >>> Naoto >>> >>> On 1/17/19 2:57 AM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> Looks good to me. Just a small suggestion. >>>> >>>> - To improve readability, can we declare "standalone mask" (0x8000) >>>> as a static field and use that at all the places? >>>> >>>> Regards, >>>> Nishit Jain >>>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8216969 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >>>>> >>>>> For parsing the context sensitive month 'M', the logic was to look >>>>> for the best match for the short name regardless of the styles. >>>>> Changed the parsing code to take the context into account. >>>>> >>>>> Naoto >>>> >> From philipp.kunz at paratix.ch Sat Jan 19 18:32:25 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 19 Jan 2019 19:32:25 +0100 Subject: Manifest copy constructor does not deeply copy individual section Attributes Message-ID: <1547922745.2363.2.camel@paratix.ch> 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 attributes instances modifications to which always affect both manifests. See test and proposed fix in the attached patch. Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: manifestcopyconstructor.patch Type: text/x-patch Size: 3039 bytes Desc: not available URL: From philipp.kunz at paratix.ch Sat Jan 19 19:34:44 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 19 Jan 2019 20:34:44 +0100 Subject: Manifest copy constructor does not deeply copy individual section Attributes In-Reply-To: <1547922745.2363.2.camel@paratix.ch> References: <1547922745.2363.2.camel@paratix.ch> Message-ID: <1547926484.2363.5.camel@paratix.ch> 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. I don't know about the background of it or why clone should only do a shallow copy but if clone should really create a shallow copy, it should probably create an even more shallow copy. In any case I figure some potential for clarification at least. Probably mostly because I already began a patch in the previous message, I continued and attached another patch for a deep copy approach. There might still be some reason not to deeply copy manifests which I don't intend to forestall. Philipp On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote: > 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 attributes instances modifications to which > always affect both manifests. See test and proposed fix in the > attached patch. > > Regards, > Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: manifestcopyconstructorandclone.patch Type: text/x-patch Size: 7429 bytes Desc: not available URL: From martinrb at google.com Sat Jan 19 21:07:57 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Jan 2019 13:07:57 -0800 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> Message-ID: 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 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 > @@ -265,9 +265,10 @@ > } > > /** > - * Compares the specified Attributes object with this Map for equality. > - * Returns true if the given object is also an instance of Attributes > - * and the two Attributes objects represent the same mappings. > + * Compares the specified object with this Map for equality. > + * Returns true if the given object is also a Map > + * and the two objects represent the same Manifest > + * attribute name-value mappings. > * > * @param o the Object to be compared > * @return true if the specified Object is equal to this Map > ??????? > > Best, > Lance > > > On Jan 17, 2019, at 6:50 PM, Lance Andersen wrote: > > > > Hi Philipp, > > > > I suspect the behavior dates back to the original implementation in JDK 1.2. I am not sure it should be changed at this point though the javadocs should be updated. > > > > Best > > Lance > >> On Jan 17, 2019, at 5:53 PM, Philipp Kunz wrote: > >> > >> Hi, > >> > >> In the JavaDoc comment for java.util.jar.Attributes#equals on line 269 > >> it says: > >> [...] Returns true if the given object is also an instance of > >> Attributes [...] > >> but that is not actually true. Passing a LinkedHashMap results also in > >> true returned given equal content of both maps. > >> Comment and implementation don't match perfectly. But which way it > >> should be? > >> Could not be less important probably, so please excuse me if it's like > >> spam. > >> > >> Philipp > > > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > > 1 Network Drive > > Burlington, MA 01803 > > Lance.Andersen at oracle.com > > > > > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From christoph.langer at sap.com Mon Jan 21 09:17:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Jan 2019 09:17:09 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: Hi Alan, first of all, thank you for your input on this. > I think the approach to explore are: > > 1. zipfs supports PosixFileAttributeView without subsetting. If > readAttribute(file, BasicFileAttributes.class) succeeds then > readAttribute(file, PosixFileAttributes.class) should also succeed, even > if there aren't permissions encoded in the zip entry's external file > attributes. It would mean that owner and group return default values, > and permissions may return a default value. It does mean you can't > distinguish the default value from "no permissions" but there is > precedence for that, e.g. mount a FAT32 file system on Linux or Unix > systems and `stat` a file to have the stat structure populated with > default uid, gid and mode bits. OK, I can see the point that in a PosixFileAttributeView as it is, there's no place for optionality/null values. However, with this approach the benefits would be that Files::get/setPosixPermissions would work and that's why I think we should pursue this. The challenge will be to find reasonable defaults. > 2. zipfs defines a new FileAttributeView that defines read and write > access to permissions stored in a zip entry's external file attribute. > As it's a new view then it can define the behavior for the case that the > zip entry doesn't have permissions. Furthermore it does not need to > extend BasicFileAttributeView so doesn't need to be concerned with bulk > access, nor concerned with group/owner. As you know, the attributes API > allows for both type safe and dynamic access so you have a choice as to > whether to support both or just dynamic access. With the first then > jdk.zipfs would export a package with a public interface that defines > the view. If someone wants type safe access to the permissions attribute > then you need to import the class. The alternative is to not export any > packages but just define the view in the module-info. The view its name > and define the name/type of the permissions attribute, it will also > define how it behaves when the external attributes aren't populated. In > usage terms it means reading the permissions will be something like > Files.readAttribute(file, "zip:permissions") and casting the value to > Set - not pretty but it avoids depending on a > JDK-specific API. For this approach, there are 2 things I dislike. The first is that I don't think we should export named packages from module jdk.zipfs that people would develop Java code against while not being in the Java API. And secondly, this way would not support using Files::set/getPosixPermissions since the specification/implementation of that utility method explicitly refers to PosixFileAttributeView. I can imagine something like this: Zipfs by default implements an own view that offers dynamic, not type safe access to "zip:permissions" and we'll document this. If a user of zipfs wants to see full PosixFileAttributeView support with default values, then we should allow for a creation attribute for the zipfs that can control this. Maybe we can even allow specifying default values for user, group and permissions via zipfs attributes. I'll work to develop the patch into this direction unless you tell me that this idea is bogus (if so, then I hope it be soon ??) Thanks Christoph From goetz.lindenmaier at sap.com Mon Jan 21 10:00:35 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Jan 2019 10:00:35 +0000 Subject: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX Message-ID: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> Hi, please review the following small test fix: http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/ The Aix launcher always sets the path to the jdk libraries because Aix does not support $ORIGIN to find libjvm.so. So some of the test cases here fail. Skip them. Best regards, Goetz. From nishit.jain at oracle.com Mon Jan 21 10:30:45 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 21 Jan 2019 16:00:45 +0530 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> Message-ID: <5056505b-1ca6-f3be-d178-48ca9f4e3393@oracle.com> Thanks Roger, Updated. http://cr.openjdk.java.net/~nishjain/8210583/webrev.05/ Regards, Nishit Jain On 18-01-2019 21:13, Roger Riggs wrote: > Hi Nishit, > > Looks good, with a minor fix. > > ok, the rationale for MAX_VALUE-2 make sense. > > TestEncodingDecodingLength: Line 61 and 68, > ? The error message will be more readable with a ": " before the > methodname is appended. > > Thanks, Roger > > > On 01/18/2019 06:03 AM, Nishit Jain wrote: >> Hi Roger, Naoto, >> >> > The size of Integer.MAX_VALUE - 2 is implementation specific, >> I think more typically max -8 is used to get the biggest allocation. >> >> When Integer.MAX_VALUE - 8 is used, the decode methods do not throw >> the added OOME, because the computed value does not overflow >> Integer.MAX_VALUE, so to test the added OOME condition need to use >> Integer.MAX_VALUE - 2. >> >> Updated the webrev with rest of the suggestions >> >> http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ >> >> Regards, >> Nishit Jain >> On 18-01-2019 02:44, Naoto Sato wrote: >>> I agree with 'withOutputParam' comment. It does seem to require some >>> explanation. Same for the newly introduced return value -1. >>> >>> The test: >>> ? 46???????? // A separate output array is not required, as it is >>> not used and >>> ? 47???????? // the exception is thrown beforehand while calculating >>> the size >>> ? 48???????? // of the encoded bytes using input array >>> >>> This seems to make an assumption on the implementation. Test should >>> not depend on the internal impl. >>> >>> Naoto >>> >>> On 1/17/19 8:14 AM, Roger Riggs wrote: >>>> Hi Nishit, >>>> >>>> In the test, there are a couple of RuntimeExceptions with messages >>>> that start with "As expected"... >>>> >>>> That's counter intuitive, that a failure of the test is reported >>>> with a message saying, its normal! >>>> I would use a message like:? "XXException should have been thrown..." >>>> >>>> The size of Integer.MAX_VALUE - 2 is implementation specific, >>>> I think more typically max -8 is used to get the biggest allocation. >>>> >>>> java/util/Base64.java: >>>> >>>> Lines 335-342:? This optimization is not mentioned in the bug >>>> report and >>>> should be a separate review. >>>> >>>> >>>> 245, 686:? in outLength(), the 2nd parameter would be easier to >>>> understand >>>> as 'throwOOME', meaning to throw OOM if length is too large. >>>> The 'withOutputParam' only has any meaning in the context of the >>>> caller. >>>> And even for the private method write the javadoc describing the >>>> behavior. >>>> >>>> It also makes the call sites clearer, the argument will be true to >>>> throw. >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for 8210583 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>>>> >>>>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>>>> incorrectly throw unspecified exception e.g. >>>>> NegativeArraySizeException, when the input byte array size is too >>>>> large such that the calculated output byte size goes beyond the >>>>> max-integer boundary and wraps around. >>>>> >>>>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>>>> memory can not be allocated. There is an unrelated change in >>>>> encodeToString(byte[]) where a string instance is created using >>>>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of >>>>> string constructor, to save memory. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>> >> > From nishit.jain at oracle.com Mon Jan 21 10:33:05 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 21 Jan 2019 16:03:05 +0530 Subject: [13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException In-Reply-To: <79982acc-7016-290a-6b30-67ebf3833805@oracle.com> References: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com> <1822a217-8fa5-d02c-5ba6-f9761cf5a69a@oracle.com> <173eb277-a0dd-e33e-e215-a092df31383c@oracle.com> <54ca4b57-fb08-046f-3e1d-ba2374252906@oracle.com> <79982acc-7016-290a-6b30-67ebf3833805@oracle.com> Message-ID: <4ac99488-3da1-f47a-93b8-f0c0a7302c55@oracle.com> Hi Joe, Executing it on Mach5 platforms took around 3s to 5s. Below is the link https://java.se.oracle.com:10065/mdash/jobs/nishjain-jdk_04_09-20190121-0805-19402/results?search=status%3A* Also executed using JMH on local linux-64 VM (6GB RAM), it took ~2200 ms in SingleShotTime mode Benchmark?????????????? Mode? Cnt???? Score????? Error? Units MyBenchmark.testMethod??? ss?? 50? 2200.663 ? 1826.348? ms/op Regards, Nishit Jain On 19-01-2019 06:09, Joe Darcy wrote: > How long does the regression test take to run on machines that have > enough memory? > > Thanks, > > -Joe > > On 1/18/2019 3:38 PM, naoto.sato at oracle.com wrote: >> Looks good, Nishit. >> >> Naoto >> >> On 1/18/19 3:03 AM, Nishit Jain wrote: >>> Hi Roger, Naoto, >>> >>> ?> The size of Integer.MAX_VALUE - 2 is implementation specific, >>> I think more typically max -8 is used to get the biggest allocation. >>> >>> When Integer.MAX_VALUE - 8 is used, the decode methods do not throw >>> the added OOME, because the computed value does not overflow >>> Integer.MAX_VALUE, so to test the added OOME condition need to use >>> Integer.MAX_VALUE - 2. >>> >>> Updated the webrev with rest of the suggestions >>> >>> http://cr.openjdk.java.net/~nishjain/8210583/webrev.04/ >>> >>> Regards, >>> Nishit Jain >>> On 18-01-2019 02:44, Naoto Sato wrote: >>>> I agree with 'withOutputParam' comment. It does seem to require >>>> some explanation. Same for the newly introduced return value -1. >>>> >>>> The test: >>>> ? 46???????? // A separate output array is not required, as it is >>>> not used and >>>> ? 47???????? // the exception is thrown beforehand while >>>> calculating the size >>>> ? 48???????? // of the encoded bytes using input array >>>> >>>> This seems to make an assumption on the implementation. Test should >>>> not depend on the internal impl. >>>> >>>> Naoto >>>> >>>> On 1/17/19 8:14 AM, Roger Riggs wrote: >>>>> Hi Nishit, >>>>> >>>>> In the test, there are a couple of RuntimeExceptions with messages >>>>> that start with "As expected"... >>>>> >>>>> That's counter intuitive, that a failure of the test is reported >>>>> with a message saying, its normal! >>>>> I would use a message like:? "XXException should have been thrown..." >>>>> >>>>> The size of Integer.MAX_VALUE - 2 is implementation specific, >>>>> I think more typically max -8 is used to get the biggest allocation. >>>>> >>>>> java/util/Base64.java: >>>>> >>>>> Lines 335-342:? This optimization is not mentioned in the bug >>>>> report and >>>>> should be a separate review. >>>>> >>>>> >>>>> 245, 686:? in outLength(), the 2nd parameter would be easier to >>>>> understand >>>>> as 'throwOOME', meaning to throw OOM if length is too large. >>>>> The 'withOutputParam' only has any meaning in the context of the >>>>> caller. >>>>> And even for the private method write the javadoc describing the >>>>> behavior. >>>>> >>>>> It also makes the call sites clearer, the argument will be true to >>>>> throw. >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 01/17/2019 02:07 AM, Nishit Jain wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for 8210583 >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 >>>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 >>>>>> >>>>>> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods >>>>>> incorrectly throw unspecified exception e.g. >>>>>> NegativeArraySizeException, when the input byte array size is too >>>>>> large such that the calculated output byte size goes beyond the >>>>>> max-integer boundary and wraps around. >>>>>> >>>>>> Fix: Throw an OutOfMemoryError if the output byte array/buffer or >>>>>> memory can not be allocated. There is an unrelated change in >>>>>> encodeToString(byte[]) where a string instance is created using >>>>>> JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of >>>>>> string constructor, to save memory. >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>> >>> From christoph.langer at sap.com Mon Jan 21 10:42:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Jan 2019 10:42:33 +0000 Subject: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX In-Reply-To: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> References: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> Message-ID: <1da96af8ea134312b801e14d5830373d@sap.com> Hi Goetz, looks good to me. I think it should rather be "AIX" than "Aix" in the output text - but it's a developer trace only, so probably nobody cares. ?? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lindenmaier, Goetz > Sent: Montag, 21. Januar 2019 11:01 > To: core-libs-dev at openjdk.java.net > Subject: [CAUTION] RFR(XS): 8217438: Adapt > tools//launcher/Test7029048.java for AIX > > Hi, > > please review the following small test fix: > http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/ > > The Aix launcher always sets the path to the jdk libraries because > Aix does not support $ORIGIN to find libjvm.so. > So some of the test cases here fail. Skip them. > > Best regards, > Goetz. From magnus.ihse.bursie at oracle.com Mon Jan 21 10:41:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:41:10 +0100 Subject: RFR: JDK-8217269: jpackage Makefile improvments In-Reply-To: References: Message-ID: <6e7cb4f1-be9a-8d6f-a348-be3adfa78af1@oracle.com> On 2019-01-18 15:18, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The webrev includes all the jpackage Makefile Improvements listed in > [1], other than what is covered by [4], and also includes fix for > white space errors requested in [3]. Looks good to me! Thanks for fixing this. In the future, please cc build-dev for build related fixes. /Magnus > > [1] https://bugs.openjdk.java.net/browse/JDK-8217269 > > [2] http://cr.openjdk.java.net/~herrick/8217269/webrev.01/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8216521 > > [4] https://bugs.openjdk.java.net/browse/JDK-8217317 > > /Andy > From Alan.Bateman at oracle.com Mon Jan 21 14:16:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2019 14:16:03 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: On 21/01/2019 09:17, Langer, Christoph wrote: > : > OK, I can see the point that in a PosixFileAttributeView as it is, there's no place for optionality/null values. However, with this approach the benefits would be that Files::get/setPosixPermissions would work and that's why I think we should pursue this. The challenge will be to find reasonable defaults. That is how extensions are suppose to work. I think Sherman has looked at exporting zipfs specific FileAttributeViews a couple of times. Yes, it doesn't mean compiling against a JDK-specific API but we have several JDK specific modules that export APIs. > : > > I can imagine something like this: > Zipfs by default implements an own view that offers dynamic, not type safe access to "zip:permissions" and we'll document this. If a user of zipfs wants to see full PosixFileAttributeView support with default values, then we should allow for a creation attribute for the zipfs that can control this. Maybe we can even allow specifying default values for user, group and permissions via zipfs attributes. The configuration parameters that you specify to newFileSystem can work like mount options so provide some way to specify defaults may be useful. When you mount a fat32 file system on a Linux/Unix system then you can usually configure things like the umask which may give you ideas. -Alan From adinn at redhat.com Mon Jan 21 16:14:37 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 21 Jan 2019 16:14:37 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: Hi Alan, On 18/01/2019 13:32, Alan Bateman wrote: > I had a brief discussion with Brian about this yesterday. He brought up > the same concern about using MBB as it's not the right API for this in > the longer term.? So this JEP is very much about a short term/tactical > solution as we've already concluded here. This leads to the question as > to whether this JEP needs to evolve the standard/Java SE API or not. > It's convenient for the implementation of course but we should at least > explore doing this as a JDK-specific feature. I disagree with your characterization of use of MBB as a short term/ tactical solution. Despite not being entirely suitable for the task MBB is a de facto standard way for many applications to gain direct access to files of data located on persistent storage. The current proposal is not, as you characterize it, a quick fix to use MBB as a temporary way to access NVM storage until something better comes along. The intention is rather to ensure that the current API caters for a new addition to the persistent memory tier. The imperative is to allow existing code to employ it now. Of course, a better API may come along for accessing persistent storage, whether that be NVM, flash disk or spinning platter. However, I would hazard that in many cases existing application code and libraries will still want/need to continue to use the MBB API, including cases where that storage can most usefully be NVM. Rewriting application code to use a new API will not always be feasible or cost-effective. Yet, the improved speed of NVM suggests that an API encompassing this new case will be very welcome and may well be cost-effective to adopt. In sum, far from being a stop-gap this proposal should be seen as a step towards completing and maintaining the existing MBB API for emergent tech. > To that end, one approach to explore is allowing the FC.map method > accept map modes beyond those defined by MapMode. There is precedence > for extensibility in this area already, e.g. FC.open allows you to > specify options beyond the standard options specified by the method. It > would require MapMode to define a protected constructor and would > require a bit of plumbing to support MapMode defined in a JDK-specific > module but there are examples to point to. Another approach is aanother > class in a JDK-specific module to define the map method. It would > require the same plumbing under the covers but would avoid touch the FC > spec. I'm not sure what this side-step is supposed to achieve nor how that relates to the concerns over use of MBB (perhaps it doesn't). I'm not really clear what problem you are trying to avoid here by allowing the MapMode enum to be extensible via a protected constructor. If your desire is to avoid adding extra API surface to FileChannel then where would you consider it appropriate to add such a surface. Something is going to have to create and employ the extra enum tags that are currently proposed for addition to MapMode. How is a client application going to reach that something? Perhaps we might benefit form looking at a simple example? Currently, my most basic test program drives the API to create an MBB as follows: . . . String dir = "/mnt/pmem/test"; // mapSync should work, since fs mount is -o dax Path path = new File(dir, "pmemtest").toPath(); FileChannel fileChannel = (FileChannel) Files .newByteChannel(path, EnumSet.of( StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE)); MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE_PERSISTENT, 0, 1024); . . . Could you give a sketch of an alternative way that you see a client operating? One thing I did wonder about was whether we could insert the relevant behavioural switch in the call to Files.newByteChannel rather than the map call? If we passed an ExtendedOpenOption (e.g. ExtendedOpenOption.SYNC) to this call then method newByteChannel could create and return a corresponding variant of FleChannelImpl, say an instance of a subclass called SyncFileChannelImpl. This could behave as per a normal FileChannelImpl apart from adding the MAP_SYNC flag to the mmap call (well, also rejecting PRIVATE maps). Would that be a better way to drive this? Would it address the concerns you raised above? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From brian.goetz at oracle.com Mon Jan 21 17:16:41 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 21 Jan 2019 12:16:41 -0500 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> Message-ID: > Hi Alan/Brian, My apologies for having missed this the first time around; messages to lists get swept into folders, and staying on top of many lists is not an exact science. > I believe I have addressed all outstanding comments on the JEP per se, > including those made by Alan. Is it now possible for one of you to > endorse the JEP so it can be submitted? You don?t actually need my endorsement to Submit a JEP to be a Candidate; all you need is evidence that it?s been socialized on the right list (check) and a reviewer (check). So you?re not blocked on submitting at all. That said, Candidate is actually supposed to be an early stage in the lifecycle; making something a candidate is essentially a statement that the feature is worth considering. It is not any sort of commitment that the feature meets the high bar for inclusion, or is done ? just that it is something that is worth continuing to work on in OpenJDK. Clearly, you?ve done a lot more than the minimum to meet the Candidate bar. Where I see this JEP at is you?ve iterated on the implementation and the design for a few rounds ? and where we?re at now is we?re facing the stewardship questions of exactly what the right way to position this feature in the JDK is. Based on the list discussion so far, it seems like we?ve not yet reached consensus on this, so these discussions can continue, whether the JEP is a Candidate or not. I concur with Alan and Stuart?s assessment that this is very much a ?stop gap? measure. (That?s not a value judgment, either the design of MBB, or your work.) It is clear that MBBs are reaching the end of their design lifetime, and the set of mismatches to the problems people want to solve are growing, and the amount of investment needed to bring MBBs up to the task would be significant. It seems likely a much better long-term solution is Panama, but I agree that Panama is not yet ready to replace MBB, and so some stop-gap is needed to prolong the usefulness of MBBs for long enough for a better solution to emerge. However, Alan?s concern ? which I share ? is that by expanding the MBB API now, we open ourselves up to increased maintenance costs in the too-near future. Before we settle on an API, we?re going to need to come to consensus on the right tradeoffs here, and I?m not convinced we?ve found this yet. So we?ll keep talking. > Is there any other impediment to submitting the JEP and proceeding to > code review? There do not seem to be impediments to submitting the JEP, but I would call out the assumption that the next stop is code review, and then integration. That seems to want to skip over the far more important ?should we / how should we? discussions, which are still in progress. Cheers, -Brian From david.holmes at oracle.com Mon Jan 21 20:38:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 06:38:00 +1000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> Message-ID: Hi Robert, I've cc'd core-libs-dev as this is now about signed-jars and the launcher. David On 22/01/2019 4:48 am, Robert Marcano wrote: > On 1/21/19 8:25 AM, Robert Marcano wrote: >> On 1/21/19 5:19 AM, Volker Simonis wrote: >>> -- Moved to hotspot-dev -- >>> >>> Hi Robert, >>> >>> You can use "-XX:+PrintFlagsFinal" and compare the output for the two >>> variants to see if for some reason there are differing option >>> settings. >> >> Thanks, compared the output of that on a java launcher call and my >> launcher and get the same flagsa values, so it doesn't look like >> different defaults isn't the problem > > When testing this, trying to discard some weird Rust / OpenJDK 11 > interactions, I wrote a simpler test case using the JVM invocation API > from plain C. Noticed the same pattern of high memory usage, but it > allowed me to detect there was a difference when using the provided java > launcher and our custom launcher. > > Every VM option was the same (as strings), including the classpath. Both > have something like -Djava.class.path=../lib/a.jar:../lib/b.jar > > But for some error in the configuration of our test environment, ../lib > pointed to different directories for both launchers. Different ../lib > directories with the same JARs, the difference between them is that the > use for the java launcher are unsigned and ../lib for the custom > launcher are signed. These jars are signed because they come from a JNLP > application, the new launcher is part of our migration out of JNLP. > > So I managed to replicate the high memory usage using the standard java > launcher. > > So the question now is, why signed jars could affect the memory usage of > an application (we aren't doing JAR verification on our custom launcher, > yet), just by being on the java.class.path? IIRC the initial application > classpath JARs were never verified previously (by the java launcher > alone, without JNLP around). > > Note: Tested with JARs signed with a self signed certificate and with > one signed with a private CA. At most, signing the JARs could slow down > the start up if it is now expected to these being verified by the java > launcher (is it true?) but not higher memory usage and no reductions > after a GC cycle but constants heap size increases. > > > >> >>> >>> Regards, >>> Volker >>> >>> On Sat, Jan 19, 2019 at 6:23 PM Robert Marcano >>> wrote: >>>> >>>> Greetings, which is the best mailing list for discussions about >>>> embedding the JVM (via JNI_CreateJavaVM)? >>>> >>>> The JVM is being embedded for desktop integration issues, for >>>> example to >>>> show the appropriate application name on the process list instead of >>>> java/java.exe, among many other things. >>>> >>>> I am experiencing what looks like higher memory usage and/or failure to >>>> garbage collect correctly when OpenJDK 11 is the embedded JVM. Starting >>>> a test application using the java launcher, I get a GC log like this: >>>> >>>>> [0.007s][info][gc] Using G1 >>>>> [0.389s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 10M->8M(124M) 8.661ms >>>>> [0.705s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 13M->10M(124M) 6.148ms >>>>> Jan 19, 2019 1:04:26 PM test.Test init >>>>> FINE: Starting application >>>>> [1.376s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 18M->10M(40M) 4.763ms >>>>> [2.288s][info][gc] GC(4) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 23M->12M(40M) 6.382ms >>>>> [2.444s][info][gc] GC(5) Pause Young (Concurrent Start) (Metadata >>>>> GC Threshold) 18M->12M(48M) 7.579ms >>>>> [2.444s][info][gc] GC(6) Concurrent Cycle >>>>> [2.481s][info][gc] GC(6) Pause Remark 13M->13M(48M) 5.255ms >>>>> [2.498s][info][gc] GC(6) Pause Cleanup 13M->13M(48M) 0.090ms >>>>> [2.499s][info][gc] GC(6) Concurrent Cycle 54.811ms >>>>> [2.905s][info][gc] GC(7) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 26M->13M(48M) 12.726ms >>>>> [3.204s][info][gc] GC(8) Pause Young (Normal) (GCLocker Initiated >>>>> GC) 29M->15M(48M) 11.216ms >>>>> [3.462s][info][gc] GC(9) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 30M->17M(48M) 18.043ms >>>>> [3.679s][info][gc] GC(10) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 31M->18M(64M) 15.195ms >>>>> [3.933s][info][gc] GC(11) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 38M->20M(64M) 9.412ms >>>>> [4.230s][info][gc] GC(12) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 40M->21M(64M) 16.319ms >>>>> [4.536s][info][gc] GC(13) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 41M->23M(64M) 23.897ms >>>>> [4.750s][info][gc] GC(14) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 43M->24M(94M) 8.776ms >>>>> [5.180s][info][gc] GC(15) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 58M->26M(94M) 15.610ms >>>>> [5.546s][info][gc] GC(16) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 67M->27M(94M) 18.075ms >>>>> [6.058s][info][gc] GC(17) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 69M->30M(94M) 32.625ms >>>>> [7.268s][info][gc] GC(18) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 71M->31M(156M) 18.999ms >>>>> [7.458s][info][gc] GC(19) Pause Young (Concurrent Start) (Metadata >>>>> GC Threshold) 40M->31M(156M) 20.217ms >>>>> [7.459s][info][gc] GC(20) Concurrent Cycle >>>>> [7.676s][info][gc] GC(20) Pause Remark 35M->35M(156M) 19.304ms >>>>> [7.748s][info][gc] GC(20) Pause Cleanup 36M->36M(156M) 0.183ms >>>>> [7.782s][info][gc] GC(20) Concurrent Cycle 323.765ms >>>>> [8.899s][info][gc] GC(21) Pause Young (Concurrent Start) (G1 >>>>> Evacuation Pause) 84M->40M(156M) 69.976ms >>>>> [8.899s][info][gc] GC(22) Concurrent Cycle >>>>> [9.152s][info][gc] GC(22) Pause Remark 47M->47M(156M) 21.133ms >>>>> [9.244s][info][gc] GC(22) Pause Cleanup 49M->49M(156M) 0.127ms >>>>> [9.247s][info][gc] GC(22) Concurrent Cycle 348.256ms >>>>> [10.203s][info][gc] GC(23) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 97M->55M(156M) 74.572ms >>>>> [11.102s][info][gc] GC(24) Pause Full (System.gc()) 100M->21M(77M) >>>>> 115.166ms >>>>> [15.382s][info][gc] GC(25) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 48M->22M(154M) 6.371ms >>>> >>>> When the same Java 11 JVM is loaded via JNI, with the same VM arguments >>>> than using the java launcher, the log look like this (to reach the same >>>> point at startup) >>>> >>>>> [0.015s][info][gc] Using G1 >>>>> [0.501s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 6M->1M(124M) 8.550ms >>>>> [0.785s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 8M->3M(124M) 6.533ms >>>>> [0.940s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 14M->7M(124M) 17.822ms >>>>> [1.212s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 22M->10M(124M) 11.145ms >>>>> [1.462s][info][gc] GC(4) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 29M->15M(180M) 16.451ms >>>>> [1.695s][info][gc] GC(5) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 47M->25M(180M) 38.828ms >>>>> [2.041s][info][gc] GC(6) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 55M->30M(180M) 22.151ms >>>>> [2.346s][info][gc] GC(7) Pause Young (Normal) (G1 Evacuation Pause) >>>>> 80M->49M(180M) 53.093ms >>>>> Jan 19, 2019 1:01:05 PM test.Test init >>>>> FINE: Starting application >>>>> [4.094s][info][gc] GC(9) Pause Young (Concurrent Start) (Metadata >>>>> GC Threshold) 64M->40M(258M) 50.663ms >>>>> [4.094s][info][gc] GC(10) Concurrent Cycle >>>>> [4.480s][info][gc] GC(10) Pause Remark 48M->48M(258M) 7.442ms >>>>> [4.652s][info][gc] GC(10) Pause Cleanup 55M->55M(258M) 0.186ms >>>>> [4.656s][info][gc] GC(10) Concurrent Cycle 562.009ms >>>>> [5.174s][info][gc] GC(11) Pause Young (Concurrent Start) (G1 >>>>> Evacuation Pause) 82M->46M(258M) 24.726ms >>>>> [5.174s][info][gc] GC(12) Concurrent Cycle >>>>> [5.513s][info][gc] GC(12) Pause Remark 56M->56M(258M) 11.695ms >>>>> [5.657s][info][gc] GC(12) Pause Cleanup 62M->62M(258M) 0.176ms >>>>> [5.660s][info][gc] GC(12) Concurrent Cycle 486.466ms >>>>> [6.430s][info][gc] GC(13) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 107M->58M(258M) 55.665ms >>>>> [7.538s][info][gc] GC(14) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 107M->63M(258M) 58.642ms >>>>> [8.724s][info][gc] GC(15) Pause Young (Concurrent Start) (Metadata >>>>> GC Threshold) 91M->68M(496M) 47.374ms >>>>> [8.724s][info][gc] GC(16) Concurrent Cycle >>>>> [9.417s][info][gc] GC(16) Pause Remark 79M->79M(496M) 19.350ms >>>>> [9.557s][info][gc] GC(16) Pause Cleanup 81M->81M(496M) 0.340ms >>>>> [9.575s][info][gc] GC(16) Concurrent Cycle 850.788ms >>>>> [10.954s][info][gc] GC(17) Pause Young (Concurrent Start) (G1 >>>>> Evacuation Pause) 134M->85M(496M) 162.779ms >>>>> [10.954s][info][gc] GC(18) Concurrent Cycle >>>>> [11.389s][info][gc] GC(19) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 99M->90M(496M) 79.954ms >>>>> [11.519s][info][gc] GC(18) Pause Remark 93M->92M(496M) 24.636ms >>>>> [11.896s][info][gc] GC(18) Pause Cleanup 102M->102M(496M) 0.326ms >>>>> [11.903s][info][gc] GC(18) Concurrent Cycle 949.231ms >>>>> [17.356s][info][gc] GC(22) Pause Young (Concurrent Start) (G1 >>>>> Humongous Allocation) 131M->81M(365M) 56.745ms >>>>> [17.357s][info][gc] GC(23) Concurrent Cycle >>>>> [17.706s][info][gc] GC(23) Pause Remark 116M->113M(365M) 31.351ms >>>>> [18.008s][info][gc] GC(23) Pause Cleanup 117M->117M(365M) 0.250ms >>>>> [18.018s][info][gc] GC(23) Concurrent Cycle 661.284ms >>>>> [18.888s][info][gc] GC(24) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 205M->91M(365M) 93.737ms >>>>> [20.355s][info][gc] GC(25) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 324M->136M(378M) 125.037ms >>>>> [21.091s][info][gc] GC(26) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 295M->150M(378M) 93.607ms >>>>> [21.631s][info][gc] GC(27) Pause Young (Concurrent Start) (G1 >>>>> Humongous Allocation) 261M->164M(516M) 77.013ms >>>>> [21.631s][info][gc] GC(28) Concurrent Cycle >>>>> [21.981s][info][gc] GC(28) Pause Remark 212M->169M(516M) 43.679ms >>>>> [22.243s][info][gc] GC(28) Pause Cleanup 214M->214M(516M) 0.257ms >>>>> [22.250s][info][gc] GC(28) Concurrent Cycle 619.296ms >>>>> [22.827s][info][gc] GC(29) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 321M->155M(516M) 106.789ms >>>>> [23.758s][info][gc] GC(30) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 363M->187M(516M) 121.025ms >>>>> [24.957s][info][gc] GC(31) Pause Young (Normal) (GCLocker Initiated >>>>> GC) 386M->207M(516M) 111.118ms >>>>> [25.697s][info][gc] GC(32) Pause Young (Concurrent Start) (G1 >>>>> Humongous Allocation) 346M->222M(656M) 104.765ms >>>>> [25.697s][info][gc] GC(33) Concurrent Cycle >>>>> [26.128s][info][gc] GC(33) Pause Remark 270M->192M(656M) 55.681ms >>>>> [26.342s][info][gc] GC(33) Pause Cleanup 203M->203M(656M) 0.371ms >>>>> [26.349s][info][gc] GC(33) Concurrent Cycle 651.801ms >>>>> [27.421s][info][gc] GC(34) Pause Young (Prepare Mixed) (G1 >>>>> Evacuation Pause) 380M->180M(656M) 195.335ms >>>>> [27.543s][info][gc] GC(35) Pause Young (Mixed) (G1 Evacuation >>>>> Pause) 195M->172M(656M) 38.254ms >>>>> [28.694s][info][gc] GC(36) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 427M->214M(656M) 107.817ms >>>>> [31.109s][info][gc] GC(37) Pause Young (Normal) (G1 Evacuation >>>>> Pause) 486M->239M(656M) 117.275ms >>>> >>>> Notice, the higher memory usage. If a more complex applications is >>>> started, the heap continue to grow indefinitely, with long GC pauses >>>> and >>>> a growing heap. It is my understanding that the JVM should setup >>>> default >>>> GC and or memory related configuration by itself, be it from the java >>>> launcher or JNI_CreateJavaVM. >>>> >>>> The same custom launcher does not experience this when the embedded JVM >>>> is version 8. >>>> >>>> Note: the launcher is a simple Rust program, not a complex thing, just >>>> locate libjvm.so/jvm.dll, build the VM options, Use JNI_CreateJavaVM, >>>> locate the main class and invoke the main method. These logs are for >>>> the >>>> Linux version. >>>> >>>> Any help is appreciated, or a pointer to the correct mailing list. >>>> >>>> >> > From lance.andersen at oracle.com Mon Jan 21 22:50:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 21 Jan 2019 17:50:30 -0500 Subject: Manifest copy constructor does not deeply copy individual section Attributes In-Reply-To: <1547926484.2363.5.camel@paratix.ch> References: <1547922745.2363.2.camel@paratix.ch> <1547926484.2363.5.camel@paratix.ch> Message-ID: <5B707420-A006-44F1-8A5A-05EC97B76690@oracle.com> Hi Philipp, This is going to take some further discussion/input as this has been documented for sometime as a shallow copy. If there is a consensus to move this forward, it will also require a CSR. I can help with that and sponsoring the updates, if the decision is to go ahead with the proposed change Best Lance > On Jan 19, 2019, at 2:34 PM, Philipp Kunz wrote: > > 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. > I don't know about the background of it or why clone should only do a > shallow copy but if clone should really create a shallow copy, it > should probably create an even more shallow copy. In any case I figure > some potential for clarification at least. > Probably mostly because I already began a patch in the previous > message, I continued and attached another patch for a deep copy > approach. There might still be some reason not to deeply copy manifests > which I don't intend to forestall. > Philipp > > On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote: >> 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 attributes instances modifications to which >> always affect both manifests. See test and proposed fix in the >> attached patch. >> >> Regards, >> Philipp > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From patrick at os.amperecomputing.com Tue Jan 22 02:21:52 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Tue, 22 Jan 2019 02:21:52 +0000 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> References: <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> Message-ID: Thanks Roger. I did a try to push the patch within a branch to jdk/submit, and saw ?Permission denied (publickey)?. I sent my SSH pub key to keys(at)openjdk.java.net but got no response. I heard only committers can have the access right, could you please help? Regards Patrick From: Roger Riggs Sent: Wednesday, January 16, 2019 11:07 PM To: Alan Bateman ; Patrick Zhang ; David Holmes Cc: core-libs-dev Subject: Re: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi, I can sponsor this. Let me know when the jdk-submit is complete. Thanks, Roger On 01/16/2019 10:03 AM, Alan Bateman wrote: On 16/01/2019 02:30, Patrick Zhang wrote: Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. I think this patch looks okay and I assume you'll test it in the jdk-submit repo to make sure it builds on all platforms. -Alan From david.holmes at oracle.com Tue Jan 22 04:01:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 14:01:20 +1000 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> Message-ID: Hi Patrick, I'm putting this through our test system (again) and will report back when its complete. I also updated the bug report with the patch and assigned to Roger as the sponsor. Cheers, David On 22/01/2019 12:21 pm, Patrick Zhang wrote: > Thanks Roger. > > I did a try to push the patch within a branch to jdk/submit, and saw > ?Permission denied (publickey)?. I sent my SSH pub key to > keys(at)openjdk.java.net but got no response. I heard only committers > can have the access right, could you please help? > > Regards > > Patrick > > *From:* Roger Riggs > *Sent:* Wednesday, January 16, 2019 11:07 PM > *To:* Alan Bateman ; Patrick Zhang > ; David Holmes > *Cc:* core-libs-dev > *Subject:* Re: 8215976: OpenJDK fails to build with GCC when the > #include inside zip.cpp comes from a non-sysroot path > > Hi, > > I can sponsor this. Let me know when the jdk-submit is complete. > > Thanks, Roger > > On 01/16/2019 10:03 AM, Alan Bateman wrote: > > On 16/01/2019 02:30, Patrick Zhang wrote: > > Looks .patch didn't work as an attachment, retry with .txt and > paste the text below as well. Sorry for one more message here. > > I think this patch looks okay and I assume you'll test it in the > jdk-submit repo to make sure it builds on all platforms. > > -Alan > From david.holmes at oracle.com Tue Jan 22 06:45:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 16:45:14 +1000 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> Message-ID: <3d2dfc8a-55f6-f927-3c16-7eadb6af8772@oracle.com> Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris sparcv9. David On 22/01/2019 2:01 pm, David Holmes wrote: > Hi Patrick, > > I'm putting this through our test system (again) and will report back > when its complete. > > I also updated the bug report with the patch and assigned to Roger as > the sponsor. > > Cheers, > David > > On 22/01/2019 12:21 pm, Patrick Zhang wrote: >> Thanks Roger. >> >> I did a try to push the patch within a branch to jdk/submit, and saw >> ?Permission denied (publickey)?. I sent my SSH pub key to >> keys(at)openjdk.java.net but got no response. I heard only committers >> can have the access right, could you please help? >> >> Regards >> >> Patrick >> >> *From:* Roger Riggs >> *Sent:* Wednesday, January 16, 2019 11:07 PM >> *To:* Alan Bateman ; Patrick Zhang >> ; David Holmes >> *Cc:* core-libs-dev >> *Subject:* Re: 8215976: OpenJDK fails to build with GCC when the >> #include inside zip.cpp comes from a non-sysroot path >> >> Hi, >> >> I can sponsor this. Let me know when the jdk-submit is complete. >> >> Thanks, Roger >> >> On 01/16/2019 10:03 AM, Alan Bateman wrote: >> >> ??? On 16/01/2019 02:30, Patrick Zhang wrote: >> >> ??????? Looks .patch didn't work as an attachment, retry with .txt and >> ??????? paste the text below as well. Sorry for one more message here. >> >> ??? I think this patch looks okay and I assume you'll test it in the >> ??? jdk-submit repo to make sure it builds on all platforms. >> >> ??? -Alan >> From Alan.Bateman at oracle.com Tue Jan 22 09:52:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2019 09:52:26 +0000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> Message-ID: <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> On 22/01/2019 4:48 am, Robert Marcano wrote: >> : >> >> So the question now is, why signed jars could affect the memory usage >> of an application (we aren't doing JAR verification on our custom >> launcher, yet), just by being on the java.class.path? IIRC the >> initial application classpath JARs were never verified previously (by >> the java launcher alone, without JNLP around). >> >> Note: Tested with JARs signed with a self signed certificate and with >> one signed with a private CA. At most, signing the JARs could slow >> down the start up if it is now expected to these being verified by >> the java launcher (is it true?) but not higher memory usage and no >> reductions after a GC cycle but constants heap size increases. Signed JARs can be expensive to verify, esp. on first usage as the verification is likely to result in early loading of a lot of security classes and infrastructure. If you can narrow down the apparently memory leak to a small test case with analysis to suggest it's a JDK bug then it would be good to get a bug submitted. -Alan From goetz.lindenmaier at sap.com Tue Jan 22 13:09:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Jan 2019 13:09:00 +0000 Subject: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX In-Reply-To: <1da96af8ea134312b801e14d5830373d@sap.com> References: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> <1da96af8ea134312b801e14d5830373d@sap.com> Message-ID: <895fea507a5e49c2b10213a6e2ccb406@sap.com> Hi Christoph, thanks for your review. I'll update AIX to Aix before pushing. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 21. Januar 2019 11:43 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net > Subject: RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for > AIX > > Hi Goetz, > > looks good to me. I think it should rather be "AIX" than "Aix" in the output text > - but it's a developer trace only, so probably nobody cares. ?? > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Lindenmaier, Goetz > > Sent: Montag, 21. Januar 2019 11:01 > > To: core-libs-dev at openjdk.java.net > > Subject: [CAUTION] RFR(XS): 8217438: Adapt > > tools//launcher/Test7029048.java for AIX > > > > Hi, > > > > please review the following small test fix: > > http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/ > > > > The Aix launcher always sets the path to the jdk libraries because > > Aix does not support $ORIGIN to find libjvm.so. > > So some of the test cases here fail. Skip them. > > > > Best regards, > > Goetz. From arno.zeller at sap.com Tue Jan 22 13:47:59 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Tue, 22 Jan 2019 13:47:59 +0000 Subject: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX In-Reply-To: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> References: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> Message-ID: <6cb1caa100da45c8ab347b03987d7eaa@sap.com> Hi Goetz, looks good to me and should fix the issue. I just want to point out that I am not a Reviewer. Best regards, Arno >-----Original Message----- >From: core-libs-dev On Behalf Of >Lindenmaier, Goetz >Sent: Montag, 21. Januar 2019 11:01 >To: core-libs-dev at openjdk.java.net >Subject: [CAUTION] RFR(XS): 8217438: Adapt >tools//launcher/Test7029048.java for AIX > >Hi, > >please review the following small test fix: >http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/ > >The Aix launcher always sets the path to the jdk libraries because >Aix does not support $ORIGIN to find libjvm.so. >So some of the test cases here fail. Skip them. > >Best regards, > Goetz. From goetz.lindenmaier at sap.com Tue Jan 22 13:58:37 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Jan 2019 13:58:37 +0000 Subject: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX In-Reply-To: <6cb1caa100da45c8ab347b03987d7eaa@sap.com> References: <4cc0cc86c633407fbb0822d2b74bdc37@sap.com> <6cb1caa100da45c8ab347b03987d7eaa@sap.com> Message-ID: Hi Arno, thanks for looking at the change! Best regards, Goetz. > -----Original Message----- > From: Zeller, Arno > Sent: Dienstag, 22. Januar 2019 14:48 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net > Subject: RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for > AIX > > Hi Goetz, > > looks good to me and should fix the issue. > I just want to point out that I am not a Reviewer. > > Best regards, > Arno > > >-----Original Message----- > >From: core-libs-dev On Behalf Of > >Lindenmaier, Goetz > >Sent: Montag, 21. Januar 2019 11:01 > >To: core-libs-dev at openjdk.java.net > >Subject: [CAUTION] RFR(XS): 8217438: Adapt > >tools//launcher/Test7029048.java for AIX > > > >Hi, > > > >please review the following small test fix: > >http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/ > > > >The Aix launcher always sets the path to the jdk libraries because > >Aix does not support $ORIGIN to find libjvm.so. > >So some of the test cases here fail. Skip them. > > > >Best regards, > > Goetz. From Roger.Riggs at oracle.com Tue Jan 22 14:55:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 09:55:57 -0500 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: <3d2dfc8a-55f6-f927-3c16-7eadb6af8772@oracle.com> References: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> <3d2dfc8a-55f6-f927-3c16-7eadb6af8772@oracle.com> Message-ID: Hi David, Thanks for running the tests. Pushed. Thanks, Roger On 01/22/2019 01:45 AM, David Holmes wrote: > Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris > sparcv9. > > David > > On 22/01/2019 2:01 pm, David Holmes wrote: >> Hi Patrick, >> >> I'm putting this through our test system (again) and will report back >> when its complete. >> >> I also updated the bug report with the patch and assigned to Roger as >> the sponsor. >> >> Cheers, >> David >> >> On 22/01/2019 12:21 pm, Patrick Zhang wrote: >>> Thanks Roger. >>> >>> I did a try to push the patch within a branch to jdk/submit, and saw >>> ?Permission denied (publickey)?. I sent my SSH pub key to >>> keys(at)openjdk.java.net but got no response. I heard only >>> committers can have the access right, could you please help? >>> >>> Regards >>> >>> Patrick >>> >>> *From:* Roger Riggs >>> *Sent:* Wednesday, January 16, 2019 11:07 PM >>> *To:* Alan Bateman ; Patrick Zhang >>> ; David Holmes >>> >>> *Cc:* core-libs-dev >>> *Subject:* Re: 8215976: OpenJDK fails to build with GCC when the >>> #include inside zip.cpp comes from a non-sysroot path >>> >>> Hi, >>> >>> I can sponsor this. Let me know when the jdk-submit is complete. >>> >>> Thanks, Roger >>> >>> On 01/16/2019 10:03 AM, Alan Bateman wrote: >>> >>> ??? On 16/01/2019 02:30, Patrick Zhang wrote: >>> >>> ??????? Looks .patch didn't work as an attachment, retry with .txt and >>> ??????? paste the text below as well. Sorry for one more message here. >>> >>> ??? I think this patch looks okay and I assume you'll test it in the >>> ??? jdk-submit repo to make sure it builds on all platforms. >>> >>> ??? -Alan >>> From Alan.Bateman at oracle.com Tue Jan 22 16:12:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2019 16:12:22 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <708555d0-d3e5-2d2c-f69d-16f76a83f66a@gmail.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> <708555d0-d3e5-2d2c-f69d-16f76a83f66a@gmail.com> Message-ID: <5c8a7e85-bdb4-61f8-54ed-75689d0fcf16@oracle.com> On 18/01/2019 14:28, Peter Levart wrote: > > ...unless you actually want users to construct their own MapMode(s), > like you mentioned is the case with FileChannel.open() and > FileAttribute interface. But there this makes sense because the > backend (FileSystem) is also pluggable, so users can define their own > FileSystem implementations that consume their own FileAttribute(s)... > > Are you proposing to add an spi for MappedByteBuffer's here? That > would be an overkill for this feature, I think... No, we definitely don't want to go there as buffers are closed abstraction. Instead, this is just about allowing the JDK to support additional map modes beyond those specified by FileChannel.map. If you create your own MapMode and call the map method with it then it will be rejected, probably UOE. With the suggestion, a JDK-specific module would define READ_WRITE_SYNC and you could pass that mode to FileChannel.map. There's a bit of plumbing needed make that work but there are examples of this already (e.g. socket options and file open options). -Alan. From Alan.Bateman at oracle.com Tue Jan 22 17:02:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2019 17:02:26 +0000 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> Message-ID: On 19/01/2019 12:46, Lance Andersen wrote: > 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 > @@ -265,9 +265,10 @@ > } > > /** > - * Compares the specified Attributes object with this Map for equality. > - * Returns true if the given object is also an instance of Attributes > - * and the two Attributes objects represent the same mappings. > + * Compares the specified object with this Map for equality. > + * Returns true if the given object is also a Map > + * and the two objects represent the same Manifest > + * attribute name-value mappings. > I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. -Alan From Roger.Riggs at oracle.com Tue Jan 22 20:00:17 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 15:00:17 -0500 Subject: Manifest copy constructor does not deeply copy individual section Attributes In-Reply-To: <5B707420-A006-44F1-8A5A-05EC97B76690@oracle.com> References: <1547922745.2363.2.camel@paratix.ch> <1547926484.2363.5.camel@paratix.ch> <5B707420-A006-44F1-8A5A-05EC97B76690@oracle.com> Message-ID: <7cd7aee6-55df-45e9-fb20-0829b2f5ff2a@oracle.com> Hi Phillip, Did you discover need for a deeper copy?? If so, can you elaborate? It may be that adding a new constructor would be cleaner. I'd suggest clarifying the documentation of existing methods as opposed to changing the spec and implementation and the possible risks to clients. Thanks, Roger On 01/21/2019 05:50 PM, Lance Andersen wrote: > Hi Philipp, > > This is going to take some further discussion/input as this has been documented for sometime as a shallow copy. > > If there is a consensus to move this forward, it will also require a CSR. I can help with that and sponsoring the updates, if the decision is to go ahead with the proposed change > > Best > Lance >> On Jan 19, 2019, at 2:34 PM, Philipp Kunz wrote: >> >> 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. >> I don't know about the background of it or why clone should only do a >> shallow copy but if clone should really create a shallow copy, it >> should probably create an even more shallow copy. In any case I figure >> some potential for clarification at least. >> Probably mostly because I already began a patch in the previous >> message, I continued and attached another patch for a deep copy >> approach. There might still be some reason not to deeply copy manifests >> which I don't intend to forestall. >> Philipp >> >> On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote: >>> 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 attributes instances modifications to which >>> always affect both manifests. See test and proposed fix in the >>> attached patch. >>> >>> Regards, >>> Philipp >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Roger.Riggs at oracle.com Tue Jan 22 20:08:41 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 15:08:41 -0500 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider Message-ID: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> A ClassCircularityError can occur via the ClassDescriptor code that uses String.format to concatenate strings. Please review a change to use string concatenation or a known locale instead of the default locale in calls to String.format. The java.lang.constant APIs can be used early in the startup sequence before the Locales and providers are initialized. See the bug report for the full stack trace. ? https://bugs.openjdk.java.net/browse/JDK-8217339 I have not found a reproducer for jdk 12, it only occurs on new work for jdk 13. Webrev: ?http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1 Thanks, Roger From naoto.sato at oracle.com Tue Jan 22 20:29:10 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 22 Jan 2019 12:29:10 -0800 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider In-Reply-To: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> References: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> Message-ID: Hi Roger, I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), which is the language invariant locale. Other changes look good. BTW, > I have not found a reproducer for jdk 12, it only occurs on new work for > jdk 13. Is this new code in 13? l10n causes this type of circularity exception during the VM boot up. Naoto On 1/22/19 12:08 PM, Roger Riggs wrote: > A ClassCircularityError can occur via the ClassDescriptor code that uses > String.format to > concatenate strings. > > Please review a change to use string concatenation or a known locale > instead > of the default locale in calls to String.format. > > The java.lang.constant APIs can be used early in the startup sequence > before > the Locales and providers are initialized. > > See the bug report for the full stack trace. > ? https://bugs.openjdk.java.net/browse/JDK-8217339 > > I have not found a reproducer for jdk 12, it only occurs on new work for > jdk 13. > > Webrev: > ?http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1 > > Thanks, Roger > From naoto.sato at oracle.com Tue Jan 22 20:31:00 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 22 Jan 2019 12:31:00 -0800 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <31d211ff-a51b-9c3f-d7b5-3ee18330c74f@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com> <31d211ff-a51b-9c3f-d7b5-3ee18330c74f@oracle.com> Message-ID: <118b426f-c038-224e-3e12-238cf4e7130b@oracle.com> Hi Roger, Thanks. Modified as suggested: http://cr.openjdk.java.net/~naoto/8216969/webrev.02/ Naoto On 1/19/19 10:03 AM, Roger Riggs wrote: > 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 ? Calendar.LONG_STANDALONE ? LONG_FORMAT) > > Thanks, Roger > > On 01/18/2019 06:45 PM, naoto.sato at oracle.com wrote: >> Gentle reminder. Still waiting for reviews from OpenJDK Reviewers. >> >> Naoto >> >> On 1/18/19 1:57 AM, Nishit Jain wrote: >>> Looks Good. >>> >>> Regards, >>> Nishit Jain >>> On 17-01-2019 22:07, Naoto Sato wrote: >>>> Hi Nishit, >>>> >>>> Thanks. Updated: >>>> >>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ >>>> >>>> Naoto >>>> >>>> On 1/17/19 2:57 AM, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> Looks good to me. Just a small suggestion. >>>>> >>>>> - To improve readability, can we declare "standalone mask" (0x8000) >>>>> as a static field and use that at all the places? >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix to the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8216969 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >>>>>> >>>>>> For parsing the context sensitive month 'M', the logic was to look >>>>>> for the best match for the short name regardless of the styles. >>>>>> Changed the parsing code to take the context into account. >>>>>> >>>>>> Naoto >>>>> >>> > From mandy.chung at oracle.com Tue Jan 22 20:47:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Jan 2019 12:47:49 -0800 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider In-Reply-To: References: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> Message-ID: <15083385-2751-8d37-d4b6-88df6e79df43@oracle.com> On 1/22/19 12:29 PM, Naoto Sato wrote: > Hi Roger, > > I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), > which is the language invariant locale. > Alternatively, convert those String.format to string concatenation and they are pretty simple format only one argument. > Other changes look good. > > BTW, > > > I have not found a reproducer for jdk 12, it only occurs on new work > for > > jdk 13. > > Is this new code in 13? l10n causes this type of circularity exception > during the VM boot up. > I also want to understand what changes in 13 causes the difference. Is there a regression test? Mandy > Naoto > > On 1/22/19 12:08 PM, Roger Riggs wrote: >> A ClassCircularityError can occur via the ClassDescriptor code that >> uses String.format to >> concatenate strings. >> >> Please review a change to use string concatenation or a known locale >> instead >> of the default locale in calls to String.format. >> >> The java.lang.constant APIs can be used early in the startup sequence >> before >> the Locales and providers are initialized. >> >> See the bug report for the full stack trace. >> ?? https://bugs.openjdk.java.net/browse/JDK-8217339 >> >> I have not found a reproducer for jdk 12, it only occurs on new work >> for jdk 13. >> >> Webrev: >> ??http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1 >> >> Thanks, Roger >> From joe.darcy at oracle.com Tue Jan 22 21:10:56 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 22 Jan 2019 13:10:56 -0800 Subject: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString In-Reply-To: <148940069.658971.1547630486633.JavaMail.zimbra@u-pem.fr> References: <5b278beb-296a-c7d6-9065-2675d2123415@oracle.com> <4be24258-d644-04a0-6667-e5e425059692@oracle.com> <148940069.658971.1547630486633.JavaMail.zimbra@u-pem.fr> Message-ID: <79c33311-1543-7fc4-426c-70947a12654f@oracle.com> Hi Remi, Catching up on email, at least to my eye, the current version is easier to read than the proposed refactoring in both cases. I wouldn't expect this code to be performance critical so I'm inclined to leave the code as-is unless a performance motivation is found. Thanks for the comments, -Joe On 1/16/2019 1:21 AM, Remi Forax wrote: > Hi Joe, > in j.l.Class, in methodToString, can you change > sb.append(getName() + "." + name + "("); > to > sb.append(getName()).append(".").append(name).append('('); > because using the concatenation inside a StringBuilder creates another StringBuilder (java.lang doesn't use the StringConcatFactory). > > also > return typeVar.getName() + " extends " + > Arrays.stream(bounds) > .map(Type::getTypeName) > .collect(Collectors.joining(" & ")); > can be written > return Arrays.stream(bounds) > .map(Type::getTypeName) > .collect(Collectors.joining(" & ", typeVar.getName().concat(" extends "), "")); > which also avoid the creation of an intermediary StringBuilder (at the cost of the code being less readable). > (in that case, you have also to change the same code in Executable). > > regards, > R?mi > > ----- Mail original ----- >> De: "joe darcy" >> ?: "Stuart Marks" >> Cc: "core-libs-dev" >> Envoy?: Mercredi 16 Janvier 2019 04:05:05 >> Objet: Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString >> Good catch on the 3-argument joining in this case; I'll push with that >> amendment. >> >> Thanks for the review, >> >> -Joe >> >> On 1/15/2019 3:19 PM, Stuart Marks wrote: >>> >>> On 1/14/19 7:41 PM, Joe Darcy wrote: >>>> PS And for good measure, made analogous changes in Executable.java: >>>> >>>> ???? http://cr.openjdk.java.net/~darcy/8217000.1/ >>> Thanks for following up on this. Overall, looks good. One point: >>> >>> ?114???????????? sb.append('('); >>> ?115 >>> ?116???????????? sb.append(Arrays.stream(parameterTypes) >>> ?117?????????????????????? .map(Type::getTypeName) >>> ?118?????????????????????? .collect(Collectors.joining(","))); >>> ?119 >>> ?120???????????? sb.append(')'); >>> >>> I think you can use the 3-arg form of joining() here, since the prefix >>> and suffix are included even if the stream is empty. >>> >>> s'marks From roger.riggs at oracle.com Tue Jan 22 21:33:56 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 16:33:56 -0500 Subject: [13] RFR: 8216969: ParseException thrown for certain months with russian locale In-Reply-To: <118b426f-c038-224e-3e12-238cf4e7130b@oracle.com> References: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com> <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com> <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com> <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com> <31d211ff-a51b-9c3f-d7b5-3ee18330c74f@oracle.com> <118b426f-c038-224e-3e12-238cf4e7130b@oracle.com> Message-ID: <0e647ad5-41c6-8db4-6fbf-d767a7dd4a39@oracle.com> Looks good. Thanks, Roger On 1/22/19 3:31 PM, Naoto Sato wrote: > Hi Roger, > > Thanks. Modified as suggested: > > http://cr.openjdk.java.net/~naoto/8216969/webrev.02/ > > Naoto > > On 1/19/19 10:03 AM, Roger Riggs wrote: >> 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 ? Calendar.LONG_STANDALONE ? >> LONG_FORMAT) >> >> Thanks, Roger >> >> On 01/18/2019 06:45 PM, naoto.sato at oracle.com wrote: >>> Gentle reminder. Still waiting for reviews from OpenJDK Reviewers. >>> >>> Naoto >>> >>> On 1/18/19 1:57 AM, Nishit Jain wrote: >>>> Looks Good. >>>> >>>> Regards, >>>> Nishit Jain >>>> On 17-01-2019 22:07, Naoto Sato wrote: >>>>> Hi Nishit, >>>>> >>>>> Thanks. Updated: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/ >>>>> >>>>> Naoto >>>>> >>>>> On 1/17/19 2:57 AM, Nishit Jain wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Looks good to me. Just a small suggestion. >>>>>> >>>>>> - To improve readability, can we declare "standalone mask" >>>>>> (0x8000) as a static field and use that at all the places? >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix to the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216969 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ >>>>>>> >>>>>>> For parsing the context sensitive month 'M', the logic was to >>>>>>> look for the best match for the short name regardless of the >>>>>>> styles. Changed the parsing code to take the context into account. >>>>>>> >>>>>>> Naoto >>>>>> >>>> >> From roger.riggs at oracle.com Tue Jan 22 22:25:02 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 17:25:02 -0500 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider In-Reply-To: <15083385-2751-8d37-d4b6-88df6e79df43@oracle.com> References: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> <15083385-2751-8d37-d4b6-88df6e79df43@oracle.com> Message-ID: <45f66484-0c94-f7f5-50ba-b4874c2170ca@oracle.com> Hi Mandy, Updated webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/ On 1/22/19 3:47 PM, Mandy Chung wrote: > > > On 1/22/19 12:29 PM, Naoto Sato wrote: >> Hi Roger, >> >> I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), >> which is the language invariant locale. >> > > Alternatively, convert those String.format to string concatenation and > they > are pretty simple format only one argument. ok, > >> Other changes look good. >> >> BTW, >> >> > I have not found a reproducer for jdk 12, it only occurs on new >> work for >> > jdk 13. >> >> Is this new code in 13? l10n causes this type of circularity >> exception during the VM boot up. >> > > I also want to understand what changes in 13 causes the difference. I was prototyping some more properties ideas. I suspect that in the previous init sequence, the Locale had been cached. A closed test had failed, in part because it had changed the default locale and then installed a security manager. > > Is there a regression test? My test class is: public class Circ { ??? public static void main(String[] args) { ??????? Locale.setDefault(Locale.ENGLISH); ??????? System.setSecurityManager(new SecurityManager()); ??????? NumberFormat nf = NumberFormat.getInstance(); ??? } } The circularity error only occurred if the default locale was changed. But I was unable to reproduce it without other changes. Thanks, Roger > > Mandy > >> Naoto >> >> On 1/22/19 12:08 PM, Roger Riggs wrote: >>> A ClassCircularityError can occur via the ClassDescriptor code that >>> uses String.format to >>> concatenate strings. >>> >>> Please review a change to use string concatenation or a known locale >>> instead >>> of the default locale in calls to String.format. >>> >>> The java.lang.constant APIs can be used early in the startup >>> sequence before >>> the Locales and providers are initialized. >>> >>> See the bug report for the full stack trace. >>> https://bugs.openjdk.java.net/browse/JDK-8217339 >>> >>> I have not found a reproducer for jdk 12, it only occurs on new work >>> for jdk 13. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1 >>> >>> Thanks, Roger >>> > From robert at marcanoonline.com Tue Jan 22 10:01:00 2019 From: robert at marcanoonline.com (Robert Marcano) Date: Tue, 22 Jan 2019 06:01:00 -0400 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> Message-ID: On Tue, Jan 22, 2019, 5:53 AM Alan Bateman On 22/01/2019 4:48 am, Robert Marcano wrote: > >> : > >> > >> So the question now is, why signed jars could affect the memory usage > >> of an application (we aren't doing JAR verification on our custom > >> launcher, yet), just by being on the java.class.path? IIRC the > >> initial application classpath JARs were never verified previously (by > >> the java launcher alone, without JNLP around). > >> > >> Note: Tested with JARs signed with a self signed certificate and with > >> one signed with a private CA. At most, signing the JARs could slow > >> down the start up if it is now expected to these being verified by > >> the java launcher (is it true?) but not higher memory usage and no > >> reductions after a GC cycle but constants heap size increases. > Signed JARs can be expensive to verify, esp. on first usage as the > verification is likely to result in early loading of a lot of security > classes and infrastructure. If you can narrow down the apparently memory > leak to a small test case with analysis to suggest it's a JDK bug then > it would be good to get a bug submitted. > > -Alan Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized CA doesn't trigger a validation error. > From mandy.chung at oracle.com Tue Jan 22 23:25:25 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Jan 2019 15:25:25 -0800 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider In-Reply-To: <45f66484-0c94-f7f5-50ba-b4874c2170ca@oracle.com> References: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> <15083385-2751-8d37-d4b6-88df6e79df43@oracle.com> <45f66484-0c94-f7f5-50ba-b4874c2170ca@oracle.com> Message-ID: <1b4d289c-d780-772c-713a-4bceac511af6@oracle.com> On 1/22/19 2:25 PM, Roger Riggs wrote: > Hi Mandy, > > Updated webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/ > > Looks good. >> >>> Other changes look good. >>> >>> BTW, >>> >>> > I have not found a reproducer for jdk 12, it only occurs on new >>> work for >>> > jdk 13. >>> >>> Is this new code in 13? l10n causes this type of circularity >>> exception during the VM boot up. >>> >> >> I also want to understand what changes in 13 causes the difference. > I was prototyping some more properties ideas. > I suspect that in the previous init sequence, the Locale had been cached. > A closed test had failed, in part because it had changed the default > locale > and then installed a security manager. I see how ConstantDesc gets initialized during initialization of VarHandle from your stack trace.? I can't reproduce it and so I assume it was triggered by your local change.? In any case, converting String.format to string concat is fine. I am sure Claes may look at the startup and class initialization if we can avoid loading VarHandleDesc from clinit. Mandy From mikael.vidstedt at oracle.com Wed Jan 23 00:26:19 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 22 Jan 2019 16:26:19 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> References: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> Message-ID: <93523B17-400A-4420-8DBF-C35372C07AA8@oracle.com> Please review this change which back ports the problem listing of LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push it to jdk12, but that plan got lost somewhere on the way). Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/ The change is the same as the one in jdk/jdk, but the copyright year was already updated in jdk12, so there was a trivially resolved merge conflict. Cheers, Mikael > On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt wrote: > > > Thanks Igor! Pushed. > > Cheers, > Mikael > >> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: >> >> Mikael, >> >> looks good and trivial to me. >> >> -- Igor >> >>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ >>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 >>> >>> Cheers, >>> Mikael >>> >> > From mandy.chung at oracle.com Wed Jan 23 00:30:31 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Jan 2019 16:30:31 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: <93523B17-400A-4420-8DBF-C35372C07AA8@oracle.com> References: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> <93523B17-400A-4420-8DBF-C35372C07AA8@oracle.com> Message-ID: <519f004e-1da3-2375-ab62-d068cbdb84c5@oracle.com> +1 Mandy On 1/22/19 4:26 PM, Mikael Vidstedt wrote: > Please review this change which back ports the problem listing of LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push it to jdk12, but that plan got lost somewhere on the way). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/ > > The change is the same as the one in jdk/jdk, but the copyright year was already updated in jdk12, so there was a trivially resolved merge conflict. > > Cheers, > Mikael > >> On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt wrote: >> >> >> Thanks Igor! Pushed. >> >> Cheers, >> Mikael >> >>> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: >>> >>> Mikael, >>> >>> looks good and trivial to me. >>> >>> -- Igor >>> >>>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ >>>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 >>>> >>>> Cheers, >>>> Mikael >>>> From igor.ignatyev at oracle.com Wed Jan 23 00:34:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 22 Jan 2019 16:34:46 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: <519f004e-1da3-2375-ab62-d068cbdb84c5@oracle.com> References: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> <93523B17-400A-4420-8DBF-C35372C07AA8@oracle.com> <519f004e-1da3-2375-ab62-d068cbdb84c5@oracle.com> Message-ID: looks good. -- Igor > On Jan 22, 2019, at 4:30 PM, Mandy Chung wrote: > > +1 > > Mandy > > On 1/22/19 4:26 PM, Mikael Vidstedt wrote: >> Please review this change which back ports the problem listing of LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push it to jdk12, but that plan got lost somewhere on the way). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/ >> >> The change is the same as the one in jdk/jdk, but the copyright year was already updated in jdk12, so there was a trivially resolved merge conflict. >> >> Cheers, >> Mikael >> >>> On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt wrote: >>> >>> >>> Thanks Igor! Pushed. >>> >>> Cheers, >>> Mikael >>> >>>> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: >>>> >>>> Mikael, >>>> >>>> looks good and trivial to me. >>>> >>>> -- Igor >>>> >>>>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: >>>>> >>>>> >>>>> Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >>>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ >>>>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 >>>>> >>>>> Cheers, >>>>> Mikael >>>>> > From mikael.vidstedt at oracle.com Wed Jan 23 00:42:01 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 22 Jan 2019 16:42:01 -0800 Subject: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java In-Reply-To: References: <4376C8E2-2511-4B28-85B1-0D6C5848EA46@oracle.com> <9DC7C958-5DF6-4CC4-9027-B2A71179936A@oracle.com> <93523B17-400A-4420-8DBF-C35372C07AA8@oracle.com> <519f004e-1da3-2375-ab62-d068cbdb84c5@oracle.com> Message-ID: Mandy, Igor - thanks! Change pushed to jdk12. Cheers, Mikael > On Jan 22, 2019, at 4:34 PM, Igor Ignatyev wrote: > > looks good. > > -- Igor > >> On Jan 22, 2019, at 4:30 PM, Mandy Chung wrote: >> >> +1 >> >> Mandy >> >> On 1/22/19 4:26 PM, Mikael Vidstedt wrote: >>> Please review this change which back ports the problem listing of LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push it to jdk12, but that plan got lost somewhere on the way). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/ >>> >>> The change is the same as the one in jdk/jdk, but the copyright year was already updated in jdk12, so there was a trivially resolved merge conflict. >>> >>> Cheers, >>> Mikael >>> >>>> On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> Thanks Igor! Pushed. >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: >>>>> >>>>> Mikael, >>>>> >>>>> looks good and trivial to me. >>>>> >>>>> -- Igor >>>>> >>>>>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt wrote: >>>>>> >>>>>> >>>>>> Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 >>>>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ >>>>>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >> > From lance.andersen at oracle.com Wed Jan 23 00:47:20 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Jan 2019 19:47:20 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> Message-ID: <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> > On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote: > > On 19/01/2019 12:46, Lance Andersen wrote: >> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >> @@ -265,9 +265,10 @@ >> } >> /** >> - * Compares the specified Attributes object with this Map for equality. >> - * Returns true if the given object is also an instance of Attributes >> - * and the two Attributes objects represent the same mappings. >> + * Compares the specified object with this Map for equality. >> + * Returns true if the given object is also a Map >> + * and the two objects represent the same Manifest >> + * attribute name-value mappings. >> > I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From patrick at os.amperecomputing.com Wed Jan 23 01:48:07 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Wed, 23 Jan 2019 01:48:07 +0000 Subject: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <34403c38-ff00-2ff6-0c13-a200220c53b3@oracle.com> <7714c0b0-11d6-986a-050d-d5b1a47b091b@oracle.com> <6d4873a9-80a2-9e9b-fe88-e0ecbd3e7812@oracle.com> <727c890f-d887-24ec-ff38-9a2bd4c2a577@oracle.com> <3d2dfc8a-55f6-f927-3c16-7eadb6af8772@oracle.com> Message-ID: Appreciate all your kind help in making it happen. Regards Patrick From: Roger Riggs Sent: Tuesday, January 22, 2019 10:56 PM To: David Holmes ; Patrick Zhang Cc: core-libs-dev Subject: Re: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi David, Thanks for running the tests. Pushed. Thanks, Roger On 01/22/2019 01:45 AM, David Holmes wrote: Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris sparcv9. David On 22/01/2019 2:01 pm, David Holmes wrote: Hi Patrick, I'm putting this through our test system (again) and will report back when its complete. I also updated the bug report with the patch and assigned to Roger as the sponsor. Cheers, David On 22/01/2019 12:21 pm, Patrick Zhang wrote: Thanks Roger. I did a try to push the patch within a branch to jdk/submit, and saw ?Permission denied (publickey)?. I sent my SSH pub key to keys(at)openjdk.java.net but got no response. I heard only committers can have the access right, could you please help? Regards Patrick *From:* Roger Riggs *Sent:* Wednesday, January 16, 2019 11:07 PM *To:* Alan Bateman ; Patrick Zhang ; David Holmes *Cc:* core-libs-dev *Subject:* Re: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi, I can sponsor this. Let me know when the jdk-submit is complete. Thanks, Roger On 01/16/2019 10:03 AM, Alan Bateman wrote: On 16/01/2019 02:30, Patrick Zhang wrote: Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. I think this patch looks okay and I assume you'll test it in the jdk-submit repo to make sure it builds on all platforms. -Alan From ecki at zusammenkunft.net Wed Jan 23 01:50:52 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 23 Jan 2019 01:50:52 +0000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com>, Message-ID: I don?t think the launcher is doing this, it is the class loader, that?s nothing new. You can turn on verbose security debug to see it in all versions. -- https://Bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Robert Marcano Gesendet: Mittwoch, Januar 23, 2019 2:18 AM An: Alan Bateman Cc: OpenJDK Dev list; core-libs-dev Libs Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding On Tue, Jan 22, 2019, 5:53 AM Alan Bateman On 22/01/2019 4:48 am, Robert Marcano wrote: > >> : > >> > >> So the question now is, why signed jars could affect the memory usage > >> of an application (we aren't doing JAR verification on our custom > >> launcher, yet), just by being on the java.class.path? IIRC the > >> initial application classpath JARs were never verified previously (by > >> the java launcher alone, without JNLP around). > >> > >> Note: Tested with JARs signed with a self signed certificate and with > >> one signed with a private CA. At most, signing the JARs could slow > >> down the start up if it is now expected to these being verified by > >> the java launcher (is it true?) but not higher memory usage and no > >> reductions after a GC cycle but constants heap size increases. > Signed JARs can be expensive to verify, esp. on first usage as the > verification is likely to result in early loading of a lot of security > classes and infrastructure. If you can narrow down the apparently memory > leak to a small test case with analysis to suggest it's a JDK bug then > it would be good to get a bug submitted. > > -Alan Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized CA doesn't trigger a validation error. > From joe.darcy at oracle.com Wed Jan 23 01:52:04 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 22 Jan 2019 17:52:04 -0800 Subject: Feature suggestion: Add static equals methods to Float and Double In-Reply-To: References: <1901070898.355299.1546643469299@mail.vodafone.de> <673203044.357759.1546645813058.JavaMail.zimbra@u-pem.fr> <1804954602.355374.1546648311803@mail.vodafone.de> <1661909988.228347.1546801278210@mail.vodafone.de> <867decfe-4941-c8e8-67f5-41f952a0b829@oracle.com> Message-ID: <5C47C8C4.7030203@oracle.com> Catching up on email... On 1/8/2019 10:55 AM, Hans Boehm wrote: > The IEEE standard does say that for quiet NaNs, the value (or one of them) > "should" be preserved by most operations on the quiet NaN. I have not heard > of implementations violating this for anything other than the "quiet" bit. > Thus I don't immediately see why it would be problematic to encode an > explicitly programmer-introduced error cause in the remaining bits (as > opposed to relying on hardware-generated patterns). I have not seen > non-testing code that does so, but I would be mildly surprised if it > doesn't exist somewhere. The IEEE standard does recommend the "payload" of NaN bits be preserved, that is the significand bits of the NaN. The various versions of 754 and its draft revision are less committal about the sign bit of a NaN. Some processors use an implementation of, say, floating-point multiply where the sign bit of the product is the XOR of the sign bit of the inputs. In interests of keeping such calculations more straightforward, an is-NaN check is not included on this pathway. That is all well and good in terms of supporting the "retrospective diagnostics" intention of NaN payloads, but does run afoul of aspirations to have a predictable sign bit exposed via a raw-bits view. Cheers, -Joe From philipp.kunz at paratix.ch Wed Jan 23 08:13:23 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 23 Jan 2019 09:13:23 +0100 Subject: Manifest copy constructor does not deeply copy individual section Attributes In-Reply-To: <7cd7aee6-55df-45e9-fb20-0829b2f5ff2a@oracle.com> References: <1547922745.2363.2.camel@paratix.ch> <1547926484.2363.5.camel@paratix.ch> <5B707420-A006-44F1-8A5A-05EC97B76690@oracle.com> <7cd7aee6-55df-45e9-fb20-0829b2f5ff2a@oracle.com> Message-ID: <1548231203.2363.21.camel@paratix.ch> Hi Roger, Thanks for looking into it and for your reply.I don't see a compulsory reason to change the code. In context of JDK-8217375 I happened to touch the issue and I agree to Max to solve it differently in that particular case now by creating a real deep copy based on reading the manifest bytes input stream again.h ttps://mail.openjdk.java.net/pipermail/security-dev/2019- January/019200.html Even though I don't have a strong reason to change Manifest code any more, in my opinion the current actual behavior is quite weird, possibly too strange?even to properly document without deprecating it at the same time. Chances are that other people struggled over it just like I did and will so again always getting the impression of a bug whether documented or not. The current copy constructor already now tries to deeply copy the original but clones only two out of three collections. Hence, I'd guess the current code was developed with the intention to create a deep copy back when it was developed. Maintaining perfect backward compatibility would mean to?also add a new deepClone or similar method along with another constructor wouldn't it? The are probably other uses but the only use of individual sections in manifests that I'm currently aware of is jar signing and there it has not been found so far as I'm aware of. While there certainly are risks to clients there might be chances as well to fix issues in client code. These are just some considerations in favor of changing the code but by no means meant as a conclusion. Philipp On Tue, 2019-01-22 at 15:00 -0500, Roger Riggs wrote: > Hi Phillip, > > Did you discover need for a deeper copy?? If so, can you elaborate? > It may be that adding a new constructor would be cleaner. > > I'd suggest clarifying the documentation of existing methods as > opposed > to changing the spec and implementation and the possible risks > to clients. > > Thanks, Roger > > On 01/21/2019 05:50 PM, Lance Andersen wrote: > > Hi Philipp, > > > > This is going to take some further discussion/input as this has > > been documented for sometime as a shallow copy. > > > > If there is a consensus??to move this forward, it will also require > > a CSR.???I can help with that and sponsoring the updates,??if the > > decision is to go ahead with the proposed change > > > > Best > > Lance > > > On Jan 19, 2019, at 2:34 PM, Philipp Kunz > > h> wrote: > > > > > > 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. > > > I don't know about the background of it or why clone should only > > > do a > > > shallow copy but if clone should really create a shallow copy, it > > > should probably create an even more shallow copy. In any case I > > > figure > > > some potential for clarification at least. > > > Probably mostly because I already began a patch in the previous > > > message, I continued and attached another patch for a deep copy > > > approach. There might still be some reason not to deeply copy > > > manifests > > > which I don't intend to forestall. > > > Philipp > > > > > > On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote: > > > > 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 attributes instances modifications to > > > > which > > > > always affect both manifests. See test and proposed fix in the > > > > attached patch. > > > > > > > > Regards, > > > > Philipp > > > > > > > > > > ? > > ? > > > > ? Lance > > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > > 1 Network Drive > > Burlington, MA 01803 > > Lance.Andersen at oracle.com > > > > > > From matthias.baesken at sap.com Wed Jan 23 08:29:55 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 23 Jan 2019 08:29:55 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> Message-ID: Hello Alan, here is a second webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/ I moved the Windows-only code into a new file src/java.base/windows/native/libjli/parse_manifest_md.c Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Mittwoch, 16. Januar 2019 16:43 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 16/01/2019 14:43, Baesken, Matthias wrote: > > Hi Alan , do you think it is good to start a UNIX parse_manifest_md.c too > with just a one-liner in it ? > > Or do you prefer only having the windows - file with the Windows coding > and keeping the UNIX one-liner for open_jarfile in parse_manifest.c ? > > > I think this makes sense. > > -Alan From GROEGES at uk.ibm.com Wed Jan 23 11:18:03 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 23 Jan 2019 11:18:03 +0000 Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler Message-ID: Hi Volker, Do you think it would be possible to get the change you committed to JDK12 http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ for this issue https://bugs.openjdk.java.net/browse/JDK-8214063 back-ported to JDK11, as JDK11 is a LTS release and it woud be good to have this fix? Also, we have received reports of other issues caused by the -qvisibility=hidden when using XLC 13.1 with JDK11 on AIX. One of these is related to : Desktop printer feature cannot detect by following exception. Caused by: java.lang.UnsatisfiedLinkError: sun/print/CUPSPrinter.initIDs()Z Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Hi Adam, Ichiroh, > > this is actually exactly what I wanted to propose in the mail I was > just writing :) > > You may have noticed that I've renamed the bug to "8214063: [AIX] > Disable symbol visibility flags". For the next step which will enable > symbol visibility on AIX we already have the following issue "8204541: > Correctly support AIX xlC 13.1 symbol visibility flags" [1]. Please > assign yourself and use it once the issues are resolved. > > In the meantime I've tested your change and it works fine with xlC 12. > I've only added a reference to the JBS id in the comments. Please find > a webrev of the new version here: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ > > I can sponsor that change once you and Ichiroh confirm that it also > works for you with xlC 13 and I get one more review. I've opened a new > thread for this on build-dev because the fix has now degenerated into > a pure build change: > > http://mail.openjdk.java.net/pipermail/build-dev/2018-November/024096.html > > Please answer on that new thread. > > Regards, > Volker > > PS: I don't think it makes too much sense investing into xlC 13. > You're probably aware of "JEP 347: Adopt C++14 Language Features in > HotSpot" [2] which will start introducing C++14 language features > soon. So it may be wiser to test right with the new beta of xlC 16 > because, as far as I know, there's no chance to get C++124 support > into xlC 13 anyway. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204541 > [2] http://openjdk.java.net/jeps/347 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From goetz.lindenmaier at sap.com Wed Jan 23 11:45:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2019 11:45:56 +0000 Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler In-Reply-To: References: Message-ID: Hi Steve, feel free to request the downport of this change. For this, you must first check whether the change applies cleanly: cd jdk/jdk; hg export -r 7384e00d5860 > 8215962.changeset (you find the hash in the JBS) cd jdk11u; hg import 8215962.changeset If so, you flag the bug in JBS as jdk11u-fix-request and add a comment to the bug why you want to downport this. The comment must start with "Fix Request". See for an example https://bugs.openjdk.java.net/browse/JDK-8215962 You will get a message once the downport is approved. Ping me and I will push the change for you. If the change does not apply cleanly, you must send a RFR with the adapted webrev to the list where the change was originally reviewed. You must add a link to the RFR in pipermail to the comment in the bug. See for example: https://bugs.openjdk.java.net/browse/JDK-8213754 Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Steve Groeger > Sent: Mittwoch, 23. Januar 2019 12:18 > To: OpenJDK Core Libs Developers > Cc: Simonis, Volker ; Adam Farley8 > > Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 > compiler > > Hi Volker, > > Do you think it would be possible to get the change you committed to JDK12 > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ > for this issue https://bugs.openjdk.java.net/browse/JDK-8214063 > back-ported to JDK11, as JDK11 is a LTS release and it woud be good to > have this fix? > > Also, we have received reports of other issues caused by the > -qvisibility=hidden > when using XLC 13.1 with JDK11 on AIX. > > One of these is related to : > > Desktop printer feature cannot detect by following exception. > Caused by: java.lang.UnsatisfiedLinkError: > sun/print/CUPSPrinter.initIDs()Z > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Hi Adam, Ichiroh, > > > > this is actually exactly what I wanted to propose in the mail I was > > just writing :) > > > > You may have noticed that I've renamed the bug to "8214063: [AIX] > > Disable symbol visibility flags". For the next step which will enable > > symbol visibility on AIX we already have the following issue "8204541: > > Correctly support AIX xlC 13.1 symbol visibility flags" [1]. Please > > assign yourself and use it once the issues are resolved. > > > > In the meantime I've tested your change and it works fine with xlC 12. > > I've only added a reference to the JBS id in the comments. Please find > > a webrev of the new version here: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ > > > > I can sponsor that change once you and Ichiroh confirm that it also > > works for you with xlC 13 and I get one more review. I've opened a new > > thread for this on build-dev because the fix has now degenerated into > > a pure build change: > > > > > http://mail.openjdk.java.net/pipermail/build-dev/2018- > November/024096.html > > > > Please answer on that new thread. > > > > Regards, > > Volker > > > > PS: I don't think it makes too much sense investing into xlC 13. > > You're probably aware of "JEP 347: Adopt C++14 Language Features in > > HotSpot" [2] which will start introducing C++14 language features > > soon. So it may be wiser to test right with the new beta of xlC 16 > > because, as far as I know, there's no chance to get C++124 support > > into xlC 13 anyway. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8204541 > > [2] http://openjdk.java.net/jeps/347 > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From takiguc at linux.vnet.ibm.com Wed Jan 23 12:21:15 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 23 Jan 2019 21:21:15 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <956e5876b1a32bff65931cd844cb86bd@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> <956e5876b1a32bff65931cd844cb86bd@linux.vnet.ibm.com> Message-ID: <37f449648632c0795f521ee70c2e52dc@linux.vnet.ibm.com> Hello. Could you review the fix and give your suggestion ? Thanks, Ichiroh Takiguchi On 2019-01-16 21:32, Ichiroh Takiguchi wrote: > Hello Alan and Roger. > > I appreciate your suggestions. > > Could you review the fix again ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.02/ > > I used "hg cp" command. > If I should use git format, please let me know. > > I changed Copyright year on IBM29626C.java.template and charsets file. > > Thanks, > Ichiroh Takiguchi > > On 2019-01-16 01:01, Roger Riggs wrote: >> Hi, >> >> I'd suggest using 2002, 2019, for the copyright, since much of the >> code in the new >> file comes from an older source. >> >> $.02, Roger >> >> >> On 01/15/2019 10:43 AM, Alan Bateman wrote: >>> On 15/01/2019 00:51, Ichiroh Takiguchi wrote: >>>> 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. >>> This looks okay, assuming it's `hg copy` of EUR_JP.template to create >>> IBM29626C.java.template rather than a `hg mv` (the webrev makes it >>> look like a move/rename). >>> >>> -Alan From sean.mullan at oracle.com Wed Jan 23 12:59:56 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Jan 2019 07:59:56 -0500 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> Message-ID: <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com> On 1/22/19 8:50 PM, Bernd Eckenfels wrote: > I don?t think the launcher is doing this, it is the class loader, that?s nothing new. You can turn on verbose security debug to see it in all versions. Yes, and it only verifies the signature(s) on the JAR. It doesn't validate the certificate chain. --Sean > > -- > https://Bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag von Robert Marcano > Gesendet: Mittwoch, Januar 23, 2019 2:18 AM > An: Alan Bateman > Cc: OpenJDK Dev list; core-libs-dev Libs > Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding > > On Tue, Jan 22, 2019, 5:53 AM Alan Bateman >> On 22/01/2019 4:48 am, Robert Marcano wrote: >>>> : >>>> >>>> So the question now is, why signed jars could affect the memory usage >>>> of an application (we aren't doing JAR verification on our custom >>>> launcher, yet), just by being on the java.class.path? IIRC the >>>> initial application classpath JARs were never verified previously (by >>>> the java launcher alone, without JNLP around). >>>> >>>> Note: Tested with JARs signed with a self signed certificate and with >>>> one signed with a private CA. At most, signing the JARs could slow >>>> down the start up if it is now expected to these being verified by >>>> the java launcher (is it true?) but not higher memory usage and no >>>> reductions after a GC cycle but constants heap size increases. >> Signed JARs can be expensive to verify, esp. on first usage as the >> verification is likely to result in early loading of a lot of security >> classes and infrastructure. If you can narrow down the apparently memory >> leak to a small test case with analysis to suggest it's a JDK bug then >> it would be good to get a bug submitted. >> >> -Alan > > > Greeting. Sure, I will work on a distributable reproduction of the problem > today but it is new to me that the java launcher do JARs verification now. > If it is doing it I doesn't make sense to me, because a self signed or > unrecognized CA doesn't trigger a validation error. > >> From jai.forums2013 at gmail.com Wed Jan 23 14:27:59 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 23 Jan 2019 19:57:59 +0530 Subject: Multi-release jar file - Should the "Multi-Release" mainfest attribute have a specific value? Message-ID: <20cef243-b352-ed97-9857-f771a5256ddc@gmail.com> Hi, The Multi-Release JarFile support JEP[1] notes that the jar file is expected to contain a main attribute: Multi-Release: true The JarFile javadoc[1] on the other hand makes no mention of the value for such an attribute and just mentions that the Multi-Release main attribute needs to be present: "A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release",..." Which one of these 2 docs is expected to be the formal specification? I'm guessing it's the javadoc, in which case, is it intentional that the value for this attribute isn't mentioned or is it just a miss? My quick tests show that the implementation of this feature does indeed expect the value to be a "true" for it to consider the versioned entries in a multi-release jar. [1] http://openjdk.java.net/jeps/238 [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/jar/JarFile.html -Jaikiran From Alan.Bateman at oracle.com Wed Jan 23 14:39:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 14:39:27 +0000 Subject: Multi-release jar file - Should the "Multi-Release" mainfest attribute have a specific value? In-Reply-To: <20cef243-b352-ed97-9857-f771a5256ddc@gmail.com> References: <20cef243-b352-ed97-9857-f771a5256ddc@gmail.com> Message-ID: <4d67719b-cbdd-0dbd-1787-9e72c48be967@oracle.com> On 23/01/2019 14:27, Jaikiran Pai wrote: > Hi, > > The Multi-Release JarFile support JEP[1] notes that the jar file is > expected to contain a main attribute: > > Multi-Release: true > > The JarFile javadoc[1] on the other hand makes no mention of the value > for such an attribute and just mentions that the Multi-Release main > attribute needs to be present: > > "A multi-release jar file is a jar file that contains a manifest with a > main attribute named "Multi-Release",..." > > Which one of these 2 docs is expected to be the formal specification? > I'm guessing it's the javadoc, in which case, is it intentional that the > value for this attribute isn't mentioned or is it just a miss? My quick > tests show that the implementation of this feature does indeed expect > the value to be a "true" for it to consider the versioned entries in a > multi-release jar. > The JAR file spec [1] is the specification. There's a lengthy section defining MR JARs. The API docs are also specification, for the APIs that provide access to JAR files, including MR JARs. So yes, you need the "Multi-Release" attribute in the main section of the JAR file manifest and it needs to have a value of "true" to enable. There is also a JDK-specific property, documented in the JarFile docs, to override the configuration where needed. -Alan [1] https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html From Roger.Riggs at oracle.com Wed Jan 23 14:53:39 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 23 Jan 2019 09:53:39 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> Message-ID: +1 to retaining and correcting the javadoc to match the implementation. Thanks, Roger On 01/22/2019 07:47 PM, Lance Andersen wrote: >> On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote: >> >> On 19/01/2019 12:46, Lance Andersen wrote: >>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>> @@ -265,9 +265,10 @@ >>> } >>> /** >>> - * Compares the specified Attributes object with this Map for equality. >>> - * Returns true if the given object is also an instance of Attributes >>> - * and the two Attributes objects represent the same mappings. >>> + * Compares the specified object with this Map for equality. >>> + * Returns true if the given object is also a Map >>> + * and the two objects represent the same Manifest >>> + * attribute name-value mappings. >>> >> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. > I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 > > If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc > > Best > Lance >> -Alan > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From thomas.stuefe at gmail.com Wed Jan 23 15:26:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 23 Jan 2019 16:26:51 +0100 Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler In-Reply-To: References: Message-ID: See also official downport documentation: http://openjdk.java.net/projects/jdk-updates/approval.html Cheers, Thomas On Wed, Jan 23, 2019 at 12:46 PM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Steve, > > feel free to request the downport of this change. > > For this, you must first check whether the change applies cleanly: > cd jdk/jdk; hg export -r 7384e00d5860 > 8215962.changeset (you find the > hash in the JBS) > cd jdk11u; hg import 8215962.changeset > > If so, you flag the bug in JBS as jdk11u-fix-request and add a > comment to the bug why you want to downport this. The comment > must start with "Fix Request". > See for an example > https://bugs.openjdk.java.net/browse/JDK-8215962 > > You will get a message once the downport is approved. > Ping me and I will push the change for you. > > If the change does not apply cleanly, you must send a RFR > with the adapted webrev to the list where the change was > originally reviewed. > You must add a link to the RFR in pipermail to the comment > in the bug. > See for example: > https://bugs.openjdk.java.net/browse/JDK-8213754 > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: core-libs-dev On Behalf > Of > > Steve Groeger > > Sent: Mittwoch, 23. Januar 2019 12:18 > > To: OpenJDK Core Libs Developers > > Cc: Simonis, Volker ; Adam Farley8 > > > > Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc > 13.1 > > compiler > > > > Hi Volker, > > > > Do you think it would be possible to get the change you committed to > JDK12 > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ > > for this issue https://bugs.openjdk.java.net/browse/JDK-8214063 > > back-ported to JDK11, as JDK11 is a LTS release and it woud be good to > > have this fix? > > > > Also, we have received reports of other issues caused by the > > -qvisibility=hidden > > when using XLC 13.1 with JDK11 on AIX. > > > > One of these is related to : > > > > Desktop printer feature cannot detect by following exception. > > Caused by: java.lang.UnsatisfiedLinkError: > > sun/print/CUPSPrinter.initIDs()Z > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > > Hi Adam, Ichiroh, > > > > > > this is actually exactly what I wanted to propose in the mail I was > > > just writing :) > > > > > > You may have noticed that I've renamed the bug to "8214063: [AIX] > > > Disable symbol visibility flags". For the next step which will enable > > > symbol visibility on AIX we already have the following issue "8204541: > > > Correctly support AIX xlC 13.1 symbol visibility flags" [1]. Please > > > assign yourself and use it once the issues are resolved. > > > > > > In the meantime I've tested your change and it works fine with xlC 12. > > > I've only added a reference to the JBS id in the comments. Please find > > > a webrev of the new version here: > > > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ > > > > > > I can sponsor that change once you and Ichiroh confirm that it also > > > works for you with xlC 13 and I get one more review. I've opened a new > > > thread for this on build-dev because the fix has now degenerated into > > > a pure build change: > > > > > > > > http://mail.openjdk.java.net/pipermail/build-dev/2018- > > November/024096.html > > > > > > Please answer on that new thread. > > > > > > Regards, > > > Volker > > > > > > PS: I don't think it makes too much sense investing into xlC 13. > > > You're probably aware of "JEP 347: Adopt C++14 Language Features in > > > HotSpot" [2] which will start introducing C++14 language features > > > soon. So it may be wiser to test right with the new beta of xlC 16 > > > because, as far as I know, there's no chance to get C++124 support > > > into xlC 13 anyway. > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8204541 > > > [2] http://openjdk.java.net/jeps/347 > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > From gunter.haug at sap.com Wed Jan 23 15:59:45 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Wed, 23 Jan 2019 15:59:45 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> Hi Alan, David Here are the results of the measurements. As mentioned before, I had measured some of the standard Java benchmarks and there was no impact. This is probably not surprising to anybody as the overhead up-calls is minuscule in comparison to the calculations that take place and is far below the noise level. A benchmark that is most prone to show the impact the up-calls would do fast (short) IO operations. The fastest operations I could think of were writing to /dev/null and reading from /dev/zero on Linux or macOS. I wrote benchmarks which write/read just one byte one million times in a loop using the jmh framework (https://openjdk.java.net/projects/code-tools/jmh/). The results measured on my mac were all over the place and I moved to a otherwise empty Linux host. Results were more stable there. jmh runs the benchmark multiple times for each invocation and calculates an error within one invocation. It turned out that invocations which had a large error showed poorer performance, obviously because something happened on the host in parallel what degraded performance. I invoked the benchmarks multiple times and decided to discard measurements with an error of more than 0.01. This value is rather random but it was achieved by about one out of four invocations and I think we can get rid of the outliers. It turned out that even with this setup the impact of the up-call is below noise level. In fact, the write benchmark was faster with the up-calls what is not plausible, of course. The read benchmark showed the best and the poorest performance without the up-calls while the results for a JDK with the up-calls (see below for the actual results). As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. @Thomas, thanks for your input! I think all your suggestions are well funded. I'll reply in more detail if/when we can alleviate the more general concerns. Best regards, Gunter Write without up-call Mode Cnt Score Error Units thrpt 25 1.867 0.005 ops/s thrpt 25 1.866 0.006 ops/s thrpt 25 1.865 0.004 ops/s thrpt 25 1.860 0.010 ops/s Write with up-call Mode Cnt Score Error Units thrpt 25 1.880 0.010 ops/s thrpt 25 1.884 0.007 ops/s thrpt 25 1.887 0.004 ops/s thrpt 25 1.879 0.010 ops/s Read without up-calls Mode Cnt Score Error Units thrpt 25 2.145 0.008 ops/s thrpt 25 2.145 0.010 ops/s thrpt 25 2.129 0.010 ops/s thrpt 25 2.122 0.009 ops/s Read with up-calls Mode Cnt Score Error Units thrpt 25 2.136 0.007 ops/s thrpt 25 2.132 0.003 ops/s thrpt 25 2.130 0.006 ops/s thrpt 25 2.129 0.009 ops/s ?On 17.01.19, 18:31, "Volker Simonis" wrote: On Thu, Jan 17, 2019 at 1:31 PM Alan Bateman wrote: > > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > > > Do you object against keeping these counters (which basically boils > > down to Thread::current->stat_structure->counter++)? Or do you even > > object against making upcalls into the jvm? Note that, if deemed > > necessary, we could omit updating the counters unless JFR or our > > extended thread dumps are activated (which are the consumers of the > > counters). > > > > In any case, I would have assumed the costs for upcall + counter > > update to be insignificant compared to the IO calls. We should of > > course measure that. > > > > If you generally object upcalls into the libjvm for > > statistical/monitoring reasons, this would make matters on a number of > > fronts more complicated. For instance, it was discussed extending NMT > > coverage to the JDK - which is already in part reality at > > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > > > There are many issues here that will need write-up and discussion, maybe > a JEP if discussions converge on a proposal to bring into the main line > as this is a significant change with implications for many areas of the > platform. We could certainly create a new JEP for this feature, but in the end it is rather trivial. In fact it can be expressed in a single sentence: instrument all native IO functions to collect the number of read and written bytes. As stated before, the overhead is minimal (Gunter will provide some concrete benchmarks soon) and could even be dropped to ~zero if you really insist on this (e.g. by wrapping all calls by a switch which is based on a system property). But honestly speaking we don't think this is really necessary. I want to stress the fact that this is not a wacky idea Gunter came up with but a feature which we're using for almost 10 years in our SAP JVM. It is running in all our enterprise scenarios without ever having caused any problems. > It also potentially conflicts in direction with some of the > other projects in progress (particularly with Loom trying to re-imagine > threads, do you really want to collect I/O stats on a per thread basis > in the future???). > Who knows about the future, our trace is quite useful today :) You're right that this may change when Loom becomes available and I think we've faced similar problems when people started using ThreadPools more heavily. We've mitigated this with another SAP JVM specific feature (which we havn't contributed yet) that we've called "Thread Annotations". They could be set from user code and our profiler could then split the collected statistics based on these annotations even if they were all collected for the same native thread. I image we can come up with similar solutions for project Loom in the future, once it becomes available. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go > away or change significantly in the future. But that's actually nice! That will eventually shrink the code proposed by this change to a few places and make the costs of supporting it even smaller. And needless to say that SAP is committed to support and maintain this feature once it gets integrated. > We've been on that path for > some time, e.g. the zip area or the prototype to replace the SocketImpl > used for classic networking that eliminates a lot of the native code > touched in that area by the webrev. Once Panama is further along then I > assume we will want to make use of it in the core libraries and at least > initially replace the JNI methods that just wrap syscalls today, and > longer term more significant refactoring. Again, I think this will make our implementation simpler because we would have to instrument fewer places. > My point is that instrumenting > native methods may not be the right approach, instead maybe we should be > look at instrumenting the I/O paths at the java level as that will > likely play better with the VM. We gathered some experience with Java-level instrumentation during the last years (e.g. Dynatrace, Wiley, etc) and it has not always been positive :) The overhead is certainly higher compared to the native instrumentation at C-level. And it can influence especially JIT optimizations in an unpredictable way. Finally the Java instrumentation is version dependent and puts the burden on instrumenting the "right" places (end especially catching all the right places) on the developer / support engineer. You could of course upload this overhead into another, external project like JFR, but supporting that doesn't come for free either. > There is some support for collecting I/O > stats in JFR today and maybe someone working in that area can explain > that a bit more and what the issues are. > As far as I understand, the corresponding JFR events only sample the time spent in the instrumented calls while we do an exact IO statistics with regard to the bytes read and written. > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. As I wrote before, this is a solution we're using successfully since many years. We're convinced that is is superior to Java-level instrumentation with regards to both, overhead as well as maintainability. > > -Alan From adam.farley at uk.ibm.com Wed Jan 23 16:33:00 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 23 Jan 2019 16:33:00 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Mandy, Food for thought: - From John's email, it looked like he was advocating a clarification change to the spec (which requires no CSR). - A test case is attached to the bug. It displays "current behaviour", but doesn't show a clear "pass" or "fail", because at the start of this there appeared to be disagreement over what the correct behaviour was. - Good idea on the new line. I'll add it to the webrev shortly. - As for the comments, I think I see what John was going for, but I don't understand his first change. This seems to be the opposite of what we're trying for here. + * In the case of a field setter function on a {@code final} field, + * finality enforcement is treated as a kind of access control, + * and the lookup will fail, except in special cases of + * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. Perhaps he means it will still fail, but for the reasons we've discussed rather than anything connected to access control? Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 16/01/2019 23:52:03: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 16/01/2019 23:54 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > On 1/14/19 9:10 AM, Adam Farley8 wrote: > As for the CSR process, I'm unfamiliar with it. I've modified the > comment for the unreflectSetter method in the webrev. Do let me know if > more needs to be done. > > The CSR process is straight-forward. CSR FAQ [1] may help you get started. > > As for the fix, John has suggested the spec wording for this issue. > It's fine with the unreflectField method to have the explicit check > and throw field.makeAccessException(...). The exception message > could match the proposed spec wording like: > if(isSetter && field.isStatic() && field.isFinal()) > throw field.makeAccessException("static final field has no > write access", this); > > You have a very long line and the throw statement can start in the > next line. > > In addition, please include a test case for this change. > > Thanks > Mandy > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Wed Jan 23 16:43:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 16:43:33 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> Message-ID: <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> On 23/01/2019 15:59, Haug, Gunter wrote: > : > > As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. > There are concerns with the approach and patch. The replies from David hint that he also has concerns. I think it would be useful to start out with a summary of what the app server is looking to do with these stats. I think we need to understand if collecting by thread is really the right way to do this as it may not be the right approach in the long term. The granularity is also important as you've instrumented a bunch of places that are surprising as they aren't regular file or socket I/O. I think it's important to understand what prototypes were done with instrumentation at the java level rather than in the native methods. This goes to the maintenance concern. There were suggestions of performance issues but it's not clear if those experiments were recent or from 10 years ago. For the libraries area then we really should be reducing the native code for maintenance and debugging reasons, maybe performance reasons too once we can start to make use of Panama. Finally I think it's important to see how this fits with the instrumentation that JFR and other potential instrumentation of the libraries going forward (native method tracking was mentioned). So overall I think there is a lot to discuss and write-up. -Alan From naoto.sato at oracle.com Wed Jan 23 17:01:13 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 23 Jan 2019 09:01:13 -0800 Subject: RFR 8217339: ClassCircularityError loading NumberFormatProvider In-Reply-To: <1b4d289c-d780-772c-713a-4bceac511af6@oracle.com> References: <96e568f1-1e2e-b16d-f7c1-58c31f39e941@oracle.com> <15083385-2751-8d37-d4b6-88df6e79df43@oracle.com> <45f66484-0c94-f7f5-50ba-b4874c2170ca@oracle.com> <1b4d289c-d780-772c-713a-4bceac511af6@oracle.com> Message-ID: <481165c5-1e05-d2a7-5cd6-f3ebe418714d@oracle.com> +1 Naoto On 1/22/19 3:25 PM, Mandy Chung wrote: > > > On 1/22/19 2:25 PM, Roger Riggs wrote: >> Hi Mandy, >> >> Updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/ >> >> > > Looks good. >>> >>>> Other changes look good. >>>> >>>> BTW, >>>> >>>> > I have not found a reproducer for jdk 12, it only occurs on new >>>> work for >>>> > jdk 13. >>>> >>>> Is this new code in 13? l10n causes this type of circularity >>>> exception during the VM boot up. >>>> >>> >>> I also want to understand what changes in 13 causes the difference. >> I was prototyping some more properties ideas. >> I suspect that in the previous init sequence, the Locale had been cached. >> A closed test had failed, in part because it had changed the default >> locale >> and then installed a security manager. > > I see how ConstantDesc gets initialized during initialization of > VarHandle from > your stack trace.? I can't reproduce it and so I assume it was triggered > by your > local change.? In any case, converting String.format to string concat is > fine. > > I am sure Claes may look at the startup and class initialization if we > can avoid > loading VarHandleDesc from clinit. > > Mandy > From naoto.sato at oracle.com Wed Jan 23 17:47:48 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 23 Jan 2019 09:47:48 -0800 Subject: [13] RFR: 8217366: ZoneStrings are not populated for all the Locales Message-ID: <64a323dc-c8ee-5a2a-03e7-7255d684b639@oracle.com> Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8217366 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8217366/webrev.00/ The gist of the issue is that CLDR's "no inheritance marker" slipped into the final zone strings array, which should be converted to GMT format. Naoto From mandy.chung at oracle.com Wed Jan 23 19:18:09 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Jan 2019 11:18:09 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: <3a218c0c-e02d-3e3e-317f-8572e56e81ea@oracle.com> Hi Adam, On 1/23/19 8:33 AM, Adam Farley8 wrote: > Hi Mandy, > > Food for thought: > > - From John's email, it looked like he was advocating a clarification > change to the spec (which requires no CSR). > While the new behavior was intended when the spec was written, this fix changes the current behavior and a CSR will be needed to document the incompatible change.? The current behavior of unreflectSetter may return a MethodHandle of a static final Field object with accessible flag set and then invoke MH to change the static final field value.? The new behavior of unreflectSetter throws IAE as static final FIeld does not have write access. - * @throws IllegalAccessException if access checking fails + * @throws IllegalAccessException if access checking fails, + * or if the field is {@code final} and write access + * is not enabled on the {@code Field} object > - A test case is attached to the bug. It displays "current behaviour", > but doesn't show a clear "pass" or "fail", because at the start of > this there appeared to be disagreement over what the correct behaviour > was. > > - Good idea on the new line. I'll add it to the webrev shortly. > > - As for the comments, I think I see what John was going for, but I > don't understand his first change. This seems to be the opposite of > what we're trying for here. > > + ? ? * In the case of a field setter function on a {@code final} field, > + ? ? * finality enforcement is treated as a kind of access control, > + ? ? * and the lookup will fail, except in special cases of > + ? ? * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. > > Perhaps he means it will still fail, but for the reasons we've > discussed rather than anything connected to access control? > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8216558/webrev.01/ This webrev showing @throws change should show the spec clarification on findSetter and findStaticSetter that throws IAE when looking up a setter on a final field and the spec of unreflectSetter states that it will return a method handle only if the corresponding call to Field::set returns normally.??? This webrev is not a review request but rather showing the fix we are discussing here. Hope this clarifies it. Mandy From jpstotz at gmx.de Wed Jan 23 20:05:11 2019 From: jpstotz at gmx.de (Jan Peter Stotz) Date: Wed, 23 Jan 2019 21:05:11 +0100 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours Message-ID: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> Hi, like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And there are hundred of developers hitting this bug every year. I simply don't understand why there was no progress in 8 years, on a severe performance issue (a removeAll method on an efficient set that can require O(n^2)!) caused by code that was written to speed-up the removeAll implementation. Which makes this bug worse is that it is triggered by the relative size of the current set compared to the collection passed as parameter. Therefore for most developers this means not to use this buggy function at all (once they realized how worse it is). IMHO there is a extreme simple workaround for avoiding this problem. The relevant part of the current implementation is as follows: if (size() > c.size()) { for (Object e : c) modified |= remove(e); } else { for (Iterator i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } The problem is that the code in the first if block only makes sense if the collections passed as parameter implements the remove(Object o) method in an efficient way - this means with a complexity of less than O(n). Java currently has no way to identify Collection implementations that satisfy this property we should at least implement a workaround that prevents the Java developers form unexpected "damage". Which mean that the first if block should only be triggered if we are sure that it is faster than the second case (because removing an element from a Set is usually implemented efficiently). Therefore I would propose a patch that no only compare the size of the current set and the given collection but also makes sure that the given collection is a Set or a Map: if (size() > c.size() && (c instanceof Set || c instanceof Map) { for (Object e : c) modified |= remove(e); } else { .... Jan From Roger.Riggs at oracle.com Wed Jan 23 20:17:26 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 23 Jan 2019 15:17:26 -0500 Subject: [13] RFR: 8217366: ZoneStrings are not populated for all the Locales In-Reply-To: <64a323dc-c8ee-5a2a-03e7-7255d684b639@oracle.com> References: <64a323dc-c8ee-5a2a-03e7-7255d684b639@oracle.com> Message-ID: Hi Naoto, Looks fine to me. Roger On 01/23/2019 12:47 PM, Naoto Sato wrote: > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8217366 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8217366/webrev.00/ > > The gist of the issue is that CLDR's "no inheritance marker" slipped > into the final zone strings array, which should be converted to GMT > format. > > Naoto From Roger.Riggs at oracle.com Wed Jan 23 20:25:09 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 23 Jan 2019 15:25:09 -0500 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <37f449648632c0795f521ee70c2e52dc@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> <956e5876b1a32bff65931cd844cb86bd@linux.vnet.ibm.com> <37f449648632c0795f521ee70c2e52dc@linux.vnet.ibm.com> Message-ID: <09a6cb9d-cded-17ce-c701-3ed30d148e61@oracle.com> Hi Ichiroh, Sorry for the delay, yes, the change looks fine. I'll sponsor, and push it tomorrow. Thanks, Roger On 01/23/2019 07:21 AM, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix and give your suggestion ? > Thanks, > Ichiroh Takiguchi > > On 2019-01-16 21:32, Ichiroh Takiguchi wrote: >> Hello Alan and Roger. >> >> I appreciate your suggestions. >> >> Could you review the fix again ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214533 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.02/ >> >> I used "hg cp" command. >> If I should use git format, please let me know. >> >> I changed Copyright year on IBM29626C.java.template and charsets file. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-01-16 01:01, Roger Riggs wrote: >>> Hi, >>> >>> I'd suggest using 2002, 2019, for the copyright, since much of the >>> code in the new >>> file comes from an older source. >>> >>> $.02, Roger >>> >>> >>> On 01/15/2019 10:43 AM, Alan Bateman wrote: >>>> On 15/01/2019 00:51, Ichiroh Takiguchi wrote: >>>>> 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. >>>> This looks okay, assuming it's `hg copy` of EUR_JP.template to >>>> create IBM29626C.java.template rather than a `hg mv` (the webrev >>>> makes it look like a move/rename). >>>> >>>> -Alan > From federico.peralta at gmail.com Wed Jan 23 21:02:41 2019 From: federico.peralta at gmail.com (Federico Peralta Schaffner) Date: Wed, 23 Jan 2019 18:02:41 -0300 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> Message-ID: Hi Jan, I'm amazed to see this performance problem has persisted for so long. As a Java developer, I wasn't even aware of it, so thanks for the information. > > The relevant part of the current implementation is as follows: > > if (size() > c.size()) { > for (Object e : c) > modified |= remove(e); > } else { > for (Iterator i = iterator(); i.hasNext(); ) { > if (c.contains(i.next())) { > i.remove(); > modified = true; > } > } > } > > The problem is that the code in the first if block only makes sense if > the collections passed as parameter implements the remove(Object o) > method in an efficient way - this means with a complexity of less than > O(n). Now, how have you come to the conclusion that the problem is in the first branch of the above if statement, and that it is related to the passed collection's implementation details of the remove(Object o) method? I think this is not the problem, as elements are removed from this set and not from the passed collection. In fact, the problem is in the else branch (when this set is smaller than the passed collection). The problem is in the following line: if (c.contains(i.next())) { That c.contains(...) might not be implemented in an optimized way, i.e. c might be an ArrayList, which uses a linear search to check if the element belongs to it. > Java currently has no way to identify Collection implementations that > satisfy this property (...) Yes, you are correct. While there exists the RandomAccess marker interface for List implementations, there is no analogous marker interface for neither Set nor Map implementations that use hashing, i.e. something that could have been named "HashAccess". So I wonder and if the members of this group find it plausible to add such HashAccess marker interface to HashSet and HashMap (and to any other implementations that use hashing). If (as I suspect) introducing further marker interfaces is not desirable (or has been tacitly forbidden), then what alternatives are available and would be a good fit here? For the record, if the HashAccess marker interface had ever existed, the implementation could have been changed to: if (size() > c.size()) { for (Object e : c) modified |= remove(e); } else { Collection cc = c instanceof HashAccess ? c : new HashSet<>(c); for (Iterator i = iterator(); i.hasNext(); ) { if (cc.contains(i.next())) { i.remove(); modified = true; } } } This way, the contains invocation in `if (cc.contains(i.next())) {` would have been optimized. Thanks, fps.- From jai.forums2013 at gmail.com Thu Jan 24 03:12:59 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 24 Jan 2019 08:42:59 +0530 Subject: Multi-release jar file - Should the "Multi-Release" mainfest attribute have a specific value? In-Reply-To: <4d67719b-cbdd-0dbd-1787-9e72c48be967@oracle.com> References: <20cef243-b352-ed97-9857-f771a5256ddc@gmail.com> <4d67719b-cbdd-0dbd-1787-9e72c48be967@oracle.com> Message-ID: <74caae61-eda9-d476-0979-385821c74dc6@gmail.com> Thank you Alan. -Jaikiran On 23/01/19 8:09 PM, Alan Bateman wrote: > On 23/01/2019 14:27, Jaikiran Pai wrote: >> Hi, >> >> The Multi-Release JarFile support JEP[1] notes that the jar file is >> expected to contain a main attribute: >> >> Multi-Release: true >> >> The JarFile javadoc[1] on the other hand makes no mention of the value >> for such an attribute and just mentions that the Multi-Release main >> attribute needs to be present: >> >> "A multi-release jar file is a jar file that contains a manifest with a >> main attribute named "Multi-Release",..." >> >> Which one of these 2 docs is expected to be the formal specification? >> I'm guessing it's the javadoc, in which case, is it intentional that the >> value for this attribute isn't mentioned or is it just a miss? My quick >> tests show that the implementation of this feature does indeed expect >> the value to be a "true" for it to consider the versioned entries in a >> multi-release jar. >> > The JAR file spec [1] is the specification. There's a lengthy section > defining MR JARs. The API docs are also specification, for the APIs > that provide access to JAR files, including MR JARs. So yes, you need > the "Multi-Release" attribute in the main section of the JAR file > manifest and it needs to have a value of "true" to enable. There is > also a JDK-specific property, documented in the JarFile docs, to > override the configuration where needed. > > -Alan > > [1] https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html From GROEGES at uk.ibm.com Thu Jan 24 08:35:44 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 24 Jan 2019 08:35:44 +0000 Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler In-Reply-To: References: Message-ID: Goetz, Have requested the downport of this fix which has been accepted (issue is now tagged with jdk11u-fix-yes). Please could you push this change to the jdk11u branch. Thanks. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Lindenmaier, Goetz" To: Steve Groeger , OpenJDK Core Libs Developers Cc: "Simonis, Volker" , Adam Farley8 Date: 23/01/2019 11:46 Subject: RE: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler Hi Steve, feel free to request the downport of this change. For this, you must first check whether the change applies cleanly: cd jdk/jdk; hg export -r 7384e00d5860 > 8215962.changeset (you find the hash in the JBS) cd jdk11u; hg import 8215962.changeset If so, you flag the bug in JBS as jdk11u-fix-request and add a comment to the bug why you want to downport this. The comment must start with "Fix Request". See for an example https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215962&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=9-CVL_WPMw-8-7_7jjjpNPMK22Y6Qd9_YsAFz2HCEEw&e= You will get a message once the downport is approved. Ping me and I will push the change for you. If the change does not apply cleanly, you must send a RFR with the adapted webrev to the list where the change was originally reviewed. You must add a link to the RFR in pipermail to the comment in the bug. See for example: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=vEN6XbBHoycBpLGk5K9BC83O2bRYbkjQWQE9FLSQFTI&e= Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Steve Groeger > Sent: Mittwoch, 23. Januar 2019 12:18 > To: OpenJDK Core Libs Developers > Cc: Simonis, Volker ; Adam Farley8 > > Subject: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 > compiler > > Hi Volker, > > Do you think it would be possible to get the change you committed to JDK12 > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=yvtwAfUqwwFwsa2PvD-S647mjYjIy7kGIiJvJJQLePU&e= > for this issue https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8214063&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=9GpEP_EpssbR6bk6A4Pm1djpu0aCo0nWGyRyaeAlBQg&e= > back-ported to JDK11, as JDK11 is a LTS release and it woud be good to > have this fix? > > Also, we have received reports of other issues caused by the > -qvisibility=hidden > when using XLC 13.1 with JDK11 on AIX. > > One of these is related to : > > Desktop printer feature cannot detect by following exception. > Caused by: java.lang.UnsatisfiedLinkError: > sun/print/CUPSPrinter.initIDs()Z > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Hi Adam, Ichiroh, > > > > this is actually exactly what I wanted to propose in the mail I was > > just writing :) > > > > You may have noticed that I've renamed the bug to "8214063: [AIX] > > Disable symbol visibility flags". For the next step which will enable > > symbol visibility on AIX we already have the following issue "8204541: > > Correctly support AIX xlC 13.1 symbol visibility flags" [1]. Please > > assign yourself and use it once the issues are resolved. > > > > In the meantime I've tested your change and it works fine with xlC 12. > > I've only added a reference to the JBS id in the comments. Please find > > a webrev of the new version here: > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=yvtwAfUqwwFwsa2PvD-S647mjYjIy7kGIiJvJJQLePU&e= > > > > I can sponsor that change once you and Ichiroh confirm that it also > > works for you with xlC 13 and I get one more review. I've opened a new > > thread for this on build-dev because the fix has now degenerated into > > a pure build change: > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_build-2Ddev_2018-2D&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=SYyXZkfheBq4KITNmsyba0_TL_lls6gNY2b40NJWiqY&e= > November/024096.html > > > > Please answer on that new thread. > > > > Regards, > > Volker > > > > PS: I don't think it makes too much sense investing into xlC 13. > > You're probably aware of "JEP 347: Adopt C++14 Language Features in > > HotSpot" [2] which will start introducing C++14 language features > > soon. So it may be wiser to test right with the new beta of xlC 16 > > because, as far as I know, there's no chance to get C++124 support > > into xlC 13 anyway. > > > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8204541&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=Zw_o0FP51SSpASE9yASOhy82mLi1MWf17QNxiH2xN2I&e= > > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_347&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=TVzux2_9BUtfhp4VHu8rYT4eL4VpbEVBxrFE7Cyv5B8&s=Gh2aK6Y0BFJiLwzEf0x6fQ2LEtEppNnV2PGzIagsD-g&e= > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From daniel.fuchs at oracle.com Thu Jan 24 11:42:22 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Jan 2019 11:42:22 +0000 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference Message-ID: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Hi, Please find below a fix for: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference https://bugs.openjdk.java.net/browse/JDK-8217353 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ This test has been seen failing from time to time with an exception originating from the finally { } clause of the main method. The suspicion is that this exception in fact hides another exception previously thrown in the try { } body. This is only a fix in so far that it will ensure that the real exception - if any - is added to the suppressed list of the secondary exception so that we eventually see it in the log. As to why the test failed in the first place - I am not quite sure, but it might be due to -Xcomp or some other combination of options preventing the WeakReference to be cleared within the time (and number of gc() calls) expected by the test (the test has never been seen failing without these combinations). best regards, -- daniel From Alan.Bateman at oracle.com Thu Jan 24 12:04:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Jan 2019 12:04:22 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> Message-ID: <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> On 23/01/2019 08:29, Baesken, Matthias wrote: > Hello Alan, here is a second webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/ > > I moved the Windows-only code into a new file > > src/java.base/windows/native/libjli/parse_manifest_md.c > Did you consider adding a Unix version of open_jarfile to avoid #ifdef WIN32 ? On the Windows version then your patch is low risk but the retrying after ENOENT is a bit icky. I'm just wondering if you've considered creating an absolute path and adding the prefix when the length is 247 or greater. I also wonder about the share mode specified to CreateFileW where it might be better to specify FILE_SHARE_READ at least so that you don't exclude other processes from also opening the file to read. -Alan From lance.andersen at oracle.com Thu Jan 24 12:14:23 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 07:14:23 -0500 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: Morning Daniel, The change seems like a good approach Best Lance > On Jan 24, 2019, at 6:42 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java > fails with Unexpected reference: java.lang.ref.WeakReference > https://bugs.openjdk.java.net/browse/JDK-8217353 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ > > This test has been seen failing from time to time with an > exception originating from the finally { } clause of the > main method. The suspicion is that this exception in fact > hides another exception previously thrown in the try { } > body. > > This is only a fix in so far that it will ensure that the > real exception - if any - is added to the suppressed list > of the secondary exception so that we eventually see it in > the log. > > As to why the test failed in the first place - I am not quite > sure, but it might be due to -Xcomp or some other combination > of options preventing the WeakReference to be cleared within > the time (and number of gc() calls) expected by the test > (the test has never been seen failing without these combinations). > > best regards, > > -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Thu Jan 24 12:20:11 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Jan 2019 12:20:11 +0000 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: Thanks Lance. Meanwhile I noticed that the first loop calling gc() used a sleep(100) - which is probably not enough in those greedy configurations - so I extended that to 1000. (webrev updated in place). http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ Hopefully that will reduce the frequency of failures. Re testing in progress... best regards, -- daniel On 24/01/2019 12:14, Lance Andersen wrote: > Morning Daniel, > > The change seems like a good approach > > Best > Lance >> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs > > wrote: >> >> Hi, >> >> Please find below a fix for: >> >> 8217353: >> java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java >> >> ?????????fails with Unexpected reference: java.lang.ref.WeakReference >> https://bugs.openjdk.java.net/browse/JDK-8217353 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >> >> This test has been seen failing from time to time with an >> exception originating from the finally { } clause of the >> main method. The suspicion is that this exception in fact >> hides another exception previously thrown in the try { } >> body. >> >> This is only a fix in so far that it will ensure that the >> real exception - if any - is added to the suppressed list >> of the secondary exception so that we eventually see it in >> the log. >> >> As to why the test failed in the first place - I am not quite >> sure, but it might be due to -Xcomp or some other combination >> of options preventing the WeakReference to be cleared within >> the time (and number of gc() calls) expected by the test >> (the test has never been seen failing without these combinations). >> >> best regards, >> >> -- daniel > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Jan 24 12:39:36 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 07:39:36 -0500 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: <45E170CA-215C-48A3-80ED-6AAEE460E088@oracle.com> Looking good still Daniel :-) > On Jan 24, 2019, at 7:20 AM, Daniel Fuchs wrote: > > Thanks Lance. > > Meanwhile I noticed that the first loop calling gc() used > a sleep(100) - which is probably not enough in those > greedy configurations - so I extended that to 1000. > (webrev updated in place). > http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ > > Hopefully that will reduce the frequency of failures. > Re testing in progress... > > best regards, > > -- daniel > > On 24/01/2019 12:14, Lance Andersen wrote: >> Morning Daniel, >> The change seems like a good approach >> Best >> Lance >>> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs > wrote: >>> >>> Hi, >>> >>> Please find below a fix for: >>> >>> 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java >>> fails with Unexpected reference: java.lang.ref.WeakReference >>> https://bugs.openjdk.java.net/browse/JDK-8217353 >>> >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >>> >>> This test has been seen failing from time to time with an >>> exception originating from the finally { } clause of the >>> main method. The suspicion is that this exception in fact >>> hides another exception previously thrown in the try { } >>> body. >>> >>> This is only a fix in so far that it will ensure that the >>> real exception - if any - is added to the suppressed list >>> of the secondary exception so that we eventually see it in >>> the log. >>> >>> As to why the test failed in the first place - I am not quite >>> sure, but it might be due to -Xcomp or some other combination >>> of options preventing the WeakReference to be cleared within >>> the time (and number of gc() calls) expected by the test >>> (the test has never been seen failing without these combinations). >>> >>> best regards, >>> >>> -- daniel >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From robert at marcanoonline.com Thu Jan 24 13:25:49 2019 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 24 Jan 2019 09:25:49 -0400 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com> References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com> Message-ID: On 1/23/19 8:59 AM, Sean Mullan wrote: > On 1/22/19 8:50 PM, Bernd Eckenfels wrote: >> I don?t think the launcher is doing this, it is the class loader, >> that?s nothing new. You can turn on verbose security debug to see it >> in all versions. > > Yes, and it only verifies the signature(s) on the JAR. It doesn't > validate the certificate chain. > > --Sean I noticed that trying to identify the higher memory usage after what looks like a big application is loaded. I am doing memory profiling and notice JarFile taking more memory that on Java 8. Still need to detect the real cause for an independent test case. We probably didn't notice this slowdown before because Oracle's JNLP implementation was slow enough at startup. IMHO the class library should not do doing signature checks without certificate validation, because it doesn't give any protection if the signature is not verified, the only thing it could do now is to detect some random bit flips, that maybe the Zip format CRC detect before that. With no certificate verification the signature could be replaced by anybody with bad intentions. Maybe adding a constructor flag to URLClassloader to pass to JarFile to skip verification and a system property to tell the Java startup code to skip verification of java.class.path (just for compatibility with old code that expect it to be done). There is precedent of other runtimes that added options to disable this, like CLR [1] (Ii not only verified signatures, It do CRL/OSCP checks too) Our new launcher replacing JNLP now do signature verification in native code, at download time, and install on a system area (not user home directory), so signature verification at application launch is a slowdown we want to avoid, but think on another kind of users, those deploying to OS Stores (for example Windows Store), why add the slowdown of verification when the application is verified by the store client at install time?, this could help these situations too. Note: This can be avoided removing the signatures of all JARs if you distribute to an OS store, there are a few libraries that distribute their JARs signed (The old Java Help framework comes to my mind right now) [1] https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ > >> >> -- >> https://Bernd.eckenfels.net >> >> ________________________________ >> Von: core-libs-dev im Auftrag >> von Robert Marcano >> Gesendet: Mittwoch, Januar 23, 2019 2:18 AM >> An: Alan Bateman >> Cc: OpenJDK Dev list; core-libs-dev Libs >> Betreff: Re: High memory usage / leaks was: Best mailing list for JVM >> embedding >> >> On Tue, Jan 22, 2019, 5:53 AM Alan Bateman > wrote: >> >>> On 22/01/2019 4:48 am, Robert Marcano wrote: >>>>> : >>>>> >>>>> So the question now is, why signed jars could affect the memory usage >>>>> of an application (we aren't doing JAR verification on our custom >>>>> launcher, yet), just by being on the java.class.path? IIRC the >>>>> initial application classpath JARs were never verified previously (by >>>>> the java launcher alone, without JNLP around). >>>>> >>>>> Note: Tested with JARs signed with a self signed certificate and with >>>>> one signed with a private CA. At most, signing the JARs could slow >>>>> down the start up if it is now expected to these being verified by >>>>> the java launcher (is it true?) but not higher memory usage and no >>>>> reductions after a GC cycle but constants heap size increases. >>> Signed JARs can be expensive to verify, esp. on first usage as the >>> verification is likely to result in early loading of a lot of security >>> classes and infrastructure. If you can narrow down the apparently memory >>> leak to a small test case with analysis to suggest it's a JDK bug then >>> it would be good to get a bug submitted. >>> >>> -Alan >> >> >> Greeting. Sure, I will work on a distributable reproduction of the >> problem >> today but it is new to me that the java launcher do JARs verification >> now. >> If it is doing it I doesn't make sense to me, because a self signed or >> unrecognized CA doesn't trigger a validation error. >> >>> From sean.mullan at oracle.com Thu Jan 24 15:05:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2019 10:05:47 -0500 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com> Message-ID: On 1/24/19 8:25 AM, Robert Marcano wrote: > On 1/23/19 8:59 AM, Sean Mullan wrote: >> On 1/22/19 8:50 PM, Bernd Eckenfels wrote: >>> I don?t think the launcher is doing this, it is the class loader, >>> that?s nothing new. You can turn on verbose security debug to see it >>> in all versions. >> >> Yes, and it only verifies the signature(s) on the JAR. It doesn't >> validate the certificate chain. >> >> --Sean > > I noticed that trying to identify the higher memory usage after what > looks like a big application is loaded. I am doing memory profiling and > notice JarFile taking more memory that on Java 8. Still need to detect > the real cause for an independent test case. We probably didn't notice > this slowdown before because Oracle's JNLP implementation was slow > enough at startup. > > IMHO the class library should not do doing signature checks without > certificate validation, because it doesn't give any protection if the > signature is not verified, the only thing it could do now is to detect > some random bit flips, that maybe the Zip format CRC detect before that. > With no certificate verification the signature could be replaced by > anybody with bad intentions. It's a fair point, although since URLClassLoader is a subclass of SecureClassLoader the certificate chain does get populated into the CodeSource of the classes loaded, so one could potentially write a custom ClassLoader or additional code to additionally validate the certificate chain. Also, keep in mind that validating a certificate chain for signed code is not usually sufficient to determine if you actually trust who signed the code; some additional policy configuration (or UI prompts) are usually required. Also, if you run the application with a SecurityManager you can grant the signed JARs additional permissions based on who signed the code in an associated policy file, see [1] for more info. > Maybe adding a constructor flag to URLClassloader to pass to JarFile to > skip verification and a system property to tell the Java startup code to > skip verification of java.class.path (just for compatibility with old > code that expect it to be done). There is precedent of other runtimes > that added options to disable this, like CLR [1] (Ii not only verified > signatures, It do CRL/OSCP checks too) It's easy enough to strip signatures from JAR files (which you mention below). So if this is really an issue, I would be more inclined to just do that if it is an option. > Our new launcher replacing JNLP now do signature verification in native > code, at download time, and install on a system area (not user home > directory), so signature verification at application launch is a > slowdown we want to avoid, but think on another kind of users, those > deploying to OS Stores (for example Windows Store), why add the slowdown > of verification when the application is verified by the store client at > install time?, this could help these situations too. > > Note: This can be avoided removing the signatures of all JARs if you > distribute to an OS store, there are a few libraries that distribute > their JARs signed (The old Java Help framework comes to my mind right now) > > [1] > https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ --Sean [1] https://docs.oracle.com/en/java/javase/11/security/permissions-jdk1.html#GUID-7450CEFD-8EDC-495E-A7A3-6C2561FA4999 From igor.ignatyev at oracle.com Thu Jan 24 15:59:59 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 24 Jan 2019 07:59:59 -0800 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: Hi Daniel, it might be a better idea to scale sleep time using jdk.test.lib.Utils::adjustTimeout, so it will remain the same on configuration w/ timeout-factor=1, and scaled proportionally to timeout-factor on slow configurations. the rest looks good. Thanks, -- Igor > On Jan 24, 2019, at 4:20 AM, Daniel Fuchs wrote: > > Thanks Lance. > > Meanwhile I noticed that the first loop calling gc() used > a sleep(100) - which is probably not enough in those > greedy configurations - so I extended that to 1000. > (webrev updated in place). > http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ > > Hopefully that will reduce the frequency of failures. > Re testing in progress... > > best regards, > > -- daniel > > On 24/01/2019 12:14, Lance Andersen wrote: >> Morning Daniel, >> The change seems like a good approach >> Best >> Lance >>> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs > wrote: >>> >>> Hi, >>> >>> Please find below a fix for: >>> >>> 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java >>> fails with Unexpected reference: java.lang.ref.WeakReference >>> https://bugs.openjdk.java.net/browse/JDK-8217353 >>> >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >>> >>> This test has been seen failing from time to time with an >>> exception originating from the finally { } clause of the >>> main method. The suspicion is that this exception in fact >>> hides another exception previously thrown in the try { } >>> body. >>> >>> This is only a fix in so far that it will ensure that the >>> real exception - if any - is added to the suppressed list >>> of the secondary exception so that we eventually see it in >>> the log. >>> >>> As to why the test failed in the first place - I am not quite >>> sure, but it might be due to -Xcomp or some other combination >>> of options preventing the WeakReference to be cleared within >>> the time (and number of gc() calls) expected by the test >>> (the test has never been seen failing without these combinations). >>> >>> best regards, >>> >>> -- daniel >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > From daniel.fuchs at oracle.com Thu Jan 24 16:14:41 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Jan 2019 16:14:41 +0000 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive Message-ID: Hi, Please find below another test fix for: 8195716: BootstrapLoggerTest : Executor still alive https://bugs.openjdk.java.net/browse/JDK-8195716 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/ This test has been seen failing intermittently with -Xcomp and some other combination of options. The reason for the failure has baffled me until I recently noticed that the name of the executor's thread the test was joining in the end, didn't match the name of the executor thread that was still alive. Presumably the test is taking longer to execute, which allows the first executor thread timeout to expire, letting the executor release its thread and then later create a new one on demand. The fix is therefore simple (if a bit cumbersome): I changed the test to join any executor thread that is still found alive at the end, and then to wait for all of them to be GC'ed, instead of waiting on the single thread found at the beginning. I believe that should fix the issue. best regards, -- daniel From matthias.baesken at sap.com Thu Jan 24 16:19:10 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 24 Jan 2019 16:19:10 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> Message-ID: > Did you consider adding a Unix version of open_jarfile to avoid #ifdef > WIN32 ? Hi Alan, do you mean , adding a separate c-file for UNIX containing the function open_jarfile ? I considered this, but did not like the idea to add a separate file for UNIX just for the small function . Your suggestion to use FILE_SHARE_READ is probably the right way to do it , I changed this, second webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ Best Regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Donnerstag, 24. Januar 2019 13:04 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 23/01/2019 08:29, Baesken, Matthias wrote: > > Hello Alan, here is a second webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/ > > > > I moved the Windows-only code into a new file > > > > src/java.base/windows/native/libjli/parse_manifest_md.c > > > Did you consider adding a Unix version of open_jarfile to avoid #ifdef > WIN32 ? > > On the Windows version then your patch is low risk but the retrying > after ENOENT is a bit icky. I'm just wondering if you've considered > creating an absolute path and adding the prefix when the length is 247 > or greater. I also wonder about the share mode specified to CreateFileW > where it might be better to specify FILE_SHARE_READ at least so that you > don't exclude other processes from also opening the file to read. > > -Alan From daniel.fuchs at oracle.com Thu Jan 24 16:35:36 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Jan 2019 16:35:36 +0000 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: Thanks Igor, On 24/01/2019 15:59, Igor Ignatyev wrote: > Hi Daniel, > > it might be a better idea to scale sleep time using jdk.test.lib.Utils::adjustTimeout, so it will remain the same on configuration w/ timeout-factor=1, and scaled proportionally to timeout-factor on slow configurations. the rest looks good. I've chosen a slightly different path and adjusted the number of iterations instead: http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.01 best regards, -- daniel > > Thanks, > -- Igor > >> On Jan 24, 2019, at 4:20 AM, Daniel Fuchs wrote: >> >> Thanks Lance. >> >> Meanwhile I noticed that the first loop calling gc() used >> a sleep(100) - which is probably not enough in those >> greedy configurations - so I extended that to 1000. >> (webrev updated in place). >> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >> >> Hopefully that will reduce the frequency of failures. >> Re testing in progress... >> >> best regards, >> >> -- daniel >> >> On 24/01/2019 12:14, Lance Andersen wrote: >>> Morning Daniel, >>> The change seems like a good approach >>> Best >>> Lance >>>> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs > wrote: >>>> >>>> Hi, >>>> >>>> Please find below a fix for: >>>> >>>> 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java >>>> fails with Unexpected reference: java.lang.ref.WeakReference >>>> https://bugs.openjdk.java.net/browse/JDK-8217353 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >>>> >>>> This test has been seen failing from time to time with an >>>> exception originating from the finally { } clause of the >>>> main method. The suspicion is that this exception in fact >>>> hides another exception previously thrown in the try { } >>>> body. >>>> >>>> This is only a fix in so far that it will ensure that the >>>> real exception - if any - is added to the suppressed list >>>> of the secondary exception so that we eventually see it in >>>> the log. >>>> >>>> As to why the test failed in the first place - I am not quite >>>> sure, but it might be due to -Xcomp or some other combination >>>> of options preventing the WeakReference to be cleared within >>>> the time (and number of gc() calls) expected by the test >>>> (the test has never been seen failing without these combinations). >>>> >>>> best regards, >>>> >>>> -- daniel >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >> > From igor.ignatyev at oracle.com Thu Jan 24 16:38:35 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 24 Jan 2019 08:38:35 -0800 Subject: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference In-Reply-To: References: <03249f81-ff88-5fc7-8fdd-636ae3e9ae8a@oracle.com> Message-ID: Looks good. let's hope it will be enough to make these tests more robust. -- Igor > On Jan 24, 2019, at 8:35 AM, Daniel Fuchs wrote: > > Thanks Igor, > > On 24/01/2019 15:59, Igor Ignatyev wrote: >> Hi Daniel, >> it might be a better idea to scale sleep time using jdk.test.lib.Utils::adjustTimeout, so it will remain the same on configuration w/ timeout-factor=1, and scaled proportionally to timeout-factor on slow configurations. the rest looks good. > > I've chosen a slightly different path and adjusted the number of > iterations instead: > http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.01 > > best regards, > > -- daniel > >> Thanks, >> -- Igor >>> On Jan 24, 2019, at 4:20 AM, Daniel Fuchs wrote: >>> >>> Thanks Lance. >>> >>> Meanwhile I noticed that the first loop calling gc() used >>> a sleep(100) - which is probably not enough in those >>> greedy configurations - so I extended that to 1000. >>> (webrev updated in place). >>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >>> >>> Hopefully that will reduce the frequency of failures. >>> Re testing in progress... >>> >>> best regards, >>> >>> -- daniel >>> >>> On 24/01/2019 12:14, Lance Andersen wrote: >>>> Morning Daniel, >>>> The change seems like a good approach >>>> Best >>>> Lance >>>>> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please find below a fix for: >>>>> >>>>> 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java >>>>> fails with Unexpected reference: java.lang.ref.WeakReference >>>>> https://bugs.openjdk.java.net/browse/JDK-8217353 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/ >>>>> >>>>> This test has been seen failing from time to time with an >>>>> exception originating from the finally { } clause of the >>>>> main method. The suspicion is that this exception in fact >>>>> hides another exception previously thrown in the try { } >>>>> body. >>>>> >>>>> This is only a fix in so far that it will ensure that the >>>>> real exception - if any - is added to the suppressed list >>>>> of the secondary exception so that we eventually see it in >>>>> the log. >>>>> >>>>> As to why the test failed in the first place - I am not quite >>>>> sure, but it might be due to -Xcomp or some other combination >>>>> of options preventing the WeakReference to be cleared within >>>>> the time (and number of gc() calls) expected by the test >>>>> (the test has never been seen failing without these combinations). >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>> > From christoph.langer at sap.com Thu Jan 24 16:40:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 16:40:44 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system Message-ID: Hello, please help review this backport for 8034802 to jdk11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8034802 Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5 Original review thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055490.html Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8034802.11u/ The patch did not apply cleanly - I had to manually resolve 3 hunks. Jtreg tests for zipfs all pass. Thanks Christoph From martinrb at google.com Thu Jan 24 18:19:48 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 10:19:48 -0800 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive In-Reply-To: References: Message-ID: I don't understand your test, but: typo: bootsrap Consider copying in gcAwait from a concurrency test, e.g. ArrayBlockingQueue/WhiteBox.java:229: static void gcAwait(BooleanSupplier s) { On Thu, Jan 24, 2019 at 8:17 AM Daniel Fuchs wrote: > > Hi, > > Please find below another test fix for: > > 8195716: BootstrapLoggerTest : Executor still alive > https://bugs.openjdk.java.net/browse/JDK-8195716 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/ > > This test has been seen failing intermittently with -Xcomp > and some other combination of options. > The reason for the failure has baffled me until I recently > noticed that the name of the executor's thread the test was > joining in the end, didn't match the name of the executor > thread that was still alive. > Presumably the test is taking longer to execute, which allows > the first executor thread timeout to expire, letting the executor > release its thread and then later create a new one on demand. > > The fix is therefore simple (if a bit cumbersome): I changed > the test to join any executor thread that is still found > alive at the end, and then to wait for all of them to be GC'ed, > instead of waiting on the single thread found at the beginning. > > I believe that should fix the issue. > > best regards, > > -- daniel > From javalists at cbfiddle.com Thu Jan 24 18:23:52 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 24 Jan 2019 10:23:52 -0800 Subject: possible problem with JNI GetStringUTFChars Message-ID: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> I am having a problem with file names that contain emojis when passed to a macOS system call. Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. For example, where String.getBytes() returns -16 -97 -115 -69 GetStringUTFChars returns: -19 -96 -68 -19 -67 -69 I?m not a UTF expert, so can someone say whether I should file a bug report? (Tested in JDK 9, 11, and a fairly recent 12) From claes.redestad at oracle.com Thu Jan 24 18:32:56 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 24 Jan 2019 19:32:56 +0100 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> Message-ID: <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> Hi Alan, GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence as used by the VM internally for historical reasons. See answers to this related question on SO (which contains links to official docs): https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni HTH /Claes On 2019-01-24 19:23, Alan Snyder wrote: > I am having a problem with file names that contain emojis when passed to a macOS system call. > > Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. > > For example, where String.getBytes() returns > > -16 -97 -115 -69 > > GetStringUTFChars returns: > > -19 -96 -68 -19 -67 -69 > > I?m not a UTF expert, so can someone say whether I should file a bug report? > > (Tested in JDK 9, 11, and a fairly recent 12) > From javalists at cbfiddle.com Thu Jan 24 18:39:49 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 24 Jan 2019 10:39:49 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> Message-ID: Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? Alan > On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: > > Hi Alan, > > GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence > as used by the VM internally for historical reasons. > > See answers to this related question on SO (which contains links to official docs): > https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni > > HTH > > /Claes > > On 2019-01-24 19:23, Alan Snyder wrote: >> I am having a problem with file names that contain emojis when passed to a macOS system call. >> >> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >> >> For example, where String.getBytes() returns >> >> -16 -97 -115 -69 >> >> GetStringUTFChars returns: >> >> -19 -96 -68 -19 -67 -69 >> >> I?m not a UTF expert, so can someone say whether I should file a bug report? >> >> (Tested in JDK 9, 11, and a fairly recent 12) >> > From jpstotz at gmx.de Thu Jan 24 18:53:26 2019 From: jpstotz at gmx.de (Jan Peter Stotz) Date: Thu, 24 Jan 2019 19:53:26 +0100 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> Message-ID: <363f696d-664f-3b6a-f57f-1ae86396b8e4@gmx.de> Hi. Unfortunately in my last message I made mistake and mixed up the two sections. The main reasons for were first too many coding hours yesterday and second I had investigated this issue not yesterday but some weeks ago. During the last weeks I searched a way to participate in OpenJDK except for some high-traffic mailing list (that is IMHO development as it was in the last millennium). Especially the useless bug tracker (as it is only a bug viewer) is really not understandable to me. Federico Peralta Schaffner wrote: > Now, how have you come to the conclusion that the problem is in the first > branch of the above if statement, and that it is related to the passed > collection's implementation details of the remove(Object o) method? I think > this is not the problem, as elements are removed from this set and not from > the passed collection. You are right, the first section is not the problem but the second one is. I came to the same conclusion as you did when I first investigated this issue. However I would not call a marker interface HashAccess as it reflects a technology not an implementation characteristic. E.g. a TreeSet has an access time of O(log(n)) which may also be sufficiently fast enough for the second code part of AbstractSet.removeAll() but it's implementation does not base on hashing. Therefore my suggestion is still to simply check if the other collection is a Set and only if it is one use the second code part. Jan PS: If somebody answers please cc me personally as I only use the digest mode of this list. From ecki at zusammenkunft.net Thu Jan 24 18:57:09 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 24 Jan 2019 18:57:09 +0000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com>, Message-ID: Hello, I think in the Java 9 timeframe the Zip implementation was changed to no longer mmap the Zip index table. So this was not visible in the heap but now is. (Although it seems to be a bit slower). That might be the reason for your regression. You could use the following System property in Java 8 to get the new method there as well (in Java 9 the property and the old method is gone) https://bugs.openjdk.java.net/browse/JDK-8175192 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Robert Marcano Gesendet: Donnerstag, Januar 24, 2019 5:26 PM An: core-libs-dev at openjdk.java.net Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding On 1/23/19 8:59 AM, Sean Mullan wrote: > On 1/22/19 8:50 PM, Bernd Eckenfels wrote: >> I don?t think the launcher is doing this, it is the class loader, >> that?s nothing new. You can turn on verbose security debug to see it >> in all versions. > > Yes, and it only verifies the signature(s) on the JAR. It doesn't > validate the certificate chain. > > --Sean I noticed that trying to identify the higher memory usage after what looks like a big application is loaded. I am doing memory profiling and notice JarFile taking more memory that on Java 8. Still need to detect the real cause for an independent test case. We probably didn't notice this slowdown before because Oracle's JNLP implementation was slow enough at startup. IMHO the class library should not do doing signature checks without certificate validation, because it doesn't give any protection if the signature is not verified, the only thing it could do now is to detect some random bit flips, that maybe the Zip format CRC detect before that. With no certificate verification the signature could be replaced by anybody with bad intentions. Maybe adding a constructor flag to URLClassloader to pass to JarFile to skip verification and a system property to tell the Java startup code to skip verification of java.class.path (just for compatibility with old code that expect it to be done). There is precedent of other runtimes that added options to disable this, like CLR [1] (Ii not only verified signatures, It do CRL/OSCP checks too) Our new launcher replacing JNLP now do signature verification in native code, at download time, and install on a system area (not user home directory), so signature verification at application launch is a slowdown we want to avoid, but think on another kind of users, those deploying to OS Stores (for example Windows Store), why add the slowdown of verification when the application is verified by the store client at install time?, this could help these situations too. Note: This can be avoided removing the signatures of all JARs if you distribute to an OS store, there are a few libraries that distribute their JARs signed (The old Java Help framework comes to my mind right now) [1] https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ > >> >> -- >> https://Bernd.eckenfels.net >> >> ________________________________ >> Von: core-libs-dev im Auftrag >> von Robert Marcano >> Gesendet: Mittwoch, Januar 23, 2019 2:18 AM >> An: Alan Bateman >> Cc: OpenJDK Dev list; core-libs-dev Libs >> Betreff: Re: High memory usage / leaks was: Best mailing list for JVM >> embedding >> >> On Tue, Jan 22, 2019, 5:53 AM Alan Bateman > wrote: >> >>> On 22/01/2019 4:48 am, Robert Marcano wrote: >>>>> : >>>>> >>>>> So the question now is, why signed jars could affect the memory usage >>>>> of an application (we aren't doing JAR verification on our custom >>>>> launcher, yet), just by being on the java.class.path? IIRC the >>>>> initial application classpath JARs were never verified previously (by >>>>> the java launcher alone, without JNLP around). >>>>> >>>>> Note: Tested with JARs signed with a self signed certificate and with >>>>> one signed with a private CA. At most, signing the JARs could slow >>>>> down the start up if it is now expected to these being verified by >>>>> the java launcher (is it true?) but not higher memory usage and no >>>>> reductions after a GC cycle but constants heap size increases. >>> Signed JARs can be expensive to verify, esp. on first usage as the >>> verification is likely to result in early loading of a lot of security >>> classes and infrastructure. If you can narrow down the apparently memory >>> leak to a small test case with analysis to suggest it's a JDK bug then >>> it would be good to get a bug submitted. >>> >>> -Alan >> >> >> Greeting. Sure, I will work on a distributable reproduction of the >> problem >> today but it is new to me that the java launcher do JARs verification >> now. >> If it is doing it I doesn't make sense to me, because a self signed or >> unrecognized CA doesn't trigger a validation error. >> >>> From lance.andersen at oracle.com Thu Jan 24 20:48:20 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 15:48:20 -0500 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module Message-ID: Hi all, Please review the following patch which addresses https://bugs.openjdk.java.net/browse/JDK-8210469 where jdk.zipfs was missing a doPriviledged block and permission needed when closing a zip file system when a security manager has been enabled. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8210469/webrev.00/index.html Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Thu Jan 24 21:28:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 Jan 2019 13:28:55 -0800 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: References: Message-ID: <92b30217-3f5f-6582-c5bc-c2440535d02b@oracle.com> Hi Lance, Stylistically, putting the comma at the beginning of line 327 looks ... unusual 325 zfpath = AccessController.doPrivileged( 326 (PrivilegedExceptionAction) () -> tempPath.toRealPath() 327 , null, 328 new java.util.PropertyPermission("user.dir", "read")); -- Jon On 01/24/2019 12:48 PM, Lance Andersen wrote: > Hi all, > > Please review the following patch which addresses https://bugs.openjdk.java.net/browse/JDK-8210469 where jdk.zipfs was missing a doPriviledged block and permission needed when closing a zip file system when a security manager has been enabled. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8210469/webrev.00/index.html > > Best > Lance > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Jan 24 21:34:50 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 16:34:50 -0500 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <92b30217-3f5f-6582-c5bc-c2440535d02b@oracle.com> References: <92b30217-3f5f-6582-c5bc-c2440535d02b@oracle.com> Message-ID: <87CF8A21-AAC8-4BBD-B45A-40BB89EDD8E0@oracle.com> Hi Jon, > On Jan 24, 2019, at 4:28 PM, Jonathan Gibbons wrote: > > Hi Lance, > > Stylistically, putting the comma at the beginning of line 327 looks ... unusual > > 325 zfpath = AccessController.doPrivileged( > 326 (PrivilegedExceptionAction) () -> tempPath.toRealPath() > 327 , null, > 328 new java.util.PropertyPermission("user.dir", "read")); > thanks for catching that, I agree, it should not be there, I think I just saw what I wanted to see. :-) I updated the webrev in place as there is no other change Best Lance > -- Jon > > On 01/24/2019 12:48 PM, Lance Andersen wrote: >> Hi all, >> >> Please review the following patch which addresses https://bugs.openjdk.java.net/browse/JDK-8210469 where jdk.zipfs was missing a doPriviledged block and permission needed when closing a zip file system when a security manager has been enabled. >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8210469/webrev.00/index.html >> >> Best >> Lance >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Thu Jan 24 21:50:57 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Jan 2019 13:50:57 -0800 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: References: Message-ID: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> On 1/24/19 12:48 PM, Lance Andersen wrote: > Hi all, > > Please review the following patch which addresses https://bugs.openjdk.java.net/browse/JDK-8210469 where jdk.zipfs was missing a doPriviledged block and permission needed when closing a zip file system when a security manager has been enabled. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8210469/webrev.00/index.html Alternatively you can simply do: ??????????? PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); ??????????? return AccessController.doPrivileged(pea); In this case, limited doPrivileged does not make whole lot of difference jdk.zip explicitly grants for limited permissions and this doPrivileged block is one single operation, toRealPath. The new test has a couple of blank lines (line 64 an 83). Formatting nit: indentation in line 74. Mandy From lance.andersen at oracle.com Thu Jan 24 21:55:45 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 16:55:45 -0500 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> Message-ID: <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> Hi Mandy, > On Jan 24, 2019, at 4:50 PM, Mandy Chung wrote: > > > > On 1/24/19 12:48 PM, Lance Andersen wrote: >> Hi all, >> >> Please review the following patch which addresses https://bugs.openjdk.java.net/browse/JDK-8210469 where jdk.zipfs was missing a doPriviledged block and permission needed when closing a zip file system when a security manager has been enabled. >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8210469/webrev.00/index.html > > Alternatively you can simply do: > PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); > return AccessController.doPrivileged(pea); > > In this case, limited doPrivileged does not make whole lot of difference jdk.zip explicitly grants for limited permissions and this doPrivileged block is one single operation, toRealPath. Do you have a preference here either way? I had that originally but changed it to make it clearer why it was done. > > The new test has a couple of blank lines (line 64 an 83). Formatting nit: indentation in line 74. Addressed for when I push. Best Lance > > Mandy > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From christoph.langer at sap.com Thu Jan 24 22:23:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 22:23:59 +0000 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> Message-ID: Hi Lance, > > Alternatively you can simply do: > > PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); > > return AccessController.doPrivileged(pea); > > > > In this case, limited doPrivileged does not make whole lot of difference > jdk.zip explicitly grants for limited permissions and this doPrivileged block is > one single operation, toRealPath. > > Do you have a preference here either way? I had that originally but changed > it to make it clearer why it was done. I would prefer the way Mandy suggests. Furthermore, the imports in the test case can be condensed to: import java.io.IOException; import java.nio.file.FileSystem; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.spi.FileSystemProvider; import java.util.Map; import org.testng.annotations.AfterClass; import org.testng.annotations.BeforeClass; import org.testng.annotations.Test; Other than that: reviewed ?? Best Christoph From mandy.chung at oracle.com Thu Jan 24 23:20:08 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Jan 2019 15:20:08 -0800 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> Message-ID: On 1/24/19 1:55 PM, Lance Andersen wrote: > >> Alternatively you can simply do: >> ??????????? PrivilegedExceptionAction pea = () -> >> tempPath.toRealPath(); >> ??????????? return AccessController.doPrivileged(pea); >> >> In this case, limited doPrivileged does not make whole lot of >> difference jdk.zip explicitly grants for limited permissions and this >> doPrivileged block is one single operation, toRealPath. > > Do you have a preference here either way? ?I had that originally but > changed it ?to make it clearer why it was done. For this simple case, I would avoid using limited doPrivileged. Mandy From stuart.marks at oracle.com Fri Jan 25 00:07:42 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Jan 2019 16:07:42 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> Message-ID: <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> On 1/23/19 12:05 PM, Jan Peter Stotz wrote: > like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() > and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And > there are hundred of developers hitting this bug every year. > > I simply don't understand why there was no progress in 8 years, on a severe > performance issue (a removeAll method on an efficient set that can require > O(n^2)!) caused by code that was written to speed-up the removeAll implementation. > > Which makes this bug worse is that it is triggered by the relative size of the > current set compared to the collection passed as parameter. > Therefore for most developers this means not to use this buggy function at all > (once they realized how worse it is). I wasn't aware that hundreds of developers are hitting this bug every year. I haven't seen any mention of it (besides in the bug database) on Twitter, on Reddit, on DZone, at the conferences I attend, or in several years of core-libs-dev emails. Well, it was mentioned on core-libs-dev once in 2011 [1] although that was a suggestion for improvement, not a complaint about performance. Nonetheless this is a real problem, and if it's causing difficulties we can certainly take a look at it. There is, however, more to the story. The ACTUAL problem is a semantic one; see JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on the relative sizes of x and y, this method might end up using either x's or y's definition of membership, which could differ from each other. (See the bug report for an example.) Thus the semantics of this method depend upon the relative sizes of the collections, which is arguably flawed. Worse, this behavior is specified to iterate this set or the argument, depending upon their relative sizes. [3] So, fixing this will require an incompatible specification change. The obvious way to fix this is to get rid of the "optimizations" (that turn out not to be optimizations at all in some cases) and replace it with a simple loop: public boolean removeAll(Collection c) { Objects.requireNonNull(c); boolean modified = false; for (Object e : c) modified |= remove(e); return modified; } I would argue that iterating the argument and calling remove() on "this" are the right semantics, because you want set membership to be determined by this set, not by whatever collection you pass as an argument. However, I note that AbstractCollection.removeAll and other removeAll implementations iterate over "this" and do a contains() check on the argument. The revised AbstractSet.removeAll would be an outlier here, though it makes sense to me to do it this way. Is it worth the incompatibility? s'marks [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html [2] https://bugs.openjdk.java.net/browse/JDK-6394757 [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) From lance.andersen at oracle.com Fri Jan 25 00:11:35 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Jan 2019 19:11:35 -0500 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> Message-ID: <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> > On Jan 24, 2019, at 6:20 PM, Mandy Chung wrote: > > > > On 1/24/19 1:55 PM, Lance Andersen wrote: >> >>> Alternatively you can simply do: >>> PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); >>> return AccessController.doPrivileged(pea); >>> >>> In this case, limited doPrivileged does not make whole lot of difference jdk.zip explicitly grants for limited permissions and this doPrivileged block is one single operation, toRealPath. >> >> Do you have a preference here either way? I had that originally but changed it to make it clearer why it was done. > > For this simple case, I would avoid using limited doPrivileged. Okie Dokie, I made the change and also ran optimize imports on the test: http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html Best Lance > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Fri Jan 25 01:08:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Jan 2019 17:08:37 -0800 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> Message-ID: On 1/24/19 4:11 PM, Lance Andersen wrote: > http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html +1 Mandy From stuart.marks at oracle.com Fri Jan 25 02:57:42 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Jan 2019 18:57:42 -0800 Subject: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int) In-Reply-To: <5311541547500963@iva1-a2ffb02749cf.qloud-c.yandex.net> References: <63305801547147103@sas1-c85b0e8ec090.qloud-c.yandex.net> <5311541547500963@iva1-a2ffb02749cf.qloud-c.yandex.net> Message-ID: <0577da6e-d74d-0fb9-b88d-a6eafe708d7b@oracle.com> It seems to me rather odd and surprising to introduce a code path into sb.append(cs,int,int) that allocates memory in order to get at an intrinsic that only sometimes makes things run faster. As you observed, the performance tradeoffs aren't obvious. Instead, if we want to optimize sb.append(cs,int,int) maybe we should just go ahead and do that, possibly by adding or rearranging the intrinsics. I've filed JDK-8217675 to cover this. Jim Laskey said he might be able to look at it. https://bugs.openjdk.java.net/browse/JDK-8217675 s'marks From christoph.langer at sap.com Fri Jan 25 05:48:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 05:48:05 +0000 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> Message-ID: +1 > -----Original Message----- > From: core-libs-dev On Behalf > Of Mandy Chung > Sent: Freitag, 25. Januar 2019 02:09 > To: Lance Andersen > Cc: core-libs-dev at openjdk.java.net >> core-libs-dev dev at openjdk.java.net> > Subject: Re: RFR: 8210469: Missing doPriviledged block and permission for > jdk.zipfs module > > > > On 1/24/19 4:11 PM, Lance Andersen wrote: > > http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html > > +1 > > Mandy From david.holmes at oracle.com Fri Jan 25 06:04:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 16:04:24 +1000 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> Message-ID: On 25/01/2019 4:39 am, Alan Snyder wrote: > Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. > > What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: https://bugs.openjdk.java.net/browse/JDK-5030776 so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. Cheers, David ----- > Alan > > > > >> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >> >> Hi Alan, >> >> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >> as used by the VM internally for historical reasons. >> >> See answers to this related question on SO (which contains links to official docs): >> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >> >> HTH >> >> /Claes >> >> On 2019-01-24 19:23, Alan Snyder wrote: >>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>> >>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>> >>> For example, where String.getBytes() returns >>> >>> -16 -97 -115 -69 >>> >>> GetStringUTFChars returns: >>> >>> -19 -96 -68 -19 -67 -69 >>> >>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>> >>> (Tested in JDK 9, 11, and a fairly recent 12) >>> >> > From goetz.lindenmaier at sap.com Fri Jan 25 08:01:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 25 Jan 2019 08:01:07 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: References: Message-ID: <6ab11b43b93647da910b410d3544957a@sap.com> Hi Christoph, This is a big change, and it seems a lot more changed than resolving Hunks. Some hunks are missing altogether. For example, http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5, ZipFileSystem 2341 2.341- IndexNode inode = new IndexNode(cen, nlen, pos); 2.342+ IndexNode inode = new IndexNode(cen, pos, nlen); Is missing in your change. And I see much more differences if I compare the diffs. Please explain. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Langer, Christoph > Sent: Thursday, January 24, 2019 5:41 PM > To: core-libs-dev at openjdk.java.net > Subject: [CAUTION] RFR [11u backport]: 8034802: (zipfs) newFileSystem > throws UOE when the zip file is located in a custom file system > > Hello, > > please help review this backport for 8034802 to jdk11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034802 > Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5 > Original review thread: https://mail.openjdk.java.net/pipermail/core-libs- > dev/2018-September/055490.html > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8034802.11u/ > > The patch did not apply cleanly - I had to manually resolve 3 hunks. Jtreg tests > for zipfs all pass. > > Thanks > Christoph From Alan.Bateman at oracle.com Fri Jan 25 08:46:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2019 08:46:36 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: <6ab11b43b93647da910b410d3544957a@sap.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> Message-ID: <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> On 25/01/2019 08:01, Lindenmaier, Goetz wrote: > Hi Christoph, > > This is a big change, and it seems a lot more changed than resolving > Hunks. The support for zip files located in file systems created by custom providers was essentially a new feature in JDK 12 so it may not have got a lot of usage yet. There has been a lot of other improvements in zipfs in recent builds too and it's come a long way from its days as a demo file system. I don't have any involvement in JDK 11 updates but one suggestion is to x10 the testing of zipfs with a view to shaking out issues in the mainline before doing a refresh. That is, it might be saner to a bulk update after some bake time rather than picking out specific changes. -Alan. From yumin.qi at gmail.com Fri Jan 25 08:52:14 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 25 Jan 2019 16:52:14 +0800 Subject: Anonymous class Message-ID: Hi, I have a question of anonymous class. We know the anonymous class with a host_klass, and the flag is set when the InstanceKlass is created after the class parsed. In case of a regular java class file, the flag will be set correctly but for the case it is not set: SystemDictionary::parse_stream or resolve_from_stream, which is called from JVM_DefineClassWithSource or jni_defineClass. The stack trace like: #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream(class_name=0x7f0ee40243f0, class_loader=..., protection_domain=...,d__=0x7f0f04001000) at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionaryShared.cpp:656 #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream (class_name=0x7f0ee40243f0, class_loader=..., protection_doma in=..., st=0x7f0f0a5f3850, verify=true, __the_thread__=0x7f0f04001000) at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionary.cpp:1234 #2 0x00007f1126f3cadb in jvm_define_class_common (env=0x7f0f04001220, name=0x7f0f0a5f3e60 "com/google/common/collect/Iterato rs$3", loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, pd=0x7f0f0a5f3f48, source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/", verify=1 '\001', __the_thread__=0x7f0f04001000) at /home/yumin.qi/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prims/jvm.cpp:1082 #3 0x00007f1126f3d019 in JVM_DefineClassWithSource (env=0x7f0f04001220, name=0x7f0f0a5f3e60 "com/google/common/collect/Itera tors$3", loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, pd=0x7f0f0a5f3f48, source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/") at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prim/jvm.cpp:1102 #4 0x00007f112581214f in Java_java_lang_ClassLoader_defineClass1 () from /home/ws/openjdk/8/jdk8u/build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/jre/lib/amd64/libjava.so #5 0x00007f11118f5402 in ?? () #6 0x00007f0f0a5f3f48 in ?? () #7 0x00007f0f0a5f3f70 in ?? () #8 0x0000000755dbbc28 in ?? () The class name is com.google.common.collect.Iterators$3, and it is an anonymous class. This is an example using Guava. I also can reproduce with jdk13. The field after parsing: _nonstatic_oop_map_size = 1, _is_marked_dependent = false, _has_unloaded_dependent = false, _misc_flags = 38, ////// <------------ not set for anonymous _minor_version = 0, _major_version = 50, _init_thread = 0x0, _vtable_len = 8, _itable_len = 8, This path is from a custom loader defining a anonymous class, does not set anonymous correctly for the flag. Is this a bug? If in java land, supply a host as parameter, it can be set correctly in VM part. Should I file a bug for it? Thanks Yumin From Alan.Bateman at oracle.com Fri Jan 25 08:55:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2019 08:55:04 +0000 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> Message-ID: On 25/01/2019 00:11, Lance Andersen wrote: >> On Jan 24, 2019, at 6:20 PM, Mandy Chung wrote: >> >> >> >> On 1/24/19 1:55 PM, Lance Andersen wrote: >>>> Alternatively you can simply do: >>>> PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); >>>> return AccessController.doPrivileged(pea); >>>> >>>> In this case, limited doPrivileged does not make whole lot of difference jdk.zip explicitly grants for limited permissions and this doPrivileged block is one single operation, toRealPath. >>> Do you have a preference here either way? I had that originally but changed it to make it clearer why it was done. >> For this simple case, I would avoid using limited doPrivileged. > Okie Dokie, I made the change and also ran optimize imports on the test: http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html > Here's an alternative that avoids the cast, it might be a bit more readable. PrivilegedExceptionAction action = tempPath::toRealPath; zfpath = AccessController.doPrivileged(action); In the test then you it might be clearer to rename ZIPFS_MAP to ZIPFS_OPTIONS. -Alan From daniel.fuchs at oracle.com Fri Jan 25 10:33:22 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jan 2019 10:33:22 +0000 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive In-Reply-To: References: Message-ID: Hi Martin, On 24/01/2019 18:19, Martin Buchholz wrote: > I don't understand your test, but: > > typo: bootsrap Thanks! Fixed. > Consider copying in gcAwait from a concurrency test, e.g. > ArrayBlockingQueue/WhiteBox.java:229: static void > gcAwait(BooleanSupplier s) { Interesting. The main difference would be waiting for the GC to run finalization hooks. This is a nice trick. I hadn't seen it before. I'm not sure this is strictly needed in the case of this test though, but I will keep that in mind in case this test (or some of the other logging tests that try to check that resources/loggers are correctly released) are seen failing again. Maybe then a global pass on all these test would be warranted. Thanks for the pointer! It is good food for thoughts :-) best regards, -- daniel > > On Thu, Jan 24, 2019 at 8:17 AM Daniel Fuchs wrote: >> >> Hi, >> >> Please find below another test fix for: >> >> 8195716: BootstrapLoggerTest : Executor still alive >> https://bugs.openjdk.java.net/browse/JDK-8195716 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/ >> >> This test has been seen failing intermittently with -Xcomp >> and some other combination of options. >> The reason for the failure has baffled me until I recently >> noticed that the name of the executor's thread the test was >> joining in the end, didn't match the name of the executor >> thread that was still alive. >> Presumably the test is taking longer to execute, which allows >> the first executor thread timeout to expire, letting the executor >> release its thread and then later create a new one on demand. >> >> The fix is therefore simple (if a bit cumbersome): I changed >> the test to join any executor thread that is still found >> alive at the end, and then to wait for all of them to be GC'ed, >> instead of waiting on the single thread found at the beginning. >> >> I believe that should fix the issue. >> >> best regards, >> >> -- daniel >> From christoph.langer at sap.com Fri Jan 25 10:40:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 10:40:00 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: <6ab11b43b93647da910b410d3544957a@sap.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> Message-ID: Hi Goetz, > > And I see much more differences if I compare the diffs. > > Please explain. > unfortunately, the udiffs of the webrev look different in quite some parts to what you see when you look at the commit on the hg web server (http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5), although those are the same. There were only 3 rejects when I applied the change to jdk11u (you could try this yourself). > This is a big change, and it seems a lot more changed than resolving > Hunks. Some hunks are missing altogether. > > For example, > http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5, > ZipFileSystem 2341 > 2.341- IndexNode inode = new IndexNode(cen, nlen, pos); > 2.342+ IndexNode inode = new IndexNode(cen, pos, nlen); > Is missing in your change. The constructor IndexNode(byte[] cen, int noff, int nlen, int pos) (jdk11u) vs. IndexNode(byte[] cen, int pos, int nlen) (jdk11) was actually the part where the failing hunks originated. There was another patch pre 8034802 in jdk12 which changed signature: IndexNode(byte[] cen, int noff, int nlen, int pos) -to IndexNode(byte[] cen, int nlen, int pos). 8034802 did this change then: IndexNode(byte[] cen, int nlen, int pos) -> IndexNode(byte[] cen, int pos, int nlen) I chose not to touch this part but maybe this change should change the constructor from IndexNode(byte[] cen, int noff, int nlen, int pos) -> IndexNode(byte[] cen, int noff, int pos, int nlen), though, to take over this change of order in arguments. It's a package private constructor that is only called in one spot. What do you think? Thanks & Best regards Christoph From christoph.langer at sap.com Fri Jan 25 10:51:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 10:51:05 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> Message-ID: <52555ebbe422432d8f9172285fda3fdb@sap.com> Hi Alan, thanks for your view on this backport request even though you aren't involved in jdk11u any longer. > The support for zip files located in file systems created by custom > providers was essentially a new feature in JDK 12 so it may not have got > a lot of usage yet. There has been a lot of other improvements in zipfs > in recent builds too and it's come a long way from its days as a demo > file system. I don't have any involvement in JDK 11 updates but one > suggestion is to x10 the testing of zipfs with a view to shaking out > issues in the mainline before doing a refresh. That is, it might be > saner to a bulk update after some bake time rather than picking out > specific changes. I think doing a bulk change to take over all the fixes that have been done on jdk.zipfs in the recent past seems quite appealing. Especially since those fixes don't break the Java API and probably don't even have CSRs associated. For the moment, I need this change back in jdk11u because with the SapMachine 11 build of OpenJDK we'd like to ship the preliminary version of the POSIX permission feature to be used by a customer. And this fix is somehow a prerequisite because it enables the testcase we have there. Without the fix, a call to "Files.createFile(fs.getPath(name), PosixFilePermissions.asFileAttribute(perms));" would not work. Fixing this is a nice side effect of the change of 8034802. So we'd kill two birds with one stone here. As far as I can see, this fix is disjunct in its core from the other fixes made to jdk.zipfs. However, for the jdk11u OpenJDK community I'd volunteer to do a bulk update of jdk.zipfs in the near future. Preferrably after we've come to a solution on 8213031 (POSIX permissions). Thanks Christoph From david.holmes at oracle.com Fri Jan 25 11:18:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 21:18:27 +1000 Subject: Anonymous class In-Reply-To: References: Message-ID: <8ccbfa3b-6297-d76c-97db-28121c965fdd@oracle.com> On 25/01/2019 6:52 pm, yumin qi wrote: > Hi, > > I have a question of anonymous class. We know the anonymous class with a > host_klass, and the flag is set when the InstanceKlass is created after the > class parsed. In case of a regular java class file, the flag will be set > correctly but for the case it is not set: > SystemDictionary::parse_stream or resolve_from_stream, which is called > from JVM_DefineClassWithSource or jni_defineClass. The stack trace like: > > #1 0x00007f1127291ce7 in > SystemDictionary::resolve_from_stream(class_name=0x7f0ee40243f0, > class_loader=..., protection_domain=...,d__=0x7f0f04001000) at > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionaryShared.cpp:656 > #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream > (class_name=0x7f0ee40243f0, class_loader=..., protection_doma > in=..., > st=0x7f0f0a5f3850, verify=true, __the_thread__=0x7f0f04001000) > at > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionary.cpp:1234 > #2 0x00007f1126f3cadb in jvm_define_class_common (env=0x7f0f04001220, > name=0x7f0f0a5f3e60 "com/google/common/collect/Iterato > rs$3", > loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, > pd=0x7f0f0a5f3f48, > source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/", > verify=1 '\001', __the_thread__=0x7f0f04001000) at > /home/yumin.qi/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prims/jvm.cpp:1082 > #3 0x00007f1126f3d019 in JVM_DefineClassWithSource (env=0x7f0f04001220, > name=0x7f0f0a5f3e60 "com/google/common/collect/Itera > tors$3", > loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, > pd=0x7f0f0a5f3f48, > source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/") at > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prim/jvm.cpp:1102 > #4 0x00007f112581214f in Java_java_lang_ClassLoader_defineClass1 () > from > /home/ws/openjdk/8/jdk8u/build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/jre/lib/amd64/libjava.so > #5 0x00007f11118f5402 in ?? () > #6 0x00007f0f0a5f3f48 in ?? () > #7 0x00007f0f0a5f3f70 in ?? () > #8 0x0000000755dbbc28 in ?? () > > The class name is com.google.common.collect.Iterators$3, and it is an > anonymous class. I'm confused. Are you talking about Java level anonymous classes or VM anonymous classes as created by Unsafe.defineAnonymousClass? Only VM anonymous classes have a "host class". Java level "anonymous classes" are just regular classes. David ----- > This is an example using Guava. I also can reproduce with jdk13. > > The field after parsing: > > _nonstatic_oop_map_size = 1, > _is_marked_dependent = false, > _has_unloaded_dependent = false, > _misc_flags = 38, ////// <------------ not set for anonymous > _minor_version = 0, > _major_version = 50, > _init_thread = 0x0, > _vtable_len = 8, > _itable_len = 8, > > This path is from a custom loader defining a anonymous class, does not > set anonymous correctly for the flag. Is this a bug? If in java land, > supply a host as parameter, it can be set correctly in VM part. Should I > file a bug for it? > > Thanks > Yumin > From GROEGES at uk.ibm.com Fri Jan 25 11:39:55 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 25 Jan 2019 11:39:55 +0000 Subject: RFR: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail Message-ID: Hi all, I have found an issue with the jdk/java/util/prefs/ExportSubtree.java test. Using jtreg to run this test the test passes no matter what happens within the test. Have raised an issue for this: https://bugs.openjdk.java.net/browse/JDK-8217777 I think the issue is 2 fold: 1) the test check the expected vs. actual and throws an exception but this is caught later in the code, which causes the test to pass as there is no exception thrown. 2) the exported XML now contains a `standalone="no"` entry in the XML prologue, which is not in the expected XML. I have generated a webrev to resolve this: http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ This occurs on jdk11 but is probabaly also an issue on other releases ie jdk8u, jdk12, jdk etc Please could someone review this webrev and sponsor this chnage for me as I am unable to commit this myself. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From robert at marcanoonline.com Fri Jan 25 12:34:34 2019 From: robert at marcanoonline.com (Robert Marcano) Date: Fri, 25 Jan 2019 08:34:34 -0400 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> <7cb6f5c4-0322-1978-5932-5ae302726a35@oracle.com> Message-ID: <94f79759-127a-3b9b-5fa9-97845bbb5360@marcanoonline.com> On 1/24/19 11:05 AM, Sean Mullan wrote: > On 1/24/19 8:25 AM, Robert Marcano wrote: >> On 1/23/19 8:59 AM, Sean Mullan wrote: >>> On 1/22/19 8:50 PM, Bernd Eckenfels wrote: >>>> I don?t think the launcher is doing this, it is the class loader, >>>> that?s nothing new. You can turn on verbose security debug to see it >>>> in all versions. >>> >>> Yes, and it only verifies the signature(s) on the JAR. It doesn't >>> validate the certificate chain. >>> >>> --Sean >> >> I noticed that trying to identify the higher memory usage after what >> looks like a big application is loaded. I am doing memory profiling >> and notice JarFile taking more memory that on Java 8. Still need to >> detect the real cause for an independent test case. We probably didn't >> notice this slowdown before because Oracle's JNLP implementation was >> slow enough at startup. >> >> IMHO the class library should not do doing signature checks without >> certificate validation, because it doesn't give any protection if the >> signature is not verified, the only thing it could do now is to detect >> some random bit flips, that maybe the Zip format CRC detect before >> that. With no certificate verification the signature could be replaced >> by anybody with bad intentions. > > It's a fair point, although since URLClassLoader is a subclass of > SecureClassLoader the certificate chain does get populated into the > CodeSource of the classes loaded, so one could potentially write a > custom ClassLoader or additional code to additionally validate the > certificate chain. Also, keep in mind that validating a certificate > chain for signed code is not usually sufficient to determine if you > actually trust who signed the code; some additional policy configuration > (or UI prompts) are usually required. Also, if you run the application > with a SecurityManager you can grant the signed JARs additional > permissions based on who signed the code in an associated policy file, > see [1] for more info. Thanks for the info, but this is for corporate intranet application distribution of an ISV (us) application, no untrusted code installation. We are signing our code with a certificate from a private CA and the CA is embedded on the native updater/launcher as the exclusive CA used for dowloaded updates validation. It is more like the Firefox/Chrome updater. > >> Maybe adding a constructor flag to URLClassloader to pass to JarFile >> to skip verification and a system property to tell the Java startup >> code to skip verification of java.class.path (just for compatibility >> with old code that expect it to be done). There is precedent of other >> runtimes that added options to disable this, like CLR [1] (Ii not only >> verified signatures, It do CRL/OSCP checks too) > > It's easy enough to strip signatures from JAR files (which you mention > below). So if this is really an issue, I would be more inclined to just > do that if it is an option. Yea, I added an option to remove the signatures from the downloaded updates (after signature validation) so they are not validated anymore at launch time. > >> Our new launcher replacing JNLP now do signature verification in >> native code, at download time, and install on a system area (not user >> home directory), so signature verification at application launch is a >> slowdown we want to avoid, but think on another kind of users, those >> deploying to OS Stores (for example Windows Store), why add the >> slowdown of verification when the application is verified by the store >> client at install time?, this could help these situations too. >> >> Note: This can be avoided removing the signatures of all JARs if you >> distribute to an OS store, there are a few libraries that distribute >> their JARs signed (The old Java Help framework comes to my mind right >> now) >> >> [1] >> https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ > > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/11/security/permissions-jdk1.html#GUID-7450CEFD-8EDC-495E-A7A3-6C2561FA4999 > From yumin.qi at gmail.com Fri Jan 25 13:06:34 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 25 Jan 2019 21:06:34 +0800 Subject: Anonymous class In-Reply-To: <8ccbfa3b-6297-d76c-97db-28121c965fdd@oracle.com> References: <8ccbfa3b-6297-d76c-97db-28121c965fdd@oracle.com> Message-ID: Hi, David I am confused here. As you pointed out: Java anonymous classes are not VM anonymous classes. VM anonymous classes are created by Unsafe_DefineAnonymousClass only. Is my understanding right? All all lambda classes are vm anonymous? Thanks Yumin On Fri, Jan 25, 2019 at 7:18 PM David Holmes wrote: > > > On 25/01/2019 6:52 pm, yumin qi wrote: > > Hi, > > > > I have a question of anonymous class. We know the anonymous class > with a > > host_klass, and the flag is set when the InstanceKlass is created after > the > > class parsed. In case of a regular java class file, the flag will be set > > correctly but for the case it is not set: > > SystemDictionary::parse_stream or resolve_from_stream, which is called > > from JVM_DefineClassWithSource or jni_defineClass. The stack trace like: > > > > #1 0x00007f1127291ce7 in > > SystemDictionary::resolve_from_stream(class_name=0x7f0ee40243f0, > > class_loader=..., protection_domain=...,d__=0x7f0f04001000) at > > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionaryShared.cpp:656 > > #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream > > (class_name=0x7f0ee40243f0, class_loader=..., protection_doma > > in=..., > > st=0x7f0f0a5f3850, verify=true, __the_thread__=0x7f0f04001000) > > at > > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionary.cpp:1234 > > #2 0x00007f1126f3cadb in jvm_define_class_common (env=0x7f0f04001220, > > name=0x7f0f0a5f3e60 "com/google/common/collect/Iterato > > rs$3", > > loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", > len=943, > > pd=0x7f0f0a5f3f48, > > source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/", > > verify=1 '\001', __the_thread__=0x7f0f04001000) at > > /home/yumin.qi/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prims/jvm.cpp:1082 > > #3 0x00007f1126f3d019 in JVM_DefineClassWithSource (env=0x7f0f04001220, > > name=0x7f0f0a5f3e60 "com/google/common/collect/Itera > > tors$3", > > loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", > len=943, > > pd=0x7f0f0a5f3f48, > > source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/") > at > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prim/jvm.cpp:1102 > > #4 0x00007f112581214f in Java_java_lang_ClassLoader_defineClass1 () > > from > > > /home/ws/openjdk/8/jdk8u/build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/jre/lib/amd64/libjava.so > > #5 0x00007f11118f5402 in ?? () > > #6 0x00007f0f0a5f3f48 in ?? () > > #7 0x00007f0f0a5f3f70 in ?? () > > #8 0x0000000755dbbc28 in ?? () > > > > The class name is com.google.common.collect.Iterators$3, and it is an > > anonymous class. > > I'm confused. Are you talking about Java level anonymous classes or VM > anonymous classes as created by Unsafe.defineAnonymousClass? Only VM > anonymous classes have a "host class". Java level "anonymous classes" > are just regular classes. > > David > ----- > > > > > This is an example using Guava. I also can reproduce with jdk13. > > > > The field after parsing: > > > > _nonstatic_oop_map_size = 1, > > _is_marked_dependent = false, > > _has_unloaded_dependent = false, > > _misc_flags = 38, ////// <------------ not set for anonymous > > _minor_version = 0, > > _major_version = 50, > > _init_thread = 0x0, > > _vtable_len = 8, > > _itable_len = 8, > > > > This path is from a custom loader defining a anonymous class, does not > > set anonymous correctly for the flag. Is this a bug? If in java land, > > supply a host as parameter, it can be set correctly in VM part. Should I > > file a bug for it? > > > > Thanks > > Yumin > > > From david.holmes at oracle.com Fri Jan 25 13:37:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 23:37:12 +1000 Subject: Anonymous class In-Reply-To: References: <8ccbfa3b-6297-d76c-97db-28121c965fdd@oracle.com> Message-ID: <684252eb-391c-4ca1-a164-090c33160c2c@oracle.com> On 25/01/2019 11:06 pm, yumin qi wrote: > Hi, David > > I am confused here. > As you pointed out: > ? ?Java anonymous classes are not VM anonymous classes. > ? ?VM anonymous classes are created by Unsafe_DefineAnonymousClass only. > > Is my understanding right? All all lambda classes are vm anonymous? I don't know if it is correct to say "all lambda classes" as I don't know the full translation strategy for lambda expressions, but yes some lambda generated classes are VM anonymous classes. David > Thanks > Yumin > > On Fri, Jan 25, 2019 at 7:18 PM David Holmes > wrote: > > > > On 25/01/2019 6:52 pm, yumin qi wrote: > > Hi, > > > >? ? I have a question of anonymous class. We know the anonymous > class with a > > host_klass, and the flag is set when the InstanceKlass is created > after the > > class parsed. In case of a regular java class file, the flag will > be set > > correctly but for the case it is not set: > >? ? SystemDictionary::parse_stream or resolve_from_stream, which > is called > > from JVM_DefineClassWithSource or jni_defineClass. The stack > trace like: > > > > #1? 0x00007f1127291ce7 in > > SystemDictionary::resolve_from_stream(class_name=0x7f0ee40243f0, > > class_loader=..., protection_domain=...,d__=0x7f0f04001000) at > > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionaryShared.cpp:656 > > #1? 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream > > (class_name=0x7f0ee40243f0, class_loader=..., protection_doma > > in=..., > >? ? ? st=0x7f0f0a5f3850, verify=true, __the_thread__=0x7f0f04001000) > >? ? ? at > > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionary.cpp:1234 > > #2? 0x00007f1126f3cadb in jvm_define_class_common > (env=0x7f0f04001220, > > name=0x7f0f0a5f3e60 "com/google/common/collect/Iterato > > rs$3", > >? ? ? loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 > "\312\376\272\276", len=943, > > pd=0x7f0f0a5f3f48, > >? ? ? source=0x7f0f0a5f3a60 > "jar:file:/home/<...>/lib/guava-19.0.jar!/", > > verify=1 '\001', __the_thread__=0x7f0f04001000) at > > > /home/yumin.qi/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prims/jvm.cpp:1082 > > #3? 0x00007f1126f3d019 in JVM_DefineClassWithSource > (env=0x7f0f04001220, > > name=0x7f0f0a5f3e60 "com/google/common/collect/Itera > > tors$3", > >? ? ? loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 > "\312\376\272\276", len=943, > > pd=0x7f0f0a5f3f48, > >? ? ? source=0x7f0f0a5f3a60 > "jar:file:/home/<...>/lib/guava-19.0.jar!/") at > > /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prim/jvm.cpp:1102 > > #4? 0x00007f112581214f in Java_java_lang_ClassLoader_defineClass1 () > >? ? ?from > > > /home/ws/openjdk/8/jdk8u/build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/jre/lib/amd64/libjava.so > > #5? 0x00007f11118f5402 in ?? () > > #6? 0x00007f0f0a5f3f48 in ?? () > > #7? 0x00007f0f0a5f3f70 in ?? () > > #8? 0x0000000755dbbc28 in ?? () > > > > The class name is com.google.common.collect.Iterators$3, and it is an > > anonymous class. > > I'm confused. Are you talking about Java level anonymous classes or VM > anonymous classes as created by Unsafe.defineAnonymousClass? Only VM > anonymous classes have a "host class". Java level "anonymous classes" > are just regular classes. > > David > ----- > > > > > This is an example using Guava. I also can reproduce with jdk13. > > > > The field after parsing: > > > >? ?_nonstatic_oop_map_size = 1, > >? ? _is_marked_dependent = false, > >? ? _has_unloaded_dependent = false, > >? ? _misc_flags = 38,? ? ? ////// <------------ not set for anonymous > >? ? _minor_version = 0, > >? ? _major_version = 50, > >? ? _init_thread = 0x0, > >? ? _vtable_len = 8, > >? ? _itable_len = 8, > > > >? ? This path is from a custom loader defining a anonymous class, > does not > > set anonymous correctly for the flag. Is this a bug? If in java land, > > supply a host as parameter,? it can be set correctly in VM part. > Should I > > file a bug for it? > > > > Thanks > > Yumin > > > From christoph.langer at sap.com Fri Jan 25 14:03:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 14:03:10 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> Message-ID: <37026c1f489b4228b0956f50a870b13b@sap.com> Hi Matthias, thanks for bringing this enhancement into the OpenJDK. I have a few wishes, though. First of all, I think this method fits perfectly well to jli_util. It does not really have to do with the logic of parsing manifests but it is rather an enhanced open function. So you should declare a function "int JLI_Open (const char* name, int flags);" in jli_util.h. Then, create a platform file jli_util_md.c, at least for Windows (instead of parse_manifest_md.c). I also rather like the idea to symmetrically create a jli_util_md.c file for Unix, although it has very little contents. Alternatively, you can maybe consider using "#define JLI_Open open" in the header file for the Unix version. As for the Windows implementation I have a few stylistic comments: 40 if (fd == -1 && ENOENT == errno) { I'd rather like 40 if (fd == -1 && errno == ENOENT) { 41 #define ELP_PREFIX L"\\\\?\\" Can you move this line out of the function, after the includes? Can you change the indentation of: 64 wfullname_with_prefix = (wchar_t*) malloc((wcslen(ELP_PREFIX) + wfullnamelen + 1) 65 * sizeof(wchar_t)); to: 64 wfullname_with_prefix = (wchar_t*) malloc( 65 (wcslen(ELP_PREFIX) + wfullnamelen + 1) * sizeof(wchar_t)); I also don't like the label/goto syntax so much... don't know if you would want to rewrite this a bit? Maybe you can then also pick up Alan's suggestion to check for the length of 247 and only add the prefix in case it's equal or larger which would save you a malloc operation. Thanks Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 24. Januar 2019 17:19 > To: Alan Bateman ; core-libs- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > > Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > WIN32 ? > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > function open_jarfile ? > I considered this, but did not like the idea to add a separate file for UNIX just > for the small function . > > Your suggestion to use FILE_SHARE_READ is probably the right way to do it , > I changed this, second webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > Best Regards, Matthias > > > > -----Original Message----- > > From: Alan Bateman > > Sent: Donnerstag, 24. Januar 2019 13:04 > > To: Baesken, Matthias ; core-libs- > > dev at openjdk.java.net > > Subject: Re: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > On 23/01/2019 08:29, Baesken, Matthias wrote: > > > Hello Alan, here is a second webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/ > > > > > > I moved the Windows-only code into a new file > > > > > > src/java.base/windows/native/libjli/parse_manifest_md.c > > > > > Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > WIN32 ? > > > > On the Windows version then your patch is low risk but the retrying > > after ENOENT is a bit icky. I'm just wondering if you've considered > > creating an absolute path and adding the prefix when the length is 247 > > or greater. I also wonder about the share mode specified to CreateFileW > > where it might be better to specify FILE_SHARE_READ at least so that you > > don't exclude other processes from also opening the file to read. > > > > -Alan From christoph.langer at sap.com Fri Jan 25 14:30:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 14:30:30 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: Message-ID: Hi Steve, in general this change looks reasonable to me. I think in case there is an error, it would be useful to get a printout of the expected/vs actual strings like these lines: 43 //System.out.print(baos.toString()); 44 //System.out.print(expectedResult); I'll take the change and run it through our test system and see if we see any issues. Is it ok for you if we do the fix just in the jdk branch (JDK13) or are you particularly interested in getting this fixed for jdk12 and/or jdk11u? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Steve Groeger > Sent: Freitag, 25. Januar 2019 12:40 > To: core-libs > Subject: RFR: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java > passes even when test should fail > > Hi all, > > I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > test. > Using jtreg to run this test the test passes no matter what happens within > the test. > Have raised an issue for this: > https://bugs.openjdk.java.net/browse/JDK-8217777 > > I think the issue is 2 fold: > 1) the test check the expected vs. actual and throws an exception but this > is caught later in the code, which causes the test to pass as there is no > exception thrown. > 2) the exported XML now contains a `standalone="no"` entry in the XML > prologue, which is not in the expected XML. > > I have generated a webrev to resolve this: > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ > > This occurs on jdk11 but is probabaly also an issue on other releases ie > jdk8u, jdk12, jdk etc > > Please could someone review this webrev and sponsor this chnage for me as > I am unable to commit this myself. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From GROEGES at uk.ibm.com Fri Jan 25 14:57:15 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 25 Jan 2019 14:57:15 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: Message-ID: Hi Christoph, Thanks for looking at this. These lines 43 //System.out.print(baos.toString()); 44 //System.out.print(expectedResult); were commented out in the current code but if you think displaying this info would be good then I can un-comment them. I think only fixing this in the jdk (JDK13) branch is OK. If it is later determined that this is really needed in jdk12 or jdk11u , then I can always request a backport. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: Steve Groeger Cc: core-libs Date: 25/01/2019 14:30 Subject: RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail Hi Steve, in general this change looks reasonable to me. I think in case there is an error, it would be useful to get a printout of the expected/vs actual strings like these lines: 43 //System.out.print(baos.toString()); 44 //System.out.print(expectedResult); I'll take the change and run it through our test system and see if we see any issues. Is it ok for you if we do the fix just in the jdk branch (JDK13) or are you particularly interested in getting this fixed for jdk12 and/or jdk11u? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Steve Groeger > Sent: Freitag, 25. Januar 2019 12:40 > To: core-libs > Subject: RFR: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java > passes even when test should fail > > Hi all, > > I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > test. > Using jtreg to run this test the test passes no matter what happens within > the test. > Have raised an issue for this: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217777&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=UJRfQmkVQXm0xJJoewO9mmR8OiJfiMCZyz_Ky1Ucp5E&e= > > I think the issue is 2 fold: > 1) the test check the expected vs. actual and throws an exception but this > is caught later in the code, which causes the test to pass as there is no > exception thrown. > 2) the exported XML now contains a `standalone="no"` entry in the XML > prologue, which is not in the expected XML. > > I have generated a webrev to resolve this: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8217777_webrev.00_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=k81f_C-Jgejb860DUQscboWahNDRMgOCLnLQnL-ZQ4Y&e= > > This occurs on jdk11 but is probabaly also an issue on other releases ie > jdk8u, jdk12, jdk etc > > Please could someone review this webrev and sponsor this chnage for me as > I am unable to commit this myself. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Fri Jan 25 15:23:44 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2019 10:23:44 -0500 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: Message-ID: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> Hi Steve, Add 8217777 to the @bug line; it helps track and run tests that fixed bugs? (jtreg -bug:8217777) +1 printing the expected and actual (when a failure occurs). Looks fine overall. Thanks, Roger On 01/25/2019 09:57 AM, Steve Groeger wrote: > Hi Christoph, > > Thanks for looking at this. > > These lines > > 43 //System.out.print(baos.toString()); > 44 //System.out.print(expectedResult); > > were commented out in the current code but if you think displaying this > info would be good then I can un-comment them. > > I think only fixing this in the jdk (JDK13) branch is OK. > If it is later determined that this is really needed in jdk12 or jdk11u , > then I can always request a backport. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: "Langer, Christoph" > To: Steve Groeger > Cc: core-libs > Date: 25/01/2019 14:30 > Subject: RE: JDK-8217777 TEST_BUG: > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > Hi Steve, > > in general this change looks reasonable to me. > > I think in case there is an error, it would be useful to get a printout of > the expected/vs actual strings like these lines: > 43 //System.out.print(baos.toString()); > 44 //System.out.print(expectedResult); > > I'll take the change and run it through our test system and see if we see > any issues. > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > you particularly interested in getting this fixed for jdk12 and/or jdk11u? > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Steve Groeger >> Sent: Freitag, 25. Januar 2019 12:40 >> To: core-libs >> Subject: RFR: JDK-8217777 TEST_BUG: > jdk/java/util/prefs/ExportSubtree.java >> passes even when test should fail >> >> Hi all, >> >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java >> test. >> Using jtreg to run this test the test passes no matter what happens > within >> the test. >> Have raised an issue for this: >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217777&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=UJRfQmkVQXm0xJJoewO9mmR8OiJfiMCZyz_Ky1Ucp5E&e= > >> I think the issue is 2 fold: >> 1) the test check the expected vs. actual and throws an exception but > this >> is caught later in the code, which causes the test to pass as there is > no >> exception thrown. >> 2) the exported XML now contains a `standalone="no"` entry in the XML >> prologue, which is not in the expected XML. >> >> I have generated a webrev to resolve this: >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8217777_webrev.00_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=k81f_C-Jgejb860DUQscboWahNDRMgOCLnLQnL-ZQ4Y&e= > >> This occurs on jdk11 but is probabaly also an issue on other releases ie >> jdk8u, jdk12, jdk etc >> >> Please could someone review this webrev and sponsor this chnage for me > as >> I am unable to commit this myself. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mandy.chung at oracle.com Fri Jan 25 16:12:22 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 Jan 2019 08:12:22 -0800 Subject: Anonymous class In-Reply-To: <684252eb-391c-4ca1-a164-090c33160c2c@oracle.com> References: <8ccbfa3b-6297-d76c-97db-28121c965fdd@oracle.com> <684252eb-391c-4ca1-a164-090c33160c2c@oracle.com> Message-ID: <089ba997-998f-cf3e-0d83-433015797335@oracle.com> On 1/25/19 5:37 AM, David Holmes wrote: >> >> ???? > The class name is com.google.common.collect.Iterators$3, and >> it is an >> ???? > anonymous class. >> >> ??? I'm confused. Are you talking about Java level anonymous classes >> or VM >> ??? anonymous classes as created by Unsafe.defineAnonymousClass? Only VM >> ??? anonymous classes have a "host class". Java level "anonymous >> classes" >> ??? are just regular classes. Based on the class name com.google.common.collect.Iterators$3, this is a Java anonymous class.? As the stack trace shows, it's defined from JVM_DefineClassWithSource. VM anonymous class is defined via a different VM entry point Unsafe.defineAnonymousClass, as David said. No host class for this class is right if it's Java anonymous? class. You can use -Djdk.internal.lambda.dumpProxyClasses= that will dump the generated lambda proxy classes to the specified path (mkdir path first).? This might help Mandy From GROEGES at uk.ibm.com Fri Jan 25 16:21:04 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 25 Jan 2019 16:21:04 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> Message-ID: Hi Roger, Thanks. Have included the bug number to the @bug line and have included the expected and actual output when there is an error. Have generated a new webrev here: http://cr.openjdk.java.net/~sgroeger/8217777/webrev.01/ Hope this is now OK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 25/01/2019 15:30 Subject: Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail Sent by: "core-libs-dev" Hi Steve, Add 8217777 to the @bug line; it helps track and run tests that fixed bugs (jtreg -bug:8217777) +1 printing the expected and actual (when a failure occurs). Looks fine overall. Thanks, Roger On 01/25/2019 09:57 AM, Steve Groeger wrote: > Hi Christoph, > > Thanks for looking at this. > > These lines > > 43 //System.out.print(baos.toString()); > 44 //System.out.print(expectedResult); > > were commented out in the current code but if you think displaying this > info would be good then I can un-comment them. > > I think only fixing this in the jdk (JDK13) branch is OK. > If it is later determined that this is really needed in jdk12 or jdk11u , > then I can always request a backport. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: "Langer, Christoph" > To: Steve Groeger > Cc: core-libs > Date: 25/01/2019 14:30 > Subject: RE: JDK-8217777 TEST_BUG: > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > Hi Steve, > > in general this change looks reasonable to me. > > I think in case there is an error, it would be useful to get a printout of > the expected/vs actual strings like these lines: > 43 //System.out.print(baos.toString()); > 44 //System.out.print(expectedResult); > > I'll take the change and run it through our test system and see if we see > any issues. > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > you particularly interested in getting this fixed for jdk12 and/or jdk11u? > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Steve Groeger >> Sent: Freitag, 25. Januar 2019 12:40 >> To: core-libs >> Subject: RFR: JDK-8217777 TEST_BUG: > jdk/java/util/prefs/ExportSubtree.java >> passes even when test should fail >> >> Hi all, >> >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java >> test. >> Using jtreg to run this test the test passes no matter what happens > within >> the test. >> Have raised an issue for this: >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217777&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=UJRfQmkVQXm0xJJoewO9mmR8OiJfiMCZyz_Ky1Ucp5E&e= > >> I think the issue is 2 fold: >> 1) the test check the expected vs. actual and throws an exception but > this >> is caught later in the code, which causes the test to pass as there is > no >> exception thrown. >> 2) the exported XML now contains a `standalone="no"` entry in the XML >> prologue, which is not in the expected XML. >> >> I have generated a webrev to resolve this: >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8217777_webrev.00_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=8dKzRNI_r6CzuhGDpG6M4U24tdu2IEH8qUbdohhixek&s=k81f_C-Jgejb860DUQscboWahNDRMgOCLnLQnL-ZQ4Y&e= > >> This occurs on jdk11 but is probabaly also an issue on other releases ie >> jdk8u, jdk12, jdk etc >> >> Please could someone review this webrev and sponsor this chnage for me > as >> I am unable to commit this myself. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Fri Jan 25 16:52:22 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2019 11:52:22 -0500 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> Message-ID: <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> +1, Thanks, Roger On 01/25/2019 11:21 AM, Steve Groeger wrote: > Hi Roger, > > Thanks. Have included the bug number to the @bug line and have > included the expected and actual output when there is an error. > > Have generated a new webrev here: > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.01/ > > > Hope this is now OK. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net > Date: 25/01/2019 15:30 > Subject: Re: JDK-8217777 TEST_BUG: > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > Sent by: "core-libs-dev" > ------------------------------------------------------------------------ > > > > Hi Steve, > > Add 8217777 to the @bug line; it helps track and run tests that fixed > bugs? (jtreg -bug:8217777) > > +1 printing the expected and actual (when a failure occurs). > > Looks fine overall. > > Thanks, Roger > > > > On 01/25/2019 09:57 AM, Steve Groeger wrote: > > Hi Christoph, > > > > Thanks for looking at this. > > > > These lines > > > > 43 ? ? ? ? ? //System.out.print(baos.toString()); > > 44 ? ? ? ? ? //System.out.print(expectedResult); > > > > were commented out in the current code but if you think displaying this > > info would be good then I can un-comment them. > > > > I think only fixing this in the jdk (JDK13) branch is OK. > > If it is later determined that this is really needed in jdk12 or > jdk11u , > > then I can always request a backport. > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > From: ? "Langer, Christoph" > > To: ? ? Steve Groeger > > Cc: ? ? core-libs > > Date: ? 25/01/2019 14:30 > > Subject: ? ? ? ?RE: JDK-8217777 TEST_BUG: > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > > > > > Hi Steve, > > > > in general this change looks reasonable to me. > > > > I think in case there is an error, it would be useful to get a > printout of > > the expected/vs actual strings like these lines: > > 43 ? ? ? ? ? //System.out.print(baos.toString()); > > 44 ? ? ? ? ? //System.out.print(expectedResult); > > > > I'll take the change and run it through our test system and see if > we see > > any issues. > > > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > > you particularly interested in getting this fixed for jdk12 and/or > jdk11u? > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: core-libs-dev On Behalf > >> Of Steve Groeger > >> Sent: Freitag, 25. Januar 2019 12:40 > >> To: core-libs > >> Subject: RFR: JDK-8217777 TEST_BUG: > > jdk/java/util/prefs/ExportSubtree.java > >> passes even when test should fail > >> > >> Hi all, > >> > >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > >> test. > >> Using jtreg to run this test the test passes no matter what happens > > within > >> the test. > >> Have raised an issue for this: > >> > > https://bugs.openjdk.java.net/browse/JDK-8217777 > > > >> I think the issue is 2 fold: > >> 1) the test check the expected vs. actual and throws an exception but > > this > >> is caught later in the code, which causes the test to pass as there is > > no > >> exception thrown. > >> 2) the exported XML now contains a `standalone="no"` entry in the XML > >> prologue, which is not in the expected XML. > >> > >> I have generated a webrev to resolve this: > >> > > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ > > > > >> This occurs on jdk11 but is probabaly also an issue on other > releases ie > >> jdk8u, jdk12, jdk ?etc > >> > >> Please could someone review this webrev and sponsor this chnage for me > > as > >> I am unable to commit this myself. > >> > >> Thanks > >> Steve Groeger > >> IBM Runtime Technologies > >> Hursley, Winchester > >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > >> Fax (44) 1962 816800 > >> Lotus Notes: Steve Groeger/UK/IBM > >> Internet: groeges at uk.ibm.com > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> 3AU > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> 3AU > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From lance.andersen at oracle.com Fri Jan 25 17:03:34 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 12:03:34 -0500 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> Message-ID: <5174FD37-53F5-4C20-9178-DE44840B532B@oracle.com> > On Jan 25, 2019, at 3:55 AM, Alan Bateman wrote: > > > > On 25/01/2019 00:11, Lance Andersen wrote: >>> On Jan 24, 2019, at 6:20 PM, Mandy Chung wrote: >>> >>> >>> >>> On 1/24/19 1:55 PM, Lance Andersen wrote: >>>>> Alternatively you can simply do: >>>>> PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); >>>>> return AccessController.doPrivileged(pea); >>>>> >>>>> In this case, limited doPrivileged does not make whole lot of difference jdk.zip explicitly grants for limited permissions and this doPrivileged block is one single operation, toRealPath. >>>> Do you have a preference here either way? I had that originally but changed it to make it clearer why it was done. >>> For this simple case, I would avoid using limited doPrivileged. >> Okie Dokie, I made the change and also ran optimize imports on the test: http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html >> > Here's an alternative that avoids the cast, it might be a bit more readable. > > PrivilegedExceptionAction action = tempPath::toRealPath; > zfpath = AccessController.doPrivileged(action); > > In the test then you it might be clearer to rename ZIPFS_MAP to ZIPFS_OPTIONS. Okie Dokie part 2 ;-) Updates can be found here: http://cr.openjdk.java.net/~lancea/8210469/webrev.02/index.html Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From javalists at cbfiddle.com Fri Jan 25 17:29:57 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 25 Jan 2019 09:29:57 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> Message-ID: My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? It may not have been an issue to you, but it was to me when I discovered my program could not handle certain file names. I?ll bet I?m not the last person to assume that a primitive named GetStringUTFChars returns UTF. I have fixed my code, so its not an issue for me any more, but it seems like an unnecessary tarpit awaiting the unwary. Just my 2c. Alan > On Jan 24, 2019, at 10:04 PM, David Holmes wrote: > > On 25/01/2019 4:39 am, Alan Snyder wrote: >> Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. >> What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? > > Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. > > The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: > > https://bugs.openjdk.java.net/browse/JDK-5030776 > > so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. > > Cheers, > David > ----- > > >> Alan >>> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >>> >>> Hi Alan, >>> >>> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >>> as used by the VM internally for historical reasons. >>> >>> See answers to this related question on SO (which contains links to official docs): >>> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >>> >>> HTH >>> >>> /Claes >>> >>> On 2019-01-24 19:23, Alan Snyder wrote: >>>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>>> >>>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>>> >>>> For example, where String.getBytes() returns >>>> >>>> -16 -97 -115 -69 >>>> >>>> GetStringUTFChars returns: >>>> >>>> -19 -96 -68 -19 -67 -69 >>>> >>>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>>> >>>> (Tested in JDK 9, 11, and a fairly recent 12) >>>> >>> > From huizhe.wang at oracle.com Fri Jan 25 17:47:12 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 25 Jan 2019 09:47:12 -0800 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException Message-ID: <5C4B4BA0.7050704@oracle.com> Please review a fix for XMLStreamWriter.setDefaultNamespace that throws NullPointerException when the value is null. JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ Thanks, Joe From lance.andersen at oracle.com Fri Jan 25 17:52:02 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 12:52:02 -0500 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException In-Reply-To: <5C4B4BA0.7050704@oracle.com> References: <5C4B4BA0.7050704@oracle.com> Message-ID: +1 > On Jan 25, 2019, at 12:47 PM, Joe Wang wrote: > > Please review a fix for XMLStreamWriter.setDefaultNamespace that throws NullPointerException when the value is null. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From kustaa.nyholm at sparetimelabs.com Fri Jan 25 18:09:45 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Fri, 25 Jan 2019 20:09:45 +0200 Subject: jpackage windows 32 bit jre In-Reply-To: <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> Message-ID: <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> I tried and succeeded in using the jpackage from jdk13 (not really) to package 32 bit java8 for Windows. Everything goes nicely at build time and when I double click the .exe an install is performed, however the resulting installed .exe fails with "Failed to find library C:\Program Files\jDraft\runtime\bin\jli.dll" But that file is there, though it is a bit suspicious that it is not in the Program Files(x86). Should it be possible to embed 32 bit JRE or am I doomed to fail? wbr Kusti From huizhe.wang at oracle.com Fri Jan 25 18:20:28 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 25 Jan 2019 10:20:28 -0800 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <5C4226C6.40608@oracle.com> References: <5C421552.4030607@oracle.com> <5C4226C6.40608@oracle.com> Message-ID: <5C4B536C.4010003@oracle.com> Please review an updated webrev for this change. In the update, the change to XMLDocumentFragmentScannerImpl was to add the default value when calling getFeature at line 606 that allowed the previous commented tests to pass properly. The other change was to LSSerializerTest. Refer to the results (RESULT_TRUE and RESULT_FALSE at line 250 and 271), before the change, it outputted both entity references and the expanded text, after the change, it's either the EntityReference or Text, which makes better sense. JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ Thanks, Joe On 1/18/19, 11:19 AM, Joe Wang wrote: > Please hold on reviewing the webrevs as the tests passed while the new > tests were commented out as Lance pointed out. > > Thanks, > Joe > > On 1/18/19, 10:05 AM, Joe Wang wrote: >> Please review a change to the DOM parser so that it complies with the >> specification with regard to the ExpandEntityReferences feature. This >> change corrects the behavior so that the resulting DOM tree includes >> EntityReference nodes but not the expanded Text nodes when the >> feature is off. It also means that the DOM parser will not attempt to >> read entity references if any. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ >> >> Thanks, >> Joe From deepak.kejriwal at oracle.com Fri Jan 25 18:35:48 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 25 Jan 2019 10:35:48 -0800 (PST) Subject: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11 Message-ID: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 11 is planned. JDK-8216546 focuses on the java.lang.Character specification changes. The specification is modified to allow the new Japanese Era code point (U+32FF). This code point is expected to be assigned in version 12.1 of the Unicode Standard. Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. [0]: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html Regards, Deepak From deepak.kejriwal at oracle.com Fri Jan 25 18:37:17 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 25 Jan 2019 10:37:17 -0800 (PST) Subject: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 Message-ID: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216396/"http://cr.openjdk.java.net/~rpatil/8216396/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 8 is planned. JDK-8216396 focuses on the java.lang.Character specification changes. The specification is modified to allow the new Japanese Era code point (U+32FF), expected to be assigned in version 12.1 of the Unicode Standard, and to allow currency code points introduced in version 10.0. Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. [0]: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html Regards, Deepak From kevin.rushforth at oracle.com Fri Jan 25 18:41:39 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 25 Jan 2019 10:41:39 -0800 Subject: jpackage windows 32 bit jre In-Reply-To: <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> Message-ID: jpackage will only support JDK 11 and later. It is not a goal to be able to embed a JRE from JDK 8. For that you should continue to use the old javapackager tool that ships with JDK 8. So the fact that it "seems to work" up to a point is an accident. We should probably check for that case and fail with an informative error message. Independent of the above, Windows 32-bit is not a supported platform in JDK 11 or later so we have not done any testing of running jpackage with a 32-bit JDK (nor do we intend to). -- Kevin On 1/25/2019 10:09 AM, Kustaa Nyholm wrote: > I tried and succeeded in using the jpackage from jdk13 (not really) to package 32 bit java8 for Windows. > Everything goes nicely at build time and when I double click the .exe an install is performed, > however the resulting installed .exe fails with "Failed to find library C:\Program Files\jDraft\runtime\bin\jli.dll" > But that file is there, though it is a bit suspicious that it is not in the Program Files(x86). > > Should it be possible to embed 32 bit JRE or am I doomed to fail? > > wbr Kusti > From andy.herrick at oracle.com Fri Jan 25 18:45:57 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 25 Jan 2019 13:45:57 -0500 Subject: jpackage windows 32 bit jre In-Reply-To: <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> Message-ID: Packing JDK8 runtime, or packaging app with JDK8 runtime is not supported by jpackage. It is recommended to package JDK8 apps using the javafxpackager in JDK8. It is interesting you got this far. I tried this myself and get a 32 bit jre8 installed (by default in the wrong place, C:\Program Files\jre8 instead of C:\Program Files (x86)\jre8) but otherwise seems to work (I can run "javaws -viewer" from these to invoke the JCP) > jpackage create-jre-installer exe \ > --input empty-dir \ > --output output \ > --name jre8 \ > --runtime-image jre8 \ /Andy On 1/25/2019 1:09 PM, Kustaa Nyholm wrote: > I tried and succeeded in using the jpackage from jdk13 (not really) to package 32 bit java8 for Windows. > Everything goes nicely at build time and when I double click the .exe an install is performed, > however the resulting installed .exe fails with "Failed to find library C:\Program Files\jDraft\runtime\bin\jli.dll" > But that file is there, though it is a bit suspicious that it is not in the Program Files(x86). > > Should it be possible to embed 32 bit JRE or am I doomed to fail? > > wbr Kusti > From daniel.fuchs at oracle.com Fri Jan 25 18:45:41 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jan 2019 18:45:41 +0000 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException In-Reply-To: <5C4B4BA0.7050704@oracle.com> References: <5C4B4BA0.7050704@oracle.com> Message-ID: <68461246-588f-428a-4a3d-f43f5f9d5a8c@oracle.com> Hi Joe, I was wondering whether: return Objects.equals(uri, defaultNamespace) would be more appropriate (or not) - given the action taken by setDefaultNamespace above? I mean - what if both uri and defaultNamespace are null? Just double checking - as I have no idea what would be the right thing to do :-) best regards, -- daniel On 25/01/2019 17:47, Joe Wang wrote: > Please review a fix for XMLStreamWriter.setDefaultNamespace that throws > NullPointerException when the value is null. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ > > Thanks, > Joe > From naoto.sato at oracle.com Fri Jan 25 19:11:31 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 25 Jan 2019 11:11:31 -0800 Subject: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: References: Message-ID: <887115c4-a289-3d69-f90b-4d76e6f67aa8@oracle.com> Looks good to me. Naoto On 1/25/19 10:35 AM, Deepak Kejriwal wrote: > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 > > Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ > > Summary: > > As per previous communication from Iris[0], a maintenance review for Java SE 11 is planned. JDK-8216546 focuses on the java.lang.Character specification changes. > > The specification is modified to allow the new Japanese Era code point (U+32FF). This code point is expected to be assigned in version 12.1 of the Unicode Standard. > > Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. > > [0]: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html > > > > > > Regards, > > Deepak > From naoto.sato at oracle.com Fri Jan 25 19:12:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 25 Jan 2019 11:12:08 -0800 Subject: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 In-Reply-To: References: Message-ID: Looks good to me. Naoto On 1/25/19 10:37 AM, Deepak Kejriwal wrote: > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 > > Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216396/"http://cr.openjdk.java.net/~rpatil/8216396/ > > Summary: > > As per previous communication from Iris[0], a maintenance review for Java SE 8 is planned. JDK-8216396 focuses on the java.lang.Character specification changes. > > The specification is modified to allow the new Japanese Era code point (U+32FF), expected to be assigned in version 12.1 of the Unicode Standard, and to allow currency code points introduced in version 10.0. > > Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. > > [0]: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html > > Regards, > > Deepak > From lance.andersen at oracle.com Fri Jan 25 19:22:46 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 14:22:46 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> Message-ID: <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> The CSR review suggested a slight update to the proposed wording: ??????? $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:20:51 2019 -0500 @@ -265,10 +265,11 @@ } /** - * Compares the specified Attributes object with this Map for equality. - * Returns true if the given object is also an instance of Attributes - * and the two Attributes objects represent the same mappings. - * + * Compares the specified object to the underlying + * {@linkplain java.util.Map Map} for equality. + * Returns true if the given object is also a Map + * and the two maps represent the same mappings. + * * @param o the Object to be compared * @return true if the specified Object is equal to this Map */ ????????? Best Lance > On Jan 22, 2019, at 7:47 PM, Lance Andersen wrote: > >> >> On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote: >> >> On 19/01/2019 12:46, Lance Andersen wrote: >>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>> @@ -265,9 +265,10 @@ >>> } >>> /** >>> - * Compares the specified Attributes object with this Map for equality. >>> - * Returns true if the given object is also an instance of Attributes >>> - * and the two Attributes objects represent the same mappings. >>> + * Compares the specified object with this Map for equality. >>> + * Returns true if the given object is also a Map >>> + * and the two objects represent the same Manifest >>> + * attribute name-value mappings. >>> >> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. > > I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 > > If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc > > Best > Lance >> >> -Alan > > > > > > > >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Fri Jan 25 19:23:36 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2019 14:23:36 -0500 Subject: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: <887115c4-a289-3d69-f90b-4d76e6f67aa8@oracle.com> References: <887115c4-a289-3d69-f90b-4d76e6f67aa8@oracle.com> Message-ID: <14bedb29-846c-eacb-94ae-949e8b126e18@oracle.com> +1 On 01/25/2019 02:11 PM, naoto.sato at oracle.com wrote: > Looks good to me. > > Naoto > > On 1/25/19 10:35 AM, Deepak Kejriwal wrote: >> Hi All, >> >> >> JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 >> >> Webrev: HYPERLINK >> "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ >> >> Summary: >> >> As per previous communication from Iris[0], a maintenance review for >> Java SE 11 is planned. JDK-8216546 focuses on the java.lang.Character >> specification changes. >> >> The specification is modified to allow the new Japanese Era code >> point (U+32FF). This code point is expected to be assigned in version >> 12.1 of the Unicode Standard. >> >> Specification changes are covered in this review. A follow up code >> review will be carried out for implementation changes. >> >> [0]: >> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html >> >> >> >> Regards, >> >> Deepak >> From Roger.Riggs at oracle.com Fri Jan 25 19:21:48 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2019 14:21:48 -0500 Subject: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 In-Reply-To: References: Message-ID: +1 On 01/25/2019 02:12 PM, naoto.sato at oracle.com wrote: > Looks good to me. > > Naoto > > On 1/25/19 10:37 AM, Deepak Kejriwal wrote: >> Hi All, >> >> >> JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 >> >> Webrev: HYPERLINK >> "http://cr.openjdk.java.net/%7Erpatil/8216396/"http://cr.openjdk.java.net/~rpatil/8216396/ >> >> Summary: >> >> As per previous communication from Iris[0], a maintenance review for >> Java SE 8 is planned. JDK-8216396 focuses on the java.lang.Character >> specification changes. >> >> The specification is modified to allow the new Japanese Era code >> point (U+32FF), expected to be assigned in version 12.1 of the >> Unicode Standard, and to allow currency code points introduced in >> version 10.0. >> >> Specification changes are covered in this review. A follow up code >> review will be carried out for implementation changes. >> >> [0]: >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html >> >> Regards, >> >> Deepak >> From Roger.Riggs at oracle.com Fri Jan 25 19:24:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2019 14:24:18 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> Message-ID: <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> Looks fine, Lance Roger On 01/25/2019 02:22 PM, Lance Andersen wrote: > The CSR review suggested a slight update to the proposed wording: > > ??????? > $ hg diff > diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java > --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:20:51 2019 -0500 > @@ -265,10 +265,11 @@ > } > > /** > - * Compares the specified Attributes object with this Map for equality. > - * Returns true if the given object is also an instance of Attributes > - * and the two Attributes objects represent the same mappings. > - * > + * Compares the specified object to the underlying > + * {@linkplain java.util.Map Map} for equality. > + * Returns true if the given object is also a Map > + * and the two maps represent the same mappings. > + * > * @param o the Object to be compared > * @return true if the specified Object is equal to this Map > */ > > ????????? > > Best > Lance >> On Jan 22, 2019, at 7:47 PM, Lance Andersen wrote: >> >>> On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote: >>> >>> On 19/01/2019 12:46, Lance Andersen wrote: >>>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>>> @@ -265,9 +265,10 @@ >>>> } >>>> /** >>>> - * Compares the specified Attributes object with this Map for equality. >>>> - * Returns true if the given object is also an instance of Attributes >>>> - * and the two Attributes objects represent the same mappings. >>>> + * Compares the specified object with this Map for equality. >>>> + * Returns true if the given object is also a Map >>>> + * and the two objects represent the same Manifest >>>> + * attribute name-value mappings. >>>> >>> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. >> I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 >> >> If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc >> >> Best >> Lance >>> -Alan >> > >> > > >> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From joe.darcy at oracle.com Fri Jan 25 19:28:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Jan 2019 11:28:34 -0800 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> Message-ID: To clarify the CSR comments, for "underlying map" I meant for "map" to be a link to the protected field named "map". Thanks, -Joe On 1/25/2019 11:24 AM, Roger Riggs wrote: > Looks fine, Lance > > Roger > > On 01/25/2019 02:22 PM, Lance Andersen wrote: >> The CSR review suggested a slight update to the proposed wording: >> >> ??????? >> $ hg diff >> diff -r 6130409b923e >> src/java.base/share/classes/java/util/jar/Attributes.java >> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu >> Jan 24 10:57:31 2019 -0800 >> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri >> Jan 25 14:20:51 2019 -0500 >> @@ -265,10 +265,11 @@ >> ????? } >> ? ????? /** >> -???? * Compares the specified Attributes object with this Map for >> equality. >> -???? * Returns true if the given object is also an instance of >> Attributes >> -???? * and the two Attributes objects represent the same mappings. >> -???? * >> +???? * Compares the specified object to the underlying >> +???? * {@linkplain java.util.Map Map} for equality. >> +???? * Returns true if the given object is also a Map >> +???? * and the two maps represent the same mappings. >> +???? * >> ?????? * @param o the Object to be compared >> ?????? * @return true if the specified Object is equal to this Map >> ?????? */ >> >> ????????? >> >> Best >> Lance >>> On Jan 22, 2019, at 7:47 PM, Lance Andersen >>> wrote: >>> >>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman >>>> wrote: >>>> >>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>> 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/Attributes.java >>>>> Thu Jan 17 13:46:12 2019 -0800 >>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java >>>>> Sat Jan 19 07:35:55 2019 -0500 >>>>> @@ -265,9 +265,10 @@ >>>>> ???? } >>>>> ?????? /** >>>>> -???? * Compares the specified Attributes object with this Map for >>>>> equality. >>>>> -???? * Returns true if the given object is also an instance of >>>>> Attributes >>>>> -???? * and the two Attributes objects represent the same mappings. >>>>> +???? * Compares the specified object with this Map for equality. >>>>> +???? * Returns true if the given object is also a Map >>>>> +???? * and the two objects represent the same Manifest >>>>> +???? * attribute name-value mappings. >>>>> >>>> I think this looks okay although I like Martin's suggestion to just >>>> inherit the javadoc as Attributes is a Map. >>> I had thought about that but felt that keeping the javadoc similar >>> to what it has been might be the better approach given it has been >>> around since JDK 1.2 >>> >>> If we were to inherit the javadoc, we should probably look at the >>> rest of the methods to see where else it would? make sense to >>> inherit the javadoc >>> >>> Best >>> Lance >>>> -Alan >>> >> > >>> >> > >>> >> > >>> >> >Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> > >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From huizhe.wang at oracle.com Fri Jan 25 19:34:49 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 25 Jan 2019 11:34:49 -0800 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException In-Reply-To: <68461246-588f-428a-4a3d-f43f5f9d5a8c@oracle.com> References: <5C4B4BA0.7050704@oracle.com> <68461246-588f-428a-4a3d-f43f5f9d5a8c@oracle.com> Message-ID: <5C4B64D9.9060700@oracle.com> Hi Daniel, True, Objects.equals is better. While the default setting generally won't be null, it's always good to cover all the bases. Updated: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev02/ Previous: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev01/ Thanks, Joe On 1/25/19, 10:45 AM, Daniel Fuchs wrote: > Hi Joe, > > I was wondering whether: > > return Objects.equals(uri, defaultNamespace) > > would be more appropriate (or not) - given the action taken by > setDefaultNamespace above? > > I mean - what if both uri and defaultNamespace are null? > > Just double checking - as I have no idea what would be the > right thing to do :-) > > best regards, > > -- daniel > > On 25/01/2019 17:47, Joe Wang wrote: >> Please review a fix for XMLStreamWriter.setDefaultNamespace that >> throws NullPointerException when the value is null. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ >> >> Thanks, >> Joe >> > From lance.andersen at oracle.com Fri Jan 25 19:44:53 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 14:44:53 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> Message-ID: <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> Thank you Joe. So the change is (see bolded change): $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:44:12 2019 -0500 @@ -265,9 +265,10 @@ } /** - * Compares the specified Attributes object with this Map for equality. - * Returns true if the given object is also an instance of Attributes - * and the two Attributes objects represent the same mappings. + * Compares the specified object to the underlying + * {@linkplain map map} for equality. + * Returns true if the given object is also a Map + * and the two maps represent the same mappings. * * @param o the Object to be compared * @return true if the specified Object is equal to this Map > On Jan 25, 2019, at 2:28 PM, Joe Darcy wrote: > > To clarify the CSR comments, for "underlying map" I meant for "map" to be a link to the protected field named "map". > > Thanks, > > -Joe > > On 1/25/2019 11:24 AM, Roger Riggs wrote: >> Looks fine, Lance >> >> Roger >> >> On 01/25/2019 02:22 PM, Lance Andersen wrote: >>> The CSR review suggested a slight update to the proposed wording: >>> >>> ??????? >>> $ hg diff >>> diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java >>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 >>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:20:51 2019 -0500 >>> @@ -265,10 +265,11 @@ >>> } >>> /** >>> - * Compares the specified Attributes object with this Map for equality. >>> - * Returns true if the given object is also an instance of Attributes >>> - * and the two Attributes objects represent the same mappings. >>> - * >>> + * Compares the specified object to the underlying >>> + * {@linkplain java.util.Map Map} for equality. >>> + * Returns true if the given object is also a Map >>> + * and the two maps represent the same mappings. >>> + * >>> * @param o the Object to be compared >>> * @return true if the specified Object is equal to this Map >>> */ >>> >>> ????????? >>> >>> Best >>> Lance >>>> On Jan 22, 2019, at 7:47 PM, Lance Andersen wrote: >>>> >>>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote: >>>>> >>>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>>>>> @@ -265,9 +265,10 @@ >>>>>> } >>>>>> /** >>>>>> - * Compares the specified Attributes object with this Map for equality. >>>>>> - * Returns true if the given object is also an instance of Attributes >>>>>> - * and the two Attributes objects represent the same mappings. >>>>>> + * Compares the specified object with this Map for equality. >>>>>> + * Returns true if the given object is also a Map >>>>>> + * and the two objects represent the same Manifest >>>>>> + * attribute name-value mappings. >>>>>> >>>>> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. >>>> I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 >>>> >>>> If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc >>>> >>>> Best >>>> Lance >>>>> -Alan >>>> > >>>> > > >>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com > >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Fri Jan 25 19:49:19 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Jan 2019 11:49:19 -0800 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> Message-ID: <4ec46d89-b969-045b-3d90-06d2bf39bce6@oracle.com> Hi Lance, Assuming the javadoc renders as expected, the new version looks good to me :-) Thanks, -Joe On 1/25/2019 11:44 AM, Lance Andersen wrote: > Thank you Joe. > > So the change is (see bolded change): > > $ hg diff > diff -r 6130409b923e > src/java.base/share/classes/java/util/jar/Attributes.java > --- a/src/java.base/share/classes/java/util/jar/Attributes.javaThu Jan > 24 10:57:31 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.javaFri Jan > 25 14:44:12 2019 -0500 > @@ -265,9 +265,10 @@ > ?? ? } > > ?? ? /** > - ? ? * Compares the specified Attributes object with this Map for > equality. > - ? ? * Returns true if the given object is also an instance of Attributes > - ? ? * and the two Attributes objects represent the same mappings. > + ? ? * Compares the specified object to the underlying > + ? ? * *{@linkplain map map}* for equality. > + ? ? * Returns true if the given object is also a Map > + ? ? * and the two maps represent the same mappings. > ? ? ? * > ? ? ? * @param o the Object to be compared > ? ? ? * @return true if the specified Object is equal to this Map > >> On Jan 25, 2019, at 2:28 PM, Joe Darcy > > wrote: >> >> To clarify the CSR comments, for "underlying map" I meant for "map" >> to be a link to the protected field named "map". >> >> Thanks, >> >> -Joe >> >> On 1/25/2019 11:24 AM, Roger Riggs wrote: >>> Looks fine, Lance >>> >>> Roger >>> >>> On 01/25/2019 02:22 PM, Lance Andersen wrote: >>>> The CSR review suggested a slight update to the proposed wording: >>>> >>>> ??????? >>>> $ hg diff >>>> diff -r 6130409b923e >>>> src/java.base/share/classes/java/util/jar/Attributes.java >>>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu >>>> Jan 24 10:57:31 2019 -0800 >>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri >>>> Jan 25 14:20:51 2019 -0500 >>>> @@ -265,10 +265,11 @@ >>>> ????? } >>>> ? ????? /** >>>> -???? * Compares the specified Attributes object with this Map for >>>> equality. >>>> -???? * Returns true if the given object is also an instance of >>>> Attributes >>>> -???? * and the two Attributes objects represent the same mappings. >>>> -???? * >>>> +???? * Compares the specified object to the underlying >>>> +???? * {@linkplain java.util.Map Map} for equality. >>>> +???? * Returns true if the given object is also a Map >>>> +???? * and the two maps represent the same mappings. >>>> +???? * >>>> ?????? * @param o the Object to be compared >>>> ?????? * @return true if the specified Object is equal to this Map >>>> ?????? */ >>>> >>>> ????????? >>>> >>>> Best >>>> Lance >>>>> On Jan 22, 2019, at 7:47 PM, Lance Andersen >>>>> > wrote: >>>>> >>>>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman >>>>>> > wrote: >>>>>> >>>>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>>>> 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/Attributes.java >>>>>>> Thu Jan 17 13:46:12 2019 -0800 >>>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java >>>>>>> Sat Jan 19 07:35:55 2019 -0500 >>>>>>> @@ -265,9 +265,10 @@ >>>>>>> ???? } >>>>>>> ?????? /** >>>>>>> -???? * Compares the specified Attributes object with this Map >>>>>>> for equality. >>>>>>> -???? * Returns true if the given object is also an instance of >>>>>>> Attributes >>>>>>> -???? * and the two Attributes objects represent the same mappings. >>>>>>> +???? * Compares the specified object with this Map for equality. >>>>>>> +???? * Returns true if the given object is also a Map >>>>>>> +???? * and the two objects represent the same Manifest >>>>>>> +???? * attribute name-value mappings. >>>>>>> >>>>>> I think this looks okay although I like Martin's suggestion to >>>>>> just inherit the javadoc as Attributes is a Map. >>>>> I had thought about that but felt that keeping the javadoc similar >>>>> to what it has been might be the better approach given it has been >>>>> around since JDK 1.2 >>>>> >>>>> If we were to inherit the javadoc, we should probably look at the >>>>> rest of the methods to see where else it would? make sense to >>>>> inherit the javadoc >>>>> >>>>> Best >>>>> Lance >>>>>> -Alan >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> >Lance >>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> > >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>>> >>> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Fri Jan 25 19:53:36 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 14:53:36 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <4ec46d89-b969-045b-3d90-06d2bf39bce6@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> <4ec46d89-b969-045b-3d90-06d2bf39bce6@oracle.com> Message-ID: Hi Joe yes I checked it in my local build and it does take me to map field via the link Best Lance > On Jan 25, 2019, at 2:49 PM, Joe Darcy wrote: > > Hi Lance, > > Assuming the javadoc renders as expected, the new version looks good to me :-) > > Thanks, > -Joe > On 1/25/2019 11:44 AM, Lance Andersen wrote: >> Thank you Joe. >> >> So the change is (see bolded change): >> >> $ hg diff >> diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java >> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 >> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:44:12 2019 -0500 >> @@ -265,9 +265,10 @@ >> } >> >> >> /** >> - * Compares the specified Attributes object with this Map for equality. >> - * Returns true if the given object is also an instance of Attributes >> - * and the two Attributes objects represent the same mappings. >> + * Compares the specified object to the underlying >> + * {@linkplain map map} for equality. >> + * Returns true if the given object is also a Map >> + * and the two maps represent the same mappings. >> * >> * @param o the Object to be compared >> * @return true if the specified Object is equal to this Map >> >>> On Jan 25, 2019, at 2:28 PM, Joe Darcy > wrote: >>> >>> To clarify the CSR comments, for "underlying map" I meant for "map" to be a link to the protected field named "map". >>> >>> Thanks, >>> >>> -Joe >>> >>> On 1/25/2019 11:24 AM, Roger Riggs wrote: >>>> Looks fine, Lance >>>> >>>> Roger >>>> >>>> On 01/25/2019 02:22 PM, Lance Andersen wrote: >>>>> The CSR review suggested a slight update to the proposed wording: >>>>> >>>>> ??????? >>>>> $ hg diff >>>>> diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java >>>>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 >>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:20:51 2019 -0500 >>>>> @@ -265,10 +265,11 @@ >>>>> } >>>>> /** >>>>> - * Compares the specified Attributes object with this Map for equality. >>>>> - * Returns true if the given object is also an instance of Attributes >>>>> - * and the two Attributes objects represent the same mappings. >>>>> - * >>>>> + * Compares the specified object to the underlying >>>>> + * {@linkplain java.util.Map Map} for equality. >>>>> + * Returns true if the given object is also a Map >>>>> + * and the two maps represent the same mappings. >>>>> + * >>>>> * @param o the Object to be compared >>>>> * @return true if the specified Object is equal to this Map >>>>> */ >>>>> >>>>> ????????? >>>>> >>>>> Best >>>>> Lance >>>>>> On Jan 22, 2019, at 7:47 PM, Lance Andersen > wrote: >>>>>> >>>>>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman > wrote: >>>>>>> >>>>>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>>>>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>>>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>>>>>>> @@ -265,9 +265,10 @@ >>>>>>>> } >>>>>>>> /** >>>>>>>> - * Compares the specified Attributes object with this Map for equality. >>>>>>>> - * Returns true if the given object is also an instance of Attributes >>>>>>>> - * and the two Attributes objects represent the same mappings. >>>>>>>> + * Compares the specified object with this Map for equality. >>>>>>>> + * Returns true if the given object is also a Map >>>>>>>> + * and the two objects represent the same Manifest >>>>>>>> + * attribute name-value mappings. >>>>>>>> >>>>>>> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. >>>>>> I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 >>>>>> >>>>>> If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc >>>>>> >>>>>> Best >>>>>> Lance >>>>>>> -Alan >>>>>> >> >>>>>> >> >> >>>>>> >>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com > >> >>>>> > >>>>> > > >>>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com > >>>>> >>>>> >>>>> >>>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Fri Jan 25 19:59:29 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 25 Jan 2019 11:59:29 -0800 Subject: [13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat Message-ID: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8217609 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8217609/webrev.00/ Although the behavior described in the issue is the expected one (i.e., CLDR currently does not provide names for the new era), supplementing the name in the CLDR data is desirable from the user's point of view. Naoto From lance.andersen at oracle.com Fri Jan 25 20:05:49 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 15:05:49 -0500 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> <4ec46d89-b969-045b-3d90-06d2bf39bce6@oracle.com> Message-ID: <93DBEA21-4458-42F8-AEDF-B4145CC3C5A7@oracle.com> While this works fine in the generated javadoc {@linkplain map map} This makes intellij a bit happier : {@linkplain Attributes#map map} --------------------- $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 15:04:03 2019 -0500 @@ -265,9 +265,10 @@ } /** - * Compares the specified Attributes object with this Map for equality. - * Returns true if the given object is also an instance of Attributes - * and the two Attributes objects represent the same mappings. + * Compares the specified object to the underlying + * {@linkplain Attributes#map map} for equality. + * Returns true if the given object is also a Map + * and the two maps represent the same mappings. * * @param o the Object to be compared * @return true if the specified Object is equal to this Map --------------------- > On Jan 25, 2019, at 2:53 PM, Lance Andersen wrote: > > Hi Joe > > yes I checked it in my local build and it does take me to map field via the link > > Best > Lance >> On Jan 25, 2019, at 2:49 PM, Joe Darcy > wrote: >> >> Hi Lance, >> >> Assuming the javadoc renders as expected, the new version looks good to me :-) >> >> Thanks, >> -Joe >> On 1/25/2019 11:44 AM, Lance Andersen wrote: >>> Thank you Joe. >>> >>> So the change is (see bolded change): >>> >>> $ hg diff >>> diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java >>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 >>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:44:12 2019 -0500 >>> @@ -265,9 +265,10 @@ >>> } >>> >>> >>> /** >>> - * Compares the specified Attributes object with this Map for equality. >>> - * Returns true if the given object is also an instance of Attributes >>> - * and the two Attributes objects represent the same mappings. >>> + * Compares the specified object to the underlying >>> + * {@linkplain map map} for equality. >>> + * Returns true if the given object is also a Map >>> + * and the two maps represent the same mappings. >>> * >>> * @param o the Object to be compared >>> * @return true if the specified Object is equal to this Map >>> >>>> On Jan 25, 2019, at 2:28 PM, Joe Darcy >> wrote: >>>> >>>> To clarify the CSR comments, for "underlying map" I meant for "map" to be a link to the protected field named "map". >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> On 1/25/2019 11:24 AM, Roger Riggs wrote: >>>>> Looks fine, Lance >>>>> >>>>> Roger >>>>> >>>>> On 01/25/2019 02:22 PM, Lance Andersen wrote: >>>>>> The CSR review suggested a slight update to the proposed wording: >>>>>> >>>>>> ??????? >>>>>> $ hg diff >>>>>> diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java >>>>>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 >>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:20:51 2019 -0500 >>>>>> @@ -265,10 +265,11 @@ >>>>>> } >>>>>> /** >>>>>> - * Compares the specified Attributes object with this Map for equality. >>>>>> - * Returns true if the given object is also an instance of Attributes >>>>>> - * and the two Attributes objects represent the same mappings. >>>>>> - * >>>>>> + * Compares the specified object to the underlying >>>>>> + * {@linkplain java.util.Map Map} for equality. >>>>>> + * Returns true if the given object is also a Map >>>>>> + * and the two maps represent the same mappings. >>>>>> + * >>>>>> * @param o the Object to be compared >>>>>> * @return true if the specified Object is equal to this Map >>>>>> */ >>>>>> >>>>>> ????????? >>>>>> >>>>>> Best >>>>>> Lance >>>>>>> On Jan 22, 2019, at 7:47 PM, Lance Andersen >> wrote: >>>>>>> >>>>>>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman >> wrote: >>>>>>>> >>>>>>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>>>>>> 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/Attributes.java Thu Jan 17 13:46:12 2019 -0800 >>>>>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 07:35:55 2019 -0500 >>>>>>>>> @@ -265,9 +265,10 @@ >>>>>>>>> } >>>>>>>>> /** >>>>>>>>> - * Compares the specified Attributes object with this Map for equality. >>>>>>>>> - * Returns true if the given object is also an instance of Attributes >>>>>>>>> - * and the two Attributes objects represent the same mappings. >>>>>>>>> + * Compares the specified object with this Map for equality. >>>>>>>>> + * Returns true if the given object is also a Map >>>>>>>>> + * and the two objects represent the same Manifest >>>>>>>>> + * attribute name-value mappings. >>>>>>>>> >>>>>>>> I think this looks okay although I like Martin's suggestion to just inherit the javadoc as Attributes is a Map. >>>>>>> I had thought about that but felt that keeping the javadoc similar to what it has been might be the better approach given it has been around since JDK 1.2 >>>>>>> >>>>>>> If we were to inherit the javadoc, we should probably look at the rest of the methods to see where else it would make sense to inherit the javadoc >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>>> -Alan >>>>>>> > >>> >>>>>>> > >>> > >>> >>>>>>> > >>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>>> Oracle Java Engineering >>>>>>> 1 Network Drive >>>>>>> Burlington, MA 01803 >>>>>>> Lance.Andersen at oracle.com > >> > >>> >>>>>> >> >>>>>> >> >> >>>>>> >>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com > >> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> > >>> > > >>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com > >>> >>> >>> > > > > > > > >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Fri Jan 25 20:09:55 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 25 Jan 2019 15:09:55 -0500 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException In-Reply-To: <5C4B64D9.9060700@oracle.com> References: <5C4B4BA0.7050704@oracle.com> <68461246-588f-428a-4a3d-f43f5f9d5a8c@oracle.com> <5C4B64D9.9060700@oracle.com> Message-ID: all good still > On Jan 25, 2019, at 2:34 PM, Joe Wang wrote: > > Hi Daniel, > > True, Objects.equals is better. While the default setting generally won't be null, it's always good to cover all the bases. > > Updated: > http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev02/ > > Previous: > http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev01/ > > Thanks, > Joe > > On 1/25/19, 10:45 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> I was wondering whether: >> >> return Objects.equals(uri, defaultNamespace) >> >> would be more appropriate (or not) - given the action taken by >> setDefaultNamespace above? >> >> I mean - what if both uri and defaultNamespace are null? >> >> Just double checking - as I have no idea what would be the >> right thing to do :-) >> >> best regards, >> >> -- daniel >> >> On 25/01/2019 17:47, Joe Wang wrote: >>> Please review a fix for XMLStreamWriter.setDefaultNamespace that throws NullPointerException when the value is null. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ >>> >>> Thanks, >>> Joe >>> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From kustaa.nyholm at sparetimelabs.com Fri Jan 25 20:27:20 2019 From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm) Date: Fri, 25 Jan 2019 22:27:20 +0200 Subject: jpackage windows 32 bit jre In-Reply-To: References: <6ab11b43b93647da910b410d3544957a@sap.com> <1aecd7b3-df21-d872-563b-6dd979d9485e@oracle.com> <2197815F-7CE7-491F-87BC-563BA703E63A@sparetimelabs.com> Message-ID: <8054A814-AA40-414E-9B55-8868CFDFD18A@sparetimelabs.com> Ok, thanks, I'm not expecting this sort of backward support, I have special case were I need the 32 bit and figured since I had all the infrastructure in place, what the heck, what have I got to lose ;) I will dig up my old java8 build and use that for this, thanks again! wbr Kusti > On 25 Jan 2019, at 20.45, Andy Herrick wrote: > > Packing JDK8 runtime, or packaging app with JDK8 runtime is not supported by jpackage. > > It is recommended to package JDK8 apps using the javafxpackager in JDK8. > > It is interesting you got this far. > > I tried this myself and get a 32 bit jre8 installed (by default in the wrong place, C:\Program Files\jre8 instead of C:\Program Files (x86)\jre8) but otherwise seems to work (I can run "javaws -viewer" from these to invoke the JCP) > >> jpackage create-jre-installer exe \ >> --input empty-dir \ >> --output output \ >> --name jre8 \ >> --runtime-image jre8 \ > > /Andy > > On 1/25/2019 1:09 PM, Kustaa Nyholm wrote: >> I tried and succeeded in using the jpackage from jdk13 (not really) to package 32 bit java8 for Windows. >> Everything goes nicely at build time and when I double click the .exe an install is performed, >> however the resulting installed .exe fails with "Failed to find library C:\Program Files\jDraft\runtime\bin\jli.dll" >> But that file is there, though it is a bit suspicious that it is not in the Program Files(x86). >> >> Should it be possible to embed 32 bit JRE or am I doomed to fail? >> >> wbr Kusti >> > From huizhe.wang at oracle.com Fri Jan 25 20:30:00 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 25 Jan 2019 12:30:00 -0800 Subject: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException In-Reply-To: References: <5C4B4BA0.7050704@oracle.com> <68461246-588f-428a-4a3d-f43f5f9d5a8c@oracle.com> <5C4B64D9.9060700@oracle.com> Message-ID: <5C4B71C8.2010804@oracle.com> Thanks Lance! -Joe On 1/25/19, 12:09 PM, Lance Andersen wrote: > all good still >> On Jan 25, 2019, at 2:34 PM, Joe Wang > > wrote: >> >> Hi Daniel, >> >> True, Objects.equals is better. While the default setting generally >> won't be null, it's always good to cover all the bases. >> >> Updated: >> http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev02/ >> >> >> Previous: >> http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev01/ >> >> Thanks, >> Joe >> >> On 1/25/19, 10:45 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> I was wondering whether: >>> >>> return Objects.equals(uri, defaultNamespace) >>> >>> would be more appropriate (or not) - given the action taken by >>> setDefaultNamespace above? >>> >>> I mean - what if both uri and defaultNamespace are null? >>> >>> Just double checking - as I have no idea what would be the >>> right thing to do :-) >>> >>> best regards, >>> >>> -- daniel >>> >>> On 25/01/2019 17:47, Joe Wang wrote: >>>> Please review a fix for XMLStreamWriter.setDefaultNamespace that >>>> throws NullPointerException when the value is null. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ >>>> >>>> Thanks, >>>> Joe >>>> >>> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From joe.darcy at oracle.com Fri Jan 25 20:42:49 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Jan 2019 12:42:49 -0800 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <93DBEA21-4458-42F8-AEDF-B4145CC3C5A7@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> <4ec46d89-b969-045b-3d90-06d2bf39bce6@oracle.com> <93DBEA21-4458-42F8-AEDF-B4145CC3C5A7@oracle.com> Message-ID: <26dd354b-b2de-5240-7095-b05481d3915f@oracle.com> I don't mind if Intellij is happier :-) -Joe On 1/25/2019 12:05 PM, Lance Andersen wrote: > > > While this works fine in the generated javadoc {@linkplain map map} > > This makes intellij a bit happier : {@linkplain Attributes#map map} > > > --------------------- > $ hg diff > diff -r 6130409b923e > src/java.base/share/classes/java/util/jar/Attributes.java > --- a/src/java.base/share/classes/java/util/jar/Attributes.javaThu Jan > 24 10:57:31 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.javaFri Jan > 25 15:04:03 2019 -0500 > @@ -265,9 +265,10 @@ > ?? ? } > > > ?? ? /** > - ? ? * Compares the specified Attributes object with this Map for > equality. > - ? ? * Returns true if the given object is also an instance of Attributes > - ? ? * and the two Attributes objects represent the same mappings. > + ? ? * Compares the specified object to the underlying > + ? ? * {@linkplain Attributes#map map} for equality. > + ? ? * Returns true if the given object is also a Map > + ? ? * and the two maps represent the same mappings. > ? ? ? * > ? ? ? * @param o the Object to be compared > ? ? ? * @return true if the specified Object is equal to this Map > --------------------- >> On Jan 25, 2019, at 2:53 PM, Lance Andersen >> > wrote: >> >> Hi Joe >> >> yes I checked it in my local build and it does take me to map field >> via the link >> >> Best >> Lance >>> On Jan 25, 2019, at 2:49 PM, Joe Darcy >> > wrote: >>> >>> Hi Lance, >>> >>> Assuming the javadoc renders as expected, the new version looks good >>> to me :-) >>> >>> Thanks, >>> -Joe >>> On 1/25/2019 11:44 AM, Lance Andersen wrote: >>>> Thank you Joe. >>>> >>>> So the change is (see bolded change): >>>> >>>> $ hg diff >>>> diff -r 6130409b923e >>>> src/java.base/share/classes/java/util/jar/Attributes.java >>>> --- a/src/java.base/share/classes/java/util/jar/Attributes.javaThu >>>> Jan 24 10:57:31 2019 -0800 >>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.javaFri >>>> Jan 25 14:44:12 2019 -0500 >>>> @@ -265,9 +265,10 @@ >>>> ????} >>>> >>>> >>>> ????/** >>>> - ????* Compares the specified Attributes object with this Map for >>>> equality. >>>> - ????* Returns true if the given object is also an instance of >>>> Attributes >>>> - ????* and the two Attributes objects represent the same mappings. >>>> + ????* Compares the specified object to the underlying >>>> + ????* {@linkplain map map} for equality. >>>> + ????* Returns true if the given object is also a Map >>>> + ????* and the two maps represent the same mappings. >>>> ?????* >>>> ?????* @param o the Object to be compared >>>> ?????* @return true if the specified Object is equal to this Map >>>> >>>>> On Jan 25, 2019, at 2:28 PM, Joe Darcy >>>> > wrote: >>>>> >>>>> To clarify the CSR comments, for "underlying map" I meant for >>>>> "map" to be a link to the protected field named "map". >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> On 1/25/2019 11:24 AM, Roger Riggs wrote: >>>>>> Looks fine, Lance >>>>>> >>>>>> Roger >>>>>> >>>>>> On 01/25/2019 02:22 PM, Lance Andersen wrote: >>>>>>> The CSR review suggested a slight update to the proposed wording: >>>>>>> >>>>>>> ??????? >>>>>>> $ hg diff >>>>>>> diff -r 6130409b923e >>>>>>> src/java.base/share/classes/java/util/jar/Attributes.java >>>>>>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java >>>>>>> Thu Jan 24 10:57:31 2019 -0800 >>>>>>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java >>>>>>> Fri Jan 25 14:20:51 2019 -0500 >>>>>>> @@ -265,10 +265,11 @@ >>>>>>> ?????} >>>>>>> ???????/** >>>>>>> - ????* Compares the specified Attributes object with this Map >>>>>>> for equality. >>>>>>> - ????* Returns true if the given object is also an instance of >>>>>>> Attributes >>>>>>> - ????* and the two Attributes objects represent the same mappings. >>>>>>> - ????* >>>>>>> + ????* Compares the specified object to the underlying >>>>>>> + ????* {@linkplain java.util.Map Map} for equality. >>>>>>> + ????* Returns true if the given object is also a Map >>>>>>> + ????* and the two maps represent the same mappings. >>>>>>> + ????* >>>>>>> ??????* @param o the Object to be compared >>>>>>> ??????* @return true if the specified Object is equal to this Map >>>>>>> ??????*/ >>>>>>> >>>>>>> ????????? >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>>> On Jan 22, 2019, at 7:47 PM, Lance Andersen >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Jan 22, 2019, at 12:02 PM, Alan Bateman >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 19/01/2019 12:46, Lance Andersen wrote: >>>>>>>>>> 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/Attributes.java >>>>>>>>>> Thu Jan 17 13:46:12 2019 -0800 >>>>>>>>>> +++ >>>>>>>>>> b/src/java.base/share/classes/java/util/jar/Attributes.java >>>>>>>>>> Sat Jan 19 07:35:55 2019 -0500 >>>>>>>>>> @@ -265,9 +265,10 @@ >>>>>>>>>> ????} >>>>>>>>>> ??????/** >>>>>>>>>> - ????* Compares the specified Attributes object with this >>>>>>>>>> Map for equality. >>>>>>>>>> - ????* Returns true if the given object is also an instance >>>>>>>>>> of Attributes >>>>>>>>>> - ????* and the two Attributes objects represent the same >>>>>>>>>> mappings. >>>>>>>>>> + ????* Compares the specified object with this Map for equality. >>>>>>>>>> + ????* Returns true if the given object is also a Map >>>>>>>>>> + ????* and the two objects represent the same Manifest >>>>>>>>>> + ????* attribute name-value mappings. >>>>>>>>>> >>>>>>>>> I think this looks okay although I like Martin's suggestion to >>>>>>>>> just inherit the javadoc as Attributes is a Map. >>>>>>>> I had thought about that but felt that keeping the javadoc >>>>>>>> similar to what it has been might be the better approach given >>>>>>>> it has been around since JDK 1.2 >>>>>>>> >>>>>>>> If we were to inherit the javadoc, we should probably look at >>>>>>>> the rest of the methods to see where else it would ?make sense >>>>>>>> to inherit the javadoc >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>>> -Alan >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >>Lance >>>>>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>>>> Oracle Java Engineering >>>>>>>> 1 Network Drive >>>>>>>> Burlington, MA 01803 >>>>>>>> Lance.Andersen at oracle.com >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >Lance >>>>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>>> Oracle Java Engineering >>>>>>> 1 Network Drive >>>>>>> Burlington, MA 01803 >>>>>>> Lance.Andersen at oracle.com >>>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>>> >> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From mik3hall at gmail.com Sat Jan 26 02:18:52 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 25 Jan 2019 20:18:52 -0600 Subject: jpackage OS X $APP_ROOT vs. $APPDIR also LSEnvironment in the plist Message-ID: Just to note a few last other differences between legacy/manually built applications and jpackage ones. I notice in the .cfg file that jpackage supports the $APPDIR variable for? app.runtime=$APPDIR/PlugIns/Java.runtime With AppBundler this used to be $APP_ROOT. So I could do something like this in the JVMOptions of the plist? -Djava.security.manager -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy -Dlog4j.configuration=file:$APP_ROOT/Contents/JavaApp/log4j.xml -Dapp.lib=$APP_ROOT/Contents/JavaApp This does not work with jpackage because it doesn?t seem to resolve $APPDIR for the jvm args Whether it was a good idea to allow the application to give itself all.permissions I don?t know. But, I set it up this way many years ago and haven?t had to worry about security issues since. I seem to remember that when I brought this up on OS X port they didn?t quite seem to understand the point of having the non-classpath JavaApp directory then either. This won?t be cross-platform anyhow, so I am now considering some other all programmatic and not parm'ed solution to accomplish this. However, you may at some time hear from someone else who used $APP_ROOT in their JVMOptions. I think this was never tool supported either but the applications can sometimes need to set environment variables with the LSEnvironment plist key. Currently I use it to set R_HOME for interfacing java and R. I have no serious use for this currently but have had limited success doing R commands and scripting from Java. I remember using it in the past to set some AppleEvent debug flags as well. It can be set manually but an option of some sort for it could be nice. Thanks, Mike Hall From david.holmes at oracle.com Sat Jan 26 02:40:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2019 12:40:53 +1000 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> Message-ID: <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> On 26/01/2019 3:29 am, Alan Snyder wrote: > My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? It still does what it does because that was how it was specified 20+ years ago and there's been no reason to change. > It may not have been an issue to you, but it was to me when I discovered my program could not handle certain file names. I?ll bet I?m not the last person to assume that a primitive named GetStringUTFChars returns UTF. It does return chars in a UTF (Unicode transformation format) - that format is a modified UTF-8 format. It isn't named GetStringUTF8Chars. The documentation is quite clear: GetStringUTFChars const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); Returns a pointer to an array of bytes representing the string in modified UTF-8 encoding. --- David ----- > I have fixed my code, so its not an issue for me any more, but it seems like an unnecessary tarpit awaiting the unwary. > > Just my 2c. > > Alan > > >> On Jan 24, 2019, at 10:04 PM, David Holmes wrote: >> >> On 25/01/2019 4:39 am, Alan Snyder wrote: >>> Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. >>> What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? >> >> Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. >> >> The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: >> >> https://bugs.openjdk.java.net/browse/JDK-5030776 >> >> so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. >> >> Cheers, >> David >> ----- >> >> >>> Alan >>>> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >>>> >>>> Hi Alan, >>>> >>>> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >>>> as used by the VM internally for historical reasons. >>>> >>>> See answers to this related question on SO (which contains links to official docs): >>>> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >>>> >>>> HTH >>>> >>>> /Claes >>>> >>>> On 2019-01-24 19:23, Alan Snyder wrote: >>>>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>>>> >>>>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>>>> >>>>> For example, where String.getBytes() returns >>>>> >>>>> -16 -97 -115 -69 >>>>> >>>>> GetStringUTFChars returns: >>>>> >>>>> -19 -96 -68 -19 -67 -69 >>>>> >>>>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>>>> >>>>> (Tested in JDK 9, 11, and a fairly recent 12) >>>>> >>>> >> > From javalists at cbfiddle.com Sat Jan 26 04:24:54 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 25 Jan 2019 20:24:54 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> Message-ID: <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> The reason to change is that returning UTF-8 is useful and returning ?modified UTF-8? is apparently not (as no one has explained why it is useful). Why not deprecate it? It would be nice to get a warning. Alan > On Jan 25, 2019, at 6:40 PM, David Holmes wrote: > > On 26/01/2019 3:29 am, Alan Snyder wrote: >> My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? > > It still does what it does because that was how it was specified 20+ years ago and there's been no reason to change. > >> It may not have been an issue to you, but it was to me when I discovered my program could not handle certain file names. I?ll bet I?m not the last person to assume that a primitive named GetStringUTFChars returns UTF. > > It does return chars in a UTF (Unicode transformation format) - that format is a modified UTF-8 format. It isn't named GetStringUTF8Chars. > > The documentation is quite clear: > > GetStringUTFChars > > const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); > > Returns a pointer to an array of bytes representing the string in modified UTF-8 encoding. > > --- > > David > ----- > >> I have fixed my code, so its not an issue for me any more, but it seems like an unnecessary tarpit awaiting the unwary. >> Just my 2c. >> Alan >>> On Jan 24, 2019, at 10:04 PM, David Holmes wrote: >>> >>> On 25/01/2019 4:39 am, Alan Snyder wrote: >>>> Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. >>>> What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? >>> >>> Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. >>> >>> The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: >>> >>> https://bugs.openjdk.java.net/browse/JDK-5030776 >>> >>> so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. >>> >>> Cheers, >>> David >>> ----- >>> >>> >>>> Alan >>>>> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >>>>> >>>>> Hi Alan, >>>>> >>>>> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >>>>> as used by the VM internally for historical reasons. >>>>> >>>>> See answers to this related question on SO (which contains links to official docs): >>>>> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >>>>> >>>>> HTH >>>>> >>>>> /Claes >>>>> >>>>> On 2019-01-24 19:23, Alan Snyder wrote: >>>>>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>>>>> >>>>>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>>>>> >>>>>> For example, where String.getBytes() returns >>>>>> >>>>>> -16 -97 -115 -69 >>>>>> >>>>>> GetStringUTFChars returns: >>>>>> >>>>>> -19 -96 -68 -19 -67 -69 >>>>>> >>>>>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>>>>> >>>>>> (Tested in JDK 9, 11, and a fairly recent 12) >>>>>> >>>>> >>> > From christoph.langer at sap.com Sat Jan 26 10:47:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 26 Jan 2019 10:47:51 +0000 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <5174FD37-53F5-4C20-9178-DE44840B532B@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> <5174FD37-53F5-4C20-9178-DE44840B532B@oracle.com> Message-ID: <038a4eaf210542188405f446a626c9cb@sap.com> Looks fine now. You could, however, pull this line: 325 PrivilegedExceptionAction action = tempPath::toRealPath; out of the try block. ?? Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Freitag, 25. Januar 2019 18:04 > To: Alan Bateman > Cc: core-libs-dev > Subject: Re: RFR: 8210469: Missing doPriviledged block and permission for > jdk.zipfs module > > > > On Jan 25, 2019, at 3:55 AM, Alan Bateman > wrote: > > > > > > > > On 25/01/2019 00:11, Lance Andersen wrote: > >>> On Jan 24, 2019, at 6:20 PM, Mandy Chung > wrote: > >>> > >>> > >>> > >>> On 1/24/19 1:55 PM, Lance Andersen wrote: > >>>>> Alternatively you can simply do: > >>>>> PrivilegedExceptionAction pea = () -> > tempPath.toRealPath(); > >>>>> return AccessController.doPrivileged(pea); > >>>>> > >>>>> In this case, limited doPrivileged does not make whole lot of > difference jdk.zip explicitly grants for limited permissions and this > doPrivileged block is one single operation, toRealPath. > >>>> Do you have a preference here either way? I had that originally but > changed it to make it clearer why it was done. > >>> For this simple case, I would avoid using limited doPrivileged. > >> Okie Dokie, I made the change and also ran optimize imports on the test: > http://cr.openjdk.java.net/~lancea/8210469/webrev.01/index.html > >> > > Here's an alternative that avoids the cast, it might be a bit more readable. > > > > PrivilegedExceptionAction action = tempPath::toRealPath; > > zfpath = AccessController.doPrivileged(action); > > > > In the test then you it might be clearer to rename ZIPFS_MAP to > ZIPFS_OPTIONS. > > Okie Dokie part 2 ;-) > > Updates can be found here: > http://cr.openjdk.java.net/~lancea/8210469/webrev.02/index.html > > Best > Lance > > > > -Alan > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From deepak.kejriwal at oracle.com Sat Jan 26 10:57:06 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sat, 26 Jan 2019 02:57:06 -0800 (PST) Subject: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra Message-ID: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 8 is planned. JDK-8212941 focuses on the java.time.chrono.JapaneseEra specification changes. The java.time.chrono.JapaneseEra class introduced in Java SE 8 declares four public static final fields that represent eras in the Japanese calendar system. New eras can be defined by the relevant Japanese authorities. The JapaneseEra class should accommodate such new eras. Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. [0]: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html Regards, Deepak From deepak.kejriwal at oracle.com Sat Jan 26 10:57:11 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sat, 26 Jan 2019 02:57:11 -0800 (PST) Subject: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra Message-ID: <49949ba0-07cc-4b7c-b499-afb0fff0675b@default> Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 11 is planned. JDK-8212941 focuses on the java.time.chrono.JapaneseEra specification changes. The java.time.chrono.JapaneseEra class introduced in Java SE 11 declares four public static final fields that represent eras in the Japanese calendar system. New eras can be defined by the relevant Japanese authorities. The JapaneseEra class should accommodate such new eras. Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. [0]: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html Regards, Deepak From claes.redestad at oracle.com Sat Jan 26 15:30:06 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 26 Jan 2019 16:30:06 +0100 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> Message-ID: Modified UTF-8 goes way back in terms of internal use in java and its JVMs. It's the format used to store strings in class-files, and used as an internal representation in the HotSpot VM: various internal string tables, constant pools etc. So any Java code that interacts with the VM needs to know how to convert back and forth between java Strings and the VMs flavor of modified UTF-8. As long as the JVM speak modified UTF-8 internally, we'll need the utilities to convert back and forth. Changing this fundamental design is likely to be way more trouble than it's ever worth. As to "why do the VM do this!?", I'm too young to really know for sure, but it's fun to speculate.[1] I think we all welcome constructive suggestions on how to help developers notice that the "UTF" JNI methods aren't what your intuition might tell you. I've been there myself and learned about modified UTF-8 the hard way. /Claes [1] It turns out there are a few obvious technical difficulties with UTF-8, especially dealing with strings that encode '\0' characters (a.k.a. null) in the context of C/C++ code. C-strings (char*) are null- terminated, and there's a lot of code and utilities that'd break or behave weirdly if you give them char*s with embedded nulls in them... But UTF-8 is still mostly an attractive, compact encoding for the kind of strings JVMs care about: most of them are ASCII String literals for methods and fields encoded into classfiles, and UTF-8 encode ASCII without any overhead! But it allows null chars, and to support that you need to encode the length.. Ugh, overhead! Can't have that! What to do?! The designers likely thought it'd be less trouble modifying this new, shiny UTF-8 encoding to get something similar to it that disallows embedded nulls. And why not: it's only for a Java/JVM-internal stuff no- one on the outside needs to know about, right? And it's *mostly* compatible. And no-one uses real UTF-8, anyhow! The context here is that Unicode and UTF-8 was still relatively new (RFCs filed 1993 and 1996, respectively). The fact that it'd eventually become the de facto encoding standard was not something anyone could have known back then. As it happens, "modified UTF-8" took root in the emerging world of JVMs, and spread to a number of surprising places throughout the Java SE libraries, like java.io.DataInput/Output: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/DataInput.html#modified-utf-8 Today, in C++14, std::string supports embedding '\0' values, and is thus much more UTF-8 friendly than good old C-strings. I find it unlikely that "modified UTF-8" would be a thing if the JVM was designed from scratch today ("C++ in 2019!?"). On 2019-01-26 05:24, Alan Snyder wrote: > The reason to change is that returning UTF-8 is useful and returning ?modified UTF-8? is apparently not (as no one has explained why it is useful). > > Why not deprecate it? > > It would be nice to get a warning. > > Alan > > >> On Jan 25, 2019, at 6:40 PM, David Holmes wrote: >> >> On 26/01/2019 3:29 am, Alan Snyder wrote: >>> My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? >> >> It still does what it does because that was how it was specified 20+ years ago and there's been no reason to change. >> >>> It may not have been an issue to you, but it was to me when I discovered my program could not handle certain file names. I?ll bet I?m not the last person to assume that a primitive named GetStringUTFChars returns UTF. >> >> It does return chars in a UTF (Unicode transformation format) - that format is a modified UTF-8 format. It isn't named GetStringUTF8Chars. >> >> The documentation is quite clear: >> >> GetStringUTFChars >> >> const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); >> >> Returns a pointer to an array of bytes representing the string in modified UTF-8 encoding. >> >> --- >> >> David >> ----- >> >>> I have fixed my code, so its not an issue for me any more, but it seems like an unnecessary tarpit awaiting the unwary. >>> Just my 2c. >>> Alan >>>> On Jan 24, 2019, at 10:04 PM, David Holmes wrote: >>>> >>>> On 25/01/2019 4:39 am, Alan Snyder wrote: >>>>> Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. >>>>> What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? >>>> >>>> Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. >>>> >>>> The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-5030776 >>>> >>>> so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> >>>>> Alan >>>>>> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >>>>>> >>>>>> Hi Alan, >>>>>> >>>>>> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >>>>>> as used by the VM internally for historical reasons. >>>>>> >>>>>> See answers to this related question on SO (which contains links to official docs): >>>>>> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >>>>>> >>>>>> HTH >>>>>> >>>>>> /Claes >>>>>> >>>>>> On 2019-01-24 19:23, Alan Snyder wrote: >>>>>>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>>>>>> >>>>>>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>>>>>> >>>>>>> For example, where String.getBytes() returns >>>>>>> >>>>>>> -16 -97 -115 -69 >>>>>>> >>>>>>> GetStringUTFChars returns: >>>>>>> >>>>>>> -19 -96 -68 -19 -67 -69 >>>>>>> >>>>>>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>>>>>> >>>>>>> (Tested in JDK 9, 11, and a fairly recent 12) >>>>>>> >>>>>> >>>> >> > From martinrb at google.com Sat Jan 26 17:08:23 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 26 Jan 2019 09:08:23 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> Message-ID: It's a pet peeve that the name GetStringUTFChars is deeply misleading - there are many "UTF"s, and this encoding is meant for use with the JVM only. The documentation should make it clearer that this is NOT the UTF-8 you might expect. > > From javalists at cbfiddle.com Sat Jan 26 19:38:51 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 26 Jan 2019 11:38:51 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> Message-ID: <5DF0F9DB-2C00-4D1C-8CB2-6F3869D0250F@cbfiddle.com> My usage of GetStringUTFChars was to pass a String as a parameter to a system call that takes a NUL-terminated UTF-8 string (a file path). Obviously, the system call does not accept strings containing NUL. I suspect this is a common case. Therefore, my needs would be met by a (new) primitive that returns UTF-8 and fails if the String contains NUL. In addition, I would suggest either of these options: (1) Document GetStringUTFChars as deprecated, introduce a new primitive GetStringCharsInternalRepresentationModifiedUTF, and use C support for deprecated members where available to provide compile-time warnings when GetStringUTFChars is used. (2) Rename GetStringUTFChars to GetStringCharsInternalRepresentationModifiedUTF. I believe this is a binary compatible change, but new builds will fail, forcing developers to choose which behavior they really want. Alan > On Jan 26, 2019, at 7:30 AM, Claes Redestad wrote: > > Modified UTF-8 goes way back in terms of internal use in java and its > JVMs. It's the format used to store strings in class-files, and used as > an internal representation in the HotSpot VM: various internal string > tables, constant pools etc. > > So any Java code that interacts with the VM needs to know how to convert > back and forth between java Strings and the VMs flavor of modified > UTF-8. As long as the JVM speak modified UTF-8 internally, we'll need > the utilities to convert back and forth. Changing this fundamental > design is likely to be way more trouble than it's ever worth. > > As to "why do the VM do this!?", I'm too young to really know for sure, > but it's fun to speculate.[1] > > I think we all welcome constructive suggestions on how to help > developers notice that the "UTF" JNI methods aren't what your intuition > might tell you. I've been there myself and learned about modified UTF-8 > the hard way. > > /Claes > > [1] > > It turns out there are a few obvious technical difficulties with UTF-8, > especially dealing with strings that encode '\0' characters (a.k.a. > null) in the context of C/C++ code. C-strings (char*) are null- > terminated, and there's a lot of code and utilities that'd break or > behave weirdly if you give them char*s with embedded nulls in them... > > But UTF-8 is still mostly an attractive, compact encoding for the kind > of strings JVMs care about: most of them are ASCII String literals for > methods and fields encoded into classfiles, and UTF-8 encode ASCII > without any overhead! > > But it allows null chars, and to support that you need to encode the > length.. Ugh, overhead! Can't have that! What to do?! > > The designers likely thought it'd be less trouble modifying this new, > shiny UTF-8 encoding to get something similar to it that disallows > embedded nulls. And why not: it's only for a Java/JVM-internal stuff no- > one on the outside needs to know about, right? And it's *mostly* > compatible. And no-one uses real UTF-8, anyhow! > > The context here is that Unicode and UTF-8 was still relatively new > (RFCs filed 1993 and 1996, respectively). The fact that it'd eventually > become the de facto encoding standard was not something anyone could > have known back then. > > As it happens, "modified UTF-8" took root in the emerging world of JVMs, > and spread to a number of surprising places throughout the Java SE > libraries, like java.io.DataInput/Output: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/DataInput.html#modified-utf-8 > > Today, in C++14, std::string supports embedding '\0' values, and is thus > much more UTF-8 friendly than good old C-strings. I find it unlikely > that "modified UTF-8" would be a thing if the JVM was designed from > scratch today ("C++ in 2019!?"). > > On 2019-01-26 05:24, Alan Snyder wrote: >> The reason to change is that returning UTF-8 is useful and returning ?modified UTF-8? is apparently not (as no one has explained why it is useful). >> Why not deprecate it? >> It would be nice to get a warning. >> Alan >>> On Jan 25, 2019, at 6:40 PM, David Holmes wrote: >>> >>> On 26/01/2019 3:29 am, Alan Snyder wrote: >>>> My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? >>> >>> It still does what it does because that was how it was specified 20+ years ago and there's been no reason to change. >>> >>>> It may not have been an issue to you, but it was to me when I discovered my program could not handle certain file names. I?ll bet I?m not the last person to assume that a primitive named GetStringUTFChars returns UTF. >>> >>> It does return chars in a UTF (Unicode transformation format) - that format is a modified UTF-8 format. It isn't named GetStringUTF8Chars. >>> >>> The documentation is quite clear: >>> >>> GetStringUTFChars >>> >>> const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); >>> >>> Returns a pointer to an array of bytes representing the string in modified UTF-8 encoding. >>> >>> --- >>> >>> David >>> ----- >>> >>>> I have fixed my code, so its not an issue for me any more, but it seems like an unnecessary tarpit awaiting the unwary. >>>> Just my 2c. >>>> Alan >>>>> On Jan 24, 2019, at 10:04 PM, David Holmes wrote: >>>>> >>>>> On 25/01/2019 4:39 am, Alan Snyder wrote: >>>>>> Thank you. That post does explain what is happening, but leaves open the question of whether GetStringUTFChars should be changed. >>>>>> What is the value of the current implementation of GetStringUTFChars versus one that returns true UTF-8? >>>>> >>>>> Well that's really a Hotspot question as it concerns JNI, but this is ancient history. There's little point musing over the "why" of decisions made back in the late 1990's. But I suspect the main reason is the avoidance of embedded NUL characters. >>>>> >>>>> The only bug report I can see on this (basically the same issue you are reporting) was back in 2004: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-5030776 >>>>> >>>>> so it simply has not been an issue. As per the SO article that Claes referenced anyone needing true UTF8 has a couple of paths to achieve that. >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Alan >>>>>>> On Jan 24, 2019, at 10:32 AM, Claes Redestad wrote: >>>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> GetStringUTFChars unfortunately doesn't give you true UTF-8, but a modified UTF-8 sequence >>>>>>> as used by the VM internally for historical reasons. >>>>>>> >>>>>>> See answers to this related question on SO (which contains links to official docs): >>>>>>> https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni >>>>>>> >>>>>>> HTH >>>>>>> >>>>>>> /Claes >>>>>>> >>>>>>> On 2019-01-24 19:23, Alan Snyder wrote: >>>>>>>> I am having a problem with file names that contain emojis when passed to a macOS system call. >>>>>>>> >>>>>>>> Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. >>>>>>>> >>>>>>>> For example, where String.getBytes() returns >>>>>>>> >>>>>>>> -16 -97 -115 -69 >>>>>>>> >>>>>>>> GetStringUTFChars returns: >>>>>>>> >>>>>>>> -19 -96 -68 -19 -67 -69 >>>>>>>> >>>>>>>> I?m not a UTF expert, so can someone say whether I should file a bug report? >>>>>>>> >>>>>>>> (Tested in JDK 9, 11, and a fairly recent 12) >>>>>>>> >>>>>>> >>>>> >>> > From martinrb at google.com Sat Jan 26 21:39:31 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 26 Jan 2019 13:39:31 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <5DF0F9DB-2C00-4D1C-8CB2-6F3869D0250F@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <5DF0F9DB-2C00-4D1C-8CB2-6F3869D0250F@cbfiddle.com> Message-ID: On Sat, Jan 26, 2019 at 11:39 AM Alan Snyder wrote: > > Therefore, my needs would be met by a (new) primitive that returns UTF-8 > and fails if the String contains NUL. > Maybe your programs are always running in a UTF-8 locale and maybe most computing environments have migrated to UTF-8 (good!), BUT: - that's hardly universal - macosx has stricter requirements - it uses filenames normalized in a macosx-specific way - Windows may prefer UTF-16 encoded text. From david.holmes at oracle.com Sat Jan 26 23:19:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Jan 2019 09:19:30 +1000 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> Message-ID: On 27/01/2019 3:08 am, Martin Buchholz wrote: > It's a pet peeve that the name GetStringUTFChars is deeply misleading - > there are many "UTF"s, and this encoding is meant for use with the JVM > only. The documentation should make it clearer that this is NOT the UTF-8 > you might expect. It does! GetStringUTFChars const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); Returns a pointer to an array of bytes representing the string in modified UTF-8 encoding. --- David >> >> From Alan.Bateman at oracle.com Sun Jan 27 07:39:16 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Jan 2019 07:39:16 +0000 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> Message-ID: On 25/01/2019 19:44, Lance Andersen wrote: > Thank you Joe. > > So the change is (see bolded change): > > $ hg diff > diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java > --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Jan 25 14:44:12 2019 -0500 > @@ -265,9 +265,10 @@ > } > > /** > - * Compares the specified Attributes object with this Map for equality. > - * Returns true if the given object is also an instance of Attributes > - * and the two Attributes objects represent the same mappings. > + * Compares the specified object to the underlying > + * {@linkplain map map} for equality. > + * Returns true if the given object is also a Map > + * and the two maps represent the same mappings. > This wording looks okay (I see the other mails about fixing the javadoc link). -Alan From Alan.Bateman at oracle.com Sun Jan 27 07:41:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Jan 2019 07:41:21 +0000 Subject: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module In-Reply-To: <5174FD37-53F5-4C20-9178-DE44840B532B@oracle.com> References: <6d521243-761d-9929-edc2-231858a961e1@oracle.com> <7E08923A-56CF-4BE8-8BF9-87045748FB99@oracle.com> <298E33A1-4DBF-4819-9C30-39512B9CDBA9@oracle.com> <5174FD37-53F5-4C20-9178-DE44840B532B@oracle.com> Message-ID: <7f439c26-3386-da5a-e813-9addac7920c9@oracle.com> On 25/01/2019 17:03, Lance Andersen wrote: > >> On Jan 25, 2019, at 3:55 AM, Alan Bateman > > wrote: >> >> >> Here's an alternative that avoids the cast, it might be a bit more >> readable. >> >> PrivilegedExceptionAction action = tempPath::toRealPath; >> zfpath = AccessController.doPrivileged(action); >> >> In the test then you it might be clearer to rename ZIPFS_MAP to >> ZIPFS_OPTIONS. > > Okie Dokie part 2 ;-) > > Updates can be found here: > http://cr.openjdk.java.net/~lancea/8210469/webrev.02/index.html > Looks good. -Alan From Alan.Bateman at oracle.com Sun Jan 27 09:55:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Jan 2019 09:55:40 +0000 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: References: Message-ID: On 11/01/2019 19:41, Andy Herrick wrote: > This is the second update to the Request For Review of the > implementation of the Java Packager Tool (jpackager) as described in > JEP 343: Packaging Tool > I've started to play with the latest EA build, trying to figure it out in conjunction with the current wording in JEP 343. I think the description/definition of "application image" needs to be beefed up. The current JEP doesn't reference JEP 220 and it's not immediately obvious how they relate. The HelloWorld example in the JEP shows the runtime next to an app directory but this doesn't match what I am seeing when I use `jpackage create-image`. Instead I see the java runtime is generated into PlugIns/Java.runtime. It's not clear why there is a "PlugIns" directory. Can we do anything about simple cases where the application is a single executable JAR? When I use `jpackage create-image` for such cases then I'm forced to provide a directory to --input and? the main class to --class, neither of these options should be needed for simple cases like this, esp. when the tool also has --main-jar (which might need to be renamed to be consistent with other tools). When I use `jpackage create-image` then it creates an embedded run-time image that is missing a lot of modules. For example, if my applications is indirectly using sun.misc.Unsafe, as some libraries do, then it will fail at run-time because the jdk.unsupported module is not included. The examples I tried were also missing java.sql, java.net.http and several more. Is this a bug or a relic from the old javapackager tool? The JEP suggests that the tool can create a native launcher but it's not immediately obvious how to do that. An example in the JEP would be useful to have. I did get it working with `--secondary-launcher` but that is a really strange option. I wonder if this could be renamed to `--launcher` and also its input changed to be closer to the equivalent in jlink. I also wonder if it would be saner to have the properties specified directly to the option rather than in another properties file. I also tried `jpackage create-installer`. When I specify `--app-image` I assumed I could specify an application image that I created previously `jpackage create-image` but it doesn't like that. The error for this usage is: Error: App image directory "myimage" is invalid and does not contain "app" and/or "runtime" sub-directories Are you planning to keep `jpackage create-jre-installer`? I can't tell if this is intended to be renamed or not but I think it would be confusing to have "JRE" in the name of CLI options. Also it's not clear what "jre-name" means. I think it would be saner to simplify this to allow an installer be created for a given run-time image, never the runtime that the jpackage tool is running on. That's all I have for now. I see there is a lot of feedback and issues being tracked so I'll try it again once the implementation is a bit further along. -Alan From deepak.kejriwal at oracle.com Sun Jan 27 11:54:00 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sun, 27 Jan 2019 03:54:00 -0800 (PST) Subject: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> References: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> Message-ID: <42db3098-b44c-438f-b6a9-785c5af34c81@default> + jdk8u-dev. From: Deepak Kejriwal Sent: Saturday, January 26, 2019 4:27 PM To: core-libs-dev ; jdk-updates-dev at openjdk.java.net Subject: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 8 is planned. JDK-8212941 focuses on the java.time.chrono.JapaneseEra specification changes. The java.time.chrono.JapaneseEra class introduced in Java SE 8 declares four public static final fields that represent eras in the Japanese calendar system. New eras can be defined by the relevant Japanese authorities. The JapaneseEra class should accommodate such new eras. Specification changes are covered in this review. A follow up code review will be carried out for implementation changes. [0]: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html Regards, Deepak From andy.herrick at oracle.com Sun Jan 27 12:56:00 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 27 Jan 2019 07:56:00 -0500 Subject: RFR: JDK-8217331: Problems when space in application name Message-ID: <47130cf3-7b45-1a70-ab55-7118d0ef648d@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The webrev includes removal of the APP_FS_NAME DeployParam, and enhanced? checking of the given application name so APP_NAME parameter can be safely used in all cases. [1] https://bugs.openjdk.java.net/browse/JDK-8217331 [2] http://cr.openjdk.java.net/~herrick/8217331/ /Andy From philipp.kunz at paratix.ch Sun Jan 27 13:40:03 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 27 Jan 2019 14:40:03 +0100 Subject: RFR: JDK-8217393 Re: Clarification in Attributes equal In-Reply-To: References: <1547765585.2438.32.camel@paratix.ch> <8DD04518-CBB6-4A9F-B664-1FA67EBDB24A@oracle.com> <017AC087-7138-4F5A-BB92-48D46D34C447@oracle.com> <4c6eff08-e1f3-f9bd-787e-328753e2c679@oracle.com> <36BBB196-CD31-4640-9F3D-6838EBBB5EEE@oracle.com> Message-ID: <1548596403.2363.23.camel@paratix.ch> The class comment to Attributes says> > This map and its views have a predictable iteration order, namely the> order that keys were inserted into the map, as with {@link LinkedHashMap}.> Considering above statement, are two Attributes equal if they contain the same mappings in a different iteration order? I'm afraid I'd guess not.Attributes inherits from Map and therefore two Attributes are equal according to Map's definition of?equals regardless of their iteration order. Same for AbstractMap.I'm now wondering if it was an improvement if the equals' comment in Attributes was extended clarifying this minor ambiguity by explicitly excluding iteration order from comparison? Besides that, the new version looks good to?me. Thanks and regards,Philipp On Sun, 2019-01-27 at 07:39 +0000, Alan Bateman wrote: > On 25/01/2019 19:44, Lance Andersen wrote: > > Thank you Joe. > > > > So the change is (see bolded change): > > > > $ hg diff > > diff -r 6130409b923e > > src/java.base/share/classes/java/util/jar/Attributes.java > > --- a/src/java.base/share/classes/java/util/jar/Attributes.java > > Thu Jan 24 10:57:31 2019 -0800 > > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java > > Fri Jan 25 14:44:12 2019 -0500 > > @@ -265,9 +265,10 @@ > > ??????} > > ?? > > ??????/** > > -?????* Compares the specified Attributes object with this Map for > > equality. > > -?????* Returns true if the given object is also an instance of > > Attributes > > -?????* and the two Attributes objects represent the same mappings. > > +?????* Compares the specified object to the underlying > > +?????* {@linkplain map map} for equality. > > +?????* Returns true if the given object is also a Map > > +?????* and the two maps represent the same mappings. > > > > This wording looks okay (I see the other mails about fixing the > javadoc? > link). > > -Alan From Alan.Bateman at oracle.com Sun Jan 27 15:57:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Jan 2019 15:57:09 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> Message-ID: <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> On 24/01/2019 16:19, Baesken, Matthias wrote: >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef >> WIN32 ? > Hi Alan, do you mean , adding a separate c-file for UNIX containing the function open_jarfile ? > I considered this, but did not like the idea to add a separate file for UNIX just for the small function . > > Your suggestion to use FILE_SHARE_READ is probably the right way to do it , I changed this, second webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > Christoph Langer's suggestion to use jli_util seems worth exploring to keep the platform specific code together. I still find the call to _open and checking for ENOENT a bit icky. If this change gets pushed then I think we need a follow-up issue created to replace this to use CreateFile consistently. -Alan From matthias.baesken at sap.com Mon Jan 28 08:03:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 28 Jan 2019 08:03:36 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: Hello, seems 8214533 got pushed recently into jdk/jdk. Now we see build errors on AIX , are they related to this change ? /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: error: Decoder is not public in EUC_JP; cannot be accessed from outside package private static class Decoder extends EUC_JP.Decoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: error: Encoder is not public in EUC_JP; cannot be accessed from outside package private static class Encoder extends EUC_JP.Encoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: error: Decoder is not public in EUC_JP; cannot be accessed from outside package private static class Decoder extends EUC_JP.Decoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: error: Encoder is not public in EUC_JP; cannot be accessed from outside package private static class Encoder extends EUC_JP.Encoder { Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Ichiroh Takiguchi > Sent: Dienstag, 15. Januar 2019 01:51 > To: Alan Bateman > Cc: build-dev ; ppc-aix-port-dev port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > Subject: 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, Ltd. > > On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > > Hello Alan. > > > > I opened JDK-8215333 for Charset filtering issue [1]. > > I cannot wait until JDK-8215333 is closed. > > Is it possible to put IBM-29626C charset with standard way ? > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> Hello Roger, Magnus and Alan. > >> I may need to put alias information into charsets file. > >> stdcs-xxx cannot handle this information... > >> > >> Still AIX needs IBM-29626C charset for default encoding... > >> > >> I appreciate if you give me further suggestions. > >> > >> Thanks, > >> Ichiroh Takiguchi > >> > >> On 2018-12-10 20:50, Alan Bateman wrote: > >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >>>>> Hi, > >>>>> > >>>>> It is a nice feature that charsets are selected at build time using > >>>>> the stdcs-xxx files. > >>>>> This change breaks that pattern and embeds os specific information > >>>>> in more than one place. > >>>>> That does not seem like an improvement.? Is there any alternative? > >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >>> My reading of the patch is that the "os" key is to avoid generating > >>> it > >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >>> non-AIX platforms. The general direction is welcome but I think > >>> further work and discussion will be needed to get the right set of > >>> changes to support filtering in the build. It can probably be > >>> separated from the changes to add IBM-29626C to AIX's java.base. > >>> > >>> -Alan From chris.hegarty at oracle.com Mon Jan 28 11:18:42 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 11:18:42 +0000 Subject: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <42db3098-b44c-438f-b6a9-785c5af34c81@default> References: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> <42db3098-b44c-438f-b6a9-785c5af34c81@default> Message-ID: <518614fc-9290-984f-7cb9-d36e66d32fcf@oracle.com> On 27/01/2019 11:54, Deepak Kejriwal wrote: > ... > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 > > Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...", these references could be javadoc links. From chris.hegarty at oracle.com Mon Jan 28 11:19:01 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 11:19:01 +0000 Subject: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <49949ba0-07cc-4b7c-b499-afb0fff0675b@default> References: <49949ba0-07cc-4b7c-b499-afb0fff0675b@default> Message-ID: <1bff24d3-2583-ecf5-f361-b53fed49e7dd@oracle.com> On 26/01/2019 10:57, Deepak Kejriwal wrote: > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 > > Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...", these references could be javadoc links. From chris.hegarty at oracle.com Mon Jan 28 11:32:34 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 11:32:34 +0000 Subject: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 In-Reply-To: References: Message-ID: On 25/01/2019 18:37, Deepak Kejriwal wrote: > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 > > Webrev: http://cr.openjdk.java.net/~rpatil/8216396/ This change looks good Deepak. Reviewed. -Chris. From chris.hegarty at oracle.com Mon Jan 28 11:36:45 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 11:36:45 +0000 Subject: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: References: Message-ID: On 25/01/2019 18:35, Deepak Kejriwal wrote: > Hi All, > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 > > Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ This change looks good Deepak. Reviewed. I have added myself as Reviewer on the CSR. Trivially, can you please update the copyright year before pushing. -Chris. From matthias.baesken at sap.com Mon Jan 28 11:38:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 28 Jan 2019 11:38:13 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> Message-ID: Hello Alan / Christoph, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ - moved ELP_PREFIX define out of the function - added a check (wfullnamelen > 247) before CreateFileW is attempted - some other formatting (mostly suggested by Christoph) Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Sonntag, 27. Januar 2019 16:57 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 24/01/2019 16:19, Baesken, Matthias wrote: > >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > >> WIN32 ? > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > function open_jarfile ? > > I considered this, but did not like the idea to add a separate file for UNIX > just for the small function . > > > > Your suggestion to use FILE_SHARE_READ is probably the right way to do > it , I changed this, second webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > Christoph Langer's suggestion to use jli_util seems worth exploring to > keep the platform specific code together. > > I still find the call to _open and checking for ENOENT a bit icky. If > this change gets pushed then I think we need a follow-up issue created > to replace this to use CreateFile consistently. > > -Alan From takiguc at linux.vnet.ibm.com Mon Jan 28 13:12:40 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 28 Jan 2019 22:12:40 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: Hello. I'm very sorry. It's my fault. EUC_JP class was moved to java.base module. (sun.nio.cs.EUC_JP). make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and EUC_JP_Open. Could you suggest me how I should provide new webrev files ? Thanks, Ichiroh Takiguchi On 2019-01-28 17:03, Baesken, Matthias wrote: > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > we see build errors on AIX , are they related to this change ? > > > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > error: Decoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Decoder extends EUC_JP.Decoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > error: Encoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Encoder extends EUC_JP.Encoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > error: Decoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Decoder extends EUC_JP.Decoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > error: Encoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Encoder extends EUC_JP.Encoder { > > Best regards, Matthias > > > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Dienstag, 15. Januar 2019 01:51 >> To: Alan Bateman >> Cc: build-dev ; ppc-aix-port-dev > port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> Subject: 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, Ltd. >> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> > Hello Alan. >> > >> > I opened JDK-8215333 for Charset filtering issue [1]. >> > I cannot wait until JDK-8215333 is closed. >> > Is it possible to put IBM-29626C charset with standard way ? >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> > >> > Thanks, >> > Ichiroh Takiguchi >> > >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> Hello Roger, Magnus and Alan. >> >> I may need to put alias information into charsets file. >> >> stdcs-xxx cannot handle this information... >> >> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >> >> I appreciate if you give me further suggestions. >> >> >> >> Thanks, >> >> Ichiroh Takiguchi >> >> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >>>>> Hi, >> >>>>> >> >>>>> It is a nice feature that charsets are selected at build time using >> >>>>> the stdcs-xxx files. >> >>>>> This change breaks that pattern and embeds os specific information >> >>>>> in more than one place. >> >>>>> That does not seem like an improvement.? Is there any alternative? >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >>> My reading of the patch is that the "os" key is to avoid generating >> >>> it >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >>> non-AIX platforms. The general direction is welcome but I think >> >>> further work and discussion will be needed to get the right set of >> >>> changes to support filtering in the build. It can probably be >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >>> >> >>> -Alan From goetz.lindenmaier at sap.com Mon Jan 28 13:11:27 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Jan 2019 13:11:27 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: <8c05b5147fa7489282d7cae04e801702@sap.com> Hi Ichiroh, just open a bug, like "Fix aix build after 8214533" and post a RFR for it. I assume the fix is quite trivial so we can review it quick. Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Ichiroh Takiguchi > Sent: Montag, 28. Januar 2019 14:13 > To: Baesken, Matthias > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset > > Hello. > > I'm very sorry. It's my fault. > EUC_JP class was moved to java.base module. > (sun.nio.cs.EUC_JP). > > make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > EUC_JP_Open. > > Could you suggest me how I should provide new webrev files ? > > Thanks, > Ichiroh Takiguchi > > > On 2019-01-28 17:03, Baesken, Matthias wrote: > > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > > we see build errors on AIX , are they related to this change ? > > > > > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > > error: Decoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Decoder extends EUC_JP.Decoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > > error: Encoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Encoder extends EUC_JP.Encoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > > error: Decoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Decoder extends EUC_JP.Decoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > > error: Encoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Encoder extends EUC_JP.Encoder { > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: ppc-aix-port-dev On > >> Behalf Of Ichiroh Takiguchi > >> Sent: Dienstag, 15. Januar 2019 01:51 > >> To: Alan Bateman > >> Cc: build-dev ; ppc-aix-port-dev >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> Subject: 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, Ltd. > >> > >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> > Hello Alan. > >> > > >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> > I cannot wait until JDK-8215333 is closed. > >> > Is it possible to put IBM-29626C charset with standard way ? > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >> Hello Roger, Magnus and Alan. > >> >> I may need to put alias information into charsets file. > >> >> stdcs-xxx cannot handle this information... > >> >> > >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >> > >> >> I appreciate if you give me further suggestions. > >> >> > >> >> Thanks, > >> >> Ichiroh Takiguchi > >> >> > >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>>>> Hi, > >> >>>>> > >> >>>>> It is a nice feature that charsets are selected at build time using > >> >>>>> the stdcs-xxx files. > >> >>>>> This change breaks that pattern and embeds os specific information > >> >>>>> in more than one place. > >> >>>>> That does not seem like an improvement.? Is there any alternative? > >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> My reading of the patch is that the "os" key is to avoid generating > >> >>> it > >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >> >>> non-AIX platforms. The general direction is welcome but I think > >> >>> further work and discussion will be needed to get the right set of > >> >>> changes to support filtering in the build. It can probably be > >> >>> separated from the changes to add IBM-29626C to AIX's java.base. > >> >>> > >> >>> -Alan From leventov.ru at gmail.com Mon Jan 28 13:14:50 2019 From: leventov.ru at gmail.com (Roman Leventov) Date: Mon, 28 Jan 2019 20:14:50 +0700 Subject: ClassValue - clarify Javadoc Message-ID: computeValue() documentation says: "This method will be invoked within the first thread that accesses the value with the get method. Normally, this method is invoked at most once per class, but it may be invoked again if there has been a call to remove." It sounds exactly like ClassValue prohibits concurrent computeValue calls, but it doesn't, as could be seen in the documentation of get(): "The actual installation of the value on the class is performed atomically. At that point, if several racing threads have computed values, one is chosen, and returned to all the racing threads." From christoph.langer at sap.com Mon Jan 28 13:23:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Jan 2019 13:23:26 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> Message-ID: <2424978d6a124ff591955d4b4beff759@sap.com> Hi Matthias, thanks for the update. I still think you should avoid introducing a file parse_manifest_md.c. As per my previous mail, you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. You can take example on the implementation of JLI_Snprintf which has coding on Windows and for Unix it's just a #define to snprintf. Would it be possible to add a jtreg testcase that shows/tests the issue? Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 28. Januar 2019 12:38 > To: Alan Bateman ; core-libs- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hello Alan / Christoph, > new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ > > - moved ELP_PREFIX define out of the function > - added a check (wfullnamelen > 247) before CreateFileW is attempted > - some other formatting (mostly suggested by Christoph) > > > Best regards, Matthias > > > > -----Original Message----- > > From: Alan Bateman > > Sent: Sonntag, 27. Januar 2019 16:57 > > To: Baesken, Matthias ; core-libs- > > dev at openjdk.java.net > > Cc: Langer, Christoph > > Subject: Re: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > On 24/01/2019 16:19, Baesken, Matthias wrote: > > >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > >> WIN32 ? > > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > > function open_jarfile ? > > > I considered this, but did not like the idea to add a separate file for UNIX > > just for the small function . > > > > > > Your suggestion to use FILE_SHARE_READ is probably the right way to > do > > it , I changed this, second webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > > > Christoph Langer's suggestion to use jli_util seems worth exploring to > > keep the platform specific code together. > > > > I still find the call to _open and checking for ENOENT a bit icky. If > > this change gets pushed then I think we need a follow-up issue created > > to replace this to use CreateFile consistently. > > > > -Alan From takiguc at linux.vnet.ibm.com Mon Jan 28 13:49:34 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 28 Jan 2019 22:49:34 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8c05b5147fa7489282d7cae04e801702@sap.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> Message-ID: <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> Hello Goetz. Thank you for your suggestion. I just open JDK-8217880 [1]. I just restart clean build. I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. [1] https://bugs.openjdk.java.net/browse/JDK-8217880 Thanks, Ichiroh Takiguchi On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > Hi Ichiroh, > > just open a bug, like "Fix aix build after 8214533" and post a RFR for > it. > I assume the fix is quite trivial so we can review it quick. > > Best regards, > Goetz. > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Montag, 28. Januar 2019 14:13 >> To: Baesken, Matthias >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> charset >> >> Hello. >> >> I'm very sorry. It's my fault. >> EUC_JP class was moved to java.base module. >> (sun.nio.cs.EUC_JP). >> >> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> EUC_JP_Open. >> >> Could you suggest me how I should provide new webrev files ? >> >> Thanks, >> Ichiroh Takiguchi >> >> >> On 2019-01-28 17:03, Baesken, Matthias wrote: >> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> > we see build errors on AIX , are they related to this change ? >> > >> > >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> > error: Decoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Decoder extends EUC_JP.Decoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> > error: Encoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Encoder extends EUC_JP.Encoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> > error: Decoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Decoder extends EUC_JP.Decoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> > error: Encoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Encoder extends EUC_JP.Encoder { >> > >> > Best regards, Matthias >> > >> > >> > >> >> -----Original Message----- >> >> From: ppc-aix-port-dev On >> >> Behalf Of Ichiroh Takiguchi >> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >> To: Alan Bateman >> >> Cc: build-dev ; ppc-aix-port-dev > >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >> Subject: 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, Ltd. >> >> >> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >> > Hello Alan. >> >> > >> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >> > I cannot wait until JDK-8215333 is closed. >> >> > Is it possible to put IBM-29626C charset with standard way ? >> >> > >> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >> > >> >> > Thanks, >> >> > Ichiroh Takiguchi >> >> > >> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> >> Hello Roger, Magnus and Alan. >> >> >> I may need to put alias information into charsets file. >> >> >> stdcs-xxx cannot handle this information... >> >> >> >> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >> >> >> >> I appreciate if you give me further suggestions. >> >> >> >> >> >> Thanks, >> >> >> Ichiroh Takiguchi >> >> >> >> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>> It is a nice feature that charsets are selected at build time using >> >> >>>>> the stdcs-xxx files. >> >> >>>>> This change breaks that pattern and embeds os specific information >> >> >>>>> in more than one place. >> >> >>>>> That does not seem like an improvement.? Is there any alternative? >> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >> >>> My reading of the patch is that the "os" key is to avoid generating >> >> >>> it >> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >> >>> non-AIX platforms. The general direction is welcome but I think >> >> >>> further work and discussion will be needed to get the right set of >> >> >>> changes to support filtering in the build. It can probably be >> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >> >>> >> >> >>> -Alan From Roger.Riggs at oracle.com Mon Jan 28 15:39:00 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 28 Jan 2019 10:39:00 -0500 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> Message-ID: Hi, The simplest fix for this failing test is to add a call to reachabilityFence to prevent the loader and loaderRef from going out of scope early.? It maintains getting debug output on a failure. Offlist, Jie and I explored some alternate ways to write the test and settled on this one. Please review: diff --git a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java --- a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java +++ b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea ???????????? Reference dequeued = refQueue.remove(TIMEOUT); ???????????? if (dequeued == null) { ???????????????? System.err.println( -??????????????????? "TEST FAILED: loader not deteced weakly reachable"); +??????????????????? "TEST FAILED: loader not detected weakly reachable"); ???????????????? dumpThreads(); ???????????????? throw new RuntimeException( ???????????????????? "TEST FAILED: loader not detected weakly reachable"); ???????????? } +??????????? Reference.reachabilityFence(loader); +??????????? Reference.reachabilityFence(loaderRef); ???????????? System.err.println( ???????????????? "TEST PASSED: loader detected weakly reachable"); Thanks, Roger On 01/11/2019 07:25 PM, Jie Fu wrote: > Thanks David and Roger. > > > On 2019?01?12? 06:52, David Holmes wrote: >> Hi Roger, >> >> On 12/01/2019 2:22 am, Roger Riggs wrote: >>> Hi, >>> >>> The proposed patch changes the test in a way that is unintended. >>> >>> Adding the infinite loop of gc() and sleep, will change the timeout >>> behavior >>> from the existing timeout of TIMEOUT to the jtreg default timeout of >>> the whole test. >> >> Partially true. If the new loop gets stuck then yes the jtreg default >> timeout will apply - I don't see that is necessarily a bad thing. The >> existing timeout only applies to the refQueue.remove operation >> itself, you don't know how much time was spent before you got there, >> nor how much will be spent after in the dumpThreads() calls - so the >> jtreg timeout can still come into affect. >> >>> Further, it renders the check at lines 114-120 irrelevant since >>> loaderRef.get() >>> will have returned null and the ref will have been enqueued by then. >> >> I wouldn't say irrelevant as it double-checks the interaction between >> the ref.get() and the queue.remove() - the result of one should imply >> the result of the other, but if enqueuing had a bug .... >> >>> While it is true that calling gc() only once is unreliable, a better >>> fix is to >>> put the code from 108-120 in a loop with a fixed number of durations >> >> That would also work - say 5 loops and reduce TIMEOUT to 4000. >> >>> and add Reachability.reachabilityFence(loaderRef) to ensure the ref >>> is not ignored. >> >> Adding ReachabilityFence, alone, may solve the observed problem given >> one gc() seems to be working in practice (and because we don't >> actually have the leaked loaders anymore because those threads >> (sun.misc.GC threads) don't exist anymore). >> >> Cheers, >> David >> >>> Regards, Roger > > From christoph.langer at sap.com Mon Jan 28 15:49:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Jan 2019 15:49:27 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> Message-ID: Hi Steve, Roger, I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) This is what ran through our test system without issues: http://cr.openjdk.java.net/~clanger/webrevs/8217777.0/ In case there was an error in the output, it would read like this: ----------System.out:(39/1030)---------- Preferences::exportSubtree did not yield the expected result. Actual: Expected: d Are you all ok with that? Then I'd push it... Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Roger Riggs > Sent: Freitag, 25. Januar 2019 17:52 > To: Steve Groeger > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java > passes even when test should fail > > +1, > > Thanks, Roger > > > On 01/25/2019 11:21 AM, Steve Groeger wrote: > > Hi Roger, > > > > Thanks. Have included the bug number to the @bug line and have > > included the expected and actual output when there is an error. > > > > Have generated a new webrev here: > > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.01/ > > > > > > Hope this is now OK. > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > From: Roger Riggs > > To: core-libs-dev at openjdk.java.net > > Date: 25/01/2019 15:30 > > Subject: Re: JDK-8217777 TEST_BUG: > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > Sent by: "core-libs-dev" > > ------------------------------------------------------------------------ > > > > > > > > Hi Steve, > > > > Add 8217777 to the @bug line; it helps track and run tests that fixed > > bugs? (jtreg -bug:8217777) > > > > +1 printing the expected and actual (when a failure occurs). > > > > Looks fine overall. > > > > Thanks, Roger > > > > > > > > On 01/25/2019 09:57 AM, Steve Groeger wrote: > > > Hi Christoph, > > > > > > Thanks for looking at this. > > > > > > These lines > > > > > > 43 ? ? ? ? ? //System.out.print(baos.toString()); > > > 44 ? ? ? ? ? //System.out.print(expectedResult); > > > > > > were commented out in the current code but if you think displaying this > > > info would be good then I can un-comment them. > > > > > > I think only fixing this in the jdk (JDK13) branch is OK. > > > If it is later determined that this is really needed in jdk12 or > > jdk11u , > > > then I can always request a backport. > > > > > > Thanks > > > Steve Groeger > > > IBM Runtime Technologies > > > Hursley, Winchester > > > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > > > Fax (44) 1962 816800 > > > Lotus Notes: Steve Groeger/UK/IBM > > > Internet: groeges at uk.ibm.com > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > > > From: ? "Langer, Christoph" > > > To: ? ? Steve Groeger > > > Cc: ? ? core-libs > > > Date: ? 25/01/2019 14:30 > > > Subject: ? ? ? ?RE: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > > > > > > > > > Hi Steve, > > > > > > in general this change looks reasonable to me. > > > > > > I think in case there is an error, it would be useful to get a > > printout of > > > the expected/vs actual strings like these lines: > > > 43 ? ? ? ? ? //System.out.print(baos.toString()); > > > 44 ? ? ? ? ? //System.out.print(expectedResult); > > > > > > I'll take the change and run it through our test system and see if > > we see > > > any issues. > > > > > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > > > you particularly interested in getting this fixed for jdk12 and/or > > jdk11u? > > > > > > Best regards > > > Christoph > > > > > >> -----Original Message----- > > >> From: core-libs-dev On > Behalf > > >> Of Steve Groeger > > >> Sent: Freitag, 25. Januar 2019 12:40 > > >> To: core-libs > > >> Subject: RFR: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java > > >> passes even when test should fail > > >> > > >> Hi all, > > >> > > >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > > >> test. > > >> Using jtreg to run this test the test passes no matter what happens > > > within > > >> the test. > > >> Have raised an issue for this: > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8217777 > > > > > >> I think the issue is 2 fold: > > >> 1) the test check the expected vs. actual and throws an exception but > > > this > > >> is caught later in the code, which causes the test to pass as there is > > > no > > >> exception thrown. > > >> 2) the exported XML now contains a `standalone="no"` entry in the XML > > >> prologue, which is not in the expected XML. > > >> > > >> I have generated a webrev to resolve this: > > >> > > > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ > > > > > > > >> This occurs on jdk11 but is probabaly also an issue on other > > releases ie > > >> jdk8u, jdk12, jdk ?etc > > >> > > >> Please could someone review this webrev and sponsor this chnage for > me > > > as > > >> I am unable to commit this myself. > > >> > > >> Thanks > > >> Steve Groeger > > >> IBM Runtime Technologies > > >> Hursley, Winchester > > >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > > >> Fax (44) 1962 816800 > > >> Lotus Notes: Steve Groeger/UK/IBM > > >> Internet: groeges at uk.ibm.com > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From naoto.sato at oracle.com Mon Jan 28 16:06:38 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 28 Jan 2019 08:06:38 -0800 Subject: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <518614fc-9290-984f-7cb9-d36e66d32fcf@oracle.com> References: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> <42db3098-b44c-438f-b6a9-785c5af34c81@default> <518614fc-9290-984f-7cb9-d36e66d32fcf@oracle.com> Message-ID: <57d495d5-a685-8380-9ace-89a9179dd20e@oracle.com> +1 Naoto On 1/28/19 3:18 AM, Chris Hegarty wrote: > > On 27/01/2019 11:54, Deepak Kejriwal wrote: >> ... >> Hi All, >> >> >> JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ > > This looks good Deepak. Reviewed. > > One minor comment. "The of(int) and valueOf(String) methods ...", these > references could be javadoc links. From naoto.sato at oracle.com Mon Jan 28 16:07:07 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 28 Jan 2019 08:07:07 -0800 Subject: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <1bff24d3-2583-ecf5-f361-b53fed49e7dd@oracle.com> References: <49949ba0-07cc-4b7c-b499-afb0fff0675b@default> <1bff24d3-2583-ecf5-f361-b53fed49e7dd@oracle.com> Message-ID: <0d9e4955-bf9e-b9ac-7c0d-0ebe24949a43@oracle.com> +1 Naoto On 1/28/19 3:19 AM, Chris Hegarty wrote: > > > On 26/01/2019 10:57, Deepak Kejriwal wrote: >> Hi All, >> >> >> JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ > > This looks good Deepak. Reviewed. > > One minor comment. "The of(int) and valueOf(String) methods ...", these > references could be javadoc links. From matthias.baesken at sap.com Mon Jan 28 16:09:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 28 Jan 2019 16:09:49 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <2424978d6a124ff591955d4b4beff759@sap.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> Message-ID: > you should think of a JLI_open function and then you can > put its implementation into the Windows version of java_md.c. Hi Christoph, I like this idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > Would it be possible to add a jtreg testcase that shows/tests the issue? > Maybe I could put something into the existing jdk/test/jdk/tools/launcher tests. Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 28. Januar 2019 14:23 > To: Baesken, Matthias ; Alan Bateman > ; core-libs-dev at openjdk.java.net > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > thanks for the update. > > I still think you should avoid introducing a file parse_manifest_md.c. As per > my previous mail, you should think of a JLI_open function and then you can > put its implementation into the Windows version of java_md.c. You can take > example on the implementation of JLI_Snprintf which has coding on > Windows and for Unix it's just a #define to snprintf. > > Would it be possible to add a jtreg testcase that shows/tests the issue? > > Best regards > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Montag, 28. Januar 2019 12:38 > > To: Alan Bateman ; core-libs- > > dev at openjdk.java.net > > Cc: Langer, Christoph > > Subject: RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hello Alan / Christoph, > > new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ > > > > - moved ELP_PREFIX define out of the function > > - added a check (wfullnamelen > 247) before CreateFileW is attempted > > - some other formatting (mostly suggested by Christoph) > > > > > > Best regards, Matthias > > > > > > > -----Original Message----- > > > From: Alan Bateman > > > Sent: Sonntag, 27. Januar 2019 16:57 > > > To: Baesken, Matthias ; core-libs- > > > dev at openjdk.java.net > > > Cc: Langer, Christoph > > > Subject: Re: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > On 24/01/2019 16:19, Baesken, Matthias wrote: > > > >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > > >> WIN32 ? > > > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > > > function open_jarfile ? > > > > I considered this, but did not like the idea to add a separate file for > UNIX > > > just for the small function . > > > > > > > > Your suggestion to use FILE_SHARE_READ is probably the right way to > > do > > > it , I changed this, second webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > > > > > Christoph Langer's suggestion to use jli_util seems worth exploring to > > > keep the platform specific code together. > > > > > > I still find the call to _open and checking for ENOENT a bit icky. If > > > this change gets pushed then I think we need a follow-up issue created > > > to replace this to use CreateFile consistently. > > > > > > -Alan > From Roger.Riggs at oracle.com Mon Jan 28 16:19:16 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 28 Jan 2019 11:19:16 -0500 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> Message-ID: <2a882004-f11c-6f79-3df2-70e3c1383aec@oracle.com> Looks good, Thanks, Roger On 01/28/2019 10:49 AM, Langer, Christoph wrote: > Hi Steve, Roger, > > I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) > > This is what ran through our test system without issues: http://cr.openjdk.java.net/~clanger/webrevs/8217777.0/ > > In case there was an error in the output, it would read like this: > > ----------System.out:(39/1030)---------- > Preferences::exportSubtree did not yield the expected result. > Actual: > > > > > > > > > > > > > > > > > > > Expected: > > > > > > > > > > > > > > > > > d > > Are you all ok with that? Then I'd push it... > > Thanks > Christoph > > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Roger Riggs >> Sent: Freitag, 25. Januar 2019 17:52 >> To: Steve Groeger >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java >> passes even when test should fail >> >> +1, >> >> Thanks, Roger >> >> >> On 01/25/2019 11:21 AM, Steve Groeger wrote: >>> Hi Roger, >>> >>> Thanks. Have included the bug number to the @bug line and have >>> included the expected and actual output when there is an error. >>> >>> Have generated a new webrev here: >>> http://cr.openjdk.java.net/~sgroeger/8217777/webrev.01/ >>> >>> >>> Hope this is now OK. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >>> >>> >>> >>> From: Roger Riggs >>> To: core-libs-dev at openjdk.java.net >>> Date: 25/01/2019 15:30 >>> Subject: Re: JDK-8217777 TEST_BUG: >>> jdk/java/util/prefs/ExportSubtree.java passes even when test should fail >>> Sent by: "core-libs-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Steve, >>> >>> Add 8217777 to the @bug line; it helps track and run tests that fixed >>> bugs? (jtreg -bug:8217777) >>> >>> +1 printing the expected and actual (when a failure occurs). >>> >>> Looks fine overall. >>> >>> Thanks, Roger >>> >>> >>> >>> On 01/25/2019 09:57 AM, Steve Groeger wrote: >>>> Hi Christoph, >>>> >>>> Thanks for looking at this. >>>> >>>> These lines >>>> >>>> 43 ? ? ? ? ? //System.out.print(baos.toString()); >>>> 44 ? ? ? ? ? //System.out.print(expectedResult); >>>> >>>> were commented out in the current code but if you think displaying this >>>> info would be good then I can un-comment them. >>>> >>>> I think only fixing this in the jdk (JDK13) branch is OK. >>>> If it is later determined that this is really needed in jdk12 or >>> jdk11u , >>>> then I can always request a backport. >>>> >>>> Thanks >>>> Steve Groeger >>>> IBM Runtime Technologies >>>> Hursley, Winchester >>>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >>>> Fax (44) 1962 816800 >>>> Lotus Notes: Steve Groeger/UK/IBM >>>> Internet: groeges at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>>> >>>> >>>> From: ? "Langer, Christoph" >>>> To: ? ? Steve Groeger >>>> Cc: ? ? core-libs >>>> Date: ? 25/01/2019 14:30 >>>> Subject: ? ? ? ?RE: JDK-8217777 TEST_BUG: >>>> jdk/java/util/prefs/ExportSubtree.java passes even when test should fail >>>> >>>> >>>> >>>> Hi Steve, >>>> >>>> in general this change looks reasonable to me. >>>> >>>> I think in case there is an error, it would be useful to get a >>> printout of >>>> the expected/vs actual strings like these lines: >>>> 43 ? ? ? ? ? //System.out.print(baos.toString()); >>>> 44 ? ? ? ? ? //System.out.print(expectedResult); >>>> >>>> I'll take the change and run it through our test system and see if >>> we see >>>> any issues. >>>> >>>> Is it ok for you if we do the fix just in the jdk branch (JDK13) or are >>>> you particularly interested in getting this fixed for jdk12 and/or >>> jdk11u? >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: core-libs-dev On >> Behalf >>>>> Of Steve Groeger >>>>> Sent: Freitag, 25. Januar 2019 12:40 >>>>> To: core-libs >>>>> Subject: RFR: JDK-8217777 TEST_BUG: >>>> jdk/java/util/prefs/ExportSubtree.java >>>>> passes even when test should fail >>>>> >>>>> Hi all, >>>>> >>>>> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java >>>>> test. >>>>> Using jtreg to run this test the test passes no matter what happens >>>> within >>>>> the test. >>>>> Have raised an issue for this: >>>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8217777 >>>> >>>>> I think the issue is 2 fold: >>>>> 1) the test check the expected vs. actual and throws an exception but >>>> this >>>>> is caught later in the code, which causes the test to pass as there is >>>> no >>>>> exception thrown. >>>>> 2) the exported XML now contains a `standalone="no"` entry in the XML >>>>> prologue, which is not in the expected XML. >>>>> >>>>> I have generated a webrev to resolve this: >>>>> >>>> http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ >>> >>>>> This occurs on jdk11 but is probabaly also an issue on other >>> releases ie >>>>> jdk8u, jdk12, jdk ?etc >>>>> >>>>> Please could someone review this webrev and sponsor this chnage for >> me >>>> as >>>>> I am unable to commit this myself. >>>>> >>>>> Thanks >>>>> Steve Groeger >>>>> IBM Runtime Technologies >>>>> Hursley, Winchester >>>>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >>>>> Fax (44) 1962 816800 >>>>> Lotus Notes: Steve Groeger/UK/IBM >>>>> Internet: groeges at uk.ibm.com >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>> number >>>>> 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 >>>>> 3AU >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>> number >>>>> 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 >>>>> 3AU >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU From GROEGES at uk.ibm.com Mon Jan 28 16:25:26 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Mon, 28 Jan 2019 16:25:26 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> Message-ID: Hi Christoph, Additional changes look OK to me. Happy for for you to push. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: Steve Groeger , Roger Riggs Cc: "core-libs-dev at openjdk.java.net" Date: 28/01/2019 15:49 Subject: RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail Hi Steve, Roger, I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) This is what ran through our test system without issues: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eclanger_webrevs_8217777.0_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=-D-v0BJbhRMiCOHVFbZuV0K-O9dQfaUZfKDXpVtOFmE&e= In case there was an error in the output, it would read like this: ----------System.out:(39/1030)---------- Preferences::exportSubtree did not yield the expected result. Actual: Expected: d Are you all ok with that? Then I'd push it... Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Roger Riggs > Sent: Freitag, 25. Januar 2019 17:52 > To: Steve Groeger > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java > passes even when test should fail > > +1, > > Thanks, Roger > > > On 01/25/2019 11:21 AM, Steve Groeger wrote: > > Hi Roger, > > > > Thanks. Have included the bug number to the @bug line and have > > included the expected and actual output when there is an error. > > > > Have generated a new webrev here: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8217777_webrev.01_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=HNzeDwTU54Elbh8Xur8QRRGewTWgcTLQbtCW9nU4A7M&e= > > < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Esgroeger_8217777_webrev.01_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=A-gmLJCRSPC1xqUfEIvACidaaGaQiYlARpNTAbV0UPs&e= > > > > > Hope this is now OK. > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > From: Roger Riggs > > To: core-libs-dev at openjdk.java.net > > Date: 25/01/2019 15:30 > > Subject: Re: JDK-8217777 TEST_BUG: > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > Sent by: "core-libs-dev" > > ------------------------------------------------------------------------ > > > > > > > > Hi Steve, > > > > Add 8217777 to the @bug line; it helps track and run tests that fixed > > bugs (jtreg -bug:8217777) > > > > +1 printing the expected and actual (when a failure occurs). > > > > Looks fine overall. > > > > Thanks, Roger > > > > > > > > On 01/25/2019 09:57 AM, Steve Groeger wrote: > > > Hi Christoph, > > > > > > Thanks for looking at this. > > > > > > These lines > > > > > > 43 //System.out.print(baos.toString()); > > > 44 //System.out.print(expectedResult); > > > > > > were commented out in the current code but if you think displaying this > > > info would be good then I can un-comment them. > > > > > > I think only fixing this in the jdk (JDK13) branch is OK. > > > If it is later determined that this is really needed in jdk12 or > > jdk11u , > > > then I can always request a backport. > > > > > > Thanks > > > Steve Groeger > > > IBM Runtime Technologies > > > Hursley, Winchester > > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > > Fax (44) 1962 816800 > > > Lotus Notes: Steve Groeger/UK/IBM > > > Internet: groeges at uk.ibm.com > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > > > From: "Langer, Christoph" > > > To: Steve Groeger > > > Cc: core-libs > > > Date: 25/01/2019 14:30 > > > Subject: RE: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > > > > > > > > > Hi Steve, > > > > > > in general this change looks reasonable to me. > > > > > > I think in case there is an error, it would be useful to get a > > printout of > > > the expected/vs actual strings like these lines: > > > 43 //System.out.print(baos.toString()); > > > 44 //System.out.print(expectedResult); > > > > > > I'll take the change and run it through our test system and see if > > we see > > > any issues. > > > > > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > > > you particularly interested in getting this fixed for jdk12 and/or > > jdk11u? > > > > > > Best regards > > > Christoph > > > > > >> -----Original Message----- > > >> From: core-libs-dev On > Behalf > > >> Of Steve Groeger > > >> Sent: Freitag, 25. Januar 2019 12:40 > > >> To: core-libs > > >> Subject: RFR: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java > > >> passes even when test should fail > > >> > > >> Hi all, > > >> > > >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > > >> test. > > >> Using jtreg to run this test the test passes no matter what happens > > > within > > >> the test. > > >> Have raised an issue for this: > > >> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217777&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=XeAOtwPImh2x7iqVi4u1XlKM0DR2FGd3YX9BoQqXfQU&e= > > > > > >> I think the issue is 2 fold: > > >> 1) the test check the expected vs. actual and throws an exception but > > > this > > >> is caught later in the code, which causes the test to pass as there is > > > no > > >> exception thrown. > > >> 2) the exported XML now contains a `standalone="no"` entry in the XML > > >> prologue, which is not in the expected XML. > > >> > > >> I have generated a webrev to resolve this: > > >> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8217777_webrev.00_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=j_sE8qEQubA9iHJOOjkevrStaPbH0P31wAwAd-x_Tds&e= > > < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Esgroeger_8217777_webrev.00_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=Wsc1SgpzRruLlitHKWYS8yqAycO5xt7qqN9bCvVCySc&s=9JrVqkr7r3bbS28B8AOt8PjdRmohqn8uHbPjoB0MX_o&e= > > > > > > >> This occurs on jdk11 but is probabaly also an issue on other > > releases ie > > >> jdk8u, jdk12, jdk etc > > >> > > >> Please could someone review this webrev and sponsor this chnage for > me > > > as > > >> I am unable to commit this myself. > > >> > > >> Thanks > > >> Steve Groeger > > >> IBM Runtime Technologies > > >> Hursley, Winchester > > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > >> Fax (44) 1962 816800 > > >> Lotus Notes: Steve Groeger/UK/IBM > > >> Internet: groeges at uk.ibm.com > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From goetz.lindenmaier at sap.com Mon Jan 28 16:28:48 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Jan 2019 16:28:48 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: References: <6ab11b43b93647da910b410d3544957a@sap.com> Message-ID: Hi Christoph, Patching the file myself really helped to see there are no real changes. For the missing patch of the constructor I understand it was only an arbitrary reordering of arguments you omitted. Thus the whole chunk disappeared. This makes sense, and in case someone downports the other change he should be able to cope with that. Thus, looks good! Best regards, G?tz > -----Original Message----- > From: Langer, Christoph > Sent: Friday, January 25, 2019 11:40 AM > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net > Subject: RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE > when the zip file is located in a custom file system > > Hi Goetz, > > > > > And I see much more differences if I compare the diffs. > > > > Please explain. > > > > unfortunately, the udiffs of the webrev look different in quite some parts to > what you see when you look at the commit on the hg web server > (http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5), although those are > the same. There were only 3 rejects when I applied the change to jdk11u > (you could try this yourself). > > > This is a big change, and it seems a lot more changed than resolving > > Hunks. Some hunks are missing altogether. > > > > For example, > > http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5, > > ZipFileSystem 2341 > > 2.341- IndexNode inode = new IndexNode(cen, nlen, pos); > > 2.342+ IndexNode inode = new IndexNode(cen, pos, nlen); > > Is missing in your change. > > The constructor IndexNode(byte[] cen, int noff, int nlen, int pos) (jdk11u) vs. > IndexNode(byte[] cen, int pos, int nlen) (jdk11) was actually the part where > the failing hunks originated. There was another patch pre 8034802 in jdk12 > which changed signature: > IndexNode(byte[] cen, int noff, int nlen, int pos) -to IndexNode(byte[] cen, > int nlen, int pos). > 8034802 did this change then: > IndexNode(byte[] cen, int nlen, int pos) -> IndexNode(byte[] cen, int pos, int > nlen) > > I chose not to touch this part but maybe this change should change the > constructor from IndexNode(byte[] cen, int noff, int nlen, int pos) -> > IndexNode(byte[] cen, int noff, int pos, int nlen), though, to take over this > change of order in arguments. It's a package private constructor that is only > called in one spot. What do you think? > > Thanks & Best regards > Christoph From sean.coffey at oracle.com Mon Jan 28 16:30:47 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 28 Jan 2019 16:30:47 +0000 Subject: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: <57d495d5-a685-8380-9ace-89a9179dd20e@oracle.com> References: <62ba0b21-5942-4e49-a9cf-6f57ae4d2e5e@default> <42db3098-b44c-438f-b6a9-785c5af34c81@default> <518614fc-9290-984f-7cb9-d36e66d32fcf@oracle.com> <57d495d5-a685-8380-9ace-89a9179dd20e@oracle.com> Message-ID: <7b3b1140-338c-a8a0-c565-225694d617be@oracle.com> Thanks for the reviews. Here's the final webrev which I hope to sponsor for Deepak once I have the necessary approvals. http://cr.openjdk.java.net/~coffeys/webrev.8212941.jdk8u/webrev/ Regards, Sean. On 28/01/19 16:06, Naoto Sato wrote: > +1 > > Naoto > > On 1/28/19 3:18 AM, Chris Hegarty wrote: >> >> On 27/01/2019 11:54, Deepak Kejriwal wrote: >>> ... >>> Hi All, >>> >>> >>> JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ >> >> This looks good Deepak. Reviewed. >> >> One minor comment. "The of(int) and valueOf(String) methods ...", these >> references could be javadoc links. From chris.hegarty at oracle.com Mon Jan 28 16:46:15 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 16:46:15 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> Message-ID: <66488fb2-b612-3091-f73f-34d200506919@oracle.com> On 28/01/2019 16:09, Baesken, Matthias wrote: >> you should think of a JLI_open function and then you can >> put its implementation into the Windows version of java_md.c. > > Hi Christoph, I like this idea . > > New webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ This is the one. Looks good ( and clean ). -Chris. From turbanoff at gmail.com Sun Jan 27 22:35:34 2019 From: turbanoff at gmail.com (Andrey Turbanov) Date: Mon, 28 Jan 2019 01:35:34 +0300 Subject: Duplicate words typos in comments/javadoc/strings Message-ID: Hello. I noticed that Open JDK source code contains many duplicate words typos which could be easily find via simple regexp. I checked only java.base module and fixed problems there. Does it makes sense to create patches to other modules too? Index: src/java.base/share/classes/java/lang/module/Resolver.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/module/Resolver.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/lang/module/Resolver.java (date 1548627900626) @@ -659,7 +659,7 @@ * Checks the readability graph to ensure that *

    *
  1. A module does not read two or more modules with the same name. - * This includes the case where a module reads another another with the + * This includes the case where a module reads another with the * same name as itself.

  2. *
  3. Two or more modules in the configuration don't export the same * package to a module that reads both. This includes the case where a Index: src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java (date 1548627900979) @@ -331,7 +331,7 @@ } /** - * Load the the KeyStore as described in the specified descriptor. + * Load the KeyStore as described in the specified descriptor. */ private static KeyStore loadKeyStore( TrustStoreDescriptor descriptor) throws Exception { Index: src/java.base/share/classes/java/lang/String.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/String.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/lang/String.java (date 1548627901252) @@ -2698,7 +2698,7 @@ *

    * Otherwise, returns a substring of this string beginning with the first * code point that is not a {@link Character#isWhitespace(int) white space} - * up to to and including the last code point of this string. + * up to and including the last code point of this string. *

    * This method may be used to trim * {@link Character#isWhitespace(int) white space} from Index: src/java.base/share/classes/jdk/internal/platform/Metrics.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/jdk/internal/platform/Metrics.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/jdk/internal/platform/Metrics.java (date 1548627900501) @@ -322,7 +322,7 @@ * Returns the largest amount of physical memory, in bytes, that * have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -362,7 +362,7 @@ * Returns the largest amount of kernel physical memory, in bytes, that * have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -402,7 +402,7 @@ * Returns the largest amount of networking physical memory, in bytes, * that have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -442,7 +442,7 @@ * Returns the largest amount of physical memory and swap space, * in bytes, that have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ Index: src/java.base/share/classes/java/lang/Object.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/Object.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/lang/Object.java (date 1548627901176) @@ -430,7 +430,7 @@ * } * * @param timeoutMillis the maximum time to wait, in milliseconds - * @param nanos additional time, in nanoseconds, in the range range 0-999999 inclusive + * @param nanos additional time, in nanoseconds, in the range 0-999999 inclusive * @throws IllegalArgumentException if {@code timeoutMillis} is negative, * or if the value of {@code nanos} is out of range * @throws IllegalMonitorStateException if the current thread is not Index: src/java.base/share/classes/sun/security/util/ConstraintsParameters.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/util/ConstraintsParameters.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/util/ConstraintsParameters.java (date 1548627901022) @@ -37,7 +37,7 @@ * This class contains parameters for checking against constraints that extend * past the publicly available parameters in java.security.AlgorithmConstraints. - * This is currently on passed between between PKIX, AlgorithmChecker, + * This is currently on passed between PKIX, AlgorithmChecker, * and DisabledAlgorithmConstraints. */ public class ConstraintsParameters { Index: src/java.base/share/classes/java/util/SimpleTimeZone.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/util/SimpleTimeZone.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/util/SimpleTimeZone.java (date 1548627900673) @@ -310,7 +310,7 @@ * See the class description for the special cases of this parameter. * @param endDayOfWeek The daylight saving time ending day-of-week. * See the class description for the special cases of this parameter. - * @param endTime The daylight saving ending time in time time mode + * @param endTime The daylight saving ending time in time mode * specified by endTimeMode. * @param endTimeMode The mode of the end time specified by endTime * @param dstSavings The amount of time in milliseconds saved during Index: src/java.base/share/classes/sun/security/util/math/SmallValue.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/util/math/SmallValue.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/util/math/SmallValue.java (date 1548627900541) @@ -28,7 +28,7 @@ /** * A "small" value that can be used with the field arithmetic library. This * interface enables optimizations based on the fact that certain values are - * known to be small, where the definition of small is specific to the the + * known to be small, where the definition of small is specific to the * arithmetic implementation. */ Index: src/java.base/share/classes/java/lang/invoke/MethodHandle.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/invoke/MethodHandle.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/lang/invoke/MethodHandle.java (date 1548627901076) @@ -1083,7 +1083,7 @@ * else if (makeVarargs) * return asVarargsCollector(type().lastParameterType()); * else - * return return asFixedArity(); + * return asFixedArity(); * } * @param makeVarargs true if the return method handle should have variable arity behavior * @return a method handle of the same type, with possibly adjusted variable arity behavior Index: src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java (date 1548627900928) @@ -145,7 +145,7 @@ if (!chc.conContext.isNegotiated) { if (chc.activeCipherSuites.contains( CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV)) { - // Using the the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. + // Using the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. return null; } Index: src/java.base/share/classes/sun/security/ssl/HandshakeHash.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/ssl/HandshakeHash.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/ssl/HandshakeHash.java (date 1548627901128) @@ -246,7 +246,7 @@ try { baos.writeTo(result.baos); } catch (IOException ex) { - throw new RuntimeException("unable to to clone hash state"); + throw new RuntimeException("unable to clone hash state"); } return result; } Index: src/java.base/share/classes/sun/security/ssl/SSLTransport.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/security/ssl/SSLTransport.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/sun/security/ssl/SSLTransport.java (date 1548627900586) @@ -71,7 +71,7 @@ * destination application data buffers. * * For SSL/TLS connections, if no source data, the network data may be - * received from the underlying underlying SSL/TLS input stream. + * received from the underlying SSL/TLS input stream. * * @param context the transportation context * @param srcs an array of {@code ByteBuffers} containing the Index: src/java.base/share/classes/java/util/stream/WhileOps.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/util/stream/WhileOps.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/util/stream/WhileOps.java (date 1548627900792) @@ -658,7 +658,7 @@ // True if no splitting should be performed, if true then // this spliterator may be used for an underlying spliterator whose // covered elements have an encounter order - // See use in stream take/dropWhile default default methods + // See use in stream take/dropWhile default methods final boolean noSplitting; // True when operations are cancelled for all related spliterators // For taking, spliterators cannot split or traversed Index: src/java.base/share/classes/java/lang/invoke/VarHandle.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/invoke/VarHandle.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/java/lang/invoke/VarHandle.java (date 1548627900836) @@ -2160,7 +2160,7 @@ * Construct a {@linkplain VarHandleDesc} given a kind, name, and declaring * class. * - * @param kind the kind of of the var handle + * @param kind the kind of the var handle * @param name the unqualified name of the field, for field var handles; otherwise ignored * @param declaringClass a {@link ClassDesc} describing the declaring class, * for field var handles @@ -2217,7 +2217,7 @@ /** * Returns a {@linkplain VarHandleDesc} corresponding to a {@link VarHandle} - * for for an array type. + * for an array type. * * @param arrayClass a {@link ClassDesc} describing the type of the array * @return the {@linkplain VarHandleDesc} Index: src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java (date 1548627900895) @@ -58,7 +58,7 @@ public static final int YES_NO_OPTION = 0; /** - * YES/NO/CANCEL confirmation confirmation option. + * YES/NO/CANCEL confirmation option. * *

    An underlying security service specifies this as the * {@code optionType} to a {@code ConfirmationCallback} @@ -68,7 +68,7 @@ public static final int YES_NO_CANCEL_OPTION = 1; /** - * OK/CANCEL confirmation confirmation option. + * OK/CANCEL confirmation option. * *

    An underlying security service specifies this as the * {@code optionType} to a {@code ConfirmationCallback} Index: src/java.base/share/classes/jdk/internal/access/SharedSecrets.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/jdk/internal/access/SharedSecrets.java (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) +++ src/java.base/share/classes/jdk/internal/access/SharedSecrets.java (date 1548627901204) @@ -77,7 +77,7 @@ public static JavaUtilJarAccess javaUtilJarAccess() { if (javaUtilJarAccess == null) { - // Ensure JarFile is initialized; we know that that class + // Ensure JarFile is initialized; we know that this class // provides the shared secret unsafe.ensureClassInitialized(JarFile.class); } Andrey Turbanov. From lance.andersen at oracle.com Mon Jan 28 17:04:44 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 28 Jan 2019 12:04:44 -0500 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: Message-ID: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> The updates look fine > On Jan 27, 2019, at 5:35 PM, Andrey Turbanov wrote: > > Hello. > I noticed that Open JDK source code contains many duplicate words > typos which could be easily find via simple regexp. > I checked only java.base module and fixed problems there. Does it > makes sense to create patches to other modules too? > > Index: src/java.base/share/classes/java/lang/module/Resolver.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/lang/module/Resolver.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/lang/module/Resolver.java > (date 1548627900626) > @@ -659,7 +659,7 @@ > * Checks the readability graph to ensure that > *

      > *
    1. A module does not read two or more modules with the same name. > - * This includes the case where a module reads another another with the > + * This includes the case where a module reads another with the > * same name as itself.

    2. > *
    3. Two or more modules in the configuration don't export the same > * package to a module that reads both. This includes the case where a > Index: src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java > (date 1548627900979) > @@ -331,7 +331,7 @@ > } > > /** > - * Load the the KeyStore as described in the specified descriptor. > + * Load the KeyStore as described in the specified descriptor. > */ > private static KeyStore loadKeyStore( > TrustStoreDescriptor descriptor) throws Exception { > Index: src/java.base/share/classes/java/lang/String.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/lang/String.java (revision > 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/lang/String.java (date 1548627901252) > @@ -2698,7 +2698,7 @@ > *

      > * Otherwise, returns a substring of this string beginning with the first > * code point that is not a {@link Character#isWhitespace(int) white space} > - * up to to and including the last code point of this string. > + * up to and including the last code point of this string. > *

      > * This method may be used to trim > * {@link Character#isWhitespace(int) white space} from > Index: src/java.base/share/classes/jdk/internal/platform/Metrics.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/jdk/internal/platform/Metrics.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/jdk/internal/platform/Metrics.java > (date 1548627900501) > @@ -322,7 +322,7 @@ > * Returns the largest amount of physical memory, in bytes, that > * have been allocated in the Isolation Group. > * > - * @return The largest amount of memory in bytes or or 0 if this > + * @return The largest amount of memory in bytes or 0 if this > * metric is not available. > * > */ > @@ -362,7 +362,7 @@ > * Returns the largest amount of kernel physical memory, in bytes, that > * have been allocated in the Isolation Group. > * > - * @return The largest amount of memory in bytes or or 0 if this > + * @return The largest amount of memory in bytes or 0 if this > * metric is not available. > * > */ > @@ -402,7 +402,7 @@ > * Returns the largest amount of networking physical memory, in bytes, > * that have been allocated in the Isolation Group. > * > - * @return The largest amount of memory in bytes or or 0 if this > + * @return The largest amount of memory in bytes or 0 if this > * metric is not available. > * > */ > @@ -442,7 +442,7 @@ > * Returns the largest amount of physical memory and swap space, > * in bytes, that have been allocated in the Isolation Group. > * > - * @return The largest amount of memory in bytes or or 0 if this > + * @return The largest amount of memory in bytes or 0 if this > * metric is not available. > * > */ > Index: src/java.base/share/classes/java/lang/Object.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/lang/Object.java (revision > 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/lang/Object.java (date 1548627901176) > @@ -430,7 +430,7 @@ > * } > * > * @param timeoutMillis the maximum time to wait, in milliseconds > - * @param nanos additional time, in nanoseconds, in the range > range 0-999999 inclusive > + * @param nanos additional time, in nanoseconds, in the range > 0-999999 inclusive > * @throws IllegalArgumentException if {@code timeoutMillis} is negative, > * or if the value of {@code nanos} is out of range > * @throws IllegalMonitorStateException if the current thread is not > Index: src/java.base/share/classes/sun/security/util/ConstraintsParameters.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/util/ConstraintsParameters.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/util/ConstraintsParameters.java > (date 1548627901022) > @@ -37,7 +37,7 @@ > * This class contains parameters for checking against constraints that extend > * past the publicly available parameters in > java.security.AlgorithmConstraints. > > - * This is currently on passed between between PKIX, AlgorithmChecker, > + * This is currently on passed between PKIX, AlgorithmChecker, > * and DisabledAlgorithmConstraints. > */ > public class ConstraintsParameters { > Index: src/java.base/share/classes/java/util/SimpleTimeZone.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/util/SimpleTimeZone.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/util/SimpleTimeZone.java (date > 1548627900673) > @@ -310,7 +310,7 @@ > * See the class description for the > special cases of this parameter. > * @param endDayOfWeek The daylight saving time ending day-of-week. > * See the class description for the > special cases of this parameter. > - * @param endTime The daylight saving ending time in time time mode > + * @param endTime The daylight saving ending time in time mode > * specified by endTimeMode. > * @param endTimeMode The mode of the end time specified by endTime > * @param dstSavings The amount of time in milliseconds saved during > Index: src/java.base/share/classes/sun/security/util/math/SmallValue.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/util/math/SmallValue.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/util/math/SmallValue.java > (date 1548627900541) > @@ -28,7 +28,7 @@ > /** > * A "small" value that can be used with the field arithmetic library. This > * interface enables optimizations based on the fact that certain values are > - * known to be small, where the definition of small is specific to the the > + * known to be small, where the definition of small is specific to the > * arithmetic implementation. > */ > > Index: src/java.base/share/classes/java/lang/invoke/MethodHandle.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/lang/invoke/MethodHandle.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/lang/invoke/MethodHandle.java > (date 1548627901076) > @@ -1083,7 +1083,7 @@ > * else if (makeVarargs) > * return asVarargsCollector(type().lastParameterType()); > * else > - * return return asFixedArity(); > + * return asFixedArity(); > * } > * @param makeVarargs true if the return method handle should > have variable arity behavior > * @return a method handle of the same type, with possibly > adjusted variable arity behavior > Index: src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java > (date 1548627900928) > @@ -145,7 +145,7 @@ > if (!chc.conContext.isNegotiated) { > if (chc.activeCipherSuites.contains( > CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV)) { > - // Using the the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. > + // Using the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. > return null; > } > > Index: src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > (date 1548627901128) > @@ -246,7 +246,7 @@ > try { > baos.writeTo(result.baos); > } catch (IOException ex) { > - throw new RuntimeException("unable to to clone hash state"); > + throw new RuntimeException("unable to clone hash state"); > } > return result; > } > Index: src/java.base/share/classes/sun/security/ssl/SSLTransport.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/sun/security/ssl/SSLTransport.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/sun/security/ssl/SSLTransport.java > (date 1548627900586) > @@ -71,7 +71,7 @@ > * destination application data buffers. > * > * For SSL/TLS connections, if no source data, the network data may be > - * received from the underlying underlying SSL/TLS input stream. > + * received from the underlying SSL/TLS input stream. > * > * @param context the transportation context > * @param srcs an array of {@code ByteBuffers} containing the > Index: src/java.base/share/classes/java/util/stream/WhileOps.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/util/stream/WhileOps.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/util/stream/WhileOps.java > (date 1548627900792) > @@ -658,7 +658,7 @@ > // True if no splitting should be performed, if true then > // this spliterator may be used for an underlying spliterator whose > // covered elements have an encounter order > - // See use in stream take/dropWhile default default methods > + // See use in stream take/dropWhile default methods > final boolean noSplitting; > // True when operations are cancelled for all related spliterators > // For taking, spliterators cannot split or traversed > Index: src/java.base/share/classes/java/lang/invoke/VarHandle.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/lang/invoke/VarHandle.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/java/lang/invoke/VarHandle.java > (date 1548627900836) > @@ -2160,7 +2160,7 @@ > * Construct a {@linkplain VarHandleDesc} given a kind, name, > and declaring > * class. > * > - * @param kind the kind of of the var handle > + * @param kind the kind of the var handle > * @param name the unqualified name of the field, for field > var handles; otherwise ignored > * @param declaringClass a {@link ClassDesc} describing the > declaring class, > * for field var handles > @@ -2217,7 +2217,7 @@ > > /** > * Returns a {@linkplain VarHandleDesc} corresponding to a > {@link VarHandle} > - * for for an array type. > + * for an array type. > * > * @param arrayClass a {@link ClassDesc} describing the type > of the array > * @return the {@linkplain VarHandleDesc} > Index: src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java > (date 1548627900895) > @@ -58,7 +58,7 @@ > public static final int YES_NO_OPTION = 0; > > /** > - * YES/NO/CANCEL confirmation confirmation option. > + * YES/NO/CANCEL confirmation option. > * > *

      An underlying security service specifies this as the > * {@code optionType} to a {@code ConfirmationCallback} > @@ -68,7 +68,7 @@ > public static final int YES_NO_CANCEL_OPTION = 1; > > /** > - * OK/CANCEL confirmation confirmation option. > + * OK/CANCEL confirmation option. > * > *

      An underlying security service specifies this as the > * {@code optionType} to a {@code ConfirmationCallback} > Index: src/java.base/share/classes/jdk/internal/access/SharedSecrets.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/jdk/internal/access/SharedSecrets.java > (revision 2fd909c73e16044cf2b92fa93ab996cd226edd9e) > +++ src/java.base/share/classes/jdk/internal/access/SharedSecrets.java > (date 1548627901204) > @@ -77,7 +77,7 @@ > > public static JavaUtilJarAccess javaUtilJarAccess() { > if (javaUtilJarAccess == null) { > - // Ensure JarFile is initialized; we know that that class > + // Ensure JarFile is initialized; we know that this class > // provides the shared secret > unsafe.ensureClassInitialized(JarFile.class); > } > > > Andrey Turbanov. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andy.herrick at oracle.com Mon Jan 28 17:56:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 28 Jan 2019 12:56:41 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: References: Message-ID: On 1/27/2019 4:55 AM, Alan Bateman wrote: > On 11/01/2019 19:41, Andy Herrick wrote: >> This is the second update to the Request For Review of the >> implementation of the Java Packager Tool (jpackager) as described in >> JEP 343: Packaging Tool >> > I've started to play with the latest EA build, trying to figure it out > in conjunction with the current wording in JEP 343. > > I think the description/definition of "application image" needs to be > beefed up. The current JEP doesn't reference JEP 220 and it's not > immediately obvious how they relate. The HelloWorld example in the JEP > shows the runtime next to an app directory but this doesn't match what > I am seeing when I use `jpackage create-image`. Instead I see the java > runtime is generated into PlugIns/Java.runtime. It's not clear why > there is a "PlugIns" directory. I filed JDK-8217902 to investigate if we can make the layout the same on Mac as it is on Linux and Windows. (otherwise we need to update the JEP) > > Can we do anything about simple cases where the application is a > single executable JAR? When I use `jpackage create-image` for such > cases then I'm forced to provide a directory to --input and? the main > class to --class, neither of these options should be needed for simple > cases like this, esp. when the tool also has --main-jar (which might > need to be renamed to be consistent with other tools). you should not need to specify --class, if the main-jar has a Main-Class manifest entry this is a bug filed as:JDK-8217791 > > When I use `jpackage create-image` then it creates an embedded > run-time image that is missing a lot of modules. For example, if my > applications is indirectly using sun.misc.Unsafe, as some libraries > do, then it will fail at run-time because the jdk.unsupported module > is not included. The examples I tried were also missing java.sql, > java.net.http and several more. Is this a bug or a relic from the old > javapackager tool? still need to investigate this. > > The JEP suggests that the tool can create a native launcher but it's > not immediately obvious how to do that. An example in the JEP would be > useful to have. I did get it working with `--secondary-launcher` but > that is a really strange option. I wonder if this could be renamed to > `--launcher` and also its input changed to be closer to the equivalent > in jlink. I also wonder if it would be saner to have the properties > specified directly to the option rather than in another properties file. > > I also tried `jpackage create-installer`. When I specify `--app-image` > I assumed I could specify an application image that I created > previously `jpackage create-image` but it doesn't like that. The error > for this usage is: > Error: App image directory "myimage" is invalid and does not contain > "app" and/or "runtime" sub-directories this is also a bug (related to JDK-8217902 ) I will add that to the description. > > Are you planning to keep `jpackage create-jre-installer`? I can't tell > if this is intended to be renamed or not but I think it would be > confusing to have "JRE" in the name of CLI options. Also it's not > clear what "jre-name" means. I think it would be saner to simplify > this to allow an installer be created for a given run-time image, > never the runtime that the jpackage tool is running on. looking into this as part of: JDK-8217894 /Andy > > That's all I have for now. I see there is a lot of feedback and issues > being tracked so I'll try it again once the implementation is a bit > further along. > > -Alan > > > > > > From Alan.Bateman at oracle.com Mon Jan 28 18:34:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Jan 2019 18:34:33 +0000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> Message-ID: <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> On 28/01/2019 17:04, Lance Andersen wrote: > The updates look fine >> - * This includes the case where a module reads another another with the >> + * This includes the case where a module reads another with the >> This one is typo, it should say "another module". -Alan From sandhya.viswanathan at intel.com Mon Jan 28 18:39:47 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 28 Jan 2019 18:39:47 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A5489E@FMSMSX126.amr.corp.intel.com> Hi Alan, Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful. ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to move up to the latest JDK. Best Regards, Sandhya -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Friday, January 18, 2019 5:33 AM To: Andrew Dinn ; Brian Goetz Cc: core-libs-dev at openjdk.java.net; hotspot compiler ; Jonathan Halliday ; Viswanathan, Sandhya Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory On 17/01/2019 14:27, Andrew Dinn wrote: > : >> Vladimir and I have reviewed the JEP, it will need an area lead to >> endorse, I think it can be Brian or Mikael in this case. > Ok, thanks for the above answers. Looking forward to hearing further > from Brian and/or Mikael (Vidstedt, I assume? :-). I had a brief discussion with Brian about this yesterday. He brought up the same concern about using MBB as it's not the right API for this in the longer term.? So this JEP is very much about a short term/tactical solution as we've already concluded here. This leads to the question as to whether this JEP needs to evolve the standard/Java SE API or not. It's convenient for the implementation of course but we should at least explore doing this as a JDK-specific feature. To that end, one approach to explore is allowing the FC.map method accept map modes beyond those defined by MapMode. There is precedence for extensibility in this area already, e.g. FC.open allows you to specify options beyond the standard options specified by the method. It would require MapMode to define a protected constructor and would require a bit of plumbing to support MapMode defined in a JDK-specific module but there are examples to point to. Another approach is aanother class in a JDK-specific module to define the map method. It would require the same plumbing under the covers but would avoid touch the FC spec. -Alan From Alan.Bateman at oracle.com Mon Jan 28 19:45:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Jan 2019 19:45:26 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A5489E@FMSMSX126.amr.corp.intel.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A5489E@FMSMSX126.amr.corp.intel.com> Message-ID: <2bfc26aa-ec5e-e36c-5de9-c44853038d99@oracle.com> On 28/01/2019 18:39, Viswanathan, Sandhya wrote: > Hi Alan, > > Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful. > ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to move up to the latest JDK. > In the API docs, you'll see a number of JDK-specific modules with names that start with "jdk." instead of "java.". Many of these modules export JDK-specific APIs. The jdk.attach module exports the JDK-specific com.sun.tools.attach API. The jdk.management module exports the com.sun.management API which has defined JDK-specific extensions to the management API since JDK 5. Closer to the feature under discussion are APIs that are extensible to allow for support beyond what the Java SE API specifies. The Direct I/O feature in JDK 10 defined a JDK-specific OpenOption that you can specify to FileChannel.open, e.g.: ? var channel = FileChannel.open(file, StandardOpenOption.WRITE, ExtendedOpenOption.DIRECT); Another example is socket options. Java SE defines? "standard" socket options in java.net.StandardSocketOptions but an implementation can support many others. The JDK has the jdk.net.ExtendedSocketOption to define additional socket options so you can do things like this: ?? Socket s = ... ?? s.setOption(ExtendedSocketOption.TCP_KEEPIDLE, 5); The suggestion on the table is to see if we can do the same for file mapping modes so that the platform specific MAP_SYNC mode can be used with the existing API. This would allow for code like this: ?? MappedByteBuffer mbb = fc.map(ExtendedMapMode.READ_WRITE_SYNC, position, size); There's plumbing needed to make this work as the underlying implementation would be in java.base but the platform specific map mode defined in a JDK-specific module. There are several advantages to the approach, the main one is that it doesn't commit Java SE to supporting this mode. I'm hoping to meet up with Andrew Dinn at FOSDEM to discuss this approach in a bit more detail. You asked about deprecating ByteBuffer but I don't think there is any suggestion to do that here. Once Panama is further along, specifically the memory region or scope/pointer API, then interop with ByteBuffer will need to be worked out. -Alan From sandhya.viswanathan at intel.com Mon Jan 28 19:54:20 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 28 Jan 2019 19:54:20 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <2bfc26aa-ec5e-e36c-5de9-c44853038d99@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2664e7c98ef@redhat.com> <34cfc530-8517-ac1a-0c04-446dc3dc2436@oracle.com> <21ef0e11-3f3d-e9a4-5dc6-898d4ac18efa@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A5489E@FMSMSX126.amr.corp.intel.com> <2bfc26aa-ec5e-e36c-5de9-c44853038d99@oracle.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A5494F@FMSMSX126.amr.corp.intel.com> Thanks a lot Alan! This is very helpful. Best Regards, Sandhya -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, January 28, 2019 11:45 AM To: Viswanathan, Sandhya ; Andrew Dinn ; Brian Goetz Cc: core-libs-dev at openjdk.java.net; hotspot compiler ; Jonathan Halliday Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory On 28/01/2019 18:39, Viswanathan, Sandhya wrote: > Hi Alan, > > Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful. > ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to move up to the latest JDK. > In the API docs, you'll see a number of JDK-specific modules with names that start with "jdk." instead of "java.". Many of these modules export JDK-specific APIs. The jdk.attach module exports the JDK-specific com.sun.tools.attach API. The jdk.management module exports the com.sun.management API which has defined JDK-specific extensions to the management API since JDK 5. Closer to the feature under discussion are APIs that are extensible to allow for support beyond what the Java SE API specifies. The Direct I/O feature in JDK 10 defined a JDK-specific OpenOption that you can specify to FileChannel.open, e.g.: ? var channel = FileChannel.open(file, StandardOpenOption.WRITE, ExtendedOpenOption.DIRECT); Another example is socket options. Java SE defines? "standard" socket options in java.net.StandardSocketOptions but an implementation can support many others. The JDK has the jdk.net.ExtendedSocketOption to define additional socket options so you can do things like this: ?? Socket s = ... ?? s.setOption(ExtendedSocketOption.TCP_KEEPIDLE, 5); The suggestion on the table is to see if we can do the same for file mapping modes so that the platform specific MAP_SYNC mode can be used with the existing API. This would allow for code like this: ?? MappedByteBuffer mbb = fc.map(ExtendedMapMode.READ_WRITE_SYNC, position, size); There's plumbing needed to make this work as the underlying implementation would be in java.base but the platform specific map mode defined in a JDK-specific module. There are several advantages to the approach, the main one is that it doesn't commit Java SE to supporting this mode. I'm hoping to meet up with Andrew Dinn at FOSDEM to discuss this approach in a bit more detail. You asked about deprecating ByteBuffer but I don't think there is any suggestion to do that here. Once Panama is further along, specifically the memory region or scope/pointer API, then interop with ByteBuffer will need to be worked out. -Alan From kevin.rushforth at oracle.com Mon Jan 28 21:54:56 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 28 Jan 2019 13:54:56 -0800 Subject: RFR: JDK-8217331: Problems when space in application name In-Reply-To: <47130cf3-7b45-1a70-ab55-7118d0ef648d@oracle.com> References: <47130cf3-7b45-1a70-ab55-7118d0ef648d@oracle.com> Message-ID: <9dc4602b-f076-a50f-15c6-3a52b52660da@oracle.com> This looks fine to me. I note that it still allows characters that will cause problems (e.g., ":" on Linux or ";" on Windows), but that could be done as a follow-on bug. -- Kevin On 1/27/2019 4:56 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The webrev includes removal of the APP_FS_NAME DeployParam, and > enhanced? checking of the given application name so APP_NAME parameter > can be safely used in all cases. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217331 > > [2] http://cr.openjdk.java.net/~herrick/8217331/ > > /Andy > From stuart.marks at oracle.com Mon Jan 28 22:10:07 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 28 Jan 2019 14:10:07 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> Message-ID: <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> On 1/26/19 3:19 PM, David Holmes wrote: > On 27/01/2019 3:08 am, Martin Buchholz wrote: >> It's a pet peeve that the name GetStringUTFChars is deeply misleading - >> there are many "UTF"s, and this encoding is meant for use with the JVM >> only.? The documentation should make it clearer that this is NOT the UTF-8 >> you might expect. > > It does! > > GetStringUTFChars > > const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy); > > Returns a pointer to an array of bytes representing the string in modified UTF-8 > encoding. This is pretty easy to miss, especially if you're not aware that the JVM and the JDK have this special concept of "modified UTF-8". Perhaps emphasis should be added. Or maybe occurrences of "modified UTF-8" should be changed to be links to the section in chapter 3 of the JNI spec where "modified UTF-8" is defined. (Making the occurrences be links might be emphasis enough.) I think it would be far too troublesome to try to migrate the JNI methods to process real UTF-8 instead of modified UTF-8. That raises the question, though: is there a use case for processing real UTF-8 within JNI? For example, for interoperating with external components that expect real UTF-8. If so, perhaps some conversion methods could be added. (From Java code, the Charset encoders/decoders handle real UTF-8, which seems to cover most cases. Modified UTF-8 occurs only within serialization and Data{Input,Output}Stream.) Alan Snyder wrote: > -16 -97 -115 -69 I'll drink to that! s'marks From javalists at cbfiddle.com Mon Jan 28 22:15:51 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 28 Jan 2019 14:15:51 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> Message-ID: In case you missed my previous message, there is a use case for file paths using macOS APIs. Alan > On Jan 28, 2019, at 2:10 PM, Stuart Marks wrote: > > I think it would be far too troublesome to try to migrate the JNI methods to process real UTF-8 instead of modified UTF-8. That raises the question, though: is there a use case for processing real UTF-8 within JNI? For example, for interoperating with external components that expect real UTF-8. If so, perhaps some conversion methods could be added. From turbanoff at gmail.com Mon Jan 28 22:23:38 2019 From: turbanoff at gmail.com (Andrey Turbanov) Date: Tue, 29 Jan 2019 01:23:38 +0300 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> Message-ID: > On 28/01/2019 17:04, Lance Andersen wrote: > > The updates look fine > >> - * This includes the case where a module reads another another with the > >> + * This includes the case where a module reads another with the > >> > This one is typo, it should say "another module". > > -Alan Thanks to review. Patch updated. I'm not really sure what to do next. I should find someone who can create issue and commit my patch to repository, right? diff -r fcfeed9fef45 src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/lang/Object.java Tue Jan 29 01:21:13 2019 +0300 @@ -430,7 +430,7 @@ * } * * @param timeoutMillis the maximum time to wait, in milliseconds - * @param nanos additional time, in nanoseconds, in the range range 0-999999 inclusive + * @param nanos additional time, in nanoseconds, in the range 0-999999 inclusive * @throws IllegalArgumentException if {@code timeoutMillis} is negative, * or if the value of {@code nanos} is out of range * @throws IllegalMonitorStateException if the current thread is not diff -r fcfeed9fef45 src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/lang/String.java Tue Jan 29 01:21:13 2019 +0300 @@ -2698,7 +2698,7 @@ *

      * Otherwise, returns a substring of this string beginning with the first * code point that is not a {@link Character#isWhitespace(int) white space} - * up to to and including the last code point of this string. + * up to and including the last code point of this string. *

      * This method may be used to trim * {@link Character#isWhitespace(int) white space} from diff -r fcfeed9fef45 src/java.base/share/classes/java/lang/invoke/MethodHandle.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Tue Jan 29 01:21:13 2019 +0300 @@ -1083,7 +1083,7 @@ * else if (makeVarargs) * return asVarargsCollector(type().lastParameterType()); * else - * return return asFixedArity(); + * return asFixedArity(); * } * @param makeVarargs true if the return method handle should have variable arity behavior * @return a method handle of the same type, with possibly adjusted variable arity behavior diff -r fcfeed9fef45 src/java.base/share/classes/java/lang/invoke/VarHandle.java --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java Tue Jan 29 01:21:13 2019 +0300 @@ -2160,7 +2160,7 @@ * Construct a {@linkplain VarHandleDesc} given a kind, name, and declaring * class. * - * @param kind the kind of of the var handle + * @param kind the kind of the var handle * @param name the unqualified name of the field, for field var handles; otherwise ignored * @param declaringClass a {@link ClassDesc} describing the declaring class, * for field var handles @@ -2217,7 +2217,7 @@ /** * Returns a {@linkplain VarHandleDesc} corresponding to a {@link VarHandle} - * for for an array type. + * for an array type. * * @param arrayClass a {@link ClassDesc} describing the type of the array * @return the {@linkplain VarHandleDesc} diff -r fcfeed9fef45 src/java.base/share/classes/java/lang/module/Resolver.java --- a/src/java.base/share/classes/java/lang/module/Resolver.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/lang/module/Resolver.java Tue Jan 29 01:21:13 2019 +0300 @@ -659,7 +659,7 @@ * Checks the readability graph to ensure that *

        *
      1. A module does not read two or more modules with the same name. - * This includes the case where a module reads another another with the + * This includes the case where a module reads another module with the * same name as itself.

      2. *
      3. Two or more modules in the configuration don't export the same * package to a module that reads both. This includes the case where a diff -r fcfeed9fef45 src/java.base/share/classes/java/util/SimpleTimeZone.java --- a/src/java.base/share/classes/java/util/SimpleTimeZone.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/util/SimpleTimeZone.java Tue Jan 29 01:21:13 2019 +0300 @@ -310,7 +310,7 @@ * See the class description for the special cases of this parameter. * @param endDayOfWeek The daylight saving time ending day-of-week. * See the class description for the special cases of this parameter. - * @param endTime The daylight saving ending time in time time mode + * @param endTime The daylight saving ending time in time mode * specified by endTimeMode. * @param endTimeMode The mode of the end time specified by endTime * @param dstSavings The amount of time in milliseconds saved during diff -r fcfeed9fef45 src/java.base/share/classes/java/util/stream/WhileOps.java --- a/src/java.base/share/classes/java/util/stream/WhileOps.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/java/util/stream/WhileOps.java Tue Jan 29 01:21:13 2019 +0300 @@ -658,7 +658,7 @@ // True if no splitting should be performed, if true then // this spliterator may be used for an underlying spliterator whose // covered elements have an encounter order - // See use in stream take/dropWhile default default methods + // See use in stream take/dropWhile default methods final boolean noSplitting; // True when operations are cancelled for all related spliterators // For taking, spliterators cannot split or traversed diff -r fcfeed9fef45 src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java --- a/src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java Tue Jan 29 01:21:13 2019 +0300 @@ -58,7 +58,7 @@ public static final int YES_NO_OPTION = 0; /** - * YES/NO/CANCEL confirmation confirmation option. + * YES/NO/CANCEL confirmation option. * *

        An underlying security service specifies this as the * {@code optionType} to a {@code ConfirmationCallback} @@ -68,7 +68,7 @@ public static final int YES_NO_CANCEL_OPTION = 1; /** - * OK/CANCEL confirmation confirmation option. + * OK/CANCEL confirmation option. * *

        An underlying security service specifies this as the * {@code optionType} to a {@code ConfirmationCallback} diff -r fcfeed9fef45 src/java.base/share/classes/jdk/internal/access/SharedSecrets.java --- a/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java Tue Jan 29 01:21:13 2019 +0300 @@ -77,7 +77,7 @@ public static JavaUtilJarAccess javaUtilJarAccess() { if (javaUtilJarAccess == null) { - // Ensure JarFile is initialized; we know that that class + // Ensure JarFile is initialized; we know that this class // provides the shared secret unsafe.ensureClassInitialized(JarFile.class); } diff -r fcfeed9fef45 src/java.base/share/classes/jdk/internal/platform/Metrics.java --- a/src/java.base/share/classes/jdk/internal/platform/Metrics.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/jdk/internal/platform/Metrics.java Tue Jan 29 01:21:13 2019 +0300 @@ -322,7 +322,7 @@ * Returns the largest amount of physical memory, in bytes, that * have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -362,7 +362,7 @@ * Returns the largest amount of kernel physical memory, in bytes, that * have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -402,7 +402,7 @@ * Returns the largest amount of networking physical memory, in bytes, * that have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ @@ -442,7 +442,7 @@ * Returns the largest amount of physical memory and swap space, * in bytes, that have been allocated in the Isolation Group. * - * @return The largest amount of memory in bytes or or 0 if this + * @return The largest amount of memory in bytes or 0 if this * metric is not available. * */ diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/ssl/HandshakeHash.java --- a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java Tue Jan 29 01:21:13 2019 +0300 @@ -246,7 +246,7 @@ try { baos.writeTo(result.baos); } catch (IOException ex) { - throw new RuntimeException("unable to to clone hash state"); + throw new RuntimeException("unable to clone hash state"); } return result; } diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java --- a/src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java Tue Jan 29 01:21:13 2019 +0300 @@ -145,7 +145,7 @@ if (!chc.conContext.isNegotiated) { if (chc.activeCipherSuites.contains( CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV)) { - // Using the the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. + // Using the TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead. return null; } diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/ssl/SSLTransport.java --- a/src/java.base/share/classes/sun/security/ssl/SSLTransport.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/ssl/SSLTransport.java Tue Jan 29 01:21:13 2019 +0300 @@ -71,7 +71,7 @@ * destination application data buffers. * * For SSL/TLS connections, if no source data, the network data may be - * received from the underlying underlying SSL/TLS input stream. + * received from the underlying SSL/TLS input stream. * * @param context the transportation context * @param srcs an array of {@code ByteBuffers} containing the diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java --- a/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java Tue Jan 29 01:21:13 2019 +0300 @@ -331,7 +331,7 @@ } /** - * Load the the KeyStore as described in the specified descriptor. + * Load the KeyStore as described in the specified descriptor. */ private static KeyStore loadKeyStore( TrustStoreDescriptor descriptor) throws Exception { diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/util/ConstraintsParameters.java --- a/src/java.base/share/classes/sun/security/util/ConstraintsParameters.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/util/ConstraintsParameters.java Tue Jan 29 01:21:13 2019 +0300 @@ -37,7 +37,7 @@ * This class contains parameters for checking against constraints that extend * past the publicly available parameters in java.security.AlgorithmConstraints. - * This is currently on passed between between PKIX, AlgorithmChecker, + * This is currently on passed between PKIX, AlgorithmChecker, * and DisabledAlgorithmConstraints. */ public class ConstraintsParameters { diff -r fcfeed9fef45 src/java.base/share/classes/sun/security/util/math/SmallValue.java --- a/src/java.base/share/classes/sun/security/util/math/SmallValue.java Mon Jan 28 21:44:57 2019 +0100 +++ b/src/java.base/share/classes/sun/security/util/math/SmallValue.java Tue Jan 29 01:21:13 2019 +0300 @@ -28,7 +28,7 @@ /** * A "small" value that can be used with the field arithmetic library. This * interface enables optimizations based on the fact that certain values are - * known to be small, where the definition of small is specific to the the + * known to be small, where the definition of small is specific to the * arithmetic implementation. */ From javalists at cbfiddle.com Mon Jan 28 22:24:00 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 28 Jan 2019 14:24:00 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> Message-ID: <44D0FDF6-73BB-42C7-ACCE-BF64F6CE600C@cbfiddle.com> If you search the JDK repo for GetStringUTFChars, you will find several uses that do not appear to involve serialization or data input/output. It is not obvious whether these uses are correct or not. Consider test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c where GetStringUTFChars is used to convert a file path to pass to open(). At the very least, anyone using GetStringUTFChars as a short cut for true UTF-8 conversion should document why this short cut is correct, as is done in awt_InputMethod, for example. Alan > On Jan 28, 2019, at 2:10 PM, Stuart Marks wrote: > > (From Java code, the Charset encoders/decoders handle real UTF-8, which seems to cover most cases. Modified UTF-8 occurs only within serialization and Data{Input,Output}Stream.) From christoph.langer at sap.com Mon Jan 28 22:28:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Jan 2019 22:28:10 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: References: <6ab11b43b93647da910b410d3544957a@sap.com> Message-ID: <15c94170d5a94901bddeaab79bd4d1b5@sap.com> Hi Goetz, > Patching the file myself really helped to see there are no real changes. > > For the missing patch of the constructor I understand it was only an arbitrary > reordering of arguments you omitted. Thus the whole chunk disappeared. > This makes sense, and in case someone downports the other change he > should be able to cope with that. Well, there were actually 3 failing hunks: --- ZipFileSystem.java +++ ZipFileSystem.java @@ -316,8 +326,8 @@ IndexNode inode = getInode(path); if (inode == null) return null; - e = new Entry(inode.name, inode.isdir); // pseudo directory - e.method = METHOD_STORED; // STORED for dir + // pseudo directory, uses METHOD_STORED + e = new Entry(inode.name, inode.isdir, METHOD_STORED); e.mtime = e.atime = e.ctime = zfsDefaultTimeStamp; } } finally { This one just had to find its place -> it is included in my change (line 329 of new file). @@ -1087,8 +1061,9 @@ if (pos + CENHDR + nlen > limit) { zerror("invalid CEN header (bad header size)"); } - IndexNode inode = new IndexNode(cen, nlen, pos); + IndexNode inode = new IndexNode(cen, pos, nlen); inodes.put(inode, inode); + // skip ext and comment pos += (CENHDR + nlen + elen + clen); } This one was the reordering of arguments when calling the "IndexNode" constructor itself. @@ -1806,7 +1777,7 @@ } // constructor for cenInit() (1) remove tailing '/' (2) pad leading '/' - IndexNode(byte[] cen, int nlen, int pos) { + IndexNode(byte[] cen, int pos, int nlen) { int noff = pos + CENHDR; if (cen[noff + nlen - 1] == '/') { isdir = true; This one was the reordering of arguments of the "IndexNode" constructor itself. I think it's better to also take over the reordering of arguments of the constructor. Here's an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8034802.11u.1/ The updates are in line 1054 and 1770 of the new ZipFileSystem.java. Best regards Christoh From alexander.matveev at oracle.com Mon Jan 28 22:41:57 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 28 Jan 2019 14:41:57 -0800 Subject: RFR: JDK-8217331: Problems when space in application name In-Reply-To: <47130cf3-7b45-1a70-ab55-7118d0ef648d@oracle.com> References: <47130cf3-7b45-1a70-ab55-7118d0ef648d@oracle.com> Message-ID: <2142f9a2-cc67-5d82-d59d-ca34d8fcc43f@oracle.com> Hi Andy, Looks fine. Thanks, Alexander On 1/27/2019 4:56 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The webrev includes removal of the APP_FS_NAME DeployParam, and > enhanced? checking of the given application name so APP_NAME parameter > can be safely used in all cases. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217331 > > [2] http://cr.openjdk.java.net/~herrick/8217331/ > > /Andy > From takiguc at linux.vnet.ibm.com Tue Jan 29 01:21:12 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 10:21:12 +0900 Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> Message-ID: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Hello. Sorry about build issue for JDK-8214533. EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ Could you review the fix ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > Hello Goetz. > > Thank you for your suggestion. > I just open JDK-8217880 [1]. > > I just restart clean build. > > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > > Thanks, > Ichiroh Takiguchi > > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> Hi Ichiroh, >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> it. >> I assume the fix is quite trivial so we can review it quick. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: ppc-aix-port-dev On >>> Behalf Of Ichiroh Takiguchi >>> Sent: Montag, 28. Januar 2019 14:13 >>> To: Baesken, Matthias >>> Cc: build-dev ; ppc-aix-port-dev >>> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >>> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >>> charset >>> >>> Hello. >>> >>> I'm very sorry. It's my fault. >>> EUC_JP class was moved to java.base module. >>> (sun.nio.cs.EUC_JP). >>> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >>> EUC_JP_Open. >>> >>> Could you suggest me how I should provide new webrev files ? >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >>> > we see build errors on AIX , are they related to this change ? >>> > >>> > >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Decoder extends EUC_JP.Decoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Encoder extends EUC_JP.Encoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Decoder extends EUC_JP.Decoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Encoder extends EUC_JP.Encoder { >>> > >>> > Best regards, Matthias >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: ppc-aix-port-dev On >>> >> Behalf Of Ichiroh Takiguchi >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >>> >> To: Alan Bateman >>> >> Cc: build-dev ; ppc-aix-port-dev >> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >>> >> Subject: 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, Ltd. >>> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >>> >> > Hello Alan. >>> >> > >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >>> >> > I cannot wait until JDK-8215333 is closed. >>> >> > Is it possible to put IBM-29626C charset with standard way ? >>> >> > >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >>> >> > >>> >> > Thanks, >>> >> > Ichiroh Takiguchi >>> >> > >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >>> >> >> Hello Roger, Magnus and Alan. >>> >> >> I may need to put alias information into charsets file. >>> >> >> stdcs-xxx cannot handle this information... >>> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >>> >> >> >>> >> >> I appreciate if you give me further suggestions. >>> >> >> >>> >> >> Thanks, >>> >> >> Ichiroh Takiguchi >>> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>> >> >>>>> Hi, >>> >> >>>>> >>> >> >>>>> It is a nice feature that charsets are selected at build time using >>> >> >>>>> the stdcs-xxx files. >>> >> >>>>> This change breaks that pattern and embeds os specific information >>> >> >>>>> in more than one place. >>> >> >>>>> That does not seem like an improvement.? Is there any alternative? >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>> >> >>> My reading of the patch is that the "os" key is to avoid generating >>> >> >>> it >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>> >> >>> non-AIX platforms. The general direction is welcome but I think >>> >> >>> further work and discussion will be needed to get the right set of >>> >> >>> changes to support filtering in the build. It can probably be >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >>> >> >>> >>> >> >>> -Alan From fujie at loongson.cn Tue Jan 29 01:46:16 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 29 Jan 2019 09:46:16 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> Message-ID: <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> Hi, I agree that the simplest way to fix the issue is just adding the reachabilityFence. But this patch might also fail since the VM doesn't guarantee that a GC would be performed. I didn't make such patch since I've learned from Sergey and Alan that calling "System.gc()" several times is unreliable to trigger a gc[1]. So I still prefer the original one[2]. Thanks a lot. Best regards, Jie [1] https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html On 2019/1/28 ??11:39, Roger Riggs wrote: > Hi, > > The simplest fix for this failing test is to add a call to > reachabilityFence to prevent > the loader and loaderRef from going out of scope early.? It maintains > getting debug > output on a failure. > > Offlist, Jie and I explored some alternate ways to write the test and > settled on this one. > > Please review: > > diff --git > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > --- > a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > +++ > b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea > ???????????? Reference dequeued = refQueue.remove(TIMEOUT); > ???????????? if (dequeued == null) { > ???????????????? System.err.println( > -??????????????????? "TEST FAILED: loader not deteced weakly reachable"); > +??????????????????? "TEST FAILED: loader not detected weakly reachable"); > ???????????????? dumpThreads(); > ???????????????? throw new RuntimeException( > ???????????????????? "TEST FAILED: loader not detected weakly reachable"); > ???????????? } > +??????????? Reference.reachabilityFence(loader); > +??????????? Reference.reachabilityFence(loaderRef); > > ???????????? System.err.println( > ???????????????? "TEST PASSED: loader detected weakly reachable"); > > Thanks, Roger > > > > On 01/11/2019 07:25 PM, Jie Fu wrote: >> Thanks David and Roger. >> >> >> On 2019?01?12? 06:52, David Holmes wrote: >>> Hi Roger, >>> >>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>> Hi, >>>> >>>> The proposed patch changes the test in a way that is unintended. >>>> >>>> Adding the infinite loop of gc() and sleep, will change the timeout >>>> behavior >>>> from the existing timeout of TIMEOUT to the jtreg default timeout >>>> of the whole test. >>> >>> Partially true. If the new loop gets stuck then yes the jtreg >>> default timeout will apply - I don't see that is necessarily a bad >>> thing. The existing timeout only applies to the refQueue.remove >>> operation itself, you don't know how much time was spent before you >>> got there, nor how much will be spent after in the dumpThreads() >>> calls - so the jtreg timeout can still come into affect. >>> >>>> Further, it renders the check at lines 114-120 irrelevant since >>>> loaderRef.get() >>>> will have returned null and the ref will have been enqueued by then. >>> >>> I wouldn't say irrelevant as it double-checks the interaction >>> between the ref.get() and the queue.remove() - the result of one >>> should imply the result of the other, but if enqueuing had a bug .... >>> >>>> While it is true that calling gc() only once is unreliable, a >>>> better fix is to >>>> put the code from 108-120 in a loop with a fixed number of durations >>> >>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>> >>>> and add Reachability.reachabilityFence(loaderRef) to ensure the ref >>>> is not ignored. >>> >>> Adding ReachabilityFence, alone, may solve the observed problem >>> given one gc() seems to be working in practice (and because we don't >>> actually have the leaked loaders anymore because those threads >>> (sun.misc.GC threads) don't exist anymore). >>> >>> Cheers, >>> David >>> >>>> Regards, Roger >> >> > From pavel.rappo at oracle.com Tue Jan 29 01:54:13 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 29 Jan 2019 01:54:13 +0000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> Message-ID: <019AC4DB-ECCB-457F-B782-B65A823A4812@oracle.com> > On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: > > Thanks to review. Patch updated. I'm not really sure what to do next. > I should find someone who can create issue and commit my patch to > repository, right? Have you signed the OCA [1]? The full process is described here [2]. If you have signed the OCA, I can sponsor that change for you. P.S. While we are here. I had a script once that was looking for the same pattern of typos, namely repeated words. Usually it happens just after the line break. As if people loose a visual context after hitting the Enter key. Would you mind accepting additional typos into your patch? -------------------------------------------------------------------------------- [1] https://www.oracle.com/technetwork/oca-405177.pdf [2] https://openjdk.java.net/contribute/ From goetz.lindenmaier at sap.com Tue Jan 29 07:58:58 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 07:58:58 +0000 Subject: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system In-Reply-To: <15c94170d5a94901bddeaab79bd4d1b5@sap.com> References: <6ab11b43b93647da910b410d3544957a@sap.com> <15c94170d5a94901bddeaab79bd4d1b5@sap.com> Message-ID: <79edb254d81049cc8dc32c9c94256a6c@sap.com> Hi Chris, this is fine, too. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 28. Januar 2019 23:28 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net > Subject: RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE > when the zip file is located in a custom file system > > Hi Goetz, > > > Patching the file myself really helped to see there are no real changes. > > > > For the missing patch of the constructor I understand it was only an arbitrary > > reordering of arguments you omitted. Thus the whole chunk disappeared. > > This makes sense, and in case someone downports the other change he > > should be able to cope with that. > > Well, there were actually 3 failing hunks: > > --- ZipFileSystem.java > +++ ZipFileSystem.java > @@ -316,8 +326,8 @@ > IndexNode inode = getInode(path); > if (inode == null) > return null; > - e = new Entry(inode.name, inode.isdir); // pseudo directory > - e.method = METHOD_STORED; // STORED for dir > + // pseudo directory, uses METHOD_STORED > + e = new Entry(inode.name, inode.isdir, METHOD_STORED); > e.mtime = e.atime = e.ctime = zfsDefaultTimeStamp; > } > } finally { > > This one just had to find its place -> it is included in my change (line 329 of new > file). > > @@ -1087,8 +1061,9 @@ > if (pos + CENHDR + nlen > limit) { > zerror("invalid CEN header (bad header size)"); > } > - IndexNode inode = new IndexNode(cen, nlen, pos); > + IndexNode inode = new IndexNode(cen, pos, nlen); > inodes.put(inode, inode); > + > // skip ext and comment > pos += (CENHDR + nlen + elen + clen); > } > > This one was the reordering of arguments when calling the "IndexNode" > constructor itself. > > @@ -1806,7 +1777,7 @@ > } > > // constructor for cenInit() (1) remove tailing '/' (2) pad leading '/' > - IndexNode(byte[] cen, int nlen, int pos) { > + IndexNode(byte[] cen, int pos, int nlen) { > int noff = pos + CENHDR; > if (cen[noff + nlen - 1] == '/') { > isdir = true; > > This one was the reordering of arguments of the "IndexNode" constructor > itself. > > I think it's better to also take over the reordering of arguments of the > constructor. Here's an updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8034802.11u.1/ > > The updates are in line 1054 and 1770 of the new ZipFileSystem.java. > > Best regards > Christoh From david.holmes at oracle.com Tue Jan 29 08:50:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jan 2019 18:50:36 +1000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <019AC4DB-ECCB-457F-B782-B65A823A4812@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <019AC4DB-ECCB-457F-B782-B65A823A4812@oracle.com> Message-ID: Hi Pavel, On 29/01/2019 11:54 am, Pavel Rappo wrote: >> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: >> >> Thanks to review. Patch updated. I'm not really sure what to do next. >> I should find someone who can create issue and commit my patch to >> repository, right? > > Have you signed the OCA [1]? The full process is described here [2]. > If you have signed the OCA, I can sponsor that change for you. I don't think this kind of trivial change needs the OCA to be signed. "A Participant may post messages to a list, submit simple patches, and make other kinds of small contributions." [1] Cheers, David ----- [1] http://openjdk.java.net/bylaws#participant > P.S. While we are here. I had a script once that was looking for the same > pattern of typos, namely repeated words. Usually it happens just after the line > break. As if people loose a visual context after hitting the Enter key. Would > you mind accepting additional typos into your patch? > > -------------------------------------------------------------------------------- > [1] https://www.oracle.com/technetwork/oca-405177.pdf > [2] https://openjdk.java.net/contribute/ > From christoph.langer at sap.com Tue Jan 29 08:58:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 29 Jan 2019 08:58:34 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <66488fb2-b612-3091-f73f-34d200506919@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> <66488fb2-b612-3091-f73f-34d200506919@oracle.com> Message-ID: <1e62e919d0424829b86018ad21b2722f@sap.com> Hi Matthias, > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > This is the one. Looks good ( and clean ). I agree, this version would be ok for me to be pushed. It would be good ,though, if there was a test for this (long paths on Windows). I also like Alan's suggestion to open a follow up bug to explore using CreateFile on Windows right away rather than trying open. Looking at libjava/libnet/libnio, it's all CreateFileW on Windows... Best regards Christoph From christoph.langer at sap.com Tue Jan 29 09:14:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 29 Jan 2019 09:14:46 +0000 Subject: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail In-Reply-To: References: <8f556f8a-c5f5-8b64-5f5a-e7046810f4cf@oracle.com> <0c2caac0-1137-7772-5dfd-f9865d8967b6@oracle.com> Message-ID: <01363c00e11d4abba391ad25b0f7a7cc@sap.com> Done: http://hg.openjdk.java.net/jdk/jdk/rev/4cfa5f51eafa From: Steve Groeger Sent: Montag, 28. Januar 2019 17:25 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; Roger Riggs Subject: RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail Hi Christoph, Additional changes look OK to me. Happy for for you to push. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" > To: Steve Groeger >, Roger Riggs > Cc: "core-libs-dev at openjdk.java.net" > Date: 28/01/2019 15:49 Subject: RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail ________________________________ Hi Steve, Roger, I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) This is what ran through our test system without issues: http://cr.openjdk.java.net/~clanger/webrevs/8217777.0/ In case there was an error in the output, it would read like this: ----------System.out:(39/1030)---------- Preferences::exportSubtree did not yield the expected result. Actual: Expected: d Are you all ok with that? Then I'd push it... Thanks Christoph > -----Original Message----- > From: core-libs-dev > On Behalf > Of Roger Riggs > Sent: Freitag, 25. Januar 2019 17:52 > To: Steve Groeger > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java > passes even when test should fail > > +1, > > Thanks, Roger > > > On 01/25/2019 11:21 AM, Steve Groeger wrote: > > Hi Roger, > > > > Thanks. Have included the bug number to the @bug line and have > > included the expected and actual output when there is an error. > > > > Have generated a new webrev here: > > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.01/ > > > > > > Hope this is now OK. > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > From: Roger Riggs > > > To: core-libs-dev at openjdk.java.net > > Date: 25/01/2019 15:30 > > Subject: Re: JDK-8217777 TEST_BUG: > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > Sent by: "core-libs-dev" > > > ------------------------------------------------------------------------ > > > > > > > > Hi Steve, > > > > Add 8217777 to the @bug line; it helps track and run tests that fixed > > bugs (jtreg -bug:8217777) > > > > +1 printing the expected and actual (when a failure occurs). > > > > Looks fine overall. > > > > Thanks, Roger > > > > > > > > On 01/25/2019 09:57 AM, Steve Groeger wrote: > > > Hi Christoph, > > > > > > Thanks for looking at this. > > > > > > These lines > > > > > > 43 //System.out.print(baos.toString()); > > > 44 //System.out.print(expectedResult); > > > > > > were commented out in the current code but if you think displaying this > > > info would be good then I can un-comment them. > > > > > > I think only fixing this in the jdk (JDK13) branch is OK. > > > If it is later determined that this is really needed in jdk12 or > > jdk11u , > > > then I can always request a backport. > > > > > > Thanks > > > Steve Groeger > > > IBM Runtime Technologies > > > Hursley, Winchester > > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > > Fax (44) 1962 816800 > > > Lotus Notes: Steve Groeger/UK/IBM > > > Internet: groeges at uk.ibm.com > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > > > From: "Langer, Christoph" > > > > To: Steve Groeger > > > > Cc: core-libs > > > > Date: 25/01/2019 14:30 > > > Subject: RE: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail > > > > > > > > > > > > Hi Steve, > > > > > > in general this change looks reasonable to me. > > > > > > I think in case there is an error, it would be useful to get a > > printout of > > > the expected/vs actual strings like these lines: > > > 43 //System.out.print(baos.toString()); > > > 44 //System.out.print(expectedResult); > > > > > > I'll take the change and run it through our test system and see if > > we see > > > any issues. > > > > > > Is it ok for you if we do the fix just in the jdk branch (JDK13) or are > > > you particularly interested in getting this fixed for jdk12 and/or > > jdk11u? > > > > > > Best regards > > > Christoph > > > > > >> -----Original Message----- > > >> From: core-libs-dev > On > Behalf > > >> Of Steve Groeger > > >> Sent: Freitag, 25. Januar 2019 12:40 > > >> To: core-libs > > > >> Subject: RFR: JDK-8217777 TEST_BUG: > > > jdk/java/util/prefs/ExportSubtree.java > > >> passes even when test should fail > > >> > > >> Hi all, > > >> > > >> I have found an issue with the jdk/java/util/prefs/ExportSubtree.java > > >> test. > > >> Using jtreg to run this test the test passes no matter what happens > > > within > > >> the test. > > >> Have raised an issue for this: > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8217777 > > > > > >> I think the issue is 2 fold: > > >> 1) the test check the expected vs. actual and throws an exception but > > > this > > >> is caught later in the code, which causes the test to pass as there is > > > no > > >> exception thrown. > > >> 2) the exported XML now contains a `standalone="no"` entry in the XML > > >> prologue, which is not in the expected XML. > > >> > > >> I have generated a webrev to resolve this: > > >> > > > http://cr.openjdk.java.net/~sgroeger/8217777/webrev.00/ > > > > > > > >> This occurs on jdk11 but is probabaly also an issue on other > > releases ie > > >> jdk8u, jdk12, jdk etc > > >> > > >> Please could someone review this webrev and sponsor this chnage for > me > > > as > > >> I am unable to commit this myself. > > >> > > >> Thanks > > >> Steve Groeger > > >> IBM Runtime Technologies > > >> Hursley, Winchester > > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > >> Fax (44) 1962 816800 > > >> Lotus Notes: Steve Groeger/UK/IBM > > >> Internet: groeges at uk.ibm.com > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > >> 3AU > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mvala at redhat.com Tue Jan 29 10:00:12 2019 From: mvala at redhat.com (Michal Vala) Date: Tue, 29 Jan 2019 11:00:12 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: <365e969c-2677-0ffb-8ad8-76314556fe9c@redhat.com> Hi Martin, I'd like to finish this review. Are you still willing to sponsor this? Thanks! On 1/9/19 11:39 AM, Michal Vala wrote: > ping > > On 1/3/19 9:31 PM, Michal Vala wrote: >> Hi Martin, >> >> can we please finish this review? >> >> On 12/19/18 6:32 PM, Michal Vala wrote: >>> >>> >>> On 12/19/18 4:15 PM, Martin Buchholz wrote: >>>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: >>>> >>>>> Hi Martin, >>>>> >>>>> It is also useful and conventional to print the seed of the random >>>>> so that if necessary it can be reproduced. >>>>> >>>> >>>> For many years, we've been using ThreadLocalRandom for testing, and that >>>> does not allow setting a seed. >>>> >>>> I remain unconvinced that saving a seed has value in the real world.? When >>>> a randomized test fails, running it with sufficient iterations has always >>>> worked for me. >>>> >>> >>> What's the reason behind using ThreadLocalRandom? >>> >>> In my opinion, reproducing the issue is key. One failure of randomized test >>> run might be caused by one issue, second run due to another issue. How we >>> reproduce then and how we know even how many issues we have? When we're >>> running random tests until it pass, it might even hide the issue. >>> >>> They sure have good value on reveal the issue, but then we have to know how >>> to reproduce and what we're searching for. >>> >>> If this case would not require ThreadLocalRandom and Random is enough, I'd >>> like to use that because of benefits I've mentioned. >>> >> > -- Michal Vala OpenJDK QE Red Hat Czech From goetz.lindenmaier at sap.com Tue Jan 29 10:17:21 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 10:17:21 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Message-ID: <81787d1a7e0040829b628cf706564f27@sap.com> Hi, this looks good, the build works with this patch. Do you need a sponsor? Best regards, Goetz. > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 02:21 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, Matthias > > Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > > Hello. > > Sorry about build issue for JDK-8214533. > > EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > > Could you review the fix ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > > Hello Goetz. > > > > Thank you for your suggestion. > > I just open JDK-8217880 [1]. > > > > I just restart clean build. > > > > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> Hi Ichiroh, > >> > >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> it. > >> I assume the fix is quite trivial so we can review it quick. > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: ppc-aix-port-dev On > >>> Behalf Of Ichiroh Takiguchi > >>> Sent: Montag, 28. Januar 2019 14:13 > >>> To: Baesken, Matthias > >>> Cc: build-dev ; ppc-aix-port-dev > >>> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > >>> > >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >>> charset > >>> > >>> Hello. > >>> > >>> I'm very sorry. It's my fault. > >>> EUC_JP class was moved to java.base module. > >>> (sun.nio.cs.EUC_JP). > >>> > >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > >>> EUC_JP_Open. > >>> > >>> Could you suggest me how I should provide new webrev files ? > >>> > >>> Thanks, > >>> Ichiroh Takiguchi > >>> > >>> > >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >>> > we see build errors on AIX , are they related to this change ? > >>> > > >>> > > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Decoder extends EUC_JP.Decoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Encoder extends EUC_JP.Encoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Decoder extends EUC_JP.Decoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Encoder extends EUC_JP.Encoder { > >>> > > >>> > Best regards, Matthias > >>> > > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: ppc-aix-port-dev > On > >>> >> Behalf Of Ichiroh Takiguchi > >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >>> >> To: Alan Bateman > >>> >> Cc: build-dev ; ppc-aix-port-dev >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >>> >> Subject: 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, Ltd. > >>> >> > >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >>> >> > Hello Alan. > >>> >> > > >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >>> >> > I cannot wait until JDK-8215333 is closed. > >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >>> >> > > >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >>> >> > > >>> >> > Thanks, > >>> >> > Ichiroh Takiguchi > >>> >> > > >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >>> >> >> Hello Roger, Magnus and Alan. > >>> >> >> I may need to put alias information into charsets file. > >>> >> >> stdcs-xxx cannot handle this information... > >>> >> >> > >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >>> >> >> > >>> >> >> I appreciate if you give me further suggestions. > >>> >> >> > >>> >> >> Thanks, > >>> >> >> Ichiroh Takiguchi > >>> >> >> > >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >>> >> >>>>> Hi, > >>> >> >>>>> > >>> >> >>>>> It is a nice feature that charsets are selected at build time using > >>> >> >>>>> the stdcs-xxx files. > >>> >> >>>>> This change breaks that pattern and embeds os specific > information > >>> >> >>>>> in more than one place. > >>> >> >>>>> That does not seem like an improvement.? Is there any > alternative? > >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >>> >> >>> My reading of the patch is that the "os" key is to avoid generating > >>> >> >>> it > >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >>> >> >>> non-AIX platforms. The general direction is welcome but I think > >>> >> >>> further work and discussion will be needed to get the right set of > >>> >> >>> changes to support filtering in the build. It can probably be > >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. > >>> >> >>> > >>> >> >>> -Alan From takiguc at linux.vnet.ibm.com Tue Jan 29 10:30:18 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 19:30:18 +0900 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <81787d1a7e0040829b628cf706564f27@sap.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Hello Goetz. Thank you for build testing. Yes, I need a sponsor. If possible, could you handle it ? Thanks, Ichiroh Takiguchi On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > Hi, > > this looks good, the build works with this patch. > Do you need a sponsor? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Ichiroh Takiguchi >> Sent: Dienstag, 29. Januar 2019 02:21 >> To: Lindenmaier, Goetz >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> Matthias >> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 >> >> Hello. >> >> Sorry about build issue for JDK-8214533. >> >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ >> >> Could you review the fix ? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> > Hello Goetz. >> > >> > Thank you for your suggestion. >> > I just open JDK-8217880 [1]. >> > >> > I just restart clean build. >> > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> > >> > Thanks, >> > Ichiroh Takiguchi >> > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> >> Hi Ichiroh, >> >> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> >> it. >> >> I assume the fix is quite trivial so we can review it quick. >> >> >> >> Best regards, >> >> Goetz. >> >> >> >>> -----Original Message----- >> >>> From: ppc-aix-port-dev On >> >>> Behalf Of Ichiroh Takiguchi >> >>> Sent: Montag, 28. Januar 2019 14:13 >> >>> To: Baesken, Matthias >> >>> Cc: build-dev ; ppc-aix-port-dev >> >>> > >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >>> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> >>> charset >> >>> >> >>> Hello. >> >>> >> >>> I'm very sorry. It's my fault. >> >>> EUC_JP class was moved to java.base module. >> >>> (sun.nio.cs.EUC_JP). >> >>> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> >>> EUC_JP_Open. >> >>> >> >>> Could you suggest me how I should provide new webrev files ? >> >>> >> >>> Thanks, >> >>> Ichiroh Takiguchi >> >>> >> >>> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> >>> > we see build errors on AIX , are they related to this change ? >> >>> > >> >>> > >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >>> > >> >>> > Best regards, Matthias >> >>> > >> >>> > >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: ppc-aix-port-dev >> On >> >>> >> Behalf Of Ichiroh Takiguchi >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >>> >> To: Alan Bateman >> >>> >> Cc: build-dev ; ppc-aix-port-dev > >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >>> >> Subject: 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, Ltd. >> >>> >> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >>> >> > Hello Alan. >> >>> >> > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >>> >> > I cannot wait until JDK-8215333 is closed. >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? >> >>> >> > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >>> >> > >> >>> >> > Thanks, >> >>> >> > Ichiroh Takiguchi >> >>> >> > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >>> >> >> Hello Roger, Magnus and Alan. >> >>> >> >> I may need to put alias information into charsets file. >> >>> >> >> stdcs-xxx cannot handle this information... >> >>> >> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >>> >> >> >> >>> >> >> I appreciate if you give me further suggestions. >> >>> >> >> >> >>> >> >> Thanks, >> >>> >> >> Ichiroh Takiguchi >> >>> >> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >>> >> >>>>> Hi, >> >>> >> >>>>> >> >>> >> >>>>> It is a nice feature that charsets are selected at build time using >> >>> >> >>>>> the stdcs-xxx files. >> >>> >> >>>>> This change breaks that pattern and embeds os specific >> information >> >>> >> >>>>> in more than one place. >> >>> >> >>>>> That does not seem like an improvement.? Is there any >> alternative? >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >>> >> >>> My reading of the patch is that the "os" key is to avoid generating >> >>> >> >>> it >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think >> >>> >> >>> further work and discussion will be needed to get the right set of >> >>> >> >>> changes to support filtering in the build. It can probably be >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >>> >> >>> >> >>> >> >>> -Alan From magnus.ihse.bursie at oracle.com Tue Jan 29 11:03:49 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 29 Jan 2019 12:03:49 +0100 Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2! 360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Message-ID: > 29 jan. 2019 kl. 02:21 skrev Ichiroh Takiguchi : > > Hello. > > Sorry about build issue for JDK-8214533. > > EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ LGTM. /Magnus > > Could you review the fix ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> Hello Goetz. >> Thank you for your suggestion. >> I just open JDK-8217880 [1]. >> I just restart clean build. >> I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> Thanks, >> Ichiroh Takiguchi >>> On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >>> Hi Ichiroh, >>> just open a bug, like "Fix aix build after 8214533" and post a RFR for it. >>> I assume the fix is quite trivial so we can review it quick. >>> Best regards, >>> Goetz. >>>> -----Original Message----- >>>> From: ppc-aix-port-dev On >>>> Behalf Of Ichiroh Takiguchi >>>> Sent: Montag, 28. Januar 2019 14:13 >>>> To: Baesken, Matthias >>>> Cc: build-dev ; ppc-aix-port-dev >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >>>> >>>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset >>>> Hello. >>>> I'm very sorry. It's my fault. >>>> EUC_JP class was moved to java.base module. >>>> (sun.nio.cs.EUC_JP). >>>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >>>> EUC_JP_Open. >>>> Could you suggest me how I should provide new webrev files ? >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-01-28 17:03, Baesken, Matthias wrote: >>>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >>>> > we see build errors on AIX , are they related to this change ? >>>> > >>>> > >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >>>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Decoder extends EUC_JP.Decoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >>>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Encoder extends EUC_JP.Encoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >>>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Decoder extends EUC_JP.Decoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >>>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Encoder extends EUC_JP.Encoder { >>>> > >>>> > Best regards, Matthias >>>> > >>>> > >>>> > >>>> >> -----Original Message----- >>>> >> From: ppc-aix-port-dev On >>>> >> Behalf Of Ichiroh Takiguchi >>>> >> Sent: Dienstag, 15. Januar 2019 01:51 >>>> >> To: Alan Bateman >>>> >> Cc: build-dev ; ppc-aix-port-dev >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >>>> >> Subject: 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, Ltd. >>>> >> >>>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >>>> >> > Hello Alan. >>>> >> > >>>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >>>> >> > I cannot wait until JDK-8215333 is closed. >>>> >> > Is it possible to put IBM-29626C charset with standard way ? >>>> >> > >>>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >>>> >> > >>>> >> > Thanks, >>>> >> > Ichiroh Takiguchi >>>> >> > >>>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >>>> >> >> Hello Roger, Magnus and Alan. >>>> >> >> I may need to put alias information into charsets file. >>>> >> >> stdcs-xxx cannot handle this information... >>>> >> >> >>>> >> >> Still AIX needs IBM-29626C charset for default encoding... >>>> >> >> >>>> >> >> I appreciate if you give me further suggestions. >>>> >> >> >>>> >> >> Thanks, >>>> >> >> Ichiroh Takiguchi >>>> >> >> >>>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>>> >> >>>>> Hi, >>>> >> >>>>> >>>> >> >>>>> It is a nice feature that charsets are selected at build time using >>>> >> >>>>> the stdcs-xxx files. >>>> >> >>>>> This change breaks that pattern and embeds os specific information >>>> >> >>>>> in more than one place. >>>> >> >>>>> That does not seem like an improvement. Is there any alternative? >>>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>>> >> >>> My reading of the patch is that the "os" key is to avoid generating >>>> >> >>> it >>>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>>> >> >>> non-AIX platforms. The general direction is welcome but I think >>>> >> >>> further work and discussion will be needed to get the right set of >>>> >> >>> changes to support filtering in the build. It can probably be >>>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >>>> >> >>> >>>> >> >>> -Alan > From nishit.jain at oracle.com Tue Jan 29 11:04:50 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 29 Jan 2019 16:34:50 +0530 Subject: [13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com> References: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com> Message-ID: <2eaebb3f-8076-411d-e724-e8168b7ffa1a@oracle.com> Hi Naoto, Look good to me. Regards, Nishit Jain On 26-01-2019 01:29, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8217609 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8217609/webrev.00/ > > Although the behavior described in the issue is the expected one > (i.e., CLDR currently does not provide names for the new era), > supplementing the name in the CLDR data is desirable from the user's > point of view. > > Naoto From matthias.baesken at sap.com Tue Jan 29 11:11:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Jan 2019 11:11:52 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Looks good to me . The patch fixed the AIX build. Best regards, Matthias > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 11:30 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > Matthias > Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 > > Hello Goetz. > > Thank you for build testing. > > Yes, I need a sponsor. > If possible, could you handle it ? > > Thanks, > Ichiroh Takiguchi > > On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > > Hi, > > > > this looks good, the build works with this patch. > > Do you need a sponsor? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Ichiroh Takiguchi > >> Sent: Dienstag, 29. Januar 2019 02:21 > >> To: Lindenmaier, Goetz > >> Cc: build-dev ; ppc-aix-port-dev > >> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > >> Matthias > >> > >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > >> > >> Hello. > >> > >> Sorry about build issue for JDK-8214533. > >> > >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > >> > >> Could you review the fix ? > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > >> > Hello Goetz. > >> > > >> > Thank you for your suggestion. > >> > I just open JDK-8217880 [1]. > >> > > >> > I just restart clean build. > >> > > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> >> Hi Ichiroh, > >> >> > >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> >> it. > >> >> I assume the fix is quite trivial so we can review it quick. > >> >> > >> >> Best regards, > >> >> Goetz. > >> >> > >> >>> -----Original Message----- > >> >>> From: ppc-aix-port-dev bounces at openjdk.java.net> On > >> >>> Behalf Of Ichiroh Takiguchi > >> >>> Sent: Montag, 28. Januar 2019 14:13 > >> >>> To: Baesken, Matthias > >> >>> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan > Bateman > >> >>> > >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> charset > >> >>> > >> >>> Hello. > >> >>> > >> >>> I'm very sorry. It's my fault. > >> >>> EUC_JP class was moved to java.base module. > >> >>> (sun.nio.cs.EUC_JP). > >> >>> > >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX > and > >> >>> EUC_JP_Open. > >> >>> > >> >>> Could you suggest me how I should provide new webrev files ? > >> >>> > >> >>> Thanks, > >> >>> Ichiroh Takiguchi > >> >>> > >> >>> > >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >> >>> > we see build errors on AIX , are they related to this change ? > >> >>> > > >> >>> > > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > > >> >>> > Best regards, Matthias > >> >>> > > >> >>> > > >> >>> > > >> >>> >> -----Original Message----- > >> >>> >> From: ppc-aix-port-dev bounces at openjdk.java.net> > >> On > >> >>> >> Behalf Of Ichiroh Takiguchi > >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >> >>> >> To: Alan Bateman > >> >>> >> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> >>> >> Subject: 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, Ltd. > >> >>> >> > >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> >>> >> > Hello Alan. > >> >>> >> > > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> >>> >> > I cannot wait until JDK-8215333 is closed. > >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >> >>> >> > > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> >>> >> > > >> >>> >> > Thanks, > >> >>> >> > Ichiroh Takiguchi > >> >>> >> > > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >>> >> >> Hello Roger, Magnus and Alan. > >> >>> >> >> I may need to put alias information into charsets file. > >> >>> >> >> stdcs-xxx cannot handle this information... > >> >>> >> >> > >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >>> >> >> > >> >>> >> >> I appreciate if you give me further suggestions. > >> >>> >> >> > >> >>> >> >> Thanks, > >> >>> >> >> Ichiroh Takiguchi > >> >>> >> >> > >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>> >> >>>>> Hi, > >> >>> >> >>>>> > >> >>> >> >>>>> It is a nice feature that charsets are selected at build time > using > >> >>> >> >>>>> the stdcs-xxx files. > >> >>> >> >>>>> This change breaks that pattern and embeds os specific > >> information > >> >>> >> >>>>> in more than one place. > >> >>> >> >>>>> That does not seem like an improvement.? Is there any > >> alternative? > >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> >> >>> My reading of the patch is that the "os" key is to avoid > generating > >> >>> >> >>> it > >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets > on > >> >>> >> >>> non-AIX platforms. The general direction is welcome but I > think > >> >>> >> >>> further work and discussion will be needed to get the right set > of > >> >>> >> >>> changes to support filtering in the build. It can probably be > >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's > java.base. > >> >>> >> >>> > >> >>> >> >>> -Alan From goetz.lindenmaier at sap.com Tue Jan 29 11:20:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 11:20:38 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Pushed. Best regards, Goetz > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 11:30 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, Matthias > > Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 > > Hello Goetz. > > Thank you for build testing. > > Yes, I need a sponsor. > If possible, could you handle it ? > > Thanks, > Ichiroh Takiguchi > > On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > > Hi, > > > > this looks good, the build works with this patch. > > Do you need a sponsor? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Ichiroh Takiguchi > >> Sent: Dienstag, 29. Januar 2019 02:21 > >> To: Lindenmaier, Goetz > >> Cc: build-dev ; ppc-aix-port-dev > >> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > >> Matthias > >> > >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > >> > >> Hello. > >> > >> Sorry about build issue for JDK-8214533. > >> > >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > >> > >> Could you review the fix ? > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > >> > Hello Goetz. > >> > > >> > Thank you for your suggestion. > >> > I just open JDK-8217880 [1]. > >> > > >> > I just restart clean build. > >> > > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> >> Hi Ichiroh, > >> >> > >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> >> it. > >> >> I assume the fix is quite trivial so we can review it quick. > >> >> > >> >> Best regards, > >> >> Goetz. > >> >> > >> >>> -----Original Message----- > >> >>> From: ppc-aix-port-dev > On > >> >>> Behalf Of Ichiroh Takiguchi > >> >>> Sent: Montag, 28. Januar 2019 14:13 > >> >>> To: Baesken, Matthias > >> >>> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > >> >>> > >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> charset > >> >>> > >> >>> Hello. > >> >>> > >> >>> I'm very sorry. It's my fault. > >> >>> EUC_JP class was moved to java.base module. > >> >>> (sun.nio.cs.EUC_JP). > >> >>> > >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > >> >>> EUC_JP_Open. > >> >>> > >> >>> Could you suggest me how I should provide new webrev files ? > >> >>> > >> >>> Thanks, > >> >>> Ichiroh Takiguchi > >> >>> > >> >>> > >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >> >>> > we see build errors on AIX , are they related to this change ? > >> >>> > > >> >>> > > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > > >> >>> > Best regards, Matthias > >> >>> > > >> >>> > > >> >>> > > >> >>> >> -----Original Message----- > >> >>> >> From: ppc-aix-port-dev bounces at openjdk.java.net> > >> On > >> >>> >> Behalf Of Ichiroh Takiguchi > >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >> >>> >> To: Alan Bateman > >> >>> >> Cc: build-dev ; ppc-aix-port-dev aix- > >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> >>> >> Subject: 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, Ltd. > >> >>> >> > >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> >>> >> > Hello Alan. > >> >>> >> > > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> >>> >> > I cannot wait until JDK-8215333 is closed. > >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >> >>> >> > > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> >>> >> > > >> >>> >> > Thanks, > >> >>> >> > Ichiroh Takiguchi > >> >>> >> > > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >>> >> >> Hello Roger, Magnus and Alan. > >> >>> >> >> I may need to put alias information into charsets file. > >> >>> >> >> stdcs-xxx cannot handle this information... > >> >>> >> >> > >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >>> >> >> > >> >>> >> >> I appreciate if you give me further suggestions. > >> >>> >> >> > >> >>> >> >> Thanks, > >> >>> >> >> Ichiroh Takiguchi > >> >>> >> >> > >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>> >> >>>>> Hi, > >> >>> >> >>>>> > >> >>> >> >>>>> It is a nice feature that charsets are selected at build time > using > >> >>> >> >>>>> the stdcs-xxx files. > >> >>> >> >>>>> This change breaks that pattern and embeds os specific > >> information > >> >>> >> >>>>> in more than one place. > >> >>> >> >>>>> That does not seem like an improvement.? Is there any > >> alternative? > >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> >> >>> My reading of the patch is that the "os" key is to avoid > generating > >> >>> >> >>> it > >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think > >> >>> >> >>> further work and discussion will be needed to get the right set of > >> >>> >> >>> changes to support filtering in the build. It can probably be > >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's > java.base. > >> >>> >> >>> > >> >>> >> >>> -Alan From takiguc at linux.vnet.ibm.com Tue Jan 29 12:01:55 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 21:01:55 +0900 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: <17a0aa2962cc11279991fd8a10b41494@linux.vnet.ibm.com> To reviewers, Thank you for reviewing in a short time. Best regards, Ichiroh Takiguchi On 2019-01-29 20:20, Lindenmaier, Goetz wrote: > Pushed. > > Best regards, > Goetz > >> -----Original Message----- >> From: Ichiroh Takiguchi >> Sent: Dienstag, 29. Januar 2019 11:30 >> To: Lindenmaier, Goetz >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> Matthias >> >> Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 >> >> Hello Goetz. >> >> Thank you for build testing. >> >> Yes, I need a sponsor. >> If possible, could you handle it ? >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-01-29 19:17, Lindenmaier, Goetz wrote: >> > Hi, >> > >> > this looks good, the build works with this patch. >> > Do you need a sponsor? >> > >> > Best regards, >> > Goetz. >> > >> >> -----Original Message----- >> >> From: Ichiroh Takiguchi >> >> Sent: Dienstag, 29. Januar 2019 02:21 >> >> To: Lindenmaier, Goetz >> >> Cc: build-dev ; ppc-aix-port-dev >> >> > >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> >> Matthias >> >> >> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 >> >> >> >> Hello. >> >> >> >> Sorry about build issue for JDK-8214533. >> >> >> >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 >> >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ >> >> >> >> Could you review the fix ? >> >> >> >> Thanks, >> >> Ichiroh Takiguchi >> >> IBM Japan, Ltd. >> >> >> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> >> > Hello Goetz. >> >> > >> >> > Thank you for your suggestion. >> >> > I just open JDK-8217880 [1]. >> >> > >> >> > I just restart clean build. >> >> > >> >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> >> > >> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> >> > >> >> > Thanks, >> >> > Ichiroh Takiguchi >> >> > >> >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> >> >> Hi Ichiroh, >> >> >> >> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> >> >> it. >> >> >> I assume the fix is quite trivial so we can review it quick. >> >> >> >> >> >> Best regards, >> >> >> Goetz. >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: ppc-aix-port-dev >> On >> >> >>> Behalf Of Ichiroh Takiguchi >> >> >>> Sent: Montag, 28. Januar 2019 14:13 >> >> >>> To: Baesken, Matthias >> >> >>> Cc: build-dev ; ppc-aix-port-dev >> >> >>> > >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >> >>> >> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> >> >>> charset >> >> >>> >> >> >>> Hello. >> >> >>> >> >> >>> I'm very sorry. It's my fault. >> >> >>> EUC_JP class was moved to java.base module. >> >> >>> (sun.nio.cs.EUC_JP). >> >> >>> >> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> >> >>> EUC_JP_Open. >> >> >>> >> >> >>> Could you suggest me how I should provide new webrev files ? >> >> >>> >> >> >>> Thanks, >> >> >>> Ichiroh Takiguchi >> >> >>> >> >> >>> >> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >> >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> >> >>> > we see build errors on AIX , are they related to this change ? >> >> >>> > >> >> >>> > >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >> >>> > >> >> >>> > Best regards, Matthias >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> >> -----Original Message----- >> >> >>> >> From: ppc-aix-port-dev > bounces at openjdk.java.net> >> >> On >> >> >>> >> Behalf Of Ichiroh Takiguchi >> >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >> >>> >> To: Alan Bateman >> >> >>> >> Cc: build-dev ; ppc-aix-port-dev > aix- >> >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >> >>> >> Subject: 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, Ltd. >> >> >>> >> >> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >> >>> >> > Hello Alan. >> >> >>> >> > >> >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >> >>> >> > I cannot wait until JDK-8215333 is closed. >> >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? >> >> >>> >> > >> >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >> >>> >> > >> >> >>> >> > Thanks, >> >> >>> >> > Ichiroh Takiguchi >> >> >>> >> > >> >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> >>> >> >> Hello Roger, Magnus and Alan. >> >> >>> >> >> I may need to put alias information into charsets file. >> >> >>> >> >> stdcs-xxx cannot handle this information... >> >> >>> >> >> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >>> >> >> >> >> >>> >> >> I appreciate if you give me further suggestions. >> >> >>> >> >> >> >> >>> >> >> Thanks, >> >> >>> >> >> Ichiroh Takiguchi >> >> >>> >> >> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >> >>> >> >>>>> Hi, >> >> >>> >> >>>>> >> >> >>> >> >>>>> It is a nice feature that charsets are selected at build time >> using >> >> >>> >> >>>>> the stdcs-xxx files. >> >> >>> >> >>>>> This change breaks that pattern and embeds os specific >> >> information >> >> >>> >> >>>>> in more than one place. >> >> >>> >> >>>>> That does not seem like an improvement.? Is there any >> >> alternative? >> >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >> >>> >> >>> My reading of the patch is that the "os" key is to avoid >> generating >> >> >>> >> >>> it >> >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think >> >> >>> >> >>> further work and discussion will be needed to get the right set of >> >> >>> >> >>> changes to support filtering in the build. It can probably be >> >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's >> java.base. >> >> >>> >> >>> >> >> >>> >> >>> -Alan From pavel.rappo at oracle.com Tue Jan 29 12:16:22 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 29 Jan 2019 12:16:22 +0000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <019AC4DB-ECCB-457F-B782-B65A823A4812@oracle.com> Message-ID: <66ACC7ED-D048-450F-9A87-3E7D9C05D057@oracle.com> > On 29 Jan 2019, at 08:50, David Holmes wrote: > > Hi Pavel, > > I don't think this kind of trivial change needs the OCA to be signed. > > "A Participant may post messages to a list, submit simple patches, and make other kinds of small contributions." [1] Hi David, That is true. However, I'm not sure how to distinguish between a trivial patch and a not so trivial. From david.holmes at oracle.com Tue Jan 29 12:20:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jan 2019 22:20:21 +1000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <66ACC7ED-D048-450F-9A87-3E7D9C05D057@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <019AC4DB-ECCB-457F-B782-B65A823A4812@oracle.com> <66ACC7ED-D048-450F-9A87-3E7D9C05D057@oracle.com> Message-ID: On 29/01/2019 10:16 pm, Pavel Rappo wrote: >> On 29 Jan 2019, at 08:50, David Holmes wrote: >> >> Hi Pavel, >> >> I don't think this kind of trivial change needs the OCA to be signed. >> >> "A Participant may post messages to a list, submit simple patches, and make other kinds of small contributions." [1] > > Hi David, > > That is true. However, I'm not sure how to distinguish between a trivial patch > and a not so trivial. True for code changes, but duplicate word removal seems about as trivial as you can get! David > > From naokikishida at gmail.com Tue Jan 29 12:21:57 2019 From: naokikishida at gmail.com (kishida naoki) Date: Tue, 29 Jan 2019 21:21:57 +0900 Subject: =?UTF-8?B?V2lsbCB3ZSBoYXZlIGFueSBvcHRpb24gdG8gZm9ybWF0IDIwMTkgYXMg5YWD5Y+35YWD?= =?UTF-8?B?5bm0Pw==?= Message-ID: As you know, Japanese government have a plan to change the era on May. It will be the first year of the new era. In practice, we describe the first year as "??" not as "1?" Now DateTimeFormatter with `G` output the era. `DateTimeFormatter.ofPattern("Gy?").format(JapaneseDate.of(2019, 5, 2))` output `??1?` Do you have any plan to have a option to format it as `????` or already implemented? -- Naoki Kishida From pavel.rappo at oracle.com Tue Jan 29 13:42:39 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 29 Jan 2019 13:42:39 +0000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> Message-ID: <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> > On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: > > Thanks to review. Patch updated. I'm not really sure what to do next. > I should find someone who can create issue and commit my patch to > repository, right? Andrey, Could you please re-generate your patch? The reason I'm asking is that the current patch contains extra line breaks. Please paste the exact diff output into your message. Do not apply any additional formatting on top of it. Thank you. From Roger.Riggs at oracle.com Tue Jan 29 14:15:31 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 29 Jan 2019 09:15:31 -0500 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: <2c3f065f-0aa4-7832-9a8e-92274c9ec089@oracle.com> fyi, mailers have a bad habit of wrapping patches at the wrong point. Attaching it as a text (.txt) file works too. On 01/29/2019 08:42 AM, Pavel Rappo wrote: >> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: >> >> Thanks to review. Patch updated. I'm not really sure what to do next. >> I should find someone who can create issue and commit my patch to >> repository, right? > Andrey, > > Could you please re-generate your patch? The reason I'm asking is that the > current patch contains extra line breaks. > > Please paste the exact diff output into your message. Do not apply any > additional formatting on top of it. > > Thank you. > From Roger.Riggs at oracle.com Tue Jan 29 14:20:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 29 Jan 2019 09:20:38 -0500 Subject: [13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: <2eaebb3f-8076-411d-e724-e8168b7ffa1a@oracle.com> References: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com> <2eaebb3f-8076-411d-e724-e8168b7ffa1a@oracle.com> Message-ID: <61e5454c-1742-b755-a4ba-b1a4ef0170e5@oracle.com> +1 On 01/29/2019 06:04 AM, Nishit Jain wrote: > Hi Naoto, > > Look good to me. > > Regards, > Nishit Jain > On 26-01-2019 01:29, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8217609 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8217609/webrev.00/ >> >> Although the behavior described in the issue is the expected one >> (i.e., CLDR currently does not provide names for the new era), >> supplementing the name in the CLDR data is desirable from the user's >> point of view. >> >> Naoto > From naoto.sato at oracle.com Tue Jan 29 16:22:01 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 29 Jan 2019 08:22:01 -0800 Subject: =?UTF-8?Q?Re=3a_Will_we_have_any_option_to_format_2019_as_=e5=85=83?= =?UTF-8?B?5Y+35YWD5bm0Pw==?= In-Reply-To: References: Message-ID: <61de0cc4-a004-3d2c-f667-81018700e709@oracle.com> Hi Kishida-san, Currently we don't have a plan to support Gannen in java.time for formatting/parsing Japanese calendar dates. Here are a couple of workarounds: 1. Use java.text APIs to format/parse dates, e.g., jshell> new SimpleDateFormat("GGGGyyyy?", Locale.forLanguageTag("ja-JP-u-ca-japanese")).format(new Calendar.Builder().setDate(2019, Calendar.MAY, 1).build().getTime()) $3 ==> "????" 2. For java.time API, use DateTimeFormatterBuilder.appendText(TemporalField, Map) to map the 1 to "?". Following issue demonstrates how to do it: https://bugs.openjdk.java.net/browse/JDK-8042131 HTH, Naoto On 1/29/19 4:21 AM, kishida naoki wrote: > As you know, Japanese government have a plan to change the era on May. > It will be the first year of the new era. > In practice, we describe the first year as "??" not as "1?" > > Now DateTimeFormatter with `G` output the era. > `DateTimeFormatter.ofPattern("Gy?").format(JapaneseDate.of(2019, 5, 2))` > output `??1?` > > Do you have any plan to have a option to format it as `????` or already > implemented? > From mik3hall at gmail.com Tue Jan 29 17:50:16 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 29 Jan 2019 11:50:16 -0600 Subject: jpackage OS X classpath Message-ID: <8961CCB7-C33C-47E9-A7AD-160C50B6C316@gmail.com> I figured out for the time being how I can programmatically handle setting security that might be cross-platform for my application. Past that it doesn?t seem to be finding resources off the class loader that it should be? With this? ClassLoader cl = Thread.currentThread().getContextClassLoader(); syslog.println("cl is " + cl + "\nuser.dir " + System.getProperty("user.dir") + "\nCP> " + System.getProperty("java.class.path")); I get this? cl is jdk.internal.loader.ClassLoaders$AppClassLoader at 55054057 user.dir /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java CP> /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar:RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar: ? :resource.jar ... ?and so on... Only the first path in java.class.path is absolute - to the main jar. Would this break if the application is moved? The other paths are relative. I notice user.dir is now default set directly to the Java directory within the app. I assume this is how relative is supposed to work. This is again a change from legacy OS X java app?s. Prior to the OS X port I think Apple set this to the parent directory of the application itself. With AppBundler set up during the port it was set to the user home directory. I think for security concerns? (App?s should usually be in the Application directory, this should not be written to by the application). So this is another change that legacy app?s could have issues with. It might be a thought to document some of the differences to legacy java applications somewhere? Anyhow, I put the resources that I am currently not finding in the resource.jar shown above. I thought some testing with non-jpackage apps showed this would work. These used to be in the ?Classes? directory as mentioned in an earlier post. A rather obscure feature probably not many app?s took advantage of. But I am now not finding them in the jpackage resource.jar for some reason still to be determined. Like? BufferedReader rdr = new BufferedReader(new InputStreamReader(cl.getResourceAsStream("Scripts/loader.js"))); org.mozilla.javascript.EvaluatorException: Couldn't open file "Scripts/mm.js". (unnamed script#1) at org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporter.java:77) at org.mozilla.javascript.DefaultErrorReporter.error(DefaultErrorReporter.java:64) at org.mozilla.javascript.Context.reportError(Context.java:956) Actually what it says it?s not finding isn?t loader.js but a script that loader.js should load? So maybe again this is some difference in how a nested load works? Again, it would be different application behavior somehow if so. From peter.levart at gmail.com Tue Jan 29 20:30:37 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 29 Jan 2019 21:30:37 +0100 Subject: Collectors.converting Message-ID: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> Hi, I wonder if there's any interest in adding a convenience factory method for a Collector to the standard repertoire which would look like the following: ??? /** ???? * Convert given {@link Collector} so that it applies an additional finisher function that ???? * converts the result of given collector. The characteristics of returned collector is ???? * the same as that of the given inner collector but without any ???? * {@link java.util.stream.Collector.Characteristics#IDENTITY_FINISH}. ???? * ???? * @param collector?????? the inner collector to delegate collection to ???? * @param resultConverter the additional result finisher function ???? * @param ???????????? the type of input stream elements ???? * @param ???????????? the type of intermediate aggregation ???? * @param ???????????? the type of result of inner collector ???? * @param ??????????? the type of final result ???? * @return the converted collector ???? */ ??? public static Collector converting( ??????? Collector collector, ??????? Function resultConverter ??? ) { ??????? return new Collector() { ??????????? @Override ??????????? public Supplier supplier() { return collector.supplier(); } ??????????? @Override ??????????? public BiConsumer accumulator() { return collector.accumulator(); } ??????????? @Override ??????????? public BinaryOperator combiner() { return collector.combiner(); } ??????????? @Override ??????????? public Function finisher() { return resultConverter.compose(collector.finisher()); } ??????????? @Override ??????????? public Set characteristics() { ??????????????? EnumSet characteristics = EnumSet.noneOf(Characteristics.class); ??????????????? characteristics.addAll(collector.characteristics()); characteristics.remove(Characteristics.IDENTITY_FINISH); ??????????????? return Collections.unmodifiableSet(characteristics); ??????????? } ??????? }; ??? } The rationale is as follows... Composability of collectors allows doing things like: ??????? interface Measurement { ??????????? long value(); ??????????? String type(); ??????? } ??????? Stream measurements = .... ??????? Map statsByType = ??????????? measurements ??????????????? .collect( ??????????????????? groupingBy( ??????????????????????? Measurement::type, ??????????????????????? summarizingLong(Measurement::value) ??????????????????? ) ??????????????? ); ...but say I wanted the final result to be a map of avarage values by type and the values to be BigDecimal objects calculated with scale of 19. I can create an intermediate map like above and then transform it to new map, like this: ??????? static BigDecimal toBDAverage(LongSummaryStatistics stats) { ??????????? return BigDecimal.valueOf(stats.getSum()) ???????????????????????????? .divide( BigDecimal.valueOf(stats.getCount()), ???????????????????????????????? 20, RoundingMode.HALF_EVEN); ??????? } ??????? Map averageByType = ??????????? statsByType ??????????????? .entrySet() ??????????????? .stream() ??????????????? .collect(toMap(Map.Entry::getKey, e -> toBDAverage(e.getValue()))); ...this is ugly as it requires intermediate result to be materialized as a HashMap. Wouldn't it be possible to collect the original stream to final result in one go? With the above Collectors.converting factory method, it would: ??????? Map averageByType = ??????????? measurements ??????????????? .collect( ??????????????????? groupingBy( ??????????????????????? Measurement::type, ??????????????????????? converting( ??????????????????????????? summarizingLong(Measurement::value), ??????????????????????????? stats -> toBDAverage(stats) ??????????????????????? ) ??????????????????? ) ??????????????? ); We already have Collectors.mapping(Function, Collector) method that constructs Collector that maps elements to be collected by inner collector. Collectors.converting(Collectors, Function) would be a twin brother that constructs Collector that converts the collection result of the inner collector. Both are useful in compositions like above, but we only have the 1st... What do you think? Regards, Peter From brian.goetz at oracle.com Tue Jan 29 20:52:25 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 29 Jan 2019 15:52:25 -0500 Subject: Collectors.converting In-Reply-To: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> References: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> Message-ID: <21b6be97-6af4-f382-04a9-e5ee2d16cacc@oracle.com> How is this different from Collectors.collectingAndThen? On 1/29/2019 3:30 PM, Peter Levart wrote: > Hi, > > I wonder if there's any interest in adding a convenience factory > method for a Collector to the standard repertoire which would look > like the following: > > ??? /** > ???? * Convert given {@link Collector} so that it applies an > additional finisher function that > ???? * converts the result of given collector. The characteristics of > returned collector is > ???? * the same as that of the given inner collector but without any > ???? * {@link > java.util.stream.Collector.Characteristics#IDENTITY_FINISH}. > ???? * > ???? * @param collector?????? the inner collector to delegate > collection to > ???? * @param resultConverter the additional result finisher function > ???? * @param ???????????? the type of input stream elements > ???? * @param ???????????? the type of intermediate aggregation > ???? * @param ???????????? the type of result of inner collector > ???? * @param ??????????? the type of final result > ???? * @return the converted collector > ???? */ > ??? public static Collector converting( > ??????? Collector collector, > ??????? Function resultConverter > ??? ) { > ??????? return new Collector() { > ??????????? @Override > ??????????? public Supplier supplier() { return > collector.supplier(); } > > ??????????? @Override > ??????????? public BiConsumer accumulator() { return > collector.accumulator(); } > > ??????????? @Override > ??????????? public BinaryOperator combiner() { return > collector.combiner(); } > > ??????????? @Override > ??????????? public Function finisher() { return > resultConverter.compose(collector.finisher()); } > > ??????????? @Override > ??????????? public Set characteristics() { > ??????????????? EnumSet characteristics = > EnumSet.noneOf(Characteristics.class); > characteristics.addAll(collector.characteristics()); > characteristics.remove(Characteristics.IDENTITY_FINISH); > ??????????????? return Collections.unmodifiableSet(characteristics); > ??????????? } > ??????? }; > ??? } > > > The rationale is as follows... Composability of collectors allows > doing things like: > > ??????? interface Measurement { > ??????????? long value(); > ??????????? String type(); > ??????? } > > ??????? Stream measurements = .... > > ??????? Map statsByType = > ??????????? measurements > ??????????????? .collect( > ??????????????????? groupingBy( > ??????????????????????? Measurement::type, > ??????????????????????? summarizingLong(Measurement::value) > ??????????????????? ) > ??????????????? ); > > ...but say I wanted the final result to be a map of avarage values by > type and the values to be BigDecimal objects calculated with scale of > 19. I can create an intermediate map like above and then transform it > to new map, like this: > > ??????? static BigDecimal toBDAverage(LongSummaryStatistics stats) { > ??????????? return BigDecimal.valueOf(stats.getSum()) > ???????????????????????????? .divide( > BigDecimal.valueOf(stats.getCount()), > ???????????????????????????????? 20, RoundingMode.HALF_EVEN); > ??????? } > > ??????? Map averageByType = > ??????????? statsByType > ??????????????? .entrySet() > ??????????????? .stream() > ??????????????? .collect(toMap(Map.Entry::getKey, e -> > toBDAverage(e.getValue()))); > > ...this is ugly as it requires intermediate result to be materialized > as a HashMap. Wouldn't it be possible to collect the original stream > to final result in one go? > > With the above Collectors.converting factory method, it would: > > ??????? Map averageByType = > ??????????? measurements > ??????????????? .collect( > ??????????????????? groupingBy( > ??????????????????????? Measurement::type, > ??????????????????????? converting( > ??????????????????????????? summarizingLong(Measurement::value), > ??????????????????????????? stats -> toBDAverage(stats) > ??????????????????????? ) > ??????????????????? ) > ??????????????? ); > > We already have Collectors.mapping(Function, Collector) method that > constructs Collector that maps elements to be collected by inner > collector. Collectors.converting(Collectors, Function) would be a twin > brother that constructs Collector that converts the collection result > of the inner collector. Both are useful in compositions like above, > but we only have the 1st... > > What do you think? > > Regards, Peter > From lowasser at google.com Tue Jan 29 20:55:17 2019 From: lowasser at google.com (Louis Wasserman) Date: Tue, 29 Jan 2019 12:55:17 -0800 Subject: Collectors.converting In-Reply-To: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> References: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> Message-ID: I'm not sure I follow how this is intended to be different from Collectors.collectingAndThen. Could you explain that a little more? On Tue, Jan 29, 2019 at 12:31 PM Peter Levart wrote: > Hi, > > I wonder if there's any interest in adding a convenience factory method > for a Collector to the standard repertoire which would look like the > following: > > /** > * Convert given {@link Collector} so that it applies an additional > finisher function that > * converts the result of given collector. The characteristics of > returned collector is > * the same as that of the given inner collector but without any > * {@link java.util.stream.Collector.Characteristics#IDENTITY_FINISH}. > * > * @param collector the inner collector to delegate collection > to > * @param resultConverter the additional result finisher function > * @param the type of input stream elements > * @param the type of intermediate aggregation > * @param the type of result of inner collector > * @param the type of final result > * @return the converted collector > */ > public static Collector converting( > Collector collector, > Function resultConverter > ) { > return new Collector() { > @Override > public Supplier supplier() { return collector.supplier(); } > > @Override > public BiConsumer accumulator() { return > collector.accumulator(); } > > @Override > public BinaryOperator combiner() { return > collector.combiner(); } > > @Override > public Function finisher() { return > resultConverter.compose(collector.finisher()); } > > @Override > public Set characteristics() { > EnumSet characteristics = > EnumSet.noneOf(Characteristics.class); > characteristics.addAll(collector.characteristics()); > characteristics.remove(Characteristics.IDENTITY_FINISH); > return Collections.unmodifiableSet(characteristics); > } > }; > } > > > The rationale is as follows... Composability of collectors allows doing > things like: > > interface Measurement { > long value(); > String type(); > } > > Stream measurements = .... > > Map statsByType = > measurements > .collect( > groupingBy( > Measurement::type, > summarizingLong(Measurement::value) > ) > ); > > ...but say I wanted the final result to be a map of avarage values by > type and the values to be BigDecimal objects calculated with scale of > 19. I can create an intermediate map like above and then transform it to > new map, like this: > > static BigDecimal toBDAverage(LongSummaryStatistics stats) { > return BigDecimal.valueOf(stats.getSum()) > .divide( > BigDecimal.valueOf(stats.getCount()), > 20, RoundingMode.HALF_EVEN); > } > > Map averageByType = > statsByType > .entrySet() > .stream() > .collect(toMap(Map.Entry::getKey, e -> > toBDAverage(e.getValue()))); > > ...this is ugly as it requires intermediate result to be materialized as > a HashMap. Wouldn't it be possible to collect the original stream to > final result in one go? > > With the above Collectors.converting factory method, it would: > > Map averageByType = > measurements > .collect( > groupingBy( > Measurement::type, > converting( > summarizingLong(Measurement::value), > stats -> toBDAverage(stats) > ) > ) > ); > > We already have Collectors.mapping(Function, Collector) method that > constructs Collector that maps elements to be collected by inner > collector. Collectors.converting(Collectors, Function) would be a twin > brother that constructs Collector that converts the collection result of > the inner collector. Both are useful in compositions like above, but we > only have the 1st... > > What do you think? > > Regards, Peter > > -- Louis Wasserman From andy.herrick at oracle.com Tue Jan 29 20:57:56 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 29 Jan 2019 15:57:56 -0500 Subject: RFR: JKDK-8217331, JDK-8217792 Message-ID: <435599fb-1e54-e2a8-6fb8-eca59976903b@oracle.com> Please review the jpackage fix for bugs [1] and [2] at [3]. These two fixes are for the JDK-8200758-branch branch of the open sandbox repository (jpackage). JDK-8217793 addresses what modules are included in the runtime of an application or jre image JDK-8217792 fixes the use of modular jars [1] https://bugs.openjdk.java.net/browse/JDK-8217793 [2] https://bugs.openjdk.java.net/browse/JDK-8217792 [3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/ /Andy From turbanoff at gmail.com Tue Jan 29 22:02:48 2019 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 30 Jan 2019 01:02:48 +0300 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: >Could you please re-generate your patch? The reason I'm asking is that the current patch contains extra line breaks. Hm. There wasn't any extra line breaks in sent email. Regenerated patch attached. Andre Turbanov From alexander.matveev at oracle.com Tue Jan 29 22:11:11 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 29 Jan 2019 14:11:11 -0800 Subject: RFR: JKDK-8217331, JDK-8217792 In-Reply-To: <435599fb-1e54-e2a8-6fb8-eca59976903b@oracle.com> References: <435599fb-1e54-e2a8-6fb8-eca59976903b@oracle.com> Message-ID: Hi Andy, http://cr.openjdk.java.net/~herrick/8217792/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html Line 419 - Log.info() logs always. I think it is better to use Log.verbose() or just remove it. Otherwise looks good. Thanks, Alexander On 1/29/2019 12:57 PM, Andy Herrick wrote: > Please review the jpackage fix for bugs [1] and [2] at [3]. > > These two fixes are for the JDK-8200758-branch branch of the open > sandbox repository (jpackage). > > JDK-8217793 addresses what modules are included in the runtime of an > application or jre image > > JDK-8217792 fixes the use of modular jars > > [1] https://bugs.openjdk.java.net/browse/JDK-8217793 > > [2] https://bugs.openjdk.java.net/browse/JDK-8217792 > > [3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/ > > /Andy > From david.holmes at oracle.com Tue Jan 29 22:27:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 08:27:53 +1000 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: No attachment received. David On 30/01/2019 8:02 am, Andrey Turbanov wrote: >> Could you please re-generate your patch? The reason I'm asking is that the current patch contains extra line breaks. > Hm. There wasn't any extra line breaks in sent email. Regenerated > patch attached. > > Andre Turbanov > From andy.herrick at oracle.com Tue Jan 29 22:39:05 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 29 Jan 2019 17:39:05 -0500 Subject: RFR: JKDK-8217331, JDK-8217792 In-Reply-To: References: <435599fb-1e54-e2a8-6fb8-eca59976903b@oracle.com> Message-ID: <417a5747-e953-112d-6d78-fa85dc5004cd@oracle.com> On 1/29/2019 5:11 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8217792/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html > > Line 419 - Log.info() logs always. I think it is better to use > Log.verbose() or just remove it. > Actually, I had created a webrev.02 - but failed to post it - this section will be removed, including the Log statement. There was some other feedback on this topic (what modules to include in a jre image) that I need to process - and may wind up with a different approach, so consider this RFR on hold till sometime tomorrow. /Andy > Otherwise looks good. > > Thanks, > Alexander > > > On 1/29/2019 12:57 PM, Andy Herrick wrote: >> Please review the jpackage fix for bugs [1] and [2] at [3]. >> >> These two fixes are for the JDK-8200758-branch branch of the open >> sandbox repository (jpackage). >> >> JDK-8217793 addresses what modules are included in the runtime of an >> application or jre image >> >> JDK-8217792 fixes the use of modular jars >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217793 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8217792 >> >> [3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/ >> >> /Andy >> > From stuart.marks at oracle.com Tue Jan 29 23:24:06 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Jan 2019 15:24:06 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <44D0FDF6-73BB-42C7-ACCE-BF64F6CE600C@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> <44D0FDF6-73BB-42C7-ACCE-BF64F6CE600C@cbfiddle.com> Message-ID: > In case you missed my previous message, there is a use case for file paths using macOS APIs. Hm, Martin had mentioned that macOS uses something more restrictive than UTF-8. It seems to me that a filesystem-specific encoding is called for here. > If you search the JDK repo for?GetStringUTFChars, you will find several uses > that do not appear to involve serialization or data input/output. To clarify, I was talking about uses of modified UTF-8 from *Java* code. The only places modified UTF-8 should appear in Java code are (I think) in serialization and in Data*Stream. Native code needs to use modified UTF-8 because it's required for various JVM interfaces. > It is not obvious whether these uses are correct or not. > > Consider test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c > > where?GetStringUTFChars is used to convert a file path to pass to open(). > > At the very least, anyone using?GetStringUTFChars as a short cut for true UTF-8 > conversion should document why this short cut is correct, as is done in > awt_InputMethod, for example. Correct. If there are places that use GetStringUTFChars is used where real UTF-8 is required, then that's quite possibly a bug. The use in libDirectIO.c is certainly suspicious. Note that this is test code, and the only strings that are passed to it are temp file names from Files.createTempFile(). It seems likely that such strings contain non-null BMP characters, for which modified UTF-8 and real UTF-8 are the same, so this is unlikely to be a problem in practice. Still, you're right, if there are places where the JDK uses GetStringUTFChars where real UTF-8 is required, those would be bugs. ** Anyway, I think it's unfortunate, but in the JNI world we're saddled with modified UTF-8. If you need real UTF-8, I recommend you do the conversion in Java before you get down to native. The reason is that there are some edge cases with codeset conversion (e.g., malformed sequences such as unpaired surrogates) that would require a bunch of additional facilities that aren't readily available from native code, as far as I know. s'marks > > ? Alan > > > >> On Jan 28, 2019, at 2:10 PM, Stuart Marks > > wrote: >> >> (From Java code, the Charset encoders/decoders handle real UTF-8, which seems >> to cover most cases. Modified UTF-8 occurs only within serialization and >> Data{Input,Output}Stream.) > From javalists at cbfiddle.com Wed Jan 30 00:16:56 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 29 Jan 2019 16:16:56 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> <44D0FDF6-73BB-42C7-ACCE-BF64F6CE600C@cbfiddle.com> Message-ID: <4665B012-582B-44E5-8864-4F6C2603BAAE@cbfiddle.com> I don?t think that is correct. There are issues with whether and how file names are normalized when stored in a directory, and the answers are file system dependent. File system lookups are described as normalization-insensitive. I?m not an expert, though, and it is hard to find decent up-to-date documentation on this matter. > On Jan 29, 2019, at 3:24 PM, Stuart Marks wrote: > > Hm, Martin had mentioned that macOS uses something more restrictive than UTF-8. It seems to me that a filesystem-specific encoding is called for here. From pavel.rappo at oracle.com Wed Jan 30 00:28:15 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 30 Jan 2019 00:28:15 +0000 Subject: RFR [13] 8218022: Repeated words typos in java.base (was: Duplicate words typos in comments/javadoc/strings) In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: Alan, Lance, I have created a webrev with the change: http://cr.openjdk.java.net/~prappo/8218022/webrev.00/ I added bonus fixes and updated the copyright years. If everybody is fine with this change, I'm pushing it. List of locations of additional fixes added to Andrey's patch: sun.net.www.http.HttpClient#HttpClient(java.net.URL, java.lang.String, int) jdk.internal.module.ServicesCatalog#create jdk.internal.platform.Metrics#getCpuSetMemoryPressure java.lang.invoke.MethodHandleNatives#linkMethod java.lang.LiveStackFrame#getStackWalker(java.util.Set) -Pavel P.S. I also added a missing '*' to the sun.security.util.ConstraintsParameters top level doc and removed the "on" preposition from the second sentence. The words seemed to be out of order: "on passed" instead of "passed on". It might look even better if we remove this preposition completely: ... * This is currently passed between PKIX, AlgorithmChecker, * and DisabledAlgorithmConstraints. */ public class ConstraintsParameters { From lance.andersen at oracle.com Wed Jan 30 00:54:11 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 29 Jan 2019 19:54:11 -0500 Subject: RFR [13] 8218022: Repeated words typos in java.base (was: Duplicate words typos in comments/javadoc/strings) In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: <68A4882E-ADEE-483A-BA72-B04872014CC3@oracle.com> Looks good Pavel :-) > On Jan 29, 2019, at 7:28 PM, Pavel Rappo wrote: > > Alan, Lance, > > I have created a webrev with the change: > > http://cr.openjdk.java.net/~prappo/8218022/webrev.00/ > > I added bonus fixes and updated the copyright years. If everybody is fine with > this change, I'm pushing it. > > List of locations of additional fixes added to Andrey's patch: > > sun.net.www.http.HttpClient#HttpClient(java.net.URL, java.lang.String, int) > jdk.internal.module.ServicesCatalog#create > jdk.internal.platform.Metrics#getCpuSetMemoryPressure > java.lang.invoke.MethodHandleNatives#linkMethod > java.lang.LiveStackFrame#getStackWalker(java.util.Set) > > -Pavel > > P.S. > > I also added a missing '*' to the sun.security.util.ConstraintsParameters top > level doc and removed the "on" preposition from the second sentence. The words > seemed to be out of order: "on passed" instead of "passed on". > > It might look even better if we remove this preposition completely: > > ... > * This is currently passed between PKIX, AlgorithmChecker, > * and DisabledAlgorithmConstraints. > */ > public class ConstraintsParameters { > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Jan 30 01:53:50 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 Jan 2019 17:53:50 -0800 Subject: RFR [13] 8218022: Repeated words typos in java.base In-Reply-To: References: <439D7F81-63D8-447B-AA23-E29CCBEF343B@oracle.com> <4783e9bc-2c76-0e4c-ff45-f8df61e6c2ed@oracle.com> <6DE3B8D5-93A5-4DCC-BE8E-D0B0181E5F78@oracle.com> Message-ID: On 1/29/19 4:28 PM, Pavel Rappo wrote: > Alan, Lance, > > I have created a webrev with the change: > > http://cr.openjdk.java.net/~prappo/8218022/webrev.00/ > Looks fine. Mandy From patrick at os.amperecomputing.com Wed Jan 30 04:32:28 2019 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Wed, 30 Jan 2019 04:32:28 +0000 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <365e969c-2677-0ffb-8ad8-76314556fe9c@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> <365e969c-2677-0ffb-8ad8-76314556fe9c@redhat.com> Message-ID: This is a nice patch as I found the same problem back to December. Privately I was using "(size + s > threshold)" condition for my cases, and found Michal's early comment that this would lead to "unwanted space allocation" caused by duplicate keys, thanks. Looking forward to having this in jdk/jdk trunk. Regards Patrick -----Original Message----- From: core-libs-dev On Behalf Of Michal Vala Sent: Tuesday, January 29, 2019 6:00 PM To: Martin Buchholz Cc: core-libs-dev Subject: Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() Hi Martin, I'd like to finish this review. Are you still willing to sponsor this? Thanks! On 1/9/19 11:39 AM, Michal Vala wrote: > ping > > On 1/3/19 9:31 PM, Michal Vala wrote: >> Hi Martin, >> >> can we please finish this review? >> >> On 12/19/18 6:32 PM, Michal Vala wrote: >>> >>> >>> On 12/19/18 4:15 PM, Martin Buchholz wrote: >>>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: >>>> >>>>> Hi Martin, >>>>> >>>>> It is also useful and conventional to print the seed of the random >>>>> so that if necessary it can be reproduced. >>>>> >>>> >>>> For many years, we've been using ThreadLocalRandom for testing, and >>>> that does not allow setting a seed. >>>> >>>> I remain unconvinced that saving a seed has value in the real >>>> world.? When a randomized test fails, running it with sufficient >>>> iterations has always worked for me. >>>> >>> >>> What's the reason behind using ThreadLocalRandom? >>> >>> In my opinion, reproducing the issue is key. One failure of >>> randomized test run might be caused by one issue, second run due to >>> another issue. How we reproduce then and how we know even how many >>> issues we have? When we're running random tests until it pass, it might even hide the issue. >>> >>> They sure have good value on reveal the issue, but then we have to >>> know how to reproduce and what we're searching for. >>> >>> If this case would not require ThreadLocalRandom and Random is >>> enough, I'd like to use that because of benefits I've mentioned. >>> >> > -- Michal Vala OpenJDK QE Red Hat Czech From naokikishida at gmail.com Wed Jan 30 07:37:48 2019 From: naokikishida at gmail.com (kishida naoki) Date: Wed, 30 Jan 2019 16:37:48 +0900 Subject: =?UTF-8?B?UmU6IFdpbGwgd2UgaGF2ZSBhbnkgb3B0aW9uIHRvIGZvcm1hdCAyMDE5IGFzIOWFg+WPtw==?= =?UTF-8?B?5YWD5bm0Pw==?= In-Reply-To: <61de0cc4-a004-3d2c-f667-81018700e709@oracle.com> References: <61de0cc4-a004-3d2c-f667-81018700e709@oracle.com> Message-ID: Hi Naoto-san, Thank you to introduce the workarounds! It's surprising that SimpleDateFormat have supportted Gannen :) 2019?1?30?(?) 1:22 Naoto Sato : > Hi Kishida-san, > > Currently we don't have a plan to support Gannen in java.time for > formatting/parsing Japanese calendar dates. Here are a couple of > workarounds: > > 1. Use java.text APIs to format/parse dates, e.g., > > jshell> new SimpleDateFormat("GGGGyyyy?", > Locale.forLanguageTag("ja-JP-u-ca-japanese")).format(new > Calendar.Builder().setDate(2019, Calendar.MAY, 1).build().getTime()) > $3 ==> "????" > > 2. For java.time API, use > DateTimeFormatterBuilder.appendText(TemporalField, Map) to > map the 1 to "?". Following issue demonstrates how to do it: > > https://bugs.openjdk.java.net/browse/JDK-8042131 > > HTH, > Naoto > > On 1/29/19 4:21 AM, kishida naoki wrote: > > As you know, Japanese government have a plan to change the era on May. > > It will be the first year of the new era. > > In practice, we describe the first year as "??" not as "1?" > > > > Now DateTimeFormatter with `G` output the era. > > `DateTimeFormatter.ofPattern("Gy?").format(JapaneseDate.of(2019, 5, 2))` > > output `??1?` > > > > Do you have any plan to have a option to format it as `????` or already > > implemented? > > > -- ??? ??? From peter.levart at gmail.com Wed Jan 30 08:22:34 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Jan 2019 09:22:34 +0100 Subject: Collectors.converting In-Reply-To: <21b6be97-6af4-f382-04a9-e5ee2d16cacc@oracle.com> References: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> <21b6be97-6af4-f382-04a9-e5ee2d16cacc@oracle.com> Message-ID: On 1/29/19 9:52 PM, Brian Goetz wrote: > How is this different from Collectors.collectingAndThen? Hi Brian, It is exactly the same! I'm sorry, I haven discovered that method when I needed it. Perhaps I was looking for another name? Regards, Peter > > On 1/29/2019 3:30 PM, Peter Levart wrote: >> Hi, >> >> I wonder if there's any interest in adding a convenience factory >> method for a Collector to the standard repertoire which would look >> like the following: >> >> ??? /** >> ???? * Convert given {@link Collector} so that it applies an >> additional finisher function that >> ???? * converts the result of given collector. The characteristics of >> returned collector is >> ???? * the same as that of the given inner collector but without any >> ???? * {@link >> java.util.stream.Collector.Characteristics#IDENTITY_FINISH}. >> ???? * >> ???? * @param collector?????? the inner collector to delegate >> collection to >> ???? * @param resultConverter the additional result finisher function >> ???? * @param ???????????? the type of input stream elements >> ???? * @param ???????????? the type of intermediate aggregation >> ???? * @param ???????????? the type of result of inner collector >> ???? * @param ??????????? the type of final result >> ???? * @return the converted collector >> ???? */ >> ??? public static Collector converting( >> ??????? Collector collector, >> ??????? Function resultConverter >> ??? ) { >> ??????? return new Collector() { >> ??????????? @Override >> ??????????? public Supplier supplier() { return >> collector.supplier(); } >> >> ??????????? @Override >> ??????????? public BiConsumer accumulator() { return >> collector.accumulator(); } >> >> ??????????? @Override >> ??????????? public BinaryOperator combiner() { return >> collector.combiner(); } >> >> ??????????? @Override >> ??????????? public Function finisher() { return >> resultConverter.compose(collector.finisher()); } >> >> ??????????? @Override >> ??????????? public Set characteristics() { >> ??????????????? EnumSet characteristics = >> EnumSet.noneOf(Characteristics.class); >> characteristics.addAll(collector.characteristics()); >> characteristics.remove(Characteristics.IDENTITY_FINISH); >> ??????????????? return Collections.unmodifiableSet(characteristics); >> ??????????? } >> ??????? }; >> ??? } >> >> >> The rationale is as follows... Composability of collectors allows >> doing things like: >> >> ??????? interface Measurement { >> ??????????? long value(); >> ??????????? String type(); >> ??????? } >> >> ??????? Stream measurements = .... >> >> ??????? Map statsByType = >> ??????????? measurements >> ??????????????? .collect( >> ??????????????????? groupingBy( >> ??????????????????????? Measurement::type, >> ??????????????????????? summarizingLong(Measurement::value) >> ??????????????????? ) >> ??????????????? ); >> >> ...but say I wanted the final result to be a map of avarage values by >> type and the values to be BigDecimal objects calculated with scale of >> 19. I can create an intermediate map like above and then transform it >> to new map, like this: >> >> ??????? static BigDecimal toBDAverage(LongSummaryStatistics stats) { >> ??????????? return BigDecimal.valueOf(stats.getSum()) >> ???????????????????????????? .divide( >> BigDecimal.valueOf(stats.getCount()), >> ???????????????????????????????? 20, RoundingMode.HALF_EVEN); >> ??????? } >> >> ??????? Map averageByType = >> ??????????? statsByType >> ??????????????? .entrySet() >> ??????????????? .stream() >> ??????????????? .collect(toMap(Map.Entry::getKey, e -> >> toBDAverage(e.getValue()))); >> >> ...this is ugly as it requires intermediate result to be materialized >> as a HashMap. Wouldn't it be possible to collect the original stream >> to final result in one go? >> >> With the above Collectors.converting factory method, it would: >> >> ??????? Map averageByType = >> ??????????? measurements >> ??????????????? .collect( >> ??????????????????? groupingBy( >> ??????????????????????? Measurement::type, >> ??????????????????????? converting( >> ??????????????????????????? summarizingLong(Measurement::value), >> ??????????????????????????? stats -> toBDAverage(stats) >> ??????????????????????? ) >> ??????????????????? ) >> ??????????????? ); >> >> We already have Collectors.mapping(Function, Collector) method that >> constructs Collector that maps elements to be collected by inner >> collector. Collectors.converting(Collectors, Function) would be a >> twin brother that constructs Collector that converts the collection >> result of the inner collector. Both are useful in compositions like >> above, but we only have the 1st... >> >> What do you think? >> >> Regards, Peter >> > From andy.herrick at oracle.com Wed Jan 30 13:27:06 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 30 Jan 2019 08:27:06 -0500 Subject: RFR: JDK-82177923: Modular jars in jpackage are not working Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). JDK-8217793 fixes the use of modular jars [1] https://bugs.openjdk.java.net/browse/JDK-8217793 [2] http://cr.openjdk.java.net/~herrick/8217793/webrev.01/ /Andy From adam.farley at uk.ibm.com Wed Jan 30 15:52:59 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 30 Jan 2019 15:52:59 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <3a218c0c-e02d-3e3e-317f-8572e56e81ea@oracle.com> References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Mandy, CSR has been raised: https://bugs.openjdk.java.net/browse/JDK-8218061 The webrev I used includes John's comments, your additions, the one-line-IF, and I also took the liberty of moving the unreflectField method underneath the unreflectSetter method, because it seemed strange that it was located between unreflectSetter and unreflectGetter. Online webrev has been updated to include these changes: http://cr.openjdk.java.net/~afarley/8216558/webrev Thoughts and comments, from you and others, are welcome as always. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 23/01/2019 19:18:09: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 23/01/2019 19:17 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > On 1/23/19 8:33 AM, Adam Farley8 wrote: > Hi Mandy, > > Food for thought: > > - From John's email, it looked like he was advocating a > clarification change to the spec (which requires no CSR). > > While the new behavior was intended when the spec was written, this > fix changes the current behavior and a CSR will be needed to > document the incompatible change. The current behavior of > unreflectSetter may return a MethodHandle of a static final Field > object with accessible flag set and then invoke MH to change the > static final field value. The new behavior of unreflectSetter > throws IAE as static final FIeld does not have write access. > > - * @throws IllegalAccessException if access checking fails > + * @throws IllegalAccessException if access checking fails, > + * or if the field is {@code final} and write access > + * is not enabled on the {@code Field} object > - A test case is attached to the bug. It displays "current > behaviour", but doesn't show a clear "pass" or "fail", because at > the start of this there appeared to be disagreement over what the > correct behaviour was. > > - Good idea on the new line. I'll add it to the webrev shortly. > > - As for the comments, I think I see what John was going for, but I > don't understand his first change. This seems to be the opposite of > what we're trying for here. > > + * In the case of a field setter function on a {@code final} field, > + * finality enforcement is treated as a kind of access control, > + * and the lookup will fail, except in special cases of > + * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. > > Perhaps he means it will still fail, but for the reasons we've > discussed rather than anything connected to access control? > > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8216558/webrev.01/ > > This webrev showing @throws change should show the spec > clarification on findSetter and findStaticSetter that throws IAE > when looking up a setter on a final field and the spec of > unreflectSetter states that it will return a method handle only if > the corresponding call to Field::set returns normally. This > webrev is not a review request but rather showing the fix we are > discussing here. > > Hope this clarifies it. > > Mandy Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.goetz at oracle.com Wed Jan 30 16:35:05 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 30 Jan 2019 11:35:05 -0500 Subject: Collectors.converting In-Reply-To: References: <97fd4aaa-df29-5fdb-95ab-df5a40839f6e@gmail.com> <21b6be97-6af4-f382-04a9-e5ee2d16cacc@oracle.com> Message-ID: <38556f2d-f209-ff5c-0a12-c411f922fa2b@oracle.com> Arguably, it could have been exposed as a default method on Collector (Collector::andThen) -- but we avoided this approach out of concern that a generic methods in receiver position can interact with type inference in ways that confuse people. On 1/30/2019 3:22 AM, Peter Levart wrote: > > > On 1/29/19 9:52 PM, Brian Goetz wrote: >> How is this different from Collectors.collectingAndThen? > > Hi Brian, > > It is exactly the same! > > I'm sorry, I haven discovered that method when I needed it. Perhaps I > was looking for another name? > > Regards, Peter > >> >> On 1/29/2019 3:30 PM, Peter Levart wrote: >>> Hi, >>> >>> I wonder if there's any interest in adding a convenience factory >>> method for a Collector to the standard repertoire which would look >>> like the following: >>> >>> ??? /** >>> ???? * Convert given {@link Collector} so that it applies an >>> additional finisher function that >>> ???? * converts the result of given collector. The characteristics >>> of returned collector is >>> ???? * the same as that of the given inner collector but without any >>> ???? * {@link >>> java.util.stream.Collector.Characteristics#IDENTITY_FINISH}. >>> ???? * >>> ???? * @param collector?????? the inner collector to delegate >>> collection to >>> ???? * @param resultConverter the additional result finisher function >>> ???? * @param ???????????? the type of input stream elements >>> ???? * @param ???????????? the type of intermediate aggregation >>> ???? * @param ???????????? the type of result of inner collector >>> ???? * @param ??????????? the type of final result >>> ???? * @return the converted collector >>> ???? */ >>> ??? public static Collector converting( >>> ??????? Collector collector, >>> ??????? Function resultConverter >>> ??? ) { >>> ??????? return new Collector() { >>> ??????????? @Override >>> ??????????? public Supplier supplier() { return >>> collector.supplier(); } >>> >>> ??????????? @Override >>> ??????????? public BiConsumer accumulator() { return >>> collector.accumulator(); } >>> >>> ??????????? @Override >>> ??????????? public BinaryOperator combiner() { return >>> collector.combiner(); } >>> >>> ??????????? @Override >>> ??????????? public Function finisher() { return >>> resultConverter.compose(collector.finisher()); } >>> >>> ??????????? @Override >>> ??????????? public Set characteristics() { >>> ??????????????? EnumSet characteristics = >>> EnumSet.noneOf(Characteristics.class); >>> characteristics.addAll(collector.characteristics()); >>> characteristics.remove(Characteristics.IDENTITY_FINISH); >>> ??????????????? return Collections.unmodifiableSet(characteristics); >>> ??????????? } >>> ??????? }; >>> ??? } >>> >>> >>> The rationale is as follows... Composability of collectors allows >>> doing things like: >>> >>> ??????? interface Measurement { >>> ??????????? long value(); >>> ??????????? String type(); >>> ??????? } >>> >>> ??????? Stream measurements = .... >>> >>> ??????? Map statsByType = >>> ??????????? measurements >>> ??????????????? .collect( >>> ??????????????????? groupingBy( >>> ??????????????????????? Measurement::type, >>> ??????????????????????? summarizingLong(Measurement::value) >>> ??????????????????? ) >>> ??????????????? ); >>> >>> ...but say I wanted the final result to be a map of avarage values >>> by type and the values to be BigDecimal objects calculated with >>> scale of 19. I can create an intermediate map like above and then >>> transform it to new map, like this: >>> >>> ??????? static BigDecimal toBDAverage(LongSummaryStatistics stats) { >>> ??????????? return BigDecimal.valueOf(stats.getSum()) >>> ???????????????????????????? .divide( >>> BigDecimal.valueOf(stats.getCount()), >>> ???????????????????????????????? 20, RoundingMode.HALF_EVEN); >>> ??????? } >>> >>> ??????? Map averageByType = >>> ??????????? statsByType >>> ??????????????? .entrySet() >>> ??????????????? .stream() >>> ??????????????? .collect(toMap(Map.Entry::getKey, e -> >>> toBDAverage(e.getValue()))); >>> >>> ...this is ugly as it requires intermediate result to be >>> materialized as a HashMap. Wouldn't it be possible to collect the >>> original stream to final result in one go? >>> >>> With the above Collectors.converting factory method, it would: >>> >>> ??????? Map averageByType = >>> ??????????? measurements >>> ??????????????? .collect( >>> ??????????????????? groupingBy( >>> ??????????????????????? Measurement::type, >>> ??????????????????????? converting( >>> summarizingLong(Measurement::value), >>> ??????????????????????????? stats -> toBDAverage(stats) >>> ??????????????????????? ) >>> ??????????????????? ) >>> ??????????????? ); >>> >>> We already have Collectors.mapping(Function, Collector) method that >>> constructs Collector that maps elements to be collected by inner >>> collector. Collectors.converting(Collectors, Function) would be a >>> twin brother that constructs Collector that converts the collection >>> result of the inner collector. Both are useful in compositions like >>> above, but we only have the 1st... >>> >>> What do you think? >>> >>> Regards, Peter >>> >> > From mandy.chung at oracle.com Wed Jan 30 18:22:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Jan 2019 10:22:40 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1356222530.1326669.1547212308746.JavaMail.zimbra@u-pem.fr> <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Adam, On 1/30/19 7:52 AM, Adam Farley8 wrote: > Hi Mandy, > > CSR has been raised: https://bugs.openjdk.java.net/browse/JDK-8218061 Thanks for doing it. A couple comments: I think the compatibility risk should be low rather than minimal. Even the code shouldn't be doing that, unreflectSetter does allow to set a static final field in the current implementation. It's low because Field::set throws exception if it's a static final field and so it's expected that very few existing libraries would use unreflectSetter. FWIW. There are few existing libraries hacking the reflection to change their static final fields but very few. Since the spec diff is small, I suggest to cut-n-paste the diff on the javadoc to the specification section and easier to see the spec change. webrev is not generally needed for CSR but welcome to include that if it helps the review. I made some minor edit to the CSR to make the problem and solution clearer. > The webrev I used includes John's comments, your additions, the > one-line-IF, > and I also took the liberty of moving the unreflectField method underneath > the unreflectSetter method, because it seemed strange that it was located > between unreflectSetter and unreflectGetter. > > Online webrev has been updated to include these changes: > http://cr.openjdk.java.net/~afarley/8216558/webrev Looks good but the patch still needs a regression test. Please include the regression test for code review. Formatting nit: a space is missing between 'if' and '(' and plase use the 4-space identation of the throw. 1901 if(isSetter && field.isStatic() && field.isFinal()) 1902 throw field.makeAccessException("static final field has no write access", this); Mandy From martinrb at google.com Wed Jan 30 20:23:58 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2019 12:23:58 -0800 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <4665B012-582B-44E5-8864-4F6C2603BAAE@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <8af9150c-c910-adb1-b539-36069739dc30@oracle.com> <44D0FDF6-73BB-42C7-ACCE-BF64F6CE600C@cbfiddle.com> <4665B012-582B-44E5-8864-4F6C2603BAAE@cbfiddle.com> Message-ID: Recommendations: - open source the moribund jni spec, perhaps as part of openjdk, so that people can improve it - Add Scare doc to anything that deals with Modified UTF-8 - Add a Charset so that Java code can explicitly encode to Modified UTF-8, despite being a bug magnet. - AFAIK the "jnu" utility native functions are not public - they contain useful stuff for efficiently converting between java char sequences and native strings, e.g. JNU_GetStringPlatformChars WITH_PLATFORM_STRING. Creating public versions of these might not be easy due to system differences, but it would be worthwhile. From andy.herrick at oracle.com Wed Jan 30 22:05:13 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 30 Jan 2019 17:05:13 -0500 Subject: RFR: JDK-8217792 : Investigate what modules are included Message-ID: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). JDK-8217792 : Investigate what modules are included For modules included in the runtime of a non-modular application, we now computes all modules that export an API as the root modules and compute their transitive closure, and do service binding.? As a result, by default you get all modules except 10 internal modules. For jre-installer (without --runtime-image option) we revert to including all modules. [1] https://bugs.openjdk.java.net/browse/JDK-8217792 [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ /Andy From alexander.matveev at oracle.com Wed Jan 30 22:16:01 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 30 Jan 2019 14:16:01 -0800 Subject: RFR: JDK-82177923: Modular jars in jpackage are not working In-Reply-To: References: Message-ID: <303ce297-96be-1f4e-df97-98354775681b@oracle.com> Hi Andy, Looks fine. Thanks, Alexander On 1/30/2019 5:27 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217793 fixes the use of modular jars > > [1] https://bugs.openjdk.java.net/browse/JDK-8217793 > > [2] http://cr.openjdk.java.net/~herrick/8217793/webrev.01/ > > /Andy > From mandy.chung at oracle.com Wed Jan 30 22:22:15 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Jan 2019 14:22:15 -0800 Subject: RFR: JDK-82177923: Modular jars in jpackage are not working In-Reply-To: References: Message-ID: On 1/30/19 5:27 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217793 fixes the use of modular jars > > [1] https://bugs.openjdk.java.net/browse/JDK-8217793 > > [2] http://cr.openjdk.java.net/~herrick/8217793/webrev.01/ It'd be good to have a regression test along with the fix. It's in a sandbox and of course no issue to add later but it's better to start adding regression tests to catch any regression in the future. Mandy From mandy.chung at oracle.com Wed Jan 30 22:24:52 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Jan 2019 14:24:52 -0800 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive In-Reply-To: References: Message-ID: On 1/24/19 8:14 AM, Daniel Fuchs wrote: > Hi, > > Please find below another test fix for: > > 8195716: BootstrapLoggerTest : Executor still alive > https://bugs.openjdk.java.net/browse/JDK-8195716 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/ Looks okay. This gets quite complicated to verify the executor gets GC'ed. It may be helpful to add a comment to describe the situation when a new one may be created. The test can convert to use StackWalker rather than Thread::getAllStackTraces and it can then filter with Class instance. Mandy From kevin.rushforth at oracle.com Wed Jan 30 22:33:13 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 30 Jan 2019 14:33:13 -0800 Subject: RFR: JDK-82177923: Modular jars in jpackage are not working In-Reply-To: <303ce297-96be-1f4e-df97-98354775681b@oracle.com> References: <303ce297-96be-1f4e-df97-98354775681b@oracle.com> Message-ID: Looks good to me, too. -- Kevin On 1/30/2019 2:16 PM, Alexander Matveev wrote: > Hi Andy, > > Looks fine. > > Thanks, > Alexander > > On 1/30/2019 5:27 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> JDK-8217793 fixes the use of modular jars >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217793 >> >> [2] http://cr.openjdk.java.net/~herrick/8217793/webrev.01/ >> >> /Andy >> > From alexander.matveev at oracle.com Wed Jan 30 22:40:14 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 30 Jan 2019 14:40:14 -0800 Subject: RFR: JDK-8217792 : Investigate what modules are included In-Reply-To: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> References: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> Message-ID: <9b84d5ea-70c8-ecd2-7749-794047651dcf@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8217792/webrev.03/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html Line 272: Did you mean "if" here? I think it should be changed back to "else if". Otherwise looks fine. Thanks, Alexander On 1/30/2019 2:05 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217792 : Investigate what modules are included > > For modules included in the runtime of a non-modular application, we > now computes all modules that export an API as the root modules and > compute their transitive closure, and do service binding.? As a > result, by default you get all modules except 10 internal modules. > > For jre-installer (without --runtime-image option) we revert to > including all modules. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217792 > > [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ > > /Andy > From kevin.rushforth at oracle.com Wed Jan 30 22:39:29 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 30 Jan 2019 14:39:29 -0800 Subject: RFR: JDK-8217792 : Investigate what modules are included In-Reply-To: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> References: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> Message-ID: <092020f2-d10d-1a10-c0fc-2b40dcb442bb@oracle.com> Looks good. -- Kevin On 1/30/2019 2:05 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217792 : Investigate what modules are included > > For modules included in the runtime of a non-modular application, we > now computes all modules that export an API as the root modules and > compute their transitive closure, and do service binding.? As a > result, by default you get all modules except 10 internal modules. > > For jre-installer (without --runtime-image option) we revert to > including all modules. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217792 > > [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ > > /Andy > From andy.herrick at oracle.com Wed Jan 30 23:17:31 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 30 Jan 2019 18:17:31 -0500 Subject: RFR: JDK-8217792 : Investigate what modules are included In-Reply-To: <9b84d5ea-70c8-ecd2-7749-794047651dcf@oracle.com> References: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> <9b84d5ea-70c8-ecd2-7749-794047651dcf@oracle.com> Message-ID: <0174fcae-ff6f-79b9-18c6-36983ed3bf88@oracle.com> yes - I will put the else back - no impact on functionality (both can't be true), but it reads better with the else, conforms to the coding style, and could be minutely faster. /Andy On 1/30/2019 5:40 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8217792/webrev.03/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html > > Line 272: Did you mean "if" here? I think it should be changed back to > "else if". > > Otherwise looks fine. > > Thanks, > Alexander > > On 1/30/2019 2:05 PM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> JDK-8217792 : Investigate what modules are included >> >> For modules included in the runtime of a non-modular application, we >> now computes all modules that export an API as the root modules and >> compute their transitive closure, and do service binding.? As a >> result, by default you get all modules except 10 internal modules. >> >> For jre-installer (without --runtime-image option) we revert to >> including all modules. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217792 >> >> [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ >> >> /Andy >> > From mandy.chung at oracle.com Wed Jan 30 23:46:09 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Jan 2019 15:46:09 -0800 Subject: RFR: JDK-8217792 : Investigate what modules are included In-Reply-To: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> References: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> Message-ID: <271609f0-71fe-b5dd-326b-c03af66a63d3@oracle.com> On 1/30/19 2:05 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217792 : Investigate what modules are included > > For modules included in the runtime of a non-modular application, we now > computes all modules that export an API as the root modules and compute > their transitive closure, and do service binding.? As a result, by > default you get all modules except 10 internal modules. > > For jre-installer (without --runtime-image option) we revert to > including all modules. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217792 > > [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ 368 ModuleFinder finder = ModuleFinder.ofSystem(); This means that you assume that the JMOD files used for linking is the same version as the system module path. This assumption is fine since jlink currently does not support linking a different version. You may want to add a comment if it helps. Mandy From andy.herrick at oracle.com Wed Jan 30 23:57:33 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 30 Jan 2019 18:57:33 -0500 Subject: RFR: JDK-8217792 : Investigate what modules are included In-Reply-To: <271609f0-71fe-b5dd-326b-c03af66a63d3@oracle.com> References: <8fe911da-feb1-5547-9c95-5bf17703cc66@oracle.com> <271609f0-71fe-b5dd-326b-c03af66a63d3@oracle.com> Message-ID: <6a19151f-1b10-2ed2-a155-0fda3b61aeb4@oracle.com> On 1/30/2019 6:46 PM, Mandy Chung wrote: > On 1/30/19 2:05 PM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> JDK-8217792 : Investigate what modules are included >> >> For modules included in the runtime of a non-modular application, we >> now computes all modules that export an API as the root modules and >> compute their transitive closure, and do service binding.? As a >> result, by default you get all modules except 10 internal modules. >> >> For jre-installer (without --runtime-image option) we revert to >> including all modules. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217792 >> >> [2] http://cr.openjdk.java.net/~herrick/8217792/webrev.03/ > > ?368???????? ModuleFinder finder = ModuleFinder.ofSystem(); > > This means that you assume that the JMOD files used for linking > is the same version as the system module path.? This assumption > is fine since jlink currently does not support linking a different > version. yes - this code is only used if building an app to run on the current jdk. (the jdk with jpackage in it.) When using --runtime-image , the whole runtime-image pointed to is included in the app, so we should be advising users to run jlink first to create a suitable runtime-image, or to otherwise provide a runtime image with only what their app might want. /Andy > > You may want to add a comment if it helps. > > Mandy From andy.herrick at oracle.com Thu Jan 31 00:01:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 30 Jan 2019 19:01:10 -0500 Subject: RFR: JDK-82177923: Modular jars in jpackage are not working In-Reply-To: References: Message-ID: <192cc29b-d3c8-2e3f-05f9-bdb0dc911526@oracle.com> On 1/30/2019 5:22 PM, Mandy Chung wrote: > > > On 1/30/19 5:27 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> JDK-8217793 fixes the use of modular jars >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217793 >> >> [2] http://cr.openjdk.java.net/~herrick/8217793/webrev.01/ > > It'd be good to have a regression test along with the fix. > It's in a sandbox and of course no issue to add later but > it's better to start adding regression tests to catch any > regression in the future. > > Mandy I will put this back to sandbox as is (without regression test for now) but I have added note in JDK-8213558 : "Create more unit and regression tests" to cover this case. /Andy From naoto.sato at oracle.com Thu Jan 31 00:35:59 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 30 Jan 2019 16:35:59 -0800 Subject: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11 Message-ID: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com> Hi, Please review the javadoc fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8216546 The CSR and the proposed changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8217938 http://cr.openjdk.java.net/~naoto/8216546/webrev.00/ This is a forward poring of the fix made in 11u release: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace The changeset has been modified from the original 11u one, in order to mandate the Japanese Era code point in all Java SE 12 implementations. Naoto From naoto.sato at oracle.com Thu Jan 31 00:51:22 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 30 Jan 2019 16:51:22 -0800 Subject: [12] RFR: 8217892: Clarify the support for the new Japanese era in java.time.chrono.JapaneseEra Message-ID: Hi, Please review the javadoc fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8217892 The CSR and the proposed changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8217939 http://cr.openjdk.java.net/~naoto/8217892/webrev.00/ This is a (effective) forward poring of the fix made in 11u release: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/75672ce3d004 Naoto From david.holmes at oracle.com Thu Jan 31 02:09:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 12:09:03 +1000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> Message-ID: Hi Jie, Roger, I think this has now consumed far too many cycles for everyone, dealing with a test that is checking for a leak that can't even exist any more. Alan was fine with the original proposed patch, as was I, so I think we can should proceed with that. Obviously there is more than one way to tackle the Xcomp problem here, and there will always be issues with any test relying on GC interaction, but the proposed patch seems "good enough" to me. Cheers, David On 29/01/2019 11:46 am, Jie Fu wrote: > Hi, > > I agree that the simplest way to fix the issue is just adding the > reachabilityFence. > But this patch might also fail since the VM doesn't guarantee that a GC > would be performed. > > I didn't make such patch since I've learned from Sergey and Alan that > calling "System.gc()" several times is unreliable to trigger a gc[1]. > So I still prefer the original one[2]. > > Thanks a lot. > > Best regards, > Jie > > [1] > https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html > [2] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html > > > > On 2019/1/28 ??11:39, Roger Riggs wrote: >> Hi, >> >> The simplest fix for this failing test is to add a call to >> reachabilityFence to prevent >> the loader and loaderRef from going out of scope early.? It maintains >> getting debug >> output on a failure. >> >> Offlist, Jie and I explored some alternate ways to write the test and >> settled on this one. >> >> Please review: >> >> diff --git >> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> >> --- >> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> >> +++ >> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >> >> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >> ???????????? if (dequeued == null) { >> ???????????????? System.err.println( >> -??????????????????? "TEST FAILED: loader not deteced weakly reachable"); >> +??????????????????? "TEST FAILED: loader not detected weakly >> reachable"); >> ???????????????? dumpThreads(); >> ???????????????? throw new RuntimeException( >> ???????????????????? "TEST FAILED: loader not detected weakly >> reachable"); >> ???????????? } >> +??????????? Reference.reachabilityFence(loader); >> +??????????? Reference.reachabilityFence(loaderRef); >> >> ???????????? System.err.println( >> ???????????????? "TEST PASSED: loader detected weakly reachable"); >> >> Thanks, Roger >> >> >> >> On 01/11/2019 07:25 PM, Jie Fu wrote: >>> Thanks David and Roger. >>> >>> >>> On 2019?01?12? 06:52, David Holmes wrote: >>>> Hi Roger, >>>> >>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> The proposed patch changes the test in a way that is unintended. >>>>> >>>>> Adding the infinite loop of gc() and sleep, will change the timeout >>>>> behavior >>>>> from the existing timeout of TIMEOUT to the jtreg default timeout >>>>> of the whole test. >>>> >>>> Partially true. If the new loop gets stuck then yes the jtreg >>>> default timeout will apply - I don't see that is necessarily a bad >>>> thing. The existing timeout only applies to the refQueue.remove >>>> operation itself, you don't know how much time was spent before you >>>> got there, nor how much will be spent after in the dumpThreads() >>>> calls - so the jtreg timeout can still come into affect. >>>> >>>>> Further, it renders the check at lines 114-120 irrelevant since >>>>> loaderRef.get() >>>>> will have returned null and the ref will have been enqueued by then. >>>> >>>> I wouldn't say irrelevant as it double-checks the interaction >>>> between the ref.get() and the queue.remove() - the result of one >>>> should imply the result of the other, but if enqueuing had a bug .... >>>> >>>>> While it is true that calling gc() only once is unreliable, a >>>>> better fix is to >>>>> put the code from 108-120 in a loop with a fixed number of durations >>>> >>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>> >>>>> and add Reachability.reachabilityFence(loaderRef) to ensure the ref >>>>> is not ignored. >>>> >>>> Adding ReachabilityFence, alone, may solve the observed problem >>>> given one gc() seems to be working in practice (and because we don't >>>> actually have the leaked loaders anymore because those threads >>>> (sun.misc.GC threads) don't exist anymore). >>>> >>>> Cheers, >>>> David >>>> >>>>> Regards, Roger >>> >>> >> > From fujie at loongson.cn Thu Jan 31 02:44:59 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 31 Jan 2019 10:44:59 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> Message-ID: <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> Hi David, I prefer the original patch[1]. Could you please sponsor this issue or help me find a sponsor. I really appreciate it. Thank you very much. Also thanks Roger. We had a pleasant discussion offlist. Best regards, Jie [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html On 2019/1/31 ??10:09, David Holmes wrote: > Hi Jie, Roger, > > I think this has now consumed far too many cycles for everyone, > dealing with a test that is checking for a leak that can't even exist > any more. Alan was fine with the original proposed patch, as was I, so > I think we can should proceed with that. Obviously there is more than > one way to tackle the Xcomp problem here, and there will always be > issues with any test relying on GC interaction, but the proposed patch > seems "good enough" to me. > > Cheers, > David > > On 29/01/2019 11:46 am, Jie Fu wrote: >> Hi, >> >> I agree that the simplest way to fix the issue is just adding the >> reachabilityFence. >> But this patch might also fail since the VM doesn't guarantee that a >> GC would be performed. >> >> I didn't make such patch since I've learned from Sergey and Alan that >> calling "System.gc()" several times is unreliable to trigger a gc[1]. >> So I still prefer the original one[2]. >> >> Thanks a lot. >> >> Best regards, >> Jie >> >> [1] >> https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html >> [2] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >> >> >> >> On 2019/1/28 ??11:39, Roger Riggs wrote: >>> Hi, >>> >>> The simplest fix for this failing test is to add a call to >>> reachabilityFence to prevent >>> the loader and loaderRef from going out of scope early.? It >>> maintains getting debug >>> output on a failure. >>> >>> Offlist, Jie and I explored some alternate ways to write the test >>> and settled on this one. >>> >>> Please review: >>> >>> diff --git >>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>> >>> --- >>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>> >>> +++ >>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>> >>> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >>> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >>> ???????????? if (dequeued == null) { >>> ???????????????? System.err.println( >>> -??????????????????? "TEST FAILED: loader not deteced weakly >>> reachable"); >>> +??????????????????? "TEST FAILED: loader not detected weakly >>> reachable"); >>> ???????????????? dumpThreads(); >>> ???????????????? throw new RuntimeException( >>> ???????????????????? "TEST FAILED: loader not detected weakly >>> reachable"); >>> ???????????? } >>> +??????????? Reference.reachabilityFence(loader); >>> +??????????? Reference.reachabilityFence(loaderRef); >>> >>> ???????????? System.err.println( >>> ???????????????? "TEST PASSED: loader detected weakly reachable"); >>> >>> Thanks, Roger >>> >>> >>> >>> On 01/11/2019 07:25 PM, Jie Fu wrote: >>>> Thanks David and Roger. >>>> >>>> >>>> On 2019?01?12? 06:52, David Holmes wrote: >>>>> Hi Roger, >>>>> >>>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> The proposed patch changes the test in a way that is unintended. >>>>>> >>>>>> Adding the infinite loop of gc() and sleep, will change the >>>>>> timeout behavior >>>>>> from the existing timeout of TIMEOUT to the jtreg default timeout >>>>>> of the whole test. >>>>> >>>>> Partially true. If the new loop gets stuck then yes the jtreg >>>>> default timeout will apply - I don't see that is necessarily a bad >>>>> thing. The existing timeout only applies to the refQueue.remove >>>>> operation itself, you don't know how much time was spent before >>>>> you got there, nor how much will be spent after in the >>>>> dumpThreads() calls - so the jtreg timeout can still come into >>>>> affect. >>>>> >>>>>> Further, it renders the check at lines 114-120 irrelevant since >>>>>> loaderRef.get() >>>>>> will have returned null and the ref will have been enqueued by then. >>>>> >>>>> I wouldn't say irrelevant as it double-checks the interaction >>>>> between the ref.get() and the queue.remove() - the result of one >>>>> should imply the result of the other, but if enqueuing had a bug .... >>>>> >>>>>> While it is true that calling gc() only once is unreliable, a >>>>>> better fix is to >>>>>> put the code from 108-120 in a loop with a fixed number of durations >>>>> >>>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>>> >>>>>> and add Reachability.reachabilityFence(loaderRef) to ensure the >>>>>> ref is not ignored. >>>>> >>>>> Adding ReachabilityFence, alone, may solve the observed problem >>>>> given one gc() seems to be working in practice (and because we >>>>> don't actually have the leaked loaders anymore because those >>>>> threads (sun.misc.GC threads) don't exist anymore). >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Regards, Roger >>>> >>>> >>> >> From david.holmes at oracle.com Thu Jan 31 02:59:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 12:59:27 +1000 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> Message-ID: <7c74daaa-7aff-ed22-8e93-64f64e462505@oracle.com> On 31/01/2019 12:44 pm, Jie Fu wrote: > Hi David, > > I prefer the original patch[1]. > > Could you please sponsor this issue or help me find a sponsor. > I really appreciate it. Thank you very much. Hopefully Roger will still sponsor this. Thanks, David > Also thanks Roger. We had a pleasant discussion offlist. > > Best regards, > Jie > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html > > > > On 2019/1/31 ??10:09, David Holmes wrote: >> Hi Jie, Roger, >> >> I think this has now consumed far too many cycles for everyone, >> dealing with a test that is checking for a leak that can't even exist >> any more. Alan was fine with the original proposed patch, as was I, so >> I think we can should proceed with that. Obviously there is more than >> one way to tackle the Xcomp problem here, and there will always be >> issues with any test relying on GC interaction, but the proposed patch >> seems "good enough" to me. >> >> Cheers, >> David >> >> On 29/01/2019 11:46 am, Jie Fu wrote: >>> Hi, >>> >>> I agree that the simplest way to fix the issue is just adding the >>> reachabilityFence. >>> But this patch might also fail since the VM doesn't guarantee that a >>> GC would be performed. >>> >>> I didn't make such patch since I've learned from Sergey and Alan that >>> calling "System.gc()" several times is unreliable to trigger a gc[1]. >>> So I still prefer the original one[2]. >>> >>> Thanks a lot. >>> >>> Best regards, >>> Jie >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html >>> >>> [2] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>> >>> >>> >>> On 2019/1/28 ??11:39, Roger Riggs wrote: >>>> Hi, >>>> >>>> The simplest fix for this failing test is to add a call to >>>> reachabilityFence to prevent >>>> the loader and loaderRef from going out of scope early.? It >>>> maintains getting debug >>>> output on a failure. >>>> >>>> Offlist, Jie and I explored some alternate ways to write the test >>>> and settled on this one. >>>> >>>> Please review: >>>> >>>> diff --git >>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>> >>>> --- >>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>> >>>> +++ >>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>> >>>> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >>>> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >>>> ???????????? if (dequeued == null) { >>>> ???????????????? System.err.println( >>>> -??????????????????? "TEST FAILED: loader not deteced weakly >>>> reachable"); >>>> +??????????????????? "TEST FAILED: loader not detected weakly >>>> reachable"); >>>> ???????????????? dumpThreads(); >>>> ???????????????? throw new RuntimeException( >>>> ???????????????????? "TEST FAILED: loader not detected weakly >>>> reachable"); >>>> ???????????? } >>>> +??????????? Reference.reachabilityFence(loader); >>>> +??????????? Reference.reachabilityFence(loaderRef); >>>> >>>> ???????????? System.err.println( >>>> ???????????????? "TEST PASSED: loader detected weakly reachable"); >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 01/11/2019 07:25 PM, Jie Fu wrote: >>>>> Thanks David and Roger. >>>>> >>>>> >>>>> On 2019?01?12? 06:52, David Holmes wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The proposed patch changes the test in a way that is unintended. >>>>>>> >>>>>>> Adding the infinite loop of gc() and sleep, will change the >>>>>>> timeout behavior >>>>>>> from the existing timeout of TIMEOUT to the jtreg default timeout >>>>>>> of the whole test. >>>>>> >>>>>> Partially true. If the new loop gets stuck then yes the jtreg >>>>>> default timeout will apply - I don't see that is necessarily a bad >>>>>> thing. The existing timeout only applies to the refQueue.remove >>>>>> operation itself, you don't know how much time was spent before >>>>>> you got there, nor how much will be spent after in the >>>>>> dumpThreads() calls - so the jtreg timeout can still come into >>>>>> affect. >>>>>> >>>>>>> Further, it renders the check at lines 114-120 irrelevant since >>>>>>> loaderRef.get() >>>>>>> will have returned null and the ref will have been enqueued by then. >>>>>> >>>>>> I wouldn't say irrelevant as it double-checks the interaction >>>>>> between the ref.get() and the queue.remove() - the result of one >>>>>> should imply the result of the other, but if enqueuing had a bug .... >>>>>> >>>>>>> While it is true that calling gc() only once is unreliable, a >>>>>>> better fix is to >>>>>>> put the code from 108-120 in a loop with a fixed number of durations >>>>>> >>>>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>>>> >>>>>>> and add Reachability.reachabilityFence(loaderRef) to ensure the >>>>>>> ref is not ignored. >>>>>> >>>>>> Adding ReachabilityFence, alone, may solve the observed problem >>>>>> given one gc() seems to be working in practice (and because we >>>>>> don't actually have the leaked loaders anymore because those >>>>>> threads (sun.misc.GC threads) don't exist anymore). >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Regards, Roger >>>>> >>>>> >>>> >>> > From Sergey.Bylokhov at oracle.com Thu Jan 31 03:02:03 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Jan 2019 19:02:03 -0800 Subject: Duplicate words typos in comments/javadoc/strings In-Reply-To: References: Message-ID: <7985d358-16e7-ec33-e0d9-7c6ad84bdf1a@oracle.com> Hi, Andrey. On 27/01/2019 14:35, Andrey Turbanov wrote: > I checked only java.base module and fixed problems there. Does it > makes sense to create patches to other modules too? You are welcome to make the similar changes in java.desktop module, please use these email alias awt-dev/2d-dev/swing-dev. -- Best regards, Sergey. From fujie at loongson.cn Thu Jan 31 03:12:42 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 31 Jan 2019 11:12:42 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: <7c74daaa-7aff-ed22-8e93-64f64e462505@oracle.com> References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> <7c74daaa-7aff-ed22-8e93-64f64e462505@oracle.com> Message-ID: Hi Roger, I really hope you can still sponsor this. Could you help me, please? Thanks again. Best regards, Jie On 2019/1/31 ??10:59, David Holmes wrote: > On 31/01/2019 12:44 pm, Jie Fu wrote: >> Hi David, >> >> I prefer the original patch[1]. >> >> Could you please sponsor this issue or help me find a sponsor. >> I really appreciate it. Thank you very much. > > Hopefully Roger will still sponsor this. > > Thanks, > David > >> Also thanks Roger. We had a pleasant discussion offlist. >> >> Best regards, >> Jie >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >> >> >> >> On 2019/1/31 ??10:09, David Holmes wrote: >>> Hi Jie, Roger, >>> >>> I think this has now consumed far too many cycles for everyone, >>> dealing with a test that is checking for a leak that can't even >>> exist any more. Alan was fine with the original proposed patch, as >>> was I, so I think we can should proceed with that. Obviously there >>> is more than one way to tackle the Xcomp problem here, and there >>> will always be issues with any test relying on GC interaction, but >>> the proposed patch seems "good enough" to me. >>> >>> Cheers, >>> David >>> >>> On 29/01/2019 11:46 am, Jie Fu wrote: >>>> Hi, >>>> >>>> I agree that the simplest way to fix the issue is just adding the >>>> reachabilityFence. >>>> But this patch might also fail since the VM doesn't guarantee that >>>> a GC would be performed. >>>> >>>> I didn't make such patch since I've learned from Sergey and Alan >>>> that calling "System.gc()" several times is unreliable to trigger a >>>> gc[1]. >>>> So I still prefer the original one[2]. >>>> >>>> Thanks a lot. >>>> >>>> Best regards, >>>> Jie >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html >>>> >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>>> >>>> >>>> >>>> On 2019/1/28 ??11:39, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> The simplest fix for this failing test is to add a call to >>>>> reachabilityFence to prevent >>>>> the loader and loaderRef from going out of scope early. It >>>>> maintains getting debug >>>>> output on a failure. >>>>> >>>>> Offlist, Jie and I explored some alternate ways to write the test >>>>> and settled on this one. >>>>> >>>>> Please review: >>>>> >>>>> diff --git >>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>> >>>>> --- >>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>> >>>>> +++ >>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>> >>>>> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >>>>> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >>>>> ???????????? if (dequeued == null) { >>>>> ???????????????? System.err.println( >>>>> -??????????????????? "TEST FAILED: loader not deteced weakly >>>>> reachable"); >>>>> +??????????????????? "TEST FAILED: loader not detected weakly >>>>> reachable"); >>>>> ???????????????? dumpThreads(); >>>>> ???????????????? throw new RuntimeException( >>>>> ???????????????????? "TEST FAILED: loader not detected weakly >>>>> reachable"); >>>>> ???????????? } >>>>> +??????????? Reference.reachabilityFence(loader); >>>>> +??????????? Reference.reachabilityFence(loaderRef); >>>>> >>>>> ???????????? System.err.println( >>>>> ???????????????? "TEST PASSED: loader detected weakly reachable"); >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> >>>>> On 01/11/2019 07:25 PM, Jie Fu wrote: >>>>>> Thanks David and Roger. >>>>>> >>>>>> >>>>>> On 2019?01?12? 06:52, David Holmes wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The proposed patch changes the test in a way that is unintended. >>>>>>>> >>>>>>>> Adding the infinite loop of gc() and sleep, will change the >>>>>>>> timeout behavior >>>>>>>> from the existing timeout of TIMEOUT to the jtreg default >>>>>>>> timeout of the whole test. >>>>>>> >>>>>>> Partially true. If the new loop gets stuck then yes the jtreg >>>>>>> default timeout will apply - I don't see that is necessarily a >>>>>>> bad thing. The existing timeout only applies to the >>>>>>> refQueue.remove operation itself, you don't know how much time >>>>>>> was spent before you got there, nor how much will be spent after >>>>>>> in the dumpThreads() calls - so the jtreg timeout can still come >>>>>>> into affect. >>>>>>> >>>>>>>> Further, it renders the check at lines 114-120 irrelevant since >>>>>>>> loaderRef.get() >>>>>>>> will have returned null and the ref will have been enqueued by >>>>>>>> then. >>>>>>> >>>>>>> I wouldn't say irrelevant as it double-checks the interaction >>>>>>> between the ref.get() and the queue.remove() - the result of one >>>>>>> should imply the result of the other, but if enqueuing had a bug >>>>>>> .... >>>>>>> >>>>>>>> While it is true that calling gc() only once is unreliable, a >>>>>>>> better fix is to >>>>>>>> put the code from 108-120 in a loop with a fixed number of >>>>>>>> durations >>>>>>> >>>>>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>>>>> >>>>>>>> and add Reachability.reachabilityFence(loaderRef) to ensure the >>>>>>>> ref is not ignored. >>>>>>> >>>>>>> Adding ReachabilityFence, alone, may solve the observed problem >>>>>>> given one gc() seems to be working in practice (and because we >>>>>>> don't actually have the leaked loaders anymore because those >>>>>>> threads (sun.misc.GC threads) don't exist anymore). >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Regards, Roger >>>>>> >>>>>> >>>>> >>>> >> From martinrb at google.com Thu Jan 31 03:15:21 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2019 19:15:21 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <365e969c-2677-0ffb-8ad8-76314556fe9c@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> <365e969c-2677-0ffb-8ad8-76314556fe9c@redhat.com> Message-ID: This one keeps bubbling to the very top of my todo stack, only to be pre-empted a minute later by some other task. On Tue, Jan 29, 2019 at 2:00 AM Michal Vala wrote: > Hi Martin, > > I'd like to finish this review. Are you still willing to sponsor this? > > Thanks! > > On 1/9/19 11:39 AM, Michal Vala wrote: > > ping > > > > On 1/3/19 9:31 PM, Michal Vala wrote: > >> Hi Martin, > >> > >> can we please finish this review? > >> > >> On 12/19/18 6:32 PM, Michal Vala wrote: > >>> > >>> > >>> On 12/19/18 4:15 PM, Martin Buchholz wrote: > >>>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs > wrote: > >>>> > >>>>> Hi Martin, > >>>>> > >>>>> It is also useful and conventional to print the seed of the random > >>>>> so that if necessary it can be reproduced. > >>>>> > >>>> > >>>> For many years, we've been using ThreadLocalRandom for testing, and > that > >>>> does not allow setting a seed. > >>>> > >>>> I remain unconvinced that saving a seed has value in the real world. > When > >>>> a randomized test fails, running it with sufficient iterations has > always > >>>> worked for me. > >>>> > >>> > >>> What's the reason behind using ThreadLocalRandom? > >>> > >>> In my opinion, reproducing the issue is key. One failure of randomized > test > >>> run might be caused by one issue, second run due to another issue. How > we > >>> reproduce then and how we know even how many issues we have? When > we're > >>> running random tests until it pass, it might even hide the issue. > >>> > >>> They sure have good value on reveal the issue, but then we have to > know how > >>> to reproduce and what we're searching for. > >>> > >>> If this case would not require ThreadLocalRandom and Random is enough, > I'd > >>> like to use that because of benefits I've mentioned. > >>> > >> > > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From peter.levart at gmail.com Thu Jan 31 07:28:06 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Jan 2019 08:28:06 +0100 Subject: possible problem with JNI GetStringUTFChars In-Reply-To: <5DF0F9DB-2C00-4D1C-8CB2-6F3869D0250F@cbfiddle.com> References: <54F283B2-F7C0-4AAA-9AC5-297182C6A1D5@cbfiddle.com> <14338fd0-ef3f-4a30-57a8-753710455da8@oracle.com> <55009932-9d3a-8866-1105-3b7665a300f3@oracle.com> <0B59C798-0922-4AE5-ACFC-309D13798BE6@cbfiddle.com> <5DF0F9DB-2C00-4D1C-8CB2-6F3869D0250F@cbfiddle.com> Message-ID: Hi Alan, On 1/26/19 8:38 PM, Alan Snyder wrote: > My usage of GetStringUTFChars was to pass a String as a parameter to a system call that takes a NUL-terminated UTF-8 string (a file path). Obviously, the system call does not accept strings containing NUL. I suspect this is a common case. > > Therefore, my needs would be met by a (new) primitive that returns UTF-8 and fails if the String contains NUL. I had similar needs when interfacing a native library and resorted to encoding the string in Java into a NUL terminated native ByteBuffer, which I then used in JNI code to obtain a pointer to native memory containing the encoded bytes. So I used ByteBuffer parameters in place where Strings would be passed to native methods... Regards, Peter From chris.hegarty at oracle.com Thu Jan 31 09:15:32 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 31 Jan 2019 09:15:32 +0000 Subject: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com> References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com> Message-ID: <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com> Naoto, > On 31 Jan 2019, at 00:35, naoto.sato at oracle.com wrote: > > ... > > https://bugs.openjdk.java.net/browse/JDK-8217938 > http://cr.openjdk.java.net/~naoto/8216546/webrev.00/ This looks good. Just a few very minor comments. 1) To be consistent can you please include the addition of the word ?conditions? to the following methods: ?... the following *conditions* is true:" isJavaIdentifierPart(char ch) isJavaIdentifierPart(int codePoint) isJavaLetter(char ch) isJavaIdentifierPart(char) 2) There was a small correction in isJavaIdentifierPart(int). Replace "the character" with "the code point" Thanks, -Chris. From chris.hegarty at oracle.com Thu Jan 31 09:19:06 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 31 Jan 2019 09:19:06 +0000 Subject: [12] RFR: 8217892: Clarify the support for the new Japanese era in java.time.chrono.JapaneseEra In-Reply-To: References: Message-ID: <88BA937B-34E9-4E58-9A27-5E4864C8F133@oracle.com> Naoto, > On 31 Jan 2019, at 00:51, naoto.sato at oracle.com wrote: > > .. > https://bugs.openjdk.java.net/browse/JDK-8217939 > http://cr.openjdk.java.net/~naoto/8217892/webrev.00/ The changes look good. Reviewed. -Chris. From adam.farley at uk.ibm.com Thu Jan 31 12:18:05 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 31 Jan 2019 12:18:05 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Mandy, I've made the changes to the webrev and uploaded the corrected version. I've also uploaded the zips in the csr and bug. As for the test, I have mentioned that the test is attached to the bug. I attached the same test to the CSR. Are you saying that the test supplied is not a suitable test? Please advise. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 30/01/2019 18:22:40: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 30/01/2019 18:22 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > On 1/30/19 7:52 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > CSR has been raised: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218061&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wVe5GwdYZTp4EVs77yXBcAfCyKsPsjBCVBjF0XjirEs&s=1DFz7ShyytN1Bj8a3YtRyTpwbT1Cn1o- > Jf-ec5OvF7w&e= > > Thanks for doing it. A couple comments: > > I think the compatibility risk should be low rather than minimal. > Even the code shouldn't be doing that, unreflectSetter does > allow to set a static final field in the current implementation. > It's low because Field::set throws exception if it's a static > final field and so it's expected that very few existing libraries > would use unreflectSetter. > > FWIW. There are few existing libraries hacking the reflection > to change their static final fields but very few. > > Since the spec diff is small, I suggest to cut-n-paste the diff > on the javadoc to the specification section and easier to see > the spec change. webrev is not generally needed for CSR but > welcome to include that if it helps the review. > > I made some minor edit to the CSR to make the problem and solution > clearer. > > > The webrev I used includes John's comments, your additions, the > > one-line-IF, > > and I also took the liberty of moving the unreflectField method underneath > > the unreflectSetter method, because it seemed strange that it was located > > between unreflectSetter and unreflectGetter. > > > > Online webrev has been updated to include these changes: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8216558_webrev&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wVe5GwdYZTp4EVs77yXBcAfCyKsPsjBCVBjF0XjirEs&s=0KYjj1f6lxz1DSEcK1UnPJ3ozG9- > VwiUx2-B_u9EaD0&e= > > Looks good but the patch still needs a regression test. Please > include the regression test for code review. > > Formatting nit: a space is missing between 'if' and '(' and > plase use the 4-space identation of the throw. > > 1901 if(isSetter && field.isStatic() && field.isFinal()) > 1902 throw field.makeAccessException("static final > field has no write access", this); > > Mandy > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From daniel.fuchs at oracle.com Thu Jan 31 14:56:59 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 31 Jan 2019 14:56:59 +0000 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive In-Reply-To: References: Message-ID: <42dc9622-1be0-8ed6-1813-b6101bb7ea3b@oracle.com> Hi Mandy, Thanks for the review. On 30/01/2019 22:24, Mandy Chung wrote: > Looks okay.? This gets quite complicated to verify the executor > gets GC'ed.? It may be helpful to add a comment to describe > the situation when a new one may be created. I have added some comments: http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.01 > The test can convert to use StackWalker rather than > Thread::getAllStackTraces and it can then filter with Class instance. I am not sure I see how the StackWalker could help here, a better idea - that you suggested to me when we talked would be to add more whitebox hooks to simplify the waiting logic in the test. I'd rather do that in a separate changeset though - and I have logged https://bugs.openjdk.java.net/browse/JDK-8218141 to track all the suggestions I have received so far. best regards -- daniel From Roger.Riggs at oracle.com Thu Jan 31 15:16:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 31 Jan 2019 10:16:14 -0500 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> <7c74daaa-7aff-ed22-8e93-64f64e462505@oracle.com> Message-ID: Pushed On 01/30/2019 10:12 PM, Jie Fu wrote: > Hi Roger, > > I really hope you can still sponsor this. > Could you help me, please? > Thanks again. > > Best regards, > Jie > > > On 2019/1/31 ??10:59, David Holmes wrote: >> On 31/01/2019 12:44 pm, Jie Fu wrote: >>> Hi David, >>> >>> I prefer the original patch[1]. >>> >>> Could you please sponsor this issue or help me find a sponsor. >>> I really appreciate it. Thank you very much. >> >> Hopefully Roger will still sponsor this. >> >> Thanks, >> David >> >>> Also thanks Roger. We had a pleasant discussion offlist. >>> >>> Best regards, >>> Jie >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>> >>> >>> >>> On 2019/1/31 ??10:09, David Holmes wrote: >>>> Hi Jie, Roger, >>>> >>>> I think this has now consumed far too many cycles for everyone, >>>> dealing with a test that is checking for a leak that can't even >>>> exist any more. Alan was fine with the original proposed patch, as >>>> was I, so I think we can should proceed with that. Obviously there >>>> is more than one way to tackle the Xcomp problem here, and there >>>> will always be issues with any test relying on GC interaction, but >>>> the proposed patch seems "good enough" to me. >>>> >>>> Cheers, >>>> David >>>> >>>> On 29/01/2019 11:46 am, Jie Fu wrote: >>>>> Hi, >>>>> >>>>> I agree that the simplest way to fix the issue is just adding the >>>>> reachabilityFence. >>>>> But this patch might also fail since the VM doesn't guarantee that >>>>> a GC would be performed. >>>>> >>>>> I didn't make such patch since I've learned from Sergey and Alan >>>>> that calling "System.gc()" several times is unreliable to trigger >>>>> a gc[1]. >>>>> So I still prefer the original one[2]. >>>>> >>>>> Thanks a lot. >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html >>>>> >>>>> [2] >>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>>>> >>>>> >>>>> >>>>> On 2019/1/28 ??11:39, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> The simplest fix for this failing test is to add a call to >>>>>> reachabilityFence to prevent >>>>>> the loader and loaderRef from going out of scope early. It >>>>>> maintains getting debug >>>>>> output on a failure. >>>>>> >>>>>> Offlist, Jie and I explored some alternate ways to write the test >>>>>> and settled on this one. >>>>>> >>>>>> Please review: >>>>>> >>>>>> diff --git >>>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>> >>>>>> --- >>>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>> >>>>>> +++ >>>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>> >>>>>> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >>>>>> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >>>>>> ???????????? if (dequeued == null) { >>>>>> ???????????????? System.err.println( >>>>>> -??????????????????? "TEST FAILED: loader not deteced weakly >>>>>> reachable"); >>>>>> +??????????????????? "TEST FAILED: loader not detected weakly >>>>>> reachable"); >>>>>> ???????????????? dumpThreads(); >>>>>> ???????????????? throw new RuntimeException( >>>>>> ???????????????????? "TEST FAILED: loader not detected weakly >>>>>> reachable"); >>>>>> ???????????? } >>>>>> +??????????? Reference.reachabilityFence(loader); >>>>>> +??????????? Reference.reachabilityFence(loaderRef); >>>>>> >>>>>> ???????????? System.err.println( >>>>>> ???????????????? "TEST PASSED: loader detected weakly reachable"); >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> >>>>>> On 01/11/2019 07:25 PM, Jie Fu wrote: >>>>>>> Thanks David and Roger. >>>>>>> >>>>>>> >>>>>>> On 2019?01?12? 06:52, David Holmes wrote: >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The proposed patch changes the test in a way that is unintended. >>>>>>>>> >>>>>>>>> Adding the infinite loop of gc() and sleep, will change the >>>>>>>>> timeout behavior >>>>>>>>> from the existing timeout of TIMEOUT to the jtreg default >>>>>>>>> timeout of the whole test. >>>>>>>> >>>>>>>> Partially true. If the new loop gets stuck then yes the jtreg >>>>>>>> default timeout will apply - I don't see that is necessarily a >>>>>>>> bad thing. The existing timeout only applies to the >>>>>>>> refQueue.remove operation itself, you don't know how much time >>>>>>>> was spent before you got there, nor how much will be spent >>>>>>>> after in the dumpThreads() calls - so the jtreg timeout can >>>>>>>> still come into affect. >>>>>>>> >>>>>>>>> Further, it renders the check at lines 114-120 irrelevant >>>>>>>>> since loaderRef.get() >>>>>>>>> will have returned null and the ref will have been enqueued by >>>>>>>>> then. >>>>>>>> >>>>>>>> I wouldn't say irrelevant as it double-checks the interaction >>>>>>>> between the ref.get() and the queue.remove() - the result of >>>>>>>> one should imply the result of the other, but if enqueuing had >>>>>>>> a bug .... >>>>>>>> >>>>>>>>> While it is true that calling gc() only once is unreliable, a >>>>>>>>> better fix is to >>>>>>>>> put the code from 108-120 in a loop with a fixed number of >>>>>>>>> durations >>>>>>>> >>>>>>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>>>>>> >>>>>>>>> and add Reachability.reachabilityFence(loaderRef) to ensure >>>>>>>>> the ref is not ignored. >>>>>>>> >>>>>>>> Adding ReachabilityFence, alone, may solve the observed problem >>>>>>>> given one gc() seems to be working in practice (and because we >>>>>>>> don't actually have the leaked loaders anymore because those >>>>>>>> threads (sun.misc.GC threads) don't exist anymore). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> Regards, Roger >>>>>>> >>>>>>> >>>>>> >>>>> >>> > From naoto.sato at oracle.com Thu Jan 31 17:07:45 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 31 Jan 2019 09:07:45 -0800 Subject: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com> References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com> <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com> Message-ID: <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com> Hi Chris, Thank you for the comments. I updated the CSR and the webrev: https://bugs.openjdk.java.net/browse/JDK-8217938 https://cr.openjdk.java.net/~naoto/8216546/webrev.01/ Naoto On 1/31/19 1:15 AM, Chris Hegarty wrote: > Naoto, > >> On 31 Jan 2019, at 00:35, naoto.sato at oracle.com wrote: >> >> ... >> >> https://bugs.openjdk.java.net/browse/JDK-8217938 >> http://cr.openjdk.java.net/~naoto/8216546/webrev.00/ > > This looks good. Just a few very minor comments. > > 1) To be consistent can you please include the addition of the > word ?conditions? to the following methods: > > ?... the following *conditions* is true:" > > isJavaIdentifierPart(char ch) > isJavaIdentifierPart(int codePoint) > isJavaLetter(char ch) > isJavaIdentifierPart(char) > > 2) There was a small correction in isJavaIdentifierPart(int). > > Replace "the character" with "the code point" > > Thanks, > -Chris. > From chris.hegarty at oracle.com Thu Jan 31 17:36:12 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 31 Jan 2019 17:36:12 +0000 Subject: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11 In-Reply-To: <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com> References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com> <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com> <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com> Message-ID: > On 31 Jan 2019, at 17:07, Naoto Sato wrote: > > Hi Chris, > > Thank you for the comments. I updated the CSR and the webrev: > > https://bugs.openjdk.java.net/browse/JDK-8217938 > https://cr.openjdk.java.net/~naoto/8216546/webrev.01/ Thanks Naoto. Reviewed. -Chris From mandy.chung at oracle.com Thu Jan 31 18:27:14 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Jan 2019 10:27:14 -0800 Subject: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive In-Reply-To: <42dc9622-1be0-8ed6-1813-b6101bb7ea3b@oracle.com> References: <42dc9622-1be0-8ed6-1813-b6101bb7ea3b@oracle.com> Message-ID: <862fb222-009a-708a-54fd-c43afc0e547e@oracle.com> On 1/31/19 6:56 AM, Daniel Fuchs wrote: > > I have added some comments: > http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.01 +1 Mandy From mandy.chung at oracle.com Thu Jan 31 18:58:25 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Jan 2019 10:58:25 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: <85b88a8c-0925-25ff-dedb-2ec3d588c841@oracle.com> On 1/31/19 4:18 AM, Adam Farley8 wrote: > Hi Mandy, > > I've made the changes to the webrev and uploaded the corrected version. > > I've also uploaded the zips in the csr and bug. > > As for the test, I have mentioned that the test is attached to the bug. > I attached the same test to the CSR. I did look at that but it's not a jtreg regression test. I assume you planned to convert it to jtreg test. Anyway, the test attached in the bug report is the reproducer of the bug. It would help the reviewer to include the regression test in the webrev along with the fix unless a test is not necessary. The OpenJDK developer guide gives a pretty good overview on the process [1] and please do ask if you have any question. http://openjdk.java.net/guide/changePlanning.html#bug > Are you saying that the test supplied is not a suitable test? TestStaticFinal.java is a standalone test. It needs to convert to a jtreg regression test. The regression should throw an exception if Lookup::unreflectSetter returns MH on a static final field with and without accessible flag set. However TestStaticFinal.java also exits with 0. The regression test should pass with your bug and fail without the fix (throwing an exception). This test verifies unreflectSetter on a static final field. I suggest it also includes a case with instance final field with and without accessible flag set to show the exception for unreflectSetter what case allows setting final fields. Mandy [1] http://openjdk.java.net/guide/changePlanning.html#bug P.S. should be updated to refer to CSR that replaced CCC. From huizhe.wang at oracle.com Thu Jan 31 19:18:20 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 31 Jan 2019 11:18:20 -0800 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used Message-ID: <5C5349FC.2070001@oracle.com> Please review a cleanup of an unused class. All core and xml tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8186321 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ Thanks, Joe From lance.andersen at oracle.com Thu Jan 31 19:29:46 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 31 Jan 2019 14:29:46 -0500 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used In-Reply-To: <5C5349FC.2070001@oracle.com> References: <5C5349FC.2070001@oracle.com> Message-ID: <0BC3020B-3716-44A7-B5FB-FA996E47A7EC@oracle.com> +1 > On Jan 31, 2019, at 2:18 PM, Joe Wang wrote: > > Please review a cleanup of an unused class. All core and xml tests passed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186321 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Thu Jan 31 19:30:40 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 31 Jan 2019 11:30:40 -0800 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used In-Reply-To: <5C5349FC.2070001@oracle.com> References: <5C5349FC.2070001@oracle.com> Message-ID: <0774F5AD-8A3A-4A63-9F9E-61188F6B9A3B@oracle.com> Hi Joe, It looks like lines 65-66 of src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncDoclocation.java can go away as well: // int owner = dtm.getDocument(); // fileLocation = xctxt.getSourceTreeManager().findURIFromDoc(owner); Thanks, Brian > On Jan 31, 2019, at 11:18 AM, Joe Wang wrote: > > Please review a cleanup of an unused class. All core and xml tests passed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186321 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ From huizhe.wang at oracle.com Thu Jan 31 20:01:41 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 31 Jan 2019 12:01:41 -0800 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used In-Reply-To: <0774F5AD-8A3A-4A63-9F9E-61188F6B9A3B@oracle.com> References: <5C5349FC.2070001@oracle.com> <0774F5AD-8A3A-4A63-9F9E-61188F6B9A3B@oracle.com> Message-ID: <5C535425.7040206@oracle.com> On 1/31/19, 11:30 AM, Brian Burkhalter wrote: > Hi Joe, > > It looks like lines 65-66 of > src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncDoclocation.java > can go away as well: > > // int owner = dtm.getDocument(); > // fileLocation = > xctxt.getSourceTreeManager().findURIFromDoc(owner); Done. Updated the webrev with the addition of FuncDoclocation: http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ Thanks, Joe > > Thanks, > > Brian > >> On Jan 31, 2019, at 11:18 AM, Joe Wang > > wrote: >> >> Please review a cleanup of an unused class. All core and xml tests >> passed. >> >> JBS:https://bugs.openjdk.java.net/browse/JDK-8186321 >> webrevs:http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ >> > From brian.burkhalter at oracle.com Thu Jan 31 20:02:24 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 31 Jan 2019 12:02:24 -0800 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used In-Reply-To: <5C535425.7040206@oracle.com> References: <5C5349FC.2070001@oracle.com> <0774F5AD-8A3A-4A63-9F9E-61188F6B9A3B@oracle.com> <5C535425.7040206@oracle.com> Message-ID: <3CD75FFA-D031-438E-A9BA-B34433D82655@oracle.com> +1 Thanks, Brian > On Jan 31, 2019, at 12:01 PM, Joe Wang wrote: > > Done. > > Updated the webrev with the addition of FuncDoclocation: > http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ From huizhe.wang at oracle.com Thu Jan 31 22:58:02 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 31 Jan 2019 14:58:02 -0800 Subject: RFR (JDK 13/java.xml) 8186321: Cleanup: SourceTreeManager not used In-Reply-To: <3CD75FFA-D031-438E-A9BA-B34433D82655@oracle.com> References: <5C5349FC.2070001@oracle.com> <0774F5AD-8A3A-4A63-9F9E-61188F6B9A3B@oracle.com> <5C535425.7040206@oracle.com> <3CD75FFA-D031-438E-A9BA-B34433D82655@oracle.com> Message-ID: <5C537D7A.1000608@oracle.com> Thanks Brian, Lance! Changeset was pushed. -Joe On 1/31/19, 12:02 PM, Brian Burkhalter wrote: > +1 > > Thanks, > > Brian > >> On Jan 31, 2019, at 12:01 PM, Joe Wang > > wrote: >> >> Done. >> >> Updated the webrev with the addition of FuncDoclocation: >> http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/ >