From jonathan.gibbons at oracle.com Tue Aug 1 20:22:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 01 Aug 2017 13:22:31 -0700 Subject: RFR: JDK-8185669: Doc issues in assorted small jdk.* modules Message-ID: <5980E307.9080906@oracle.com> Please review another small set of doc fixes in some minor jdk.* modules. JBS: https://bugs.openjdk.java.net/browse/JDK-8185669 Webrev: http://cr.openjdk.java.net/~jjg/8185669/webrev.00/ -- Jon From brian.burkhalter at oracle.com Tue Aug 1 20:42:41 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Aug 2017 13:42:41 -0700 Subject: RFR: JDK-8185669: Doc issues in assorted small jdk.* modules In-Reply-To: <5980E307.9080906@oracle.com> References: <5980E307.9080906@oracle.com> Message-ID: <32F8C0EC-DAC8-4C05-9B38-8570B4354069@oracle.com> Hi Jon, From what I recall of similar previous table changes this looks fine but I did not verify the actual HTML. Brian On Aug 1, 2017, at 1:22 PM, Jonathan Gibbons wrote: > Please review another small set of doc fixes in some minor jdk.* modules. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185669 > Webrev: http://cr.openjdk.java.net/~jjg/8185669/webrev.00/ > > -- Jon From jonathan.gibbons at oracle.com Tue Aug 1 20:45:22 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 01 Aug 2017 13:45:22 -0700 Subject: RFR: JDK-8185669: Doc issues in assorted small jdk.* modules In-Reply-To: <32F8C0EC-DAC8-4C05-9B38-8570B4354069@oracle.com> References: <5980E307.9080906@oracle.com> <32F8C0EC-DAC8-4C05-9B38-8570B4354069@oracle.com> Message-ID: <5980E862.8000901@oracle.com> Hi Brian, Thanks. For all of these fixes, I'm running the docs through tidy and other checkers, including an accessibility checker. -- Jon On 08/01/2017 01:42 PM, Brian Burkhalter wrote: > Hi Jon, > > From what I recall of similar previous table changes this looks fine but I did not verify the actual HTML. > > Brian > > On Aug 1, 2017, at 1:22 PM, Jonathan Gibbons wrote: > >> Please review another small set of doc fixes in some minor jdk.* modules. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8185669 >> Webrev: http://cr.openjdk.java.net/~jjg/8185669/webrev.00/ >> >> -- Jon From chris.hegarty at oracle.com Tue Aug 1 21:42:02 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Aug 2017 14:42:02 -0700 Subject: RFR: JDK-8185669: Doc issues in assorted small jdk.* modules In-Reply-To: <5980E307.9080906@oracle.com> References: <5980E307.9080906@oracle.com> Message-ID: <97894F6B-C7CA-4A04-AA0E-F7DD0D88BBD2@oracle.com> > On 1 Aug 2017, at 13:22, Jonathan Gibbons wrote: > > Please review another small set of doc fixes in some minor jdk.* modules. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185669 > Webrev: http://cr.openjdk.java.net/~jjg/8185669/webrev.00/ Thank you Jon, looks good. -Chris. From mandy.chung at oracle.com Wed Aug 2 03:05:20 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Aug 2017 20:05:20 -0700 Subject: Review Request: JDK-8185541: Add back test cases for resource lookup from bootclasspath Message-ID: <2DDDC881-D8DE-47DE-9D99-B8BC7D702A76@oracle.com> This patch adds back the test cases that were added for JDK-6760902 but later were removed by JDK-8142968. Those test cases are useful and converted to use -Xbootclasspath/a. Webrev at: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8185541/webrev.00/ Mandy From mandy.chung at oracle.com Wed Aug 2 05:31:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Aug 2017 22:31:58 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <4506356.BY5Vv2ZSov@logoutik> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> <4506356.BY5Vv2ZSov@logoutik> Message-ID: <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> > On Jul 27, 2017, at 2:07 AM, Jaroslav Tulach wrote: > >> One consideration might be to separate the JVMCI MBean provider in its own >> module so that it?s registered only when such module is resolved in the >> module graph. This way JVMCI can work even if java.management is not >> present. > > Yes, I can create something like jdk.internal.vm.ci.management and move the > JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's > suggestion, if I remember correctly) there. This module would have dependency > on jdk.internal.vm.ci and java.management and bridge them together. > > How do I make sure this module is enabled when possible? Or is that automatic? > Service binding will resolve a service provider module during resolution. In other words, if java.management is in the resolved graph, any modules providing the services it uses will be added to the graph. >>>> Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? >>> >>> Anything in Lab?s Graal compiler is destined for JDK Graal so the >>> distinction is only temporary at best. >> Good to know. > > The bean is in there and implements DynamicMBean interface. E.g. this part of > Graal compiler module has to have dependency on java.management - that means > to make that dependency optional or split the module in two, I assume. This is Graal-specific MBean. It doesn?t seem that it must be registered as ?platform mbean? which has to implement PlatformManagedObject. Graal can register the MBean at runtime when java.management is present by calling ManagementFactory.getPlatformMBeanServer().registerMBean method. That seems to be a better alternative. Separating the MBean in a different module would still be applicable. Mandy From ivan.gerasimov at oracle.com Wed Aug 2 06:56:54 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 1 Aug 2017 23:56:54 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Thank you Peter for sharing your thoughts and experiments! On 7/29/17 10:22 AM, Peter Levart wrote: > Hi Ivan, > > On 07/28/2017 06:25 PM, Ivan Gerasimov wrote: >> >> Hi Peter! >> >> Thank a lot for looking into this! >> >> On 7/28/17 7:32 AM, Peter Levart wrote: >>> Hi Ivan, >>> >>> In the light of what Stuart Marks wrote, then what do you think >>> about a parameterized comparator (would be sub-optimal, I know) >>> where one would supply >>> 2 Comparator(s) which would be used to compare Ax and Nx >>> sub-sequences respectively as described below... >>> >> Yes. Inspired by what Stuart suggested I made a draft of such a >> comparator (see below). >> It works, but as you've said it's not that efficient (mostly due to >> expensive substrings) and a bit harder to use in a simple case. >> Now I need to think about how to combine two approaches. > > There is a bug in MyComparator. Comparing "1" with "2" gives 0 > (equal). You must not return "equal" when both alpha prefixes are empty. > Yes, you're right. Should have checked the length of numerical substrings, or just use a separate method for end-of-sequence. >> >>> For Nx sub-sequences, one would need a comparator comparing the >>> reversed sequence lexicographically, >> I'm not sure I understand why they need to be reversed. > > Scrap that. I got confused. :-o > >>> but for Ax sub-sequences, one could choose from a plethora of >>> case-(in)sensitive comparator(s) and collators already available on >>> the platform. >>> >> Yes. In the example below I used compareToIgnoreCase to compare alpha >> subsequences. > ... >> Arrays.sort(str,new >> MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo))); > Substrings are by copy. There is another approach. Originally you > created the NumericComparator to compare CharSequence(s) - not > String(s) as you did with MyComparator. So why not keeping that? Well, it was mostly for illustrative purposes. Of course the final code should deal with CharSequences, not Strings for generality. However, I assume that in most cases this comparator will need to work with Strings, and it's important to remember that String.subSequence() is as expensive as String.substring() [1] [1] http://docs.oracle.com/javase/8/docs/api/java/lang/String.html#subSequence-int-int- > While talking about types, you don't need to have a generic parameter: > NumericComparator implements > CharSequence simple: NumericComparator implements > Comparator is suitable for comparing any subtype of > CharSequence as use-sites should accept Comparator or > Comparator. But it wouldn't work in a case you need to pass the comparator to a function of form fun(Comparator cmp). > For example: Stream sorted(Comparator comparator); > You can use Comparator to sort Stream as well as > Stream or Stream... I tried an approach > where sub-sequences are CharSequence objects by delegation and use > sub-comparators that don't convert CharSequence(s) to String(s). > Here's what this looks like: > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/AlphadecimalComparator.java > with supporting sub-comparator classes: > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/CharSequenceComparator.java > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/DecimalComparator.java > I created a JMH benchmark comparing your 02/webrev > (ivan.NumericComparator): > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/NumericComparator.java > with a modified variant of your MyComparator that works correctly > (ivan.MyComparator): > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/MyComparator.java > and my (peter.AlphadecimalComparator). The later two are tested with > case-sensitive (CS) and case-insensitive (CIS) variants for comparing > alpha sub-sequences. Here are the results: > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_speed.txt > With -prof gc, it can be seen that JIT is able to optimize-away > allocation of sub-sequence CharSequence(s). When the hot code is > JIT-ed, at least with provided helper sub-comparators, no allocation > is taking place (not so with MyComparator which creates substrings): > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_gc.txt That's a very good news then! > The performance of AlphadecimalComparator is about 50% slower than > your specialized NumericComparator, but it allows custom > parametrization. Perhaps the decimal part of variations could be > hidden behind a boolean or an enum parameter (there is a > leading-zeroes-greater, leading-zeroes-less, but also a > leading-zeroes-equal variant that makes sense). I tried to do that by > making DecimalComparator an enum and restricting the decimalComparato > parameter to that type, but maybe specializing code around a boolean > flag might yield better performance and DecimalComparator as > Comparator doesn't make much sense outside the > AlphadecimalComparator. So what do you think? Also, what do you think > about the name? Regards, Peter I've tried to go one step further and created even more abstract comparator: It uses a supplied predicate to decompose the input sequences into odd/even subsequences (e.g. alpha/numeric) and then uses two separate comparator to compare them. Additionally, a comparator for comparing sequences, consisting only of digits is provided. For example, to build a case-insensitive AlphaDecimal comparator one could use: 1) Character::isDigit -- as the predicate for decomposing, 2) String::compareToIgnoreCase -- to compare alpha (i.e. odd parts); to work with CharSequences one would need to make it Comparator.comparing(CharSequence::toString, String::compareToIgnoreCase), 3) The special decimal-only comparator, which compares the decimal representation of the sequences. Here's the file with all the comparators and a simple test: http://cr.openjdk.java.net/~igerasim/8134512/test/Test.java -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Wed Aug 2 06:58:57 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 1 Aug 2017 23:58:57 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: <0ff5a49c-e881-4430-be47-ec46e4de0d6e@oracle.com> On 7/28/17 12:16 PM, Jonathan Bluett-Duncan wrote: > Hi Ivan, > > It looks like the MyComparator code example which you gave in your > last email lost its formatting along the way, so I'm finding it > difficult to read. Would you mind resubmitting it? > Oh, sorry about that. I've just uploaded another modification of the comparator here: http://cr.openjdk.java.net/~igerasim/8134512/test/Test.java With kind regards, Ivan > Cheers, > Jonathan > > On 28 July 2017 at 17:25, Ivan Gerasimov > wrote: > > Hi Peter! > > Thank a lot for looking into this! > > On 7/28/17 7:32 AM, Peter Levart wrote: > > Hi Ivan, > > In the light of what Stuart Marks wrote, then what do you > think about a parameterized comparator (would be sub-optimal, > I know) where one would supply > 2 Comparator(s) which would be used to compare Ax and Nx > sub-sequences respectively as described below... > > Yes. Inspired by what Stuart suggested I made a draft of such a > comparator (see below). > It works, but as you've said it's not that efficient (mostly due > to expensive substrings) and a bit harder to use in a simple case. > Now I need to think about how to combine two approaches. > > For Nx sub-sequences, one would need a comparator comparing > the reversed sequence lexicographically, > > I'm not sure I understand why they need to be reversed. > > but for Ax sub-sequences, one could choose from a plethora of > case-(in)sensitive comparator(s) and collators already > available on the platform. > > Yes. In the example below I used compareToIgnoreCase to compare > alpha subsequences. > > ------- > > class MyComparator implements Comparator > {Comparator alphaCmp;Comparator > numCmp;MyComparator(Comparator alphaCmp,Comparator > numCmp) {this.alphaCmp = alphaCmp;this.numCmp = numCmp;}boolean > skipLeadingZeroes(String s, int len) {for (int i = 0; i < len ; > ++i) {if (Character.digit(s.charAt(i), 10) != 0)return > false;}return true;}@Override public int compare(String o1, String > o2) {Supplier s1 = new NumberSlicer(o1);Supplier > s2 = new NumberSlicer(o2);while (true) {// alpha part String ss1 = > s1.get();String ss2 = s2.get();int cmp = alphaCmp.compare(ss1, > ss2);if (cmp != 0) return cmp;if (ss1.length() == 0) return 0;// > numeric part ss1 = s1.get();ss2 = s2.get();int len1 = > ss1.length();int len2 = ss2.length();int dlen = len1 - len2;if > (dlen > 0) {if (!skipLeadingZeroes(ss1, dlen))return 1;ss1 = > ss1.substring(dlen, len1);} else if (dlen < 0) {if > (!skipLeadingZeroes(ss2, -dlen))return -1;ss2 = > ss2.substring(-dlen, len2);}cmp = numCmp.compare(ss1, ss2);if (cmp > != 0) return cmp;if (dlen != 0) return dlen;}}static class > NumberSlicer implements Supplier {private String > sequence;private boolean expectNumber = false;private int index = > 0;NumberSlicer(String s) {sequence = s;}@Override public String > get() {int start = index, end = start, len = sequence.length() - > start;for (; len > 0; ++end, --len) {if > (Character.isDigit(sequence.ch arAt(end)) ^ > expectNumber)break;}expectNumber = !expectNumber;return > sequence.substring(start, index = end);}}}------------Here how it > is invoked with case-insensitive comparator:Arrays.sort(str,new > MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo)));------------ > > simple test results for case insensitive sorting:java 1java 1 > javajava 1 JAVAJava 2JAVA 5jaVA 6.1java 10java 10 v 13Java 10 v > 013Java 10 v 000013java 10 v 113Java 2017Java 2017Java 20017Java > 200017Java 2000017Java 20000017Java 20000017Java 200000017With > kind regards, Ivan > > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Wed Aug 2 13:52:56 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Aug 2017 06:52:56 -0700 Subject: Review Request: JDK-8185541: Add back test cases for resource lookup from bootclasspath In-Reply-To: <2DDDC881-D8DE-47DE-9D99-B8BC7D702A76@oracle.com> References: <2DDDC881-D8DE-47DE-9D99-B8BC7D702A76@oracle.com> Message-ID: <8074f7b5-7bbb-e7f8-448f-7f4b2b1f030b@oracle.com> On 01/08/2017 20:05, Mandy Chung wrote: > This patch adds back the test cases that were added for JDK-6760902 but > later were removed by JDK-8142968. Those test cases are useful and converted > to use -Xbootclasspath/a. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8185541/webrev.00/ > Looks good to me. -Alan From jaroslav.tulach at oracle.com Wed Aug 2 14:08:24 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 02 Aug 2017 16:08:24 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> Message-ID: <3097604.jcdSgtZXxL@pracovni> > This is Graal-specific MBean. It doesn?t seem that it must be registered as > ?platform mbean? which has to implement PlatformManagedObject. > > Graal can register the MBean at runtime when java.management is present by > calling ManagementFactory.getPlatformMBeanServer().registerMBean method. > That seems to be a better alternative. Separating the MBean in a different > module would still be applicable. This is not possible to do cleanly. When shall Graal register the bean? On first compilation? Then it may enable the whole ManagementFactory infrastructure too early and influence results of regular Java programs. We have seen a benchmark failure due to registering the Graal bean too early. The bean registration triggered the java.util.logging infrastructure on and as a result the benchmarking test failed. The test tried to set "java.util.logging.config.file" property and then it assumed it will be used on subsequent call to Logger.getLogger(...). But the property was ignored as the Logger was already initialized. I believe that exactly for this reason there is the PlatformManagedObject & co. infrastructure. To not trigger the management infrastructure on prematurely. All the HotSpot beans are registered "lazily". As part of internal JDK infrastructure we believe Graal should have a way to be part of such "lazy initialization" too. I hope the need for the requested functionality is now clearer. -jt From Roger.Riggs at Oracle.com Wed Aug 2 14:21:37 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Aug 2017 10:21:37 -0400 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush Message-ID: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> Please review a correction in the RMI TestSocketFactory MatchReplaceOutputStream to correctly flush partial matches. It can cause hangs when the one or more bytes before a flush are a partial match for the pattern and the consumer is waiting for the pending bytes. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html Issue: https://bugs.openjdk.java.net/browse/JDK-8185719 Thanks, Roger From mandy.chung at oracle.com Wed Aug 2 14:37:54 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Aug 2017 07:37:54 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <3097604.jcdSgtZXxL@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> <3097604.jcdSgtZXxL@pracovni> Message-ID: > On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach wrote: > >> This is Graal-specific MBean. It doesn?t seem that it must be registered as >> ?platform mbean? which has to implement PlatformManagedObject. >> >> Graal can register the MBean at runtime when java.management is present by >> calling ManagementFactory.getPlatformMBeanServer().registerMBean method. >> That seems to be a better alternative. Separating the MBean in a different >> module would still be applicable. > > This is not possible to do cleanly. When shall Graal register the bean? On > first compilation? Then it may enable the whole ManagementFactory > infrastructure too early and influence results of regular Java programs. > > We have seen a benchmark failure due to registering the Graal bean too early. > The bean registration triggered the java.util.logging infrastructure on and as > a result the benchmarking test failed. > > The test tried to set "java.util.logging.config.file" property and then it > assumed it will be used on subsequent call to Logger.getLogger(...). But the > property was ignored as the Logger was already initialized. > > I believe that exactly for this reason there is the PlatformManagedObject & > co. infrastructure. To not trigger the management infrastructure on > prematurely. All the HotSpot beans are registered "lazily". As part of > internal JDK infrastructure we believe Graal should have a way to be part of > such "lazy initialization" too. > > I hope the need for the requested functionality is now clearer. As described in the previous mail, the current way to register a platform MBean is to have a provider module that provides sun.management.spi.PlatformMBeanProvider. The provider module will get resolved during service binding. jdk.management is one example. Mandy From lance.andersen at oracle.com Wed Aug 2 14:59:15 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Aug 2017 10:59:15 -0400 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush In-Reply-To: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> References: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> Message-ID: <86369C55-126B-4717-B87B-079C47C9635F@oracle.com> Hi Roger, the changes seem reasonable. Best Lance > On Aug 2, 2017, at 10:21 AM, Roger Riggs wrote: > > Please review a correction in the RMI TestSocketFactory MatchReplaceOutputStream to correctly flush > partial matches. It can cause hangs when the one or more bytes before a flush are a partial match > for the pattern and the consumer is waiting for the pending bytes. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8185719 > > 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 daniel.fuchs at oracle.com Wed Aug 2 15:25:30 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Aug 2017 16:25:30 +0100 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush In-Reply-To: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> References: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> Message-ID: Hi Roger, I wonder if the MatchReplaceOutputStream should store the partial match index at the time the partial bytes are flushed in order to verify that this was indeed a partial match, and report an error if it later finds that flush() was indeed called during a full match? The potential Error to throw could be created and recorded in flush() in order to diagnose the offending flush() call... On the other hand to do this properly you'd probably need to maintain a stack of partial match indexes and corresponding potential Errors to throw in case flush() is called again with a partial match while the previous partial matching hasn't been invalidated yet... I mean - if your matched bytes are stg like 0 0 0 6 and the stream looks like: 3 0 0 0 ... then either 6 or 0 0 6 coming after the second flush would make the test fail to find & replace the full match... But maybe it's not worth it if you are sure that flush() cannot be called during a full match/replace sequence? best regards, -- daniel On 02/08/2017 15:21, Roger Riggs wrote: > Please review a correction in the RMI TestSocketFactory > MatchReplaceOutputStream to correctly flush > partial matches. It can cause hangs when the one or more bytes before a > flush are a partial match > for the pattern and the consumer is waiting for the pending bytes. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8185719 > > Thanks, Roger > From Roger.Riggs at Oracle.com Wed Aug 2 15:32:20 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Aug 2017 11:32:20 -0400 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush In-Reply-To: References: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> Message-ID: <24bb1a70-78a5-2544-2751-38076ce58e21@Oracle.com> Hi Daniel, I considered keeping track of the partial match across the flush, but it could only work if the partial match was a prefix of the replacement string. It got complicated quickly. Since this is used (only) for RMI, in which flushes are used at the end of messages, it seemed sufficient to document it as not working across flushes and with a debug message if flush was in the middle of a partial match. Thanks, Roger On 8/2/2017 11:25 AM, Daniel Fuchs wrote: > Hi Roger, > > I wonder if the MatchReplaceOutputStream should store the > partial match index at the time the partial bytes are flushed > in order to verify that this was indeed a partial match, > and report an error if it later finds that flush() was indeed > called during a full match? The potential Error to throw could > be created and recorded in flush() in order to diagnose > the offending flush() call... > > On the other hand to do this properly you'd probably need > to maintain a stack of partial match indexes and corresponding > potential Errors to throw in case flush() is called again with > a partial match while the previous partial matching hasn't > been invalidated yet... > > I mean - if your matched bytes are stg like 0 0 0 6 > and the stream looks like: > > 3 0 0 0 ... > > then either 6 or 0 0 6 coming after the second flush would > make the test fail to find & replace the full match... > > But maybe it's not worth it if you are sure that flush() cannot > be called during a full match/replace sequence? > > best regards, > > -- daniel > > > > On 02/08/2017 15:21, Roger Riggs wrote: >> Please review a correction in the RMI TestSocketFactory >> MatchReplaceOutputStream to correctly flush >> partial matches. It can cause hangs when the one or more bytes >> before a flush are a partial match >> for the pattern and the consumer is waiting for the pending bytes. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8185719 >> >> Thanks, Roger >> > From daniel.fuchs at oracle.com Wed Aug 2 15:43:52 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Aug 2017 16:43:52 +0100 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush In-Reply-To: <24bb1a70-78a5-2544-2751-38076ce58e21@Oracle.com> References: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> <24bb1a70-78a5-2544-2751-38076ce58e21@Oracle.com> Message-ID: <41ac6712-0bb1-ffa1-42e1-b11d828c2afe@oracle.com> Hi Roger, On 02/08/2017 16:32, Roger Riggs wrote: > Hi Daniel, > > I considered keeping track of the partial match across the flush, but it > could only work > if the partial match was a prefix of the replacement string. It got > complicated quickly. > > Since this is used (only) for RMI, in which flushes are used at the end > of messages, it seemed > sufficient to document it as not working across flushes and with a debug > message > if flush was in the middle of a partial match. OK, looks good then. It occurred to me that the current match detection is eager anyway. That is, if the matchBytes are { 0, 0, 0, 6 } and the stream is { 3 0 0 0 0 6 0 ... } then unless I'm mistaken no match will be detected, because matching will start at byte 1 (it would need to start at byte 2 to detect a full match). So I guess this is a best effort which happens to work correctly with the input we use in our tests? best regards, -- daniel > > Thanks, Roger > > > On 8/2/2017 11:25 AM, Daniel Fuchs wrote: >> Hi Roger, >> >> I wonder if the MatchReplaceOutputStream should store the >> partial match index at the time the partial bytes are flushed >> in order to verify that this was indeed a partial match, >> and report an error if it later finds that flush() was indeed >> called during a full match? The potential Error to throw could >> be created and recorded in flush() in order to diagnose >> the offending flush() call... >> >> On the other hand to do this properly you'd probably need >> to maintain a stack of partial match indexes and corresponding >> potential Errors to throw in case flush() is called again with >> a partial match while the previous partial matching hasn't >> been invalidated yet... >> >> I mean - if your matched bytes are stg like 0 0 0 6 >> and the stream looks like: >> >> 3 0 0 0 ... >> >> then either 6 or 0 0 6 coming after the second flush would >> make the test fail to find & replace the full match... >> >> But maybe it's not worth it if you are sure that flush() cannot >> be called during a full match/replace sequence? >> >> best regards, >> >> -- daniel >> >> >> >> On 02/08/2017 15:21, Roger Riggs wrote: >>> Please review a correction in the RMI TestSocketFactory >>> MatchReplaceOutputStream to correctly flush >>> partial matches. It can cause hangs when the one or more bytes >>> before a flush are a partial match >>> for the pattern and the consumer is waiting for the pending bytes. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8185719 >>> >>> Thanks, Roger >>> >> > From Roger.Riggs at Oracle.com Wed Aug 2 15:50:11 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Aug 2017 11:50:11 -0400 Subject: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush In-Reply-To: <41ac6712-0bb1-ffa1-42e1-b11d828c2afe@oracle.com> References: <65cb7325-0e8a-233a-9684-fc7a354feec8@Oracle.com> <24bb1a70-78a5-2544-2751-38076ce58e21@Oracle.com> <41ac6712-0bb1-ffa1-42e1-b11d828c2afe@oracle.com> Message-ID: <6e8ec02d-f355-8537-e8ca-a4dbe575508b@Oracle.com> Hi Daniel, Yep, it does not try/need to handle the case where a prefix of the match appears within the match. When a mismatch is detected, it starts fresh for a match. Someday, it may need an upgrade, but for now its sufficient. Thanks, Roger On 8/2/2017 11:43 AM, Daniel Fuchs wrote: > Hi Roger, > > On 02/08/2017 16:32, Roger Riggs wrote: >> Hi Daniel, >> >> I considered keeping track of the partial match across the flush, but >> it could only work >> if the partial match was a prefix of the replacement string. It got >> complicated quickly. >> >> Since this is used (only) for RMI, in which flushes are used at the >> end of messages, it seemed >> sufficient to document it as not working across flushes and with a >> debug message >> if flush was in the middle of a partial match. > > OK, looks good then. > It occurred to me that the current match detection is eager anyway. > That is, if the matchBytes are { 0, 0, 0, 6 } and the stream > is { 3 0 0 0 0 6 0 ... } then unless I'm mistaken no match will > be detected, because matching will start at byte 1 (it would > need to start at byte 2 to detect a full match). > > So I guess this is a best effort which happens to work correctly > with the input we use in our tests? > > best regards, > > -- daniel > >> >> Thanks, Roger >> >> >> On 8/2/2017 11:25 AM, Daniel Fuchs wrote: >>> Hi Roger, >>> >>> I wonder if the MatchReplaceOutputStream should store the >>> partial match index at the time the partial bytes are flushed >>> in order to verify that this was indeed a partial match, >>> and report an error if it later finds that flush() was indeed >>> called during a full match? The potential Error to throw could >>> be created and recorded in flush() in order to diagnose >>> the offending flush() call... >>> >>> On the other hand to do this properly you'd probably need >>> to maintain a stack of partial match indexes and corresponding >>> potential Errors to throw in case flush() is called again with >>> a partial match while the previous partial matching hasn't >>> been invalidated yet... >>> >>> I mean - if your matched bytes are stg like 0 0 0 6 >>> and the stream looks like: >>> >>> 3 0 0 0 ... >>> >>> then either 6 or 0 0 6 coming after the second flush would >>> make the test fail to find & replace the full match... >>> >>> But maybe it's not worth it if you are sure that flush() cannot >>> be called during a full match/replace sequence? >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> >>> On 02/08/2017 15:21, Roger Riggs wrote: >>>> Please review a correction in the RMI TestSocketFactory >>>> MatchReplaceOutputStream to correctly flush >>>> partial matches. It can cause hangs when the one or more bytes >>>> before a flush are a partial match >>>> for the pattern and the consumer is waiting for the pending bytes. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8185719 >>>> >>>> Thanks, Roger >>>> >>> >> > From ivan.gerasimov at oracle.com Wed Aug 2 22:36:33 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Aug 2017 15:36:33 -0700 Subject: [10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class Message-ID: Hello! A couple of typos was spotted in the javadoc. Would you please help review the fix? diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java b/src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++ b/src/java.base/share/classes/java/util/regex/Pattern.java @@ -667,11 +667,11 @@ * {@code \p{Alpha}} * An alphabetic character:{@code \p{IsAlphabetic}} * {@code \p{Digit}} - * A decimal digit character:{@code p{IsDigit}} + * A decimal digit character:{@code \p{IsDigit}} * {@code \p{Alnum}} * An alphanumeric character:{@code [\p{IsAlphabetic}\p{IsDigit}]} * {@code \p{Punct}} - * A punctuation character:{@code p{IsPunctuation}} + * A punctuation character:{@code \p{IsPunctuation}} * {@code \p{Graph}} * A visible character: {@code [^\p{IsWhite_Space}\p{gc=Cc}\p{gc=Cs}\p{gc=Cn}]} * {@code \p{Print}} -- With kind regards, Ivan Gerasimov From brian.burkhalter at oracle.com Wed Aug 2 23:00:33 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Aug 2017 16:00:33 -0700 Subject: [10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class In-Reply-To: References: Message-ID: Hi Ivan, These look fine. Brian On Aug 2, 2017, at 3:36 PM, Ivan Gerasimov wrote: > Would you please help review the fix? > > --- a/src/java.base/share/classes/java/util/regex/Pattern.java > +++ b/src/java.base/share/classes/java/util/regex/Pattern.java > @@ -667,11 +667,11 @@ > [?] > - * A decimal digit character:{@code p{IsDigit}} > + * A decimal digit character:{@code \p{IsDigit}} > [?] > - * A punctuation character:{@code p{IsPunctuation}} > + * A punctuation character:{@code \p{IsPunctuation}} From ivan.gerasimov at oracle.com Wed Aug 2 23:20:58 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Aug 2017 16:20:58 -0700 Subject: [10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class In-Reply-To: References: Message-ID: <1e479898-da36-8f38-3ea5-35710e0ed251@oracle.com> Thanks! Pushed. On 8/2/17 4:00 PM, Brian Burkhalter wrote: > Hi Ivan, > > These look fine. > > Brian > > On Aug 2, 2017, at 3:36 PM, Ivan Gerasimov > wrote: > >> Would you please help review the fix? >> >> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >> @@ -667,11 +667,11 @@ >> [?] >> - * A decimal digit character:{@code p{IsDigit}} >> + * A decimal digit character:{@code \p{IsDigit}} >> [?] >> - * A punctuation character:{@code p{IsPunctuation}} >> + * A punctuation character:{@code \p{IsPunctuation}} > -- With kind regards, Ivan Gerasimov From jonathan.gibbons at oracle.com Wed Aug 2 23:21:19 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 02 Aug 2017 16:21:19 -0700 Subject: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions Message-ID: <59825E6F.5080709@oracle.com> (I'm not sure if there is a better list for this request, but the request is so simple, I'm hoping it will be sufficient. Please review this very simple fix to replace two uses of ... with {@code...}. The underlying problem being fixed is incorrect handling of the first sentence in a couple of cases, due to the presence of a '?' in the code expression. The doclet was treating the ? as terminating the first sentence, leading to confusing output, and incorrect HTML being generated. JBS: https://bugs.openjdk.java.net/browse/JDK-8185758 Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/ -- Jon From ivan.gerasimov at oracle.com Wed Aug 2 23:25:40 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Aug 2017 16:25:40 -0700 Subject: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions In-Reply-To: <59825E6F.5080709@oracle.com> References: <59825E6F.5080709@oracle.com> Message-ID: The change looks good! With kind regards, Ivan On 8/2/17 4:21 PM, Jonathan Gibbons wrote: > (I'm not sure if there is a better list for this request, but the > request is so simple, I'm hoping it will be sufficient. > > Please review this very simple fix to replace two uses of > ... with {@code...}. > > The underlying problem being fixed is incorrect handling of the first > sentence in a couple of cases, due to the presence of a '?' in the > code expression. The doclet was treating the ? as terminating the > first sentence, leading to confusing output, and incorrect HTML being > generated. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185758 > Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/ > > -- Jon > From mandy.chung at oracle.com Thu Aug 3 00:49:02 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Aug 2017 17:49:02 -0700 Subject: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions In-Reply-To: <59825E6F.5080709@oracle.com> References: <59825E6F.5080709@oracle.com> Message-ID: <870D7BF7-7247-4872-AF13-A92BA3AD90FE@oracle.com> > On Aug 2, 2017, at 4:21 PM, Jonathan Gibbons wrote: > > (I'm not sure if there is a better list for this request, but the request is so simple, I'm hoping it will be sufficient. > > Please review this very simple fix to replace two uses of ... with {@code...}. > > The underlying problem being fixed is incorrect handling of the first sentence in a couple of cases, due to the presence of a '?' in the code expression. The doclet was treating the ? as terminating the first sentence, leading to confusing output, and incorrect HTML being generated. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185758 > Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/ Looks good. Mandy From Roger.Riggs at Oracle.com Thu Aug 3 14:25:56 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 3 Aug 2017 10:25:56 -0400 Subject: RFR 8185346 : Relax RMI Registry Serial Filter to allow arrays of any type Message-ID: <45cfcd47-b5c3-9648-23d8-86d14f8ca96a@Oracle.com> Please review a relaxation of the serial filter checks on the RMI Registry. Arrays of any type are serializable and do not pose a risk except based on the array size, which is checked by the maxarray limit. Objects inserted in the array are checked Individually. The filter is modified to check only the array size against the limit and otherwise allow arrays of any type. Both the built-in filter and the pattern based override are updated to allow arrays. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-registry-allow-arrays-8185346/ Issue: https://bugs.openjdk.java.net/browse/JDK-8185346 Thanks, Roger From jaroslav.tulach at oracle.com Thu Aug 3 15:03:39 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 03 Aug 2017 17:03:39 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> Message-ID: <14332343.G5UyyslDlL@pracovni> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > On 27/07/2017 10:07, Jaroslav Tulach wrote: > > Yes, it seems like a desirable goal to let Graal compiler work with just > > java.base. Is there a description how to build JDK9/10 with just java.base > > that I could follow and test against? > > You can use jlink to create a run-time image that only contains > java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base > --output smalljre). Status update: I've just tried to run Graal compiler against JDK9 with only java.base and jdk.internal.vm.ci modules, and there are some problems. I need to resolve them first before I provide updated version of my patch. Thanks for your support so far. -jt > >> If it exposes a MBean, the dependency would be needed. > > > > Isn't there a way to require an optional dependency? That would be > > sufficient - as the classes in question are only loaded once > > java.management searches for them. E.g. only when java.management is > > installed. > > There is `requires static` but it would be a lot cleaner if the > management support could be refactored into its own service provider > module, meaning JVMCIMXBeans would be in its own module. > > -Alan From daniel.fuchs at oracle.com Thu Aug 3 15:47:21 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 3 Aug 2017 16:47:21 +0100 Subject: RFR 8185346 : Relax RMI Registry Serial Filter to allow arrays of any type In-Reply-To: <45cfcd47-b5c3-9648-23d8-86d14f8ca96a@Oracle.com> References: <45cfcd47-b5c3-9648-23d8-86d14f8ca96a@Oracle.com> Message-ID: <0ccbdcb6-5fb8-3175-3daa-adb8819cc9e5@oracle.com> Hi Roger, Looks good to me. best regards, -- daniel On 03/08/2017 15:25, Roger Riggs wrote: > Please review a relaxation of the serial filter checks on the RMI Registry. > > Arrays of any type are serializable and do not pose a risk except based > on the array size, > which is checked by the maxarray limit. Objects inserted in the array > are checked Individually. > > The filter is modified to check only the array size against the limit > and otherwise allow arrays of any type. > Both the built-in filter and the pattern based override are updated to > allow arrays. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-registry-allow-arrays-8185346/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8185346 > > Thanks, Roger > > From sean.coffey at oracle.com Thu Aug 3 19:11:07 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Aug 2017 20:11:07 +0100 Subject: RFR 8185346 : Relax RMI Registry Serial Filter to allow arrays of any type In-Reply-To: <45cfcd47-b5c3-9648-23d8-86d14f8ca96a@Oracle.com> References: <45cfcd47-b5c3-9648-23d8-86d14f8ca96a@Oracle.com> Message-ID: <838c1e01-ed6d-3e94-d457-7ac6e105a913@oracle.com> Looks fine to me Roger. Thanks for handling. Should the testcase get an @bug tag ? regards, Sean. On 03/08/2017 15:25, Roger Riggs wrote: > Please review a relaxation of the serial filter checks on the RMI > Registry. > > Arrays of any type are serializable and do not pose a risk except > based on the array size, > which is checked by the maxarray limit. Objects inserted in the array > are checked Individually. > > The filter is modified to check only the array size against the limit > and otherwise allow arrays of any type. > Both the built-in filter and the pattern based override are updated to > allow arrays. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-registry-allow-arrays-8185346/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8185346 > > Thanks, Roger > > From martinrb at google.com Tue Aug 8 00:06:16 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Aug 2017 17:06:16 -0700 Subject: RFR: jsr166 jdk10 integration wave 2 Message-ID: Need to fix 1. JDK-8185830 ConcurrentSkipListSet.clone() fails with UnsupportedOperationException http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ (It would be nice if we could submit a jdk9 backport now instead of waiting) From peter.levart at gmail.com Tue Aug 8 12:21:37 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Aug 2017 14:21:37 +0200 Subject: RFR: jsr166 jdk10 integration wave 2 In-Reply-To: References: Message-ID: <09c339d6-58db-834b-838f-a349240c1d6c@gmail.com> Hi Martin, Just a purely theoretical question... On 08/08/2017 02:06 AM, Martin Buchholz wrote: > Need to fix > > > 1. JDK-8185830 > > ConcurrentSkipListSet.clone() fails with UnsupportedOperationException > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ > > (It would be nice if we could submit a jdk9 backport now instead of waiting) Regarding ConcurrentSkipListSet.clone()... The 'm' field is final presumably to allow "safe" publication of ConcurrentSkipListSet objects to other threads via data races. clone() O.T.O.H. uses Field.setAccessible(true) on a final field, followed with Field.set(), which amounts to Unsafe.putObjectVolatile(). Is this equivalent to volatile write? Is it possible for a normal write of a reference to a cloned ConcurrentSkipListSet (i.e. publication via data race) to bubble up before the volatile write of 'm' field inside the clone and consequently allow an observer of a reference to the clone to modify the backing map of the original ConcurrentSkipListSet? Regards, Peter From peter.levart at gmail.com Tue Aug 8 12:29:53 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Aug 2017 14:29:53 +0200 Subject: RFR: jsr166 jdk10 integration wave 2 In-Reply-To: <09c339d6-58db-834b-838f-a349240c1d6c@gmail.com> References: <09c339d6-58db-834b-838f-a349240c1d6c@gmail.com> Message-ID: <11d62c21-794f-bc49-bb3f-025446c27a67@gmail.com> On 08/08/2017 02:21 PM, Peter Levart wrote: > Hi Martin, > > Just a purely theoretical question... > > On 08/08/2017 02:06 AM, Martin Buchholz wrote: >> Need to fix >> >> >> 1. JDK-8185830 >> >> ConcurrentSkipListSet.clone() fails with UnsupportedOperationException >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ >> >> (It would be nice if we could submit a jdk9 backport now instead of >> waiting) > > Regarding ConcurrentSkipListSet.clone()... The 'm' field is final > presumably to allow "safe" publication of ConcurrentSkipListSet > objects to other threads via data races. > > clone() O.T.O.H. uses Field.setAccessible(true) on a final field, > followed with Field.set(), which amounts to > Unsafe.putObjectVolatile(). Is this equivalent to volatile write? Is > it possible for a normal write of a reference to a cloned > ConcurrentSkipListSet (i.e. publication via data race) to bubble up > before the volatile write of 'm' field inside the clone and > consequently allow an observer of a reference to the clone to modify > the backing map of the original ConcurrentSkipListSet? > > Regards, Peter I know it can't be done any better than that, because ConcurrentSkipListSet is not final. If it was final, clone() could use private constructor to construct a clone. But the same can be done at least for objects of ConcurrentSkipListSet runtime class: if (getClass() == ConcurrentSkipListSet.class) { return new ConcurrentSkipListSet(clonedMap); } else { // proceed as is } Hm... An alternative would be to use explicit fence before the end of clone() Regards, Peter From paul.sandoz at oracle.com Tue Aug 8 20:01:37 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Aug 2017 13:01:37 -0700 Subject: RFR: jsr166 jdk10 integration wave 2 In-Reply-To: References: Message-ID: > On 7 Aug 2017, at 17:06, Martin Buchholz wrote: > > Need to fix > > > 1. JDK-8185830 > > ConcurrentSkipListSet.clone() fails with UnsupportedOperationException > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ > > (It would be nice if we could submit a jdk9 backport now instead of waiting) Oops that is embarrassing, i missed that one in review. +1 Paul. From jonathan.gibbons at oracle.com Tue Aug 8 20:23:08 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Aug 2017 13:23:08 -0700 Subject: RFR: JDK-8185984: fix a11y and html issues in java.logging module Message-ID: <598A1DAC.7080407@oracle.com> Please review a few small changes for accessibility and HTML issue in the API docs for the java.logging module. JBS: https://bugs.openjdk.java.net/browse/JDK-8185984 Webrev: http://cr.openjdk.java.net/~jjg/8185984/webrev.00/ -- Jon From daniel.fuchs at oracle.com Tue Aug 8 20:33:22 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 8 Aug 2017 21:33:22 +0100 Subject: RFR: JDK-8185984: fix a11y and html issues in java.logging module In-Reply-To: <598A1DAC.7080407@oracle.com> References: <598A1DAC.7080407@oracle.com> Message-ID: Hi Jon, Looks good to me! best regards, -- daniel On 08/08/17 21:23, Jonathan Gibbons wrote: > Please review a few small changes for accessibility and HTML issue in > the API docs for the java.logging module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185984 > Webrev: http://cr.openjdk.java.net/~jjg/8185984/webrev.00/ > > -- Jon From mandy.chung at oracle.com Tue Aug 8 20:38:13 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 8 Aug 2017 13:38:13 -0700 Subject: RFR: JDK-8185984: fix a11y and html issues in java.logging module In-Reply-To: <598A1DAC.7080407@oracle.com> References: <598A1DAC.7080407@oracle.com> Message-ID: Looks fine to me. Mandy On 8/8/17 1:23 PM, Jonathan Gibbons wrote: > Please review a few small changes for accessibility and HTML issue in > the API docs for the java.logging module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185984 > Webrev: http://cr.openjdk.java.net/~jjg/8185984/webrev.00/ > > -- Jon From martinrb at google.com Tue Aug 8 21:46:52 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Aug 2017 14:46:52 -0700 Subject: RFR: jsr166 jdk10 integration wave 2 In-Reply-To: <09c339d6-58db-834b-838f-a349240c1d6c@gmail.com> References: <09c339d6-58db-834b-838f-a349240c1d6c@gmail.com> Message-ID: On Tue, Aug 8, 2017 at 5:21 AM, Peter Levart wrote: > Hi Martin, > > Just a purely theoretical question... > > On 08/08/2017 02:06 AM, Martin Buchholz wrote: > >> Need to fix >> >> >> 1. JDK-8185830 >> >> ConcurrentSkipListSet.clone() fails with UnsupportedOperationException >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ >> >> (It would be nice if we could submit a jdk9 backport now instead of >> waiting) >> > > Regarding ConcurrentSkipListSet.clone()... The 'm' field is final > presumably to allow "safe" publication of ConcurrentSkipListSet objects to > other threads via data races. > > clone() O.T.O.H. uses Field.setAccessible(true) on a final field, followed > with Field.set(), which amounts to Unsafe.putObjectVolatile(). Is this > equivalent to volatile write? Is it possible for a normal write of a > reference to a cloned ConcurrentSkipListSet (i.e. publication via data > race) to bubble up before the volatile write of 'm' field inside the clone > and consequently allow an observer of a reference to the clone to modify > the backing map of the original ConcurrentSkipListSet? > Yeah, I don't think we have any really good answer for this. I've lobbied for "safe publication of non-final fields as if final" for a long time. Even making the field volatile is not enough in theory (but is in practice) to make the uninitialized field unobservable. In theory a fence in the constructor is not enough because you need a fence before every read as well. Maybe if you replace every write with a release write and every read with an acquire read you're OK. But you also want to keep the "final" for software engineering purposes, since it's "mostly" final. From huizhe.wang at oracle.com Tue Aug 8 23:43:41 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 8 Aug 2017 16:43:41 -0700 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release Message-ID: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> Please review an update to BCEL release 6.0 [1]. The sources are basically that from the release bundle with the following exceptions: * Classes that were not included in the original version are excluded; * Classes that are deprecated in BCEL 6.0 are removed; * Classes that are used only for the above classes are also removed; * Many fields were deprecated in BCEL 6.0 in order to discourage direct references, in the JDK, I've removed such deprecation and instead made them private/final. * BCEL 6.0 applied 'final' to global/local variables pretty extensively, which were the only changes to many of the classes. * A few Transform classes were updated to adopt to BCEL 6.0. * JDK-8162527 [JAXP] XSLT: Investigate why bumping the default class file version to 49 (Java 5.0) or higher for bytecode generation doesn't work [2] has not been resolved as of this update. Additional change [3] is needed before we can move up to possibly Java 5.0. BCEL has been a very old component. This update therefore removed a large amount of warnings (900+), which is very helpful to the cleaning effort. All tests passed, including the JCK. JBS: https://bugs.openjdk.java.net/browse/JDK-8163121 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/ [1] https://archive.apache.org/dist/commons/bcel/RELEASE-NOTES.txt [2] https://bugs.openjdk.java.net/browse/JDK-8162527 [3] https://bugs.openjdk.java.net/browse/JDK-8185991 Thanks, Joe From weijun.wang at oracle.com Wed Aug 9 09:11:40 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 9 Aug 2017 17:11:40 +0800 Subject: Patch a DLL in JDK? Message-ID: <7FADF1A4-B08C-42BC-A1C1-2CACA66BC6C5@oracle.com> It's possible to patch classes with --patch-module but how do I shadow a DLL? I don't want to overwrite the existing one. I am talking about bin/w2k_lsa_auth.dll, which belongs to java.security.jgss. Thanks Max From daniel.fuchs at oracle.com Wed Aug 9 13:30:00 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 9 Aug 2017 14:30:00 +0100 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> Message-ID: <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> Hi Joe, This not an easy patch to review ;-) Thanks for explaining how you arrived at the final result. The method you used as described below seems right. I haven't clicked through all the files, but instead I had a look at all the JIRA issues revealed by: hg log -k share/classes/com/sun/org/apache/bcel | grep summary | grep -v Merge to see if any of them might have been reverted/invalidated. So far so good, most of them still seem to be present in your changes, but I have a doubt about these two: https://bugs.openjdk.java.net/browse/JDK-8062608 https://bugs.openjdk.java.net/browse/JDK-8064516 Has the issue been fixed upstream in a different way, or is the issue no longer relevant, or is it going to appear again with this patch? Also looking at the JDK fixes brought my attention to java.xml/share/classes/jdk/xml/internal/SecuritySupport.java Your changes are adding these two methods: I don't know what they are for - and I am not sure they would work (the brutal cast to ListResourceBundle is dubious). Fortunately they don't seem to be called by the new code (I grepped the global patch file). Can you remove them? 234 /** 235 * Gets a resource bundle using the specified base name, the default locale, and the caller's class loader. 236 * @param bundle the base name of the resource bundle, a fully qualified class name 237 * @return a resource bundle for the given base name and the default locale 238 */ 239 public static ListResourceBundle getResourceBundle(String bundle) { 240 return getResourceBundle(bundle, Locale.getDefault()); 241 } 242 243 /** 244 * Gets a resource bundle using the specified base name and locale, and the caller's class loader. 245 * @param bundle the base name of the resource bundle, a fully qualified class name 246 * @param locale the locale for which a resource bundle is desired 247 * @return a resource bundle for the given base name and locale 248 */ 249 public static ListResourceBundle getResourceBundle(final String bundle, final Locale locale) { 250 return AccessController.doPrivileged((PrivilegedAction) () -> { 251 try { 252 return (ListResourceBundle)ResourceBundle.getBundle(bundle, locale); 253 } catch (MissingResourceException e) { 254 try { 255 return (ListResourceBundle)ResourceBundle.getBundle(bundle, new Locale("en", "US")); 256 } catch (MissingResourceException e2) { 257 throw new MissingResourceException( 258 "Could not load any resource bundle by " + bundle, bundle, ""); 259 } 260 } 261 }); 262 } best regards, -- daniel On 09/08/2017 00:43, huizhe wang wrote: > Please review an update to BCEL release 6.0 [1]. > > The sources are basically that from the release bundle with the > following exceptions: > > * Classes that were not included in the original version are excluded; > * Classes that are deprecated in BCEL 6.0 are removed; > * Classes that are used only for the above classes are also removed; > * Many fields were deprecated in BCEL 6.0 in order to discourage > direct references, in the JDK, I've removed such deprecation and > instead made them private/final. > * BCEL 6.0 applied 'final' to global/local variables pretty > extensively, which were the only changes to many of the classes. > * A few Transform classes were updated to adopt to BCEL 6.0. > * JDK-8162527 [JAXP] XSLT: Investigate why bumping the default class > file version to 49 (Java 5.0) or higher for bytecode generation > doesn't work [2] has not been resolved as of this update. Additional > change [3] is needed before we can move up to possibly Java 5.0. > > > BCEL has been a very old component. This update therefore removed a > large amount of warnings (900+), which is very helpful to the cleaning > effort. > > All tests passed, including the JCK. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163121 > webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/ > > > [1] https://archive.apache.org/dist/commons/bcel/RELEASE-NOTES.txt > [2] https://bugs.openjdk.java.net/browse/JDK-8162527 > [3] https://bugs.openjdk.java.net/browse/JDK-8185991 > > Thanks, > Joe > From jonathan.gibbons at oracle.com Wed Aug 9 20:54:59 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 9 Aug 2017 13:54:59 -0700 Subject: Greek characters in java.lang.String Message-ID: <3f23857c-74cf-b1f4-599b-224838c4afef@oracle.com> The method String.toLowerCase(Locale) contains some Greek letters in its doc comment. But the characters are presented with images, instead of native Unicode characters. See http://download.java.net/java/jdk9/docs/api/java/lang/String.html#toLowerCase-java.util.Locale- Has the time come to replace those characters with their Unicode equivalents, expressed with suitable HTML entities? -- Jon From naoto.sato at oracle.com Wed Aug 9 21:12:57 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 9 Aug 2017 14:12:57 -0700 Subject: Greek characters in java.lang.String In-Reply-To: <3f23857c-74cf-b1f4-599b-224838c4afef@oracle.com> References: <3f23857c-74cf-b1f4-599b-224838c4afef@oracle.com> Message-ID: <12e1adf1-f92c-2b9a-76e7-acdee5bdc28d@oracle.com> +1 Naoto On 8/9/17 1:54 PM, Jonathan Gibbons wrote: > The method String.toLowerCase(Locale) contains some Greek letters in its > doc comment. But the characters are presented with images, instead of > native Unicode characters. > > See > http://download.java.net/java/jdk9/docs/api/java/lang/String.html#toLowerCase-java.util.Locale- > > > Has the time come to replace those characters with their Unicode > equivalents, expressed with suitable HTML entities? > > -- Jon > From Roger.Riggs at Oracle.com Wed Aug 9 21:23:02 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 9 Aug 2017 17:23:02 -0400 Subject: Greek characters in java.lang.String In-Reply-To: <12e1adf1-f92c-2b9a-76e7-acdee5bdc28d@oracle.com> References: <3f23857c-74cf-b1f4-599b-224838c4afef@oracle.com> <12e1adf1-f92c-2b9a-76e7-acdee5bdc28d@oracle.com> Message-ID: +1, I conjecture that originally, the fonts didn't consistently include Greek. Roger On 8/9/2017 5:12 PM, Naoto Sato wrote: > +1 > > Naoto > > On 8/9/17 1:54 PM, Jonathan Gibbons wrote: >> The method String.toLowerCase(Locale) contains some Greek letters in >> its doc comment. But the characters are presented with images, >> instead of native Unicode characters. >> >> See >> http://download.java.net/java/jdk9/docs/api/java/lang/String.html#toLowerCase-java.util.Locale- >> >> >> Has the time come to replace those characters with their Unicode >> equivalents, expressed with suitable HTML entities? >> >> -- Jon >> From tom.w.hood at gmail.com Wed Aug 9 23:50:14 2017 From: tom.w.hood at gmail.com (Tom Hood) Date: Wed, 9 Aug 2017 16:50:14 -0700 Subject: JDK 9 jar tool issues - "isolated nested class" and creation of a corrupt jar Message-ID: Hi, I'm having a couple issues with the jar tool. Version: JDK 9 build 181 SPARC64 Since I'm typing this in, beware of typos. I cannot copy and paste output as my Solaris 10 box isn't permitted to access the internet. (1) isolated nested classes trying to create a multi-release jar In my test case (which I can't give you as it's on a different network), I have a number of classes compiled for java 6 (javac --release 6) and then 1 compiled for both java 6 and java 9. The java 9 version is in a "v9" subdirectory. The complete directory structure looks likes this: ./v9/com/thirdparty/jdk/JdkSpecificClass.class ./com/thirdparty/jdk/JdkSpecificClass.class ./com/thirdparty/animation/CustomAnimation.class ./com/thirdparty/animation/CustomAnimation$0.class ./com/thirdparty/animation/CustomAnimation$BackgroundPanel.class ./com/thirdparty/animation/CustomAnimation$Callback.class ./com/thirdparty/animation/CustomAnimation$n_.class ./com/thirdparty/animation/CustomAnimation$1.class ./com/thirdparty/animation/CustomAnimation$2.class ./com/thirdparty/animation/CustomAnimation$3.class ./com/thirdparty/animation/CustomAnimation$3$0.class ./com/thirdparty/animation/CustomAnimation$3$1.class ./com/thirdparty/animation/CustomAnimation$4.class ./com/thirdparty/animation/CustomAnimation$4$0.class ./com/thirdparty/animation/CustomAnimation$4$1.class ./com/thirdparty/animation/CustomAnimation$5.class ./com/thirdparty/animation/CustomAnimation$6.class ./com/thirdparty/animation/CustomAnimation$7.class ./com/thirdparty/animation/CustomAnimation$8.class ./com/thirdparty/animation/CustomAnimation$9.class ./com/thirdparty/animation/CustomAnimation$10.class ./com/thirdparty/animation/CustomAnimation$11.class ./com/thirdparty/animation/CustomAnimation$12.class ./com/thirdparty/animation/CustomAnimation$12$1.class ./com/thirdparty/animation/CustomAnimation$12$2.class ./com/thirdparty/animation/CustomAnimation$13.class ./com/thirdparty/animation/CustomAnimation$13$1.class ./com/thirdparty/animation/CustomAnimation$13$2.class >From that directory, I run the following jar command: jar cvf test.jar com --release 9 -C v9 com It outputs the following: (I'm not typing the "(in = N) (out= M)(deflated P%)" text..if you need it, let me know) added manifest adding: com/ adding: com/thirdparty/ adding: com/thirdparty/animation/ adding: com/thirdparty/animation/CustomAnimation$0.class # should CustomAnimation.class go first? adding: com/thirdparty/animation/CustomAnimation$1.class adding: com/thirdparty/animation/CustomAnimation$10.class adding: com/thirdparty/animation/CustomAnimation$11.class adding: com/thirdparty/animation/CustomAnimation$12$1.class # should CustomAnimation$12.class go first? adding: com/thirdparty/animation/CustomAnimation$12$2.class adding: com/thirdparty/animation/CustomAnimation$12.class adding: com/thirdparty/animation/CustomAnimation$13$1.class #should CustomAnimation$13.class go first? adding: com/thirdparty/animation/CustomAnimation$13$2.class adding: com/thirdparty/animation/CustomAnimation$13.class adding: com/thirdparty/animation/CustomAnimation$2.class adding: com/thirdparty/animation/CustomAnimation$3$0.class #ditto above comment adding: com/thirdparty/animation/CustomAnimation$3$1.class adding: com/thirdparty/animation/CustomAnimation$3.class adding: com/thirdparty/animation/CustomAnimation$4$0.class #ditto above comment adding: com/thirdparty/animation/CustomAnimation$4$1.class adding: com/thirdparty/animation/CustomAnimation$4.class adding: com/thirdparty/animation/CustomAnimation$5.class adding: com/thirdparty/animation/CustomAnimation$6.class adding: com/thirdparty/animation/CustomAnimation$7.class adding: com/thirdparty/animation/CustomAnimation$8.class adding: com/thirdparty/animation/CustomAnimation$9.class adding: com/thirdparty/animation/CustomAnimation$BackgroundPanel.class adding: com/thirdparty/animation/CustomAnimation$Callback.class adding: com/thirdparty/animation/CustomAnimation$n_.class adding: com/thirdparty/animation/CustomAnimation.class adding: com/thirdparty/jdk/ adding: com/thirdparty/jdk/JdkSpecificClass.class adding: META-INF/versions/9/com/ adding: META-INF/versions/9/com/thirdparty/ adding: META-INF/versions/9/com/thirdparty/jdk/ adding: META-INF/versions/9/com/thirdparty/jdk/JdkSpecificClass.class entry: com/thirdparty/animation/CustomAnimation$12$1.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$12$2.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$13$1.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$13$2.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$3$0.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$3$1.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$4$0.class, is an isolated nested class entry: com/thirdparty/animation/CustomAnimation$4$1.class, is an isolated nested class invalid multi-release jar file test.jar deleted I then thought I might be able to control the order of the adds via an @classlist file. It didn't help. I looked at the jdk source jdk.jartool/sun/tools/jar/Validator.jar and found that it sorts the class files so top level classes are supposed to come before nested ones (see ENTRYNAME_COMPARATOR). I looked briefly at it and didn't notice a bug, but someone more familiar with the jar tool code should probably take a look. I also added a -J-Djar.debug=true to the jar command line hoping for some insight...didn't get any. If you need that output, let me know. I then thought, OK, let me add the toplevel classes first, then update the jar with the nested classes using a separate "jar uvf". That's when I hit issue (2), because the "jar uvf" command was unable to read the jar just created, although "jar tvf" could read it okay. (2) creation of a corrupt jar on SPARC64 I suspect this might be related to JDK-8062911 which was closed saying the submitter had a workaround to change the zip read buffer size. Is there a way to specify different zip buffer sizes to the jar command? The jar command I ran was: jar cvf test.jar @classlist.toplevel --release 9 -C v9 com The file "classlist.toplevel" contains only the top level class files (no "$" signs) That appeared to work and create the jar. jar tvf test.jar shows the correct files. However, jar xvf test.jar gives me this output: created: META-INF/ java.io.IOExeption: Push back buffer is full at java.base/java.io.PushbackIinputStream.unread(PushbackInputStream.java:229) at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:359) at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:197) at java.base/java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:141) at jdk.jartool/sun.tools.jar.Main.extractFile(Main.java:1446) at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1353) at jdk.jartool/sun.tools.jar.Main.run(Main.java:403) at jdk.jartool/sun.tools.jar.Main.main(Main.java:1670) The only file left over from the failed extraction was the META-INF/MANIFEST.MF which contained: Manifest-Version: 1.0 Created-By: 9 (Oracle Corporation) Multi-Release: true *Windows 7 Testing* I copied the test.jar file and class directory tree from my solaris sparc box to a windows 7 box and installed the 64-bit windows version of JDK 9 build 181. I first tried to "jar xvf test.jar" to see if the windows jar tool could read the test.jar created using the SPARC64 jar tool. It couldn't and failed with the same stack trace with the java.io.IOException. I then ran the same jar create command using the windows jar tool. It worked and I was able to extract the files on windows. I was then able to update that jar and add the nested classes via an @classlist.level1 file that just contained the nested class files (one $ sign). Finally I was able to update it further with an @classlist.level2 file that had the nested nested classes (two $ signs). Pushing my luck, I tried to start over and run my original jar creation command on windows, but it failed the same way it did for the SPARC64 jar tool with the "isolated nested class" errors. I also tried creating the jar file with a combined file with classes from classlist.toplevel and classlist.level1. That worked and I was able to update the jar with the classlist.level2. Let me know what else you need to reproduce this. Thanks, -- Tom From stuart.marks at oracle.com Wed Aug 9 23:59:25 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Aug 2017 16:59:25 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: <08f39675-ba33-70f6-7f35-467569825989@oracle.com> On 8/1/17 11:56 PM, Ivan Gerasimov wrote: > I've tried to go one step further and created even more abstract comparator: It > uses a supplied predicate to decompose the input sequences into odd/even > subsequences (e.g. alpha/numeric) and then uses two separate comparator to > compare them. Additionally, a comparator for comparing sequences, consisting > only of digits is provided. For example, to build a case-insensitive > AlphaDecimal comparator one could use: 1) Character::isDigit -- as the predicate > for decomposing, 2) String::compareToIgnoreCase -- to compare alpha (i.e. odd > parts); to work with CharSequences one would need to make it > Comparator.comparing(CharSequence::toString, String::compareToIgnoreCase), 3) > The special decimal-only comparator, which compares the decimal representation > of the sequences. Here's the file with all the comparators and a simple test: > http://cr.openjdk.java.net/~igerasim/8134512/test/Test.java Hi, a couple follow-up thoughts on this. 1) Supplementary characters The current code uses Character.isDigit(char), which works only for char values in the BMP (basic multilingual plane, values <= U+FFFF). It won't work for supplementary characters. There are several blocks of digits in the BMP, but there are several more in the supplementary character range. I don't see any reason not to handle the supplementary characters as well, except that it spoils the nice char-by-char technique of processing the string. Instead, it'd have to pull in code point values, which might be comprised of two surrogate chars. There are a variety of methods on Character that help with this. Note that there is an overload Character.isDigit(int) which takes any code point value, including supplementary characters. 2) Too much generality? This version includes Predicate for determining whether a character is part of the alphabetic or decimal portion of the string. I'm thinking this might be overkill. It might be sufficient to "hardwire" the partitioning predicate to be Character::isDigit and the value mapping function to use Character::digit. The problem is that adding a predicate opens the door to a lot more complexity, while providing dimishing value. First, the predicate would have to handle code points (per the above) so it'd need to be an IntPredicate. Second, there would also need to be a mapping function from the code point value to a numeric value. This might be an IntUnaryOperator. This would allow someone to sort based on Roman numerals, using Character::getNumericValue. (Yes, Roman numerals are in Unicode.) Or maybe the mapping function should return any Comparable value, not an int. ... See where I'm going here? Since this kind of sorting is intended to be viewed by people, it's probably worth providing full internationalization support (supplementary characters, and delegation to sub-comparators, to allow locale-specific collating sequences). But I start to question any complexity beyond that. s'marks From jonathan.gibbons at oracle.com Thu Aug 10 00:11:12 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 09 Aug 2017 17:11:12 -0700 Subject: RFR: JDK-8186052: Fix a11y and HTML issues in the java.base/java.lang[.*] packages Message-ID: <598BA4A0.4040702@oracle.com> Please review this proposed change to address accessibility and HTML issues in the java.base java.lang[.*] packages. In general, the changes consist of * update tables to add scope=row|col as appropriate. In some cases, slightly more surgery was needed on the table * fix issues reported by tidy In most cases, this is removing superfluous

elements. Webrev: http://cr.openjdk.java.net/~jjg/8186052/webrev.00/index.html API: http://cr.openjdk.java.net/~jjg/8186052/api.00/index.html -- Jon From jonathan.gibbons at oracle.com Thu Aug 10 00:14:23 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 09 Aug 2017 17:14:23 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages Message-ID: <598BA55F.6050202@oracle.com> Please review this proposed change to address accessibility and HTML issues in the java.base java.io and java.nio[.*] packages. In general, the changes consist of * update tables to add scope=row|col as appropriate. In some cases, slightly more surgery was needed on the table * fix issues reported by tidy In most cases, this is removing superfluous

elements. Webrev: http://cr.openjdk.java.net/~jjg/8185994/webrev.00/index.html API: http://cr.openjdk.java.net/~jjg/8185994/api.00/index.html -- Jon From stuart.marks at oracle.com Thu Aug 10 01:28:19 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Aug 2017 18:28:19 -0700 Subject: RFR: JDK-8186052: Fix a11y and HTML issues in the java.base/java.lang[.*] packages In-Reply-To: <598BA4A0.4040702@oracle.com> References: <598BA4A0.4040702@oracle.com> Message-ID: <6c93bcf3-cea5-8558-8c61-2b5513e3a7d2@oracle.com> On 8/9/17 5:11 PM, Jonathan Gibbons wrote: > Please review this proposed change to address accessibility and HTML issues > in the java.base java.lang[.*] packages. > > In general, the changes consist of > * update tables to add scope=row|col as appropriate. > In some cases, slightly more surgery was needed on the table > * fix issues reported by tidy > In most cases, this is removing superfluous

elements. > > Webrev: http://cr.openjdk.java.net/~jjg/8186052/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8186052/api.00/index.html Hi Jon, These changes look good. In most cases the table surgery was a big improvement. One small quibble I have is with the table in String.split(regex, limit). The limit column has numbers, and the alignment changed from centered to left-aligned, neither of which is really very good. I'd suggest changing this column to be right-aligned, so the negative values in this column will be aligned appropriately. Thanks, s'marks From jonathan.gibbons at oracle.com Thu Aug 10 01:29:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 09 Aug 2017 18:29:31 -0700 Subject: RFR: JDK-8186052: Fix a11y and HTML issues in the java.base/java.lang[.*] packages In-Reply-To: <6c93bcf3-cea5-8558-8c61-2b5513e3a7d2@oracle.com> References: <598BA4A0.4040702@oracle.com> <6c93bcf3-cea5-8558-8c61-2b5513e3a7d2@oracle.com> Message-ID: <598BB6FB.1080402@oracle.com> On 08/09/2017 06:28 PM, Stuart Marks wrote: > On 8/9/17 5:11 PM, Jonathan Gibbons wrote: >> Please review this proposed change to address accessibility and HTML >> issues >> in the java.base java.lang[.*] packages. >> >> In general, the changes consist of >> * update tables to add scope=row|col as appropriate. >> In some cases, slightly more surgery was needed on the table >> * fix issues reported by tidy >> In most cases, this is removing superfluous

elements. >> >> Webrev: http://cr.openjdk.java.net/~jjg/8186052/webrev.00/index.html >> API: http://cr.openjdk.java.net/~jjg/8186052/api.00/index.html > > Hi Jon, > > These changes look good. In most cases the table surgery was a big > improvement. One small quibble I have is with the table in > String.split(regex, limit). The limit column has numbers, and the > alignment changed from centered to left-aligned, neither of which is > really very good. I'd suggest changing this column to be > right-aligned, so the negative values in this column will be aligned > appropriately. > > Thanks, > > s'marks Stuart, Thanks for the suggestion. I'll fix that. -- Jon From stuart.marks at oracle.com Thu Aug 10 01:56:48 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Aug 2017 18:56:48 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages In-Reply-To: <598BA55F.6050202@oracle.com> References: <598BA55F.6050202@oracle.com> Message-ID: <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> On 8/9/17 5:14 PM, Jonathan Gibbons wrote: > Please review this proposed change to address accessibility and HTML issues > in the java.base java.io and java.nio[.*] packages. > > In general, the changes consist of > * update tables to add scope=row|col as appropriate. > In some cases, slightly more surgery was needed on the table > * fix issues reported by tidy > In most cases, this is removing superfluous

elements. > > Webrev: http://cr.openjdk.java.net/~jjg/8185994/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8185994/api.00/index.html Again, changes mostly look good. One small formatting point on DataInput. The numbers in the table should all have similar alignment. Most of the numbers in the table body look centered. I think it would look better if the numbers in the "Bit Values" column headers, and the numbers in the Byte column, were all centered. Since they're all single digits, you can probably get away with centering (unless you want to change them all to right-aligned with padding, or something). s'marks From huizhe.wang at oracle.com Thu Aug 10 03:13:49 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 9 Aug 2017 20:13:49 -0700 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> Message-ID: <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> On 8/9/2017 6:30 AM, Daniel Fuchs wrote: > Hi Joe, > > This not an easy patch to review ;-) Indeed, took several minutes just to copy the webrevs :-) > > Thanks for explaining how you arrived at the final result. > The method you used as described below seems right. > > I haven't clicked through all the files, but instead I had a > look at all the JIRA issues revealed by: > > hg log -k share/classes/com/sun/org/apache/bcel | grep summary | grep > -v Merge > > to see if any of them might have been reverted/invalidated. > So far so good, most of them still seem to be present in > your changes, but I have a doubt about these two: > > https://bugs.openjdk.java.net/browse/JDK-8062608 > https://bugs.openjdk.java.net/browse/JDK-8064516 > > Has the issue been fixed upstream in a different way, or > is the issue no longer relevant, or is it going to appear > again with this patch? Good catch! The original patch came from BCEL, so I indeed assumed this update would get things the right way. As I double-checked, it turns out the additional patches as you listed above fixed issues that BCEL 6.0 hasn't. These issues were revealed by JRocket, did not affect JAXP, however, they are still good changes that we shall keep. I've gone through both of the above to put these changes back into the code. > > Also looking at the JDK fixes brought my attention to > java.xml/share/classes/jdk/xml/internal/SecuritySupport.java > > Your changes are adding these two methods: > I don't know what they are for - and I am not sure they would > work (the brutal cast to ListResourceBundle is dubious). > Fortunately they don't seem to be called by the new code (I > grepped the global patch file). Can you remove them? This is because I removed com/sun/org/apache/bcel/internal/util/SecuritySupport.java that is no longer used by any classes in our version of BCEL. However, a XPath class (XPATHMessages.java) was still using it, I therefore moved the getResourceBundle method that was used into the jdk util class before removing the one in bcel. The ListResourceBundle cast was needed since the XPATHMessages variable was originally declared ListResourceBundle. I've changed that to ResourceBundle and removed the cast. Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev01/ Thanks, Joe > > 234 /** > 235 * Gets a resource bundle using the specified base name, the > default locale, and the caller's class loader. > 236 * @param bundle the base name of the resource bundle, a > fully qualified class name > 237 * @return a resource bundle for the given base name and the > default locale > 238 */ > 239 public static ListResourceBundle getResourceBundle(String > bundle) { > 240 return getResourceBundle(bundle, Locale.getDefault()); > 241 } > 242 > 243 /** > 244 * Gets a resource bundle using the specified base name and > locale, and the caller's class loader. > 245 * @param bundle the base name of the resource bundle, a > fully qualified class name > 246 * @param locale the locale for which a resource bundle is > desired > 247 * @return a resource bundle for the given base name and locale > 248 */ > 249 public static ListResourceBundle getResourceBundle(final > String bundle, final Locale locale) { > 250 return > AccessController.doPrivileged((PrivilegedAction) > () -> { > 251 try { > 252 return > (ListResourceBundle)ResourceBundle.getBundle(bundle, locale); > 253 } catch (MissingResourceException e) { > 254 try { > 255 return > (ListResourceBundle)ResourceBundle.getBundle(bundle, new Locale("en", > "US")); > 256 } catch (MissingResourceException e2) { > 257 throw new MissingResourceException( > 258 "Could not load any resource bundle > by " + bundle, bundle, ""); > 259 } > 260 } > 261 }); > 262 } > > best regards, > > -- daniel > > On 09/08/2017 00:43, huizhe wang wrote: >> Please review an update to BCEL release 6.0 [1]. >> >> The sources are basically that from the release bundle with the >> following exceptions: >> >> * Classes that were not included in the original version are excluded; >> * Classes that are deprecated in BCEL 6.0 are removed; >> * Classes that are used only for the above classes are also removed; >> * Many fields were deprecated in BCEL 6.0 in order to discourage >> direct references, in the JDK, I've removed such deprecation and >> instead made them private/final. >> * BCEL 6.0 applied 'final' to global/local variables pretty >> extensively, which were the only changes to many of the classes. >> * A few Transform classes were updated to adopt to BCEL 6.0. >> * JDK-8162527 [JAXP] XSLT: Investigate why bumping the default class >> file version to 49 (Java 5.0) or higher for bytecode generation >> doesn't work [2] has not been resolved as of this update. Additional >> change [3] is needed before we can move up to possibly Java 5.0. >> >> >> BCEL has been a very old component. This update therefore removed a >> large amount of warnings (900+), which is very helpful to the >> cleaning effort. >> >> All tests passed, including the JCK. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8163121 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/ >> >> >> [1] https://archive.apache.org/dist/commons/bcel/RELEASE-NOTES.txt >> [2] https://bugs.openjdk.java.net/browse/JDK-8162527 >> [3] https://bugs.openjdk.java.net/browse/JDK-8185991 >> >> Thanks, >> Joe >> > From mandy.chung at oracle.com Thu Aug 10 18:49:33 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 10 Aug 2017 11:49:33 -0700 Subject: JDK 9 jar tool issues - "isolated nested class" and creation of a corrupt jar In-Reply-To: References: Message-ID: On 8/9/17 4:50 PM, Tom Hood wrote: > Hi, > > I'm having a couple issues with the jar tool. Version: JDK 9 build 181 > SPARC64 > > Since I'm typing this in, beware of typos. I cannot copy and paste output > as my Solaris 10 box isn't permitted to access the internet. > > (1) isolated nested classes trying to create a multi-release jar I can reproduce the isolated nested class error. It seems a bug in how it validates a nested class when its enclosing class is a nested class. I create a JBS issue to track it: https://bugs.openjdk.java.net/browse/JDK-8186087 We will look into it and provide answers to the ordering of the entry list and also corrupted JAR on sparc64. Mandy From tom.w.hood at gmail.com Thu Aug 10 19:07:50 2017 From: tom.w.hood at gmail.com (Tom Hood) Date: Thu, 10 Aug 2017 12:07:50 -0700 Subject: JDK 9 jar tool issues - "isolated nested class" and creation of a corrupt jar In-Reply-To: References: Message-ID: Glad you were able to reproduce it. Thanks for creating the JBS issue. On Thu, Aug 10, 2017 at 11:49 AM, mandy chung wrote: > > > On 8/9/17 4:50 PM, Tom Hood wrote: > >> Hi, >> >> I'm having a couple issues with the jar tool. Version: JDK 9 build 181 >> SPARC64 >> >> Since I'm typing this in, beware of typos. I cannot copy and paste output >> as my Solaris 10 box isn't permitted to access the internet. >> >> (1) isolated nested classes trying to create a multi-release jar >> > > I can reproduce the isolated nested class error. It seems a bug in how > it validates a nested class when its enclosing class is a nested class. I > create a JBS issue to track it: > https://bugs.openjdk.java.net/browse/JDK-8186087 > > We will look into it and provide answers to the ordering of the entry list > and also corrupted JAR on sparc64. > > Mandy > From brian.burkhalter at oracle.com Thu Aug 10 20:00:22 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Aug 2017 13:00:22 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages In-Reply-To: <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> References: <598BA55F.6050202@oracle.com> <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> Message-ID: On Aug 9, 2017, at 6:56 PM, Stuart Marks wrote: > On 8/9/17 5:14 PM, Jonathan Gibbons wrote: >> Please review this proposed change to address accessibility and HTML issues >> in the java.base java.io and java.nio[.*] packages. >> >> In general, the changes consist of >> * update tables to add scope=row|col as appropriate. >> In some cases, slightly more surgery was needed on the table >> * fix issues reported by tidy >> In most cases, this is removing superfluous

elements. >> >> Webrev: http://cr.openjdk.java.net/~jjg/8185994/webrev.00/index.html >> API: http://cr.openjdk.java.net/~jjg/8185994/api.00/index.html > > Again, changes mostly look good. One small formatting point on DataInput. The numbers in the table should all have similar alignment. Most of the numbers in the table body look centered. I think it would look better if the numbers in the "Bit Values" column headers, and the numbers in the Byte column, were all centered. Since they're all single digits, you can probably get away with centering (unless you want to change them all to right-aligned with padding, or something). I concur with Stuart that this is the only problem area. Centering the Byte column would be good for sure. Centering the ?Bit Values? entries ?bits x-y? could work if they were aligned in a visually appealing manner, e.g., centered with respect to the same vertical. Another possibility would be to have a separate cell for each row-column position and put ?b6?, ?b5?, etc. in the cells perhaps with a footnote below the table about the notation unless it?s deemed obvious (maybe use subscript elements b6, etc.?). Brian From jonathan.gibbons at oracle.com Thu Aug 10 20:59:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 Aug 2017 13:59:24 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages In-Reply-To: References: <598BA55F.6050202@oracle.com> <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> Message-ID: <598CC92C.7080607@oracle.com> I have posted an update to the webrev and API. The change is in DataInput ... I have tweaked the position of the text in the cells of that initial table. I would prefer not to iterate further on the layout of this table, since the changeset is primarily about addressing accessibility and HTML correctness issues. -- Jon On 08/10/2017 01:00 PM, Brian Burkhalter wrote: > On Aug 9, 2017, at 6:56 PM, Stuart Marks > wrote: > >> On 8/9/17 5:14 PM, Jonathan Gibbons wrote: >>> Please review this proposed change to address accessibility and HTML >>> issues >>> in the java.base java.io and java.nio[.*] packages. >>> >>> In general, the changes consist of >>> * update tables to add scope=row|col as appropriate. >>> In some cases, slightly more surgery was needed on the table >>> * fix issues reported by tidy >>> In most cases, this is removing superfluous

elements. >>> >>> Webrev:http://cr.openjdk.java.net/~jjg/8185994/webrev.00/index.html >>> >>> API:http://cr.openjdk.java.net/~jjg/8185994/api.00/index.html >>> >> >> Again, changes mostly look good. One small formatting point on >> DataInput. The numbers in the table should all have similar >> alignment. Most of the numbers in the table body look centered. I >> think it would look better if the numbers in the "Bit Values" column >> headers, and the numbers in the Byte column, were all centered. Since >> they're all single digits, you can probably get away with centering >> (unless you want to change them all to right-aligned with padding, or >> something). > > I concur with Stuart that this is the only problem area. Centering the > Byte column would be good for sure. Centering the ?Bit Values? entries > ?bits x-y? could work if they were aligned in a visually appealing > manner, e.g., centered with respect to the same vertical. Another > possibility would be to have a separate cell for each row-column > position and put ?b6?, ?b5?, etc. in the cells perhaps with a footnote > below the table about the notation unless it?s deemed obvious (maybe > use subscript elements b6, etc.?). > > Brian From jonathan.gibbons at oracle.com Thu Aug 10 21:00:56 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 Aug 2017 14:00:56 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages In-Reply-To: <598CC92C.7080607@oracle.com> References: <598BA55F.6050202@oracle.com> <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> <598CC92C.7080607@oracle.com> Message-ID: <598CC988.4000002@oracle.com> Ooops ... forgot the updated links: Webrev: http://cr.openjdk.java.net/~jjg/8185994/webrev.01/index.html API: http://cr.openjdk.java.net/~jjg/8185994/api.01/index.html -- Jon On 08/10/2017 01:59 PM, Jonathan Gibbons wrote: > I have posted an update to the webrev and API. > > The change is in DataInput ... I have tweaked the position of the text > in the cells of that initial table. > I would prefer not to iterate further on the layout of this table, > since the changeset is primarily > about addressing accessibility and HTML correctness issues. > > -- Jon > > > On 08/10/2017 01:00 PM, Brian Burkhalter wrote: >> On Aug 9, 2017, at 6:56 PM, Stuart Marks > > wrote: >> >>> On 8/9/17 5:14 PM, Jonathan Gibbons wrote: >>>> Please review this proposed change to address accessibility and >>>> HTML issues >>>> in the java.base java.io and java.nio[.*] packages. >>>> >>>> In general, the changes consist of >>>> * update tables to add scope=row|col as appropriate. >>>> In some cases, slightly more surgery was needed on the table >>>> * fix issues reported by tidy >>>> In most cases, this is removing superfluous

elements. >>>> >>>> Webrev:http://cr.openjdk.java.net/~jjg/8185994/webrev.00/index.html >>>> >>>> API:http://cr.openjdk.java.net/~jjg/8185994/api.00/index.html >>>> >>> >>> Again, changes mostly look good. One small formatting point on >>> DataInput. The numbers in the table should all have similar >>> alignment. Most of the numbers in the table body look centered. I >>> think it would look better if the numbers in the "Bit Values" column >>> headers, and the numbers in the Byte column, were all centered. >>> Since they're all single digits, you can probably get away with >>> centering (unless you want to change them all to right-aligned with >>> padding, or something). >> >> I concur with Stuart that this is the only problem area. Centering >> the Byte column would be good for sure. Centering the ?Bit Values? >> entries ?bits x-y? could work if they were aligned in a visually >> appealing manner, e.g., centered with respect to the same vertical. >> Another possibility would be to have a separate cell for each >> row-column position and put ?b6?, ?b5?, etc. in the cells perhaps >> with a footnote below the table about the notation unless it?s deemed >> obvious (maybe use subscript elements b6, etc.?). >> >> Brian > From brian.burkhalter at oracle.com Thu Aug 10 21:01:33 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Aug 2017 14:01:33 -0700 Subject: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages In-Reply-To: <598CC92C.7080607@oracle.com> References: <598BA55F.6050202@oracle.com> <0476006e-0439-6f08-8327-d3cd0332897d@oracle.com> <598CC92C.7080607@oracle.com> Message-ID: I think it looks fine now. Brian On Aug 10, 2017, at 1:59 PM, Jonathan Gibbons wrote: > I have posted an update to the webrev and API. > > The change is in DataInput ... I have tweaked the position of the text in the cells of that initial table. > I would prefer not to iterate further on the layout of this table, since the changeset is primarily > about addressing accessibility and HTML correctness issues. From jonathan.gibbons at oracle.com Thu Aug 10 21:02:56 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 Aug 2017 14:02:56 -0700 Subject: RFR: JDK-8186052: Fix a11y and HTML issues in the java.base/java.lang[.*] packages In-Reply-To: <6c93bcf3-cea5-8558-8c61-2b5513e3a7d2@oracle.com> References: <598BA4A0.4040702@oracle.com> <6c93bcf3-cea5-8558-8c61-2b5513e3a7d2@oracle.com> Message-ID: <598CCA00.3000901@oracle.com> Update: addresses Stuart's comment for String.split Webrev: http://cr.openjdk.java.net/~jjg/8186052/webrev.01/index.html API: http://cr.openjdk.java.net/~jjg/8186052/api.01/index.html -- Jon On 08/09/2017 06:28 PM, Stuart Marks wrote: > On 8/9/17 5:11 PM, Jonathan Gibbons wrote: >> Please review this proposed change to address accessibility and HTML >> issues >> in the java.base java.lang[.*] packages. >> >> In general, the changes consist of >> * update tables to add scope=row|col as appropriate. >> In some cases, slightly more surgery was needed on the table >> * fix issues reported by tidy >> In most cases, this is removing superfluous

elements. >> >> Webrev: http://cr.openjdk.java.net/~jjg/8186052/webrev.00/index.html >> API: http://cr.openjdk.java.net/~jjg/8186052/api.00/index.html > > Hi Jon, > > These changes look good. In most cases the table surgery was a big > improvement. One small quibble I have is with the table in > String.split(regex, limit). The limit column has numbers, and the > alignment changed from centered to left-aligned, neither of which is > really very good. I'd suggest changing this column to be > right-aligned, so the negative values in this column will be aligned > appropriately. > > Thanks, > > s'marks From igor.ignatyev at oracle.com Fri Aug 11 04:02:38 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:02:38 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 Message-ID: http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html > 14 lines changed: 1 ins; 0 del; 13 mod; Hi all, could you please review this small patch which bumps up jtreg version? besides updating jib profiles and all TEST.ROOT files, the fix updates hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to rely on having "library" test.Empty class in 'test.classes' and put test.Empty class in the workdir instead. testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] Thanks, -- Igor From david.holmes at oracle.com Fri Aug 11 04:22:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 14:22:27 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> Hi Igor, On 11/08/2017 2:02 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >> 14 lines changed: 1 ins; 0 del; 13 mod; > > Hi all, > > could you please review this small patch which bumps up jtreg version? > besides updating jib profiles and all TEST.ROOT files, That all looks fine (though deploy should not be in there). > the fix updates > hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to > rely on having "library" test.Empty class in 'test.classes' and put > test.Empty class in the workdir instead. Sorry I'm not following this part. You made two changes: 1. Added @library /test/lib What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? Thanks, David ----- > testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Aug 11 04:31:05 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:31:05 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> Message-ID: <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> > On Aug 10, 2017, at 9:22 PM, David Holmes wrote: > > Hi Igor, > > On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>> 14 lines changed: 1 ins; 0 del; 13 mod; >> Hi all, >> could you please review this small patch which bumps up jtreg version? >> besides updating jib profiles and all TEST.ROOT files, > > That all looks fine (though deploy should not be in there). > >> the fix updates >> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >> rely on having "library" test.Empty class in 'test.classes' and put >> test.Empty class in the workdir instead. > > Sorry I'm not following this part. You made two changes: > > 1. Added @library /test/lib /test/lib is needed for ClassFileInstaller. > > What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. > > How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. > > Thanks, > David > ----- > >> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >> Thanks, >> -- Igor From david.holmes at oracle.com Fri Aug 11 04:46:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 14:46:59 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> Message-ID: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: > >> On Aug 10, 2017, at 9:22 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>> Hi all, >>> could you please review this small patch which bumps up jtreg version? >>> besides updating jib profiles and all TEST.ROOT files, >> >> That all looks fine (though deploy should not be in there). >> >>> the fix updates >>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >>> rely on having "library" test.Empty class in 'test.classes' and put >>> test.Empty class in the workdir instead. >> >> Sorry I'm not following this part. You made two changes: >> >> 1. Added @library /test/lib > /test/lib is needed for ClassFileInstaller. Okay. >> >> What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) > existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. Okay. >> >> 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. >> >> How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? > test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. Sorry still don't understand the change. Where does: @build test.Empty place Empty.class? If not in test.classes then how has this test ever passed? I'm assuming the change is needed because it no longer passes with the updated jtreg. Thanks, David >> >> Thanks, >> David >> ----- >> >>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Fri Aug 11 04:55:04 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:55:04 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> Message-ID: > On Aug 10, 2017, at 9:46 PM, David Holmes wrote: > > On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>> On Aug 10, 2017, at 9:22 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>> Hi all, >>>> could you please review this small patch which bumps up jtreg version? >>>> besides updating jib profiles and all TEST.ROOT files, >>> >>> That all looks fine (though deploy should not be in there). >>> >>>> the fix updates >>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >>>> rely on having "library" test.Empty class in 'test.classes' and put >>>> test.Empty class in the workdir instead. >>> >>> Sorry I'm not following this part. You made two changes: >>> >>> 1. Added @library /test/lib >> /test/lib is needed for ClassFileInstaller. > > Okay. > >>> >>> What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) >> existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > Okay. > >>> >>> 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. >>> >>> How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? >> test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. > > Sorry still don't understand the change. Where does: > > @build test.Empty > > place Empty.class? If not in test.classes then how has this test ever passed? I'm assuming the change is needed because it no longer passes with the updated jtreg. build places it in a library dedicated directory, in this case it will be 'JTwork/classes//runtime/Metaspace/classes', but 'test.classes' points to 'JTwork/classes//runtime/Metaspace/FragmentMetaspaceSimple.d'. 'test.class.path' will have both (separated by path separator), classpath has these two paths and couple others. > > Thanks, > David > >>> >>> Thanks, >>> David >>> ----- >>> >>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>> Thanks, >>>> -- Igor From ioi.lam at oracle.com Fri Aug 11 05:23:14 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Aug 2017 22:23:14 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> Message-ID: <55822d40-565e-401d-d807-fbab0749d987@oracle.com> On 8/10/17 9:46 PM, David Holmes wrote: > On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >> >>> On Aug 10, 2017, at 9:22 PM, David Holmes >>> wrote: >>> >>> Hi Igor, >>> >>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>> Hi all, >>>> could you please review this small patch which bumps up jtreg version? >>>> besides updating jib profiles and all TEST.ROOT files, >>> >>> That all looks fine (though deploy should not be in there). >>> >>>> the fix updates >>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>> not to >>>> rely on having "library" test.Empty class in 'test.classes' and put >>>> test.Empty class in the workdir instead. >>> >>> Sorry I'm not following this part. You made two changes: >>> >>> 1. Added @library /test/lib >> /test/lib is needed for ClassFileInstaller. > > Okay. > >>> >>> What is this doing? (For that matter what is the existing "classes" >>> entry supposed to mean ??? how is "classes" a library?) >> existing 'classes' is the directory in >> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > Okay. > >>> >>> 2. Instead of the test reading from test.classes you are using the >>> ClassfileInstaller to copy the class to the working directory. >>> >>> How does this make a difference to anything? If the test wouldn't >>> find the class in test.classes, doesn't that mean ClassfileInstaller >>> will also fail to find it? >> test.classes points to the directory w/ classes from a test, but not >> from test libraries. directories w/ all needed classes (either from a >> test or from libraries) are added to classpath and 'test.class.path'. >> ClassFileInstaller uses class loader to get resources, test.Empty >> will be in CP, so ClassFileInstaller will have access to it. > > Sorry still don't understand the change. Where does: > > @build test.Empty > > place Empty.class? If not in test.classes then how has this test ever > passed? I'm assuming the change is needed because it no longer passes > with the updated jtreg. > Hi David, 27 * @build test.Empty puts test.Empty class somewhere in the classpath 28 * @run driver ClassFileInstaller test.Empty ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") to read the contents of this class (from the CLASSPATH), and writes it to ./test/Empty.class 55 String fileName = "test" + sep + "Empty.class"; 56 File file = new File(fileName); 57 byte buff[] = read(file); here the test reads "./test/Empty.class" into a buffer. (When the test runs, the current directory is the "scratch" directory). The old version of this test assumed that JTREG builds the Empty.class into a certain location, but that has changed with the jtreg 4.2 b08 feature. ClassFileInstaller is the proper way of reading the bytes of class files, and has been used by most other test cases. FragmentMetaspaceSimple seems to be the only exception. Thanks - Ioi > Thanks, > David > >>> >>> Thanks, >>> David >>> ----- >>> >>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>> Thanks, >>>> -- Igor >> From david.holmes at oracle.com Fri Aug 11 05:29:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 15:29:27 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <55822d40-565e-401d-d807-fbab0749d987@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> <55822d40-565e-401d-d807-fbab0749d987@oracle.com> Message-ID: <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> Thanks Ioi, and Igor, for clarifying. David On 11/08/2017 3:23 PM, Ioi Lam wrote: > > > On 8/10/17 9:46 PM, David Holmes wrote: >> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>> >>>> On Aug 10, 2017, at 9:22 PM, David Holmes >>>> wrote: >>>> >>>> Hi Igor, >>>> >>>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>>> Hi all, >>>>> could you please review this small patch which bumps up jtreg version? >>>>> besides updating jib profiles and all TEST.ROOT files, >>>> >>>> That all looks fine (though deploy should not be in there). >>>> >>>>> the fix updates >>>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>>> not to >>>>> rely on having "library" test.Empty class in 'test.classes' and put >>>>> test.Empty class in the workdir instead. >>>> >>>> Sorry I'm not following this part. You made two changes: >>>> >>>> 1. Added @library /test/lib >>> /test/lib is needed for ClassFileInstaller. >> >> Okay. >> >>>> >>>> What is this doing? (For that matter what is the existing "classes" >>>> entry supposed to mean ??? how is "classes" a library?) >>> existing 'classes' is the directory in >>> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. >> >> Okay. >> >>>> >>>> 2. Instead of the test reading from test.classes you are using the >>>> ClassfileInstaller to copy the class to the working directory. >>>> >>>> How does this make a difference to anything? If the test wouldn't >>>> find the class in test.classes, doesn't that mean ClassfileInstaller >>>> will also fail to find it? >>> test.classes points to the directory w/ classes from a test, but not >>> from test libraries. directories w/ all needed classes (either from a >>> test or from libraries) are added to classpath and 'test.class.path'. >>> ClassFileInstaller uses class loader to get resources, test.Empty >>> will be in CP, so ClassFileInstaller will have access to it. >> >> Sorry still don't understand the change. Where does: >> >> @build test.Empty >> >> place Empty.class? If not in test.classes then how has this test ever >> passed? I'm assuming the change is needed because it no longer passes >> with the updated jtreg. >> > Hi David, > > 27 * @build test.Empty > > puts test.Empty class somewhere in the classpath > > 28 * @run driver ClassFileInstaller test.Empty > > ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") to > read the contents of this class (from the CLASSPATH), and writes it to > ./test/Empty.class > > 55 String fileName = "test" + sep + "Empty.class"; > 56 File file = new File(fileName); > 57 byte buff[] = read(file); > > here the test reads "./test/Empty.class" into a buffer. (When the test > runs, the current directory is the "scratch" directory). > > The old version of this test assumed that JTREG builds the Empty.class > into a certain location, but that has changed with the jtreg 4.2 b08 > feature. > > ClassFileInstaller is the proper way of reading the bytes of class > files, and has been used by most other test cases. > FragmentMetaspaceSimple seems to be the only exception. > > Thanks > - Ioi > > > > >> Thanks, >> David >> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>>> Thanks, >>>>> -- Igor >>> > From frank.yuan at oracle.com Fri Aug 11 08:08:32 2017 From: frank.yuan at oracle.com (Frank Yuan) Date: Fri, 11 Aug 2017 16:08:32 +0800 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> Message-ID: <038b01d31279$081e69b0$185b3d10$@oracle.com> Hi Joe and Daniel > > So far so good, most of them still seem to be present in > > your changes, but I have a doubt about these two: > > > > https://bugs.openjdk.java.net/browse/JDK-8062608 > > https://bugs.openjdk.java.net/browse/JDK-8064516 > > > > Has the issue been fixed upstream in a different way, or > > is the issue no longer relevant, or is it going to appear > > again with this patch? > > Good catch! The original patch came from BCEL, so I indeed assumed this > update would get things the right way. As I double-checked, it turns out > the additional patches as you listed above fixed issues that BCEL 6.0 > hasn't. These issues were revealed by JRocket, did not affect JAXP, > however, they are still good changes that we shall keep. I've gone > through both of the above to put these changes back into the code. > IIUC JDK-8062608 and JDK-8064516 are related to JDK-8003147 but for JRocket, the first webrev(http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/) looks different with the fix of JDK-8003147, however we have the relevant test in the repo, i.e. http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/tip/test/javax/xml/jaxp/unittest/parsers/Bug8003147Test.java, since all tests were passed, I assume the first webrev worked for JDK-8003147, certainly the second webrev looks good too :) Thanks Frank From daniel.fuchs at oracle.com Fri Aug 11 10:31:40 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Aug 2017 11:31:40 +0100 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> Message-ID: <4ff20adb-f51c-464d-f416-be72fb4d3c63@oracle.com> Hi Joe, Thanks, looks fine now! best regards, -- daniel On 10/08/2017 04:13, huizhe wang wrote: > > On 8/9/2017 6:30 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> This not an easy patch to review ;-) > > Indeed, took several minutes just to copy the webrevs :-) > >> >> Thanks for explaining how you arrived at the final result. >> The method you used as described below seems right. >> >> I haven't clicked through all the files, but instead I had a >> look at all the JIRA issues revealed by: >> >> hg log -k share/classes/com/sun/org/apache/bcel | grep summary | grep >> -v Merge >> >> to see if any of them might have been reverted/invalidated. >> So far so good, most of them still seem to be present in >> your changes, but I have a doubt about these two: >> >> https://bugs.openjdk.java.net/browse/JDK-8062608 >> https://bugs.openjdk.java.net/browse/JDK-8064516 >> >> Has the issue been fixed upstream in a different way, or >> is the issue no longer relevant, or is it going to appear >> again with this patch? > > Good catch! The original patch came from BCEL, so I indeed assumed this > update would get things the right way. As I double-checked, it turns out > the additional patches as you listed above fixed issues that BCEL 6.0 > hasn't. These issues were revealed by JRocket, did not affect JAXP, > however, they are still good changes that we shall keep. I've gone > through both of the above to put these changes back into the code. > >> >> Also looking at the JDK fixes brought my attention to >> java.xml/share/classes/jdk/xml/internal/SecuritySupport.java >> >> Your changes are adding these two methods: >> I don't know what they are for - and I am not sure they would >> work (the brutal cast to ListResourceBundle is dubious). >> Fortunately they don't seem to be called by the new code (I >> grepped the global patch file). Can you remove them? > > This is because I removed > com/sun/org/apache/bcel/internal/util/SecuritySupport.java that is no > longer used by any classes in our version of BCEL. However, a XPath > class (XPATHMessages.java) was still using it, I therefore moved the > getResourceBundle method that was used into the jdk util class before > removing the one in bcel. > > The ListResourceBundle cast was needed since the XPATHMessages variable > was originally declared ListResourceBundle. I've changed that to > ResourceBundle and removed the cast. > > Here's the updated webrev: > http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev01/ > > Thanks, > Joe > >> >> 234 /** >> 235 * Gets a resource bundle using the specified base name, the >> default locale, and the caller's class loader. >> 236 * @param bundle the base name of the resource bundle, a >> fully qualified class name >> 237 * @return a resource bundle for the given base name and the >> default locale >> 238 */ >> 239 public static ListResourceBundle getResourceBundle(String >> bundle) { >> 240 return getResourceBundle(bundle, Locale.getDefault()); >> 241 } >> 242 >> 243 /** >> 244 * Gets a resource bundle using the specified base name and >> locale, and the caller's class loader. >> 245 * @param bundle the base name of the resource bundle, a >> fully qualified class name >> 246 * @param locale the locale for which a resource bundle is >> desired >> 247 * @return a resource bundle for the given base name and locale >> 248 */ >> 249 public static ListResourceBundle getResourceBundle(final >> String bundle, final Locale locale) { >> 250 return >> AccessController.doPrivileged((PrivilegedAction) >> () -> { >> 251 try { >> 252 return >> (ListResourceBundle)ResourceBundle.getBundle(bundle, locale); >> 253 } catch (MissingResourceException e) { >> 254 try { >> 255 return >> (ListResourceBundle)ResourceBundle.getBundle(bundle, new Locale("en", >> "US")); >> 256 } catch (MissingResourceException e2) { >> 257 throw new MissingResourceException( >> 258 "Could not load any resource bundle >> by " + bundle, bundle, ""); >> 259 } >> 260 } >> 261 }); >> 262 } >> >> best regards, >> >> -- daniel >> >> On 09/08/2017 00:43, huizhe wang wrote: >>> Please review an update to BCEL release 6.0 [1]. >>> >>> The sources are basically that from the release bundle with the >>> following exceptions: >>> >>> * Classes that were not included in the original version are excluded; >>> * Classes that are deprecated in BCEL 6.0 are removed; >>> * Classes that are used only for the above classes are also removed; >>> * Many fields were deprecated in BCEL 6.0 in order to discourage >>> direct references, in the JDK, I've removed such deprecation and >>> instead made them private/final. >>> * BCEL 6.0 applied 'final' to global/local variables pretty >>> extensively, which were the only changes to many of the classes. >>> * A few Transform classes were updated to adopt to BCEL 6.0. >>> * JDK-8162527 [JAXP] XSLT: Investigate why bumping the default class >>> file version to 49 (Java 5.0) or higher for bytecode generation >>> doesn't work [2] has not been resolved as of this update. Additional >>> change [3] is needed before we can move up to possibly Java 5.0. >>> >>> >>> BCEL has been a very old component. This update therefore removed a >>> large amount of warnings (900+), which is very helpful to the >>> cleaning effort. >>> >>> All tests passed, including the JCK. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8163121 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/ >>> >>> >>> [1] https://archive.apache.org/dist/commons/bcel/RELEASE-NOTES.txt >>> [2] https://bugs.openjdk.java.net/browse/JDK-8162527 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8185991 >>> >>> Thanks, >>> Joe >>> >> > From Roger.Riggs at Oracle.com Fri Aug 11 13:00:36 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Aug 2017 09:00:36 -0400 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> <55822d40-565e-401d-d807-fbab0749d987@oracle.com> <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> Message-ID: Hi Igor, In (some of) the TEST.ROOT files, maintenance of the files can be simplified by removing the version number from the comment. The version that is in jaxp is reasonable: "# Minimum jtreg version" and should be applied to the hotspot, jdk, langtools, and nashorn TEST.ROOT files. Thanks, Roger On 8/11/2017 1:29 AM, David Holmes wrote: > Thanks Ioi, and Igor, for clarifying. > > David > > > On 11/08/2017 3:23 PM, Ioi Lam wrote: >> >> >> On 8/10/17 9:46 PM, David Holmes wrote: >>> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>>> >>>>> On Aug 10, 2017, at 9:22 PM, David Holmes >>>>> wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>>>> Hi all, >>>>>> could you please review this small patch which bumps up jtreg >>>>>> version? >>>>>> besides updating jib profiles and all TEST.ROOT files, >>>>> >>>>> That all looks fine (though deploy should not be in there). >>>>> >>>>>> the fix updates >>>>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>>>> not to >>>>>> rely on having "library" test.Empty class in 'test.classes' and put >>>>>> test.Empty class in the workdir instead. >>>>> >>>>> Sorry I'm not following this part. You made two changes: >>>>> >>>>> 1. Added @library /test/lib >>>> /test/lib is needed for ClassFileInstaller. >>> >>> Okay. >>> >>>>> >>>>> What is this doing? (For that matter what is the existing >>>>> "classes" entry supposed to mean ??? how is "classes" a library?) >>>> existing 'classes' is the directory in >>>> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. >>> >>> Okay. >>> >>>>> >>>>> 2. Instead of the test reading from test.classes you are using the >>>>> ClassfileInstaller to copy the class to the working directory. >>>>> >>>>> How does this make a difference to anything? If the test wouldn't >>>>> find the class in test.classes, doesn't that mean >>>>> ClassfileInstaller will also fail to find it? >>>> test.classes points to the directory w/ classes from a test, but >>>> not from test libraries. directories w/ all needed classes (either >>>> from a test or from libraries) are added to classpath and >>>> 'test.class.path'. ClassFileInstaller uses class loader to get >>>> resources, test.Empty will be in CP, so ClassFileInstaller will >>>> have access to it. >>> >>> Sorry still don't understand the change. Where does: >>> >>> @build test.Empty >>> >>> place Empty.class? If not in test.classes then how has this test >>> ever passed? I'm assuming the change is needed because it no longer >>> passes with the updated jtreg. >>> >> Hi David, >> >> 27 * @build test.Empty >> >> puts test.Empty class somewhere in the classpath >> >> 28 * @run driver ClassFileInstaller test.Empty >> >> ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") >> to read the contents of this class (from the CLASSPATH), and writes >> it to ./test/Empty.class >> >> 55 String fileName = "test" + sep + "Empty.class"; >> 56 File file = new File(fileName); >> 57 byte buff[] = read(file); >> >> here the test reads "./test/Empty.class" into a buffer. (When the >> test runs, the current directory is the "scratch" directory). >> >> The old version of this test assumed that JTREG builds the >> Empty.class into a certain location, but that has changed with the >> jtreg 4.2 b08 feature. >> >> ClassFileInstaller is the proper way of reading the bytes of class >> files, and has been used by most other test cases. >> FragmentMetaspaceSimple seems to be the only exception. >> >> Thanks >> - Ioi >> >> >> >> >>> Thanks, >>> David >>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>>>> Thanks, >>>>>> -- Igor >>>> >> From stuart.marks at oracle.com Fri Aug 11 18:25:46 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Aug 2017 11:25:46 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups Message-ID: This is an old spec bug. The Object.wait spec lists several different reasons a thread could be awakened, but it omits spurious wakeup -- even though spurious wakeup is described later on. The fix is simply to add spurious wakeup to the list. There is some discussion in the original bug report: https://bugs.openjdk.java.net/browse/JDK-6344935 Patch appended below. Thanks, s'marks # HG changeset patch # User smarks # Date 1502475871 25200 # Fri Aug 11 11:24:31 2017 -0700 # Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e # Parent 27b08ab97a607df3a4abff83d8d1a2a1882e5bf1 6344935: Clarify Object.wait javadoc with respect to spurious wakeups Reviewed-by: XXX diff -r 27b08ab97a60 -r ebd66cd27b29 src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 09:04:47 2017 -0700 +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 11:24:31 2017 -0700 @@ -318,7 +318,7 @@ * place itself in the wait set for this object and then to relinquish * any and all synchronization claims on this object. Thread T * becomes disabled for thread scheduling purposes and lies dormant - * until one of four things happens: + * until one of five things happens: *

    *
  • Some other thread invokes the {@code notify} method for this * object and thread T happens to be arbitrarily chosen as @@ -330,7 +330,9 @@ *
  • The specified amount of real time has elapsed, more or less. If * {@code timeout} is zero, however, then real time is not taken into * consideration and the thread simply waits until notified. + *
  • Thread T is awakened spuriously. (See below.) *
+ *

* The thread T is then removed from the wait set for this * object and re-enabled for thread scheduling. It then competes in the * usual manner with other threads for the right to synchronize on the From jonathan.gibbons at oracle.com Fri Aug 11 18:28:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Aug 2017 11:28:21 -0700 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages Message-ID: <598DF745.40800@oracle.com> Please review the following changes to fix accessibility and HTML issues in the java.math, java.text and java.time packages. Mostly, it's "more of the same", setting scope=row|col on tables. One bigger change is in DateTimeFormatter, to change a preformatted ASCII table into a standard HTML table. JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ -- Jon From lance.andersen at oracle.com Fri Aug 11 18:30:22 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 14:30:22 -0400 Subject: RFR JDK-8184120 : javax.transaction.xa.Xid constants reference obsolete method names Message-ID: <2F650FC9-7DD4-4BD4-BBB4-F97024481240@oracle.com> Hi all The following change was addressed in the JTA 1.0.1B update but looks like the field descriptions were missed when the method names changed. The CSR for this change has also been approved. ????????? hg diff diff -r 74988518da9a src/java.sql/share/classes/javax/transaction/xa/Xid.java --- a/src/java.sql/share/classes/javax/transaction/xa/Xid.java Tue Aug 01 15:59:07 2017 -0700 +++ b/src/java.sql/share/classes/javax/transaction/xa/Xid.java Fri Aug 04 14:01:14 2017 -0400 @@ -38,12 +38,12 @@ public interface Xid { /** - * Maximum number of bytes returned by getGtrid. + * Maximum number of bytes returned by {@link #getGlobalTransactionId }. */ final static int MAXGTRIDSIZE = 64; /** - * Maximum number of bytes returned by getBqual. + * Maximum number of bytes returned by {@link #getBranchQualifier }. */ final static int MAXBQUALSIZE = 64; ???????????? 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 Fri Aug 11 18:31:21 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 14:31:21 -0400 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: <9C41BB78-9853-4C89-95CB-EE19468CB447@oracle.com> Looks fine Stuart > On Aug 11, 2017, at 2:25 PM, Stuart Marks wrote: > > This is an old spec bug. The Object.wait spec lists several different reasons a thread could be awakened, but it omits spurious wakeup -- even though spurious wakeup is described later on. The fix is simply to add spurious wakeup to the list. > > There is some discussion in the original bug report: > > https://bugs.openjdk.java.net/browse/JDK-6344935 > > Patch appended below. > > Thanks, > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1502475871 25200 > # Fri Aug 11 11:24:31 2017 -0700 > # Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e > # Parent 27b08ab97a607df3a4abff83d8d1a2a1882e5bf1 > 6344935: Clarify Object.wait javadoc with respect to spurious wakeups > Reviewed-by: XXX > > diff -r 27b08ab97a60 -r ebd66cd27b29 src/java.base/share/classes/java/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 09:04:47 2017 -0700 > +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 11:24:31 2017 -0700 > @@ -318,7 +318,7 @@ > * place itself in the wait set for this object and then to relinquish > * any and all synchronization claims on this object. Thread T > * becomes disabled for thread scheduling purposes and lies dormant > - * until one of four things happens: > + * until one of five things happens: > *

    > *
  • Some other thread invokes the {@code notify} method for this > * object and thread T happens to be arbitrarily chosen as > @@ -330,7 +330,9 @@ > *
  • The specified amount of real time has elapsed, more or less. If > * {@code timeout} is zero, however, then real time is not taken into > * consideration and the thread simply waits until notified. > + *
  • Thread T is awakened spuriously. (See below.) > *
> + *

> * The thread T is then removed from the wait set for this > * object and re-enabled for thread scheduling. It then competes in the > * usual manner with other threads for the right to synchronize on the > 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 Aug 11 18:44:59 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 14:44:59 -0400 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: <598DF745.40800@oracle.com> References: <598DF745.40800@oracle.com> Message-ID: <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> Hi Jon, Looks OK overall Any thoughts on centering some of the column values such as in RoundingMode at some point? DateTimeFormatter looks much nicer :-) Best Lance > On Aug 11, 2017, at 2:28 PM, Jonathan Gibbons wrote: > > Please review the following changes to fix accessibility and HTML issues in the > java.math, java.text and java.time packages. > > Mostly, it's "more of the same", setting scope=row|col on tables. > > One bigger change is in DateTimeFormatter, to change a preformatted ASCII > table into a standard HTML table. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 > Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ > > -- Jon 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 Aug 11 18:45:06 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 11 Aug 2017 11:45:06 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: On 8/11/17 11:25 AM, Stuart Marks wrote: > > diff -r 27b08ab97a60 -r ebd66cd27b29 > src/java.base/share/classes/java/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 > 09:04:47 2017 -0700 > +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 > 11:24:31 2017 -0700 > @@ -318,7 +318,7 @@ > * place itself in the wait set for this object and then to > relinquish > * any and all synchronization claims on this object. Thread > T > * becomes disabled for thread scheduling purposes and lies dormant > - * until one of four things happens: > + * until one of five things happens: Perhaps to say "until one of the following happens" to avoid the count. > *

    > *
  • Some other thread invokes the {@code notify} method for this > * object and thread T happens to be arbitrarily > chosen as > @@ -330,7 +330,9 @@ > *
  • The specified amount of real time has elapsed, more or > less. If > * {@code timeout} is zero, however, then real time is not taken > into > * consideration and the thread simply waits until notified. > + *
  • Thread T is awakened spuriously. (See below.) > *
> + *

> * The thread T is then removed from the wait set for > this > * object and re-enabled for thread scheduling. It then competes > in the > * usual manner with other threads for the right to synchronize > on the > Looks fine. Mandy From martinrb at google.com Fri Aug 11 18:50:26 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Aug 2017 11:50:26 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: Can we align the wording with existing wording in either LockSupport or Condition? On Fri, Aug 11, 2017 at 11:25 AM, Stuart Marks wrote: > This is an old spec bug. The Object.wait spec lists several different > reasons a thread could be awakened, but it omits spurious wakeup -- even > though spurious wakeup is described later on. The fix is simply to add > spurious wakeup to the list. > > There is some discussion in the original bug report: > > https://bugs.openjdk.java.net/browse/JDK-6344935 > > Patch appended below. > > Thanks, > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1502475871 25200 > # Fri Aug 11 11:24:31 2017 -0700 > # Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e > # Parent 27b08ab97a607df3a4abff83d8d1a2a1882e5bf1 > 6344935: Clarify Object.wait javadoc with respect to spurious wakeups > Reviewed-by: XXX > > diff -r 27b08ab97a60 -r ebd66cd27b29 src/java.base/share/classes/ja > va/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 > 09:04:47 2017 -0700 > +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 > 11:24:31 2017 -0700 > @@ -318,7 +318,7 @@ > * place itself in the wait set for this object and then to relinquish > * any and all synchronization claims on this object. Thread > T > * becomes disabled for thread scheduling purposes and lies dormant > - * until one of four things happens: > + * until one of five things happens: > *

    > *
  • Some other thread invokes the {@code notify} method for this > * object and thread T happens to be arbitrarily chosen as > @@ -330,7 +330,9 @@ > *
  • The specified amount of real time has elapsed, more or less. > If > * {@code timeout} is zero, however, then real time is not taken into > * consideration and the thread simply waits until notified. > + *
  • Thread T is awakened spuriously. (See below.) > *
> + *

> * The thread T is then removed from the wait set for this > * object and re-enabled for thread scheduling. It then competes in > the > * usual manner with other threads for the right to synchronize on the > > From martinrb at google.com Fri Aug 11 18:53:18 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Aug 2017 11:53:18 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: There's also an existing paragraph in Condition that goes "When waiting upon a Condition, a spurious ... " On Fri, Aug 11, 2017 at 11:50 AM, Martin Buchholz wrote: > Can we align the wording with existing wording in either LockSupport or > Condition? > > On Fri, Aug 11, 2017 at 11:25 AM, Stuart Marks > wrote: > >> This is an old spec bug. The Object.wait spec lists several different >> reasons a thread could be awakened, but it omits spurious wakeup -- even >> though spurious wakeup is described later on. The fix is simply to add >> spurious wakeup to the list. >> >> There is some discussion in the original bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-6344935 >> >> Patch appended below. >> >> Thanks, >> >> s'marks >> >> >> >> # HG changeset patch >> # User smarks >> # Date 1502475871 25200 >> # Fri Aug 11 11:24:31 2017 -0700 >> # Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e >> # Parent 27b08ab97a607df3a4abff83d8d1a2a1882e5bf1 >> 6344935: Clarify Object.wait javadoc with respect to spurious wakeups >> Reviewed-by: XXX >> >> diff -r 27b08ab97a60 -r ebd66cd27b29 src/java.base/share/classes/ja >> va/lang/Object.java >> --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 >> 09:04:47 2017 -0700 >> +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 >> 11:24:31 2017 -0700 >> @@ -318,7 +318,7 @@ >> * place itself in the wait set for this object and then to >> relinquish >> * any and all synchronization claims on this object. Thread >> T >> * becomes disabled for thread scheduling purposes and lies dormant >> - * until one of four things happens: >> + * until one of five things happens: >> *

    >> *
  • Some other thread invokes the {@code notify} method for this >> * object and thread T happens to be arbitrarily chosen as >> @@ -330,7 +330,9 @@ >> *
  • The specified amount of real time has elapsed, more or less. >> If >> * {@code timeout} is zero, however, then real time is not taken into >> * consideration and the thread simply waits until notified. >> + *
  • Thread T is awakened spuriously. (See below.) >> *
>> + *

>> * The thread T is then removed from the wait set for this >> * object and re-enabled for thread scheduling. It then competes in >> the >> * usual manner with other threads for the right to synchronize on >> the >> >> > From brian.burkhalter at oracle.com Fri Aug 11 18:54:16 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Aug 2017 11:54:16 -0700 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> References: <598DF745.40800@oracle.com> <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> Message-ID: On Aug 11, 2017, at 11:44 AM, Lance Andersen wrote: > Looks OK overall +1 > Any thoughts on centering some of the column values such as in RoundingMode at some point? That might be better. Brian From jonathan.gibbons at oracle.com Fri Aug 11 19:10:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Aug 2017 12:10:09 -0700 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> References: <598DF745.40800@oracle.com> <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> Message-ID: <598E0111.5080209@oracle.com> Lance, I was in two minds about changing the layout of the columns in RoundingMode. It can sometimes hard to discern the intent of the author. In addition, numbers can be problematic because ideally you want the overall column of numbers to "centered", but each individual number to be right-aligned within that centered area -- and that is not easily expressible. The best that we've achieved elsewhere is to use "right-aligned, with some right padding". While that can be done, the local style declarations start overwhelming the content ... and the whole trend of HTML5 and CSS is to separate content and style. In this case, there are several tables that would benefit from a specific style declaration, but it's not important enough IMO to add to the main javadoc stylesheet. But, the javadoc team is working on enhancements to the use of stylesheets, and maybe that will give a better way forward, eventually. But I agree the left-aligned values look less than ideal. The question is, do you want to add one of the following to all the appropriate cells: style="text-align:center" style="text-align:right; padding-right=Nem" // for some value of N -- Jon On 08/11/2017 11:44 AM, Lance Andersen wrote: > Hi Jon, > > Looks OK overall > > Any thoughts on centering some of the column values such as in > RoundingMode at some point? > > > DateTimeFormatter looks much nicer :-) > > Best > Lance > > >> On Aug 11, 2017, at 2:28 PM, Jonathan Gibbons >> > wrote: >> >> Please review the following changes to fix accessibility and HTML >> issues in the >> java.math, java.text and java.time packages. >> >> Mostly, it's "more of the same", setting scope=row|col on tables. >> >> One bigger change is in DateTimeFormatter, to change a preformatted ASCII >> table into a standard HTML table. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 >> Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ >> >> API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ >> >> >> -- Jon > > > > 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 Fri Aug 11 19:14:11 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Aug 2017 12:14:11 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: <309c24aa-36d5-0c8e-20c6-73f30cfc9b6a@oracle.com> In general, I'm in favor of ensuring that wording in various bits of the specification is well aligned. I don't see specifically what would need to be improved in this case, though. > Can we align the wording with existing wording in either LockSupport or > Condition? The various LockSupport.park methods have a similar bullet list, and among them is the following: * The call spuriously (that is, for no reason) returns. But note this says that the park call returns, whereas the wait call does NOT necessarily return because of spurious wakeup; it's merely removed from the wait set. Thus the proposed text says * Thread T is awakened spuriously. (See below.) and subsequent paragraphs talk about removal from wait set, competing to re-acquire the lock, and spurious wakeup. > There's also an existing paragraph in Condition that goes "When waiting upon > a Condition, a spurious ... " This paragraph from the Condition specification says, > When waiting upon a Condition, a "spurious wakeup" is permitted to occur, in > general, as a concession to the underlying platform semantics. This has > little practical impact on most application programs as a Condition should > always be waited upon in a loop, testing the state predicate that is being > waited for. An implementation is free to remove the possibility of spurious > wakeups but it is recommended that applications programmers always assume > that they can occur and so always wait in a loop. whereas the one in Object.wait(long) says: > A thread can also wake up without being notified, interrupted, or timing out, > a so-called spurious wakeup. While this will rarely occur in practice, > applications must guard against it by testing for the condition that should > have caused the thread to be awakened, and continuing to wait if the > condition is not satisfied. In other words, waits should always occur in > loops, like this one: > ? > synchronized (obj) { > while () > obj.wait(timeout); > ... // Perform action appropriate to condition > } These mostly say the same thing, though the Condition spec talks about the underlying implementation, whereas the Object.wait spec is strongly oriented toward the application programmer. I think this is ok. If there's some bit of wording that needs to be corrected somewhere, please suggest it. s'marks From mandy.chung at oracle.com Fri Aug 11 19:47:25 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 11 Aug 2017 12:47:25 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: On 8/10/17 9:02 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java 26 * @library /test/lib classes 27 * @build test.Empty 28 * @run driver ClassFileInstaller test.Empty jdk.test.lib.compiler.CompilerUtils is easy to use. I would suggest to convert these implicit compile+copy steps into an explicit setup step to compile ${test.src}/test/Empty.java into the destination directory. It'd be easy to read and understand. Bumping up jtreg version is fine. Mandy From lance.andersen at oracle.com Fri Aug 11 20:32:16 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 16:32:16 -0400 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: <598E0111.5080209@oracle.com> References: <598DF745.40800@oracle.com> <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> <598E0111.5080209@oracle.com> Message-ID: Hi Jon > On Aug 11, 2017, at 3:10 PM, Jonathan Gibbons wrote: > > Lance, > > I was in two minds about changing the layout of the columns in RoundingMode. > It can sometimes hard to discern the intent of the author. In addition, numbers > can be problematic because ideally you want the overall column of numbers to > "centered", but each individual number to be right-aligned within that centered area > -- and that is not easily expressible. The best that we've achieved elsewhere is to use > "right-aligned, with some right padding". While that can be done, the local > style declarations start overwhelming the content ... and the whole trend of > HTML5 and CSS is to separate content and style. > > In this case, there are several tables that would benefit from a specific style > declaration, but it's not important enough IMO to add to the main javadoc stylesheet. > But, the javadoc team is working on enhancements to the use of stylesheets, > and maybe that will give a better way forward, eventually. > > But I agree the left-aligned values look less than ideal. The question is, do you > want to add one of the following to all the appropriate cells: > style="text-align:center" > style="text-align:right; padding-right=Nem" // for some value of N I am happy to give it a go after your initial putback and see out it looks Best Lance > > -- Jon > > > On 08/11/2017 11:44 AM, Lance Andersen wrote: >> Hi Jon, >> >> Looks OK overall >> >> Any thoughts on centering some of the column values such as in RoundingMode at some point? >> >> >> DateTimeFormatter looks much nicer :-) >> >> Best >> Lance >> >> >>> On Aug 11, 2017, at 2:28 PM, Jonathan Gibbons > wrote: >>> >>> Please review the following changes to fix accessibility and HTML issues in the >>> java.math, java.text and java.time packages. >>> >>> Mostly, it's "more of the same", setting scope=row|col on tables. >>> >>> One bigger change is in DateTimeFormatter, to change a preformatted ASCII >>> table into a standard HTML table. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 >>> Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ >>> API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ >>> >>> -- Jon >> >> >> >> 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 jonathan.gibbons at oracle.com Fri Aug 11 20:59:42 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Aug 2017 13:59:42 -0700 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: References: <598DF745.40800@oracle.com> <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> <598E0111.5080209@oracle.com> Message-ID: <598E1ABE.9060804@oracle.com> On 08/11/2017 01:32 PM, Lance Andersen wrote: > Hi Jon >> On Aug 11, 2017, at 3:10 PM, Jonathan Gibbons >> > wrote: >> >> Lance, >> >> I was in two minds about changing the layout of the columns in >> RoundingMode. >> It can sometimes hard to discern the intent of the author. In >> addition, numbers >> can be problematic because ideally you want the overall column of >> numbers to >> "centered", but each individual number to be right-aligned within >> that centered area >> -- and that is not easily expressible. The best that we've achieved >> elsewhere is to use >> "right-aligned, with some right padding". While that can be done, the >> local >> style declarations start overwhelming the content ... and the whole >> trend of >> HTML5 and CSS is to separate content and style. >> >> In this case, there are several tables that would benefit from a >> specific style >> declaration, but it's not important enough IMO to add to the main >> javadoc stylesheet. >> But, the javadoc team is working on enhancements to the use of >> stylesheets, >> and maybe that will give a better way forward, eventually. >> >> But I agree the left-aligned values look less than ideal. The >> question is, do you >> want to add one of the following to all the appropriate cells: >> style="text-align:center" >> style="text-align:right; padding-right=Nem" // for some value of N > > I am happy to give it a go after your initial putback and see out it looks I looked at the page again. The values are already all right-aligned, so it would just be a case of adding padding. I think the displayed HTML would look nice, but the source HTML would be less so. It's a shame, since it would be easy to do in either page-specific CSS or in a stylesheet. -- Jon > > Best > Lance >> >> -- Jon >> >> >> On 08/11/2017 11:44 AM, Lance Andersen wrote: >>> Hi Jon, >>> >>> Looks OK overall >>> >>> Any thoughts on centering some of the column values such as in >>> RoundingMode at some point? >>> >>> >>> DateTimeFormatter looks much nicer :-) >>> >>> Best >>> Lance >>> >>> >>>> On Aug 11, 2017, at 2:28 PM, Jonathan Gibbons >>>> > >>>> wrote: >>>> >>>> Please review the following changes to fix accessibility and HTML >>>> issues in the >>>> java.math, java.text and java.time packages. >>>> >>>> Mostly, it's "more of the same", setting scope=row|col on tables. >>>> >>>> One bigger change is in DateTimeFormatter, to change a preformatted >>>> ASCII >>>> table into a standard HTML table. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ >>>> >>>> API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ >>>> >>>> >>>> -- Jon >>> >>> >>> >>> >>> 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 brian.burkhalter at oracle.com Fri Aug 11 21:22:15 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Aug 2017 14:22:15 -0700 Subject: JDK 10 RFR of 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if Engilsh Locale unavailable Message-ID: https://bugs.openjdk.java.net/browse/JDK-8186157 This change is intended to put a branch in the test which will fail if the English Locale is unavailable on the system with a view toward detecting a configuration problem as opposed to an actual test failure. Thanks, Brian @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2017, 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 @@ -59,7 +59,14 @@ !"ja".equals(lang)) { //Before we have resource to improve the test to be ready for //arbitrary locale, force the default locale to be "English" - //for now. + //for now. First we check whether the "English" locale is + //available on the system as it could be absent due to varying + //configurations. + if (!Arrays.asList(Locale.getAvailableLocales()) + .contains(Locale.ENGLISH)) { + throw new RuntimeException + ("The \"English\" Locale is unavailable on this system"); + } Locale.setDefault(Locale.ENGLISH); } skipTest(); From Roger.Riggs at Oracle.com Fri Aug 11 21:23:10 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Aug 2017 17:23:10 -0400 Subject: RFR: JDK-8186153, , Fix a11y and HTML issues in the java.math, java.text and java.time packages In-Reply-To: <598E1ABE.9060804@oracle.com> References: <598DF745.40800@oracle.com> <3A6B8192-FF23-423D-9306-908448BD0CAE@oracle.com> <598E0111.5080209@oracle.com> <598E1ABE.9060804@oracle.com> Message-ID: Hi Jon, looks good, While you are in DateTimeFormatter.java can you add a leading ' (single-quote) to the example for ISO_WEEK_DATE in the Predefiend Formatters table. Line 246. Thanks, Roger On 8/11/2017 4:59 PM, Jonathan Gibbons wrote: > > > On 08/11/2017 01:32 PM, Lance Andersen wrote: >> Hi Jon >>> On Aug 11, 2017, at 3:10 PM, Jonathan Gibbons >>> > >>> wrote: >>> >>> Lance, >>> >>> I was in two minds about changing the layout of the columns in >>> RoundingMode. >>> It can sometimes hard to discern the intent of the author. In >>> addition, numbers >>> can be problematic because ideally you want the overall column of >>> numbers to >>> "centered", but each individual number to be right-aligned within >>> that centered area >>> -- and that is not easily expressible. The best that we've achieved >>> elsewhere is to use >>> "right-aligned, with some right padding". While that can be done, >>> the local >>> style declarations start overwhelming the content ... and the whole >>> trend of >>> HTML5 and CSS is to separate content and style. >>> >>> In this case, there are several tables that would benefit from a >>> specific style >>> declaration, but it's not important enough IMO to add to the main >>> javadoc stylesheet. >>> But, the javadoc team is working on enhancements to the use of >>> stylesheets, >>> and maybe that will give a better way forward, eventually. >>> >>> But I agree the left-aligned values look less than ideal. The >>> question is, do you >>> want to add one of the following to all the appropriate cells: >>> style="text-align:center" >>> style="text-align:right; padding-right=Nem" // for some value of N >> >> I am happy to give it a go after your initial putback and see out it >> looks > > I looked at the page again. The values are already all right-aligned, > so it would just be a case of adding padding. > I think the displayed HTML would look nice, but the source HTML would > be less so. It's a shame, since it would > be easy to do in either page-specific CSS or in a stylesheet. > > -- Jon > > >> >> Best >> Lance >>> >>> -- Jon >>> >>> >>> On 08/11/2017 11:44 AM, Lance Andersen wrote: >>>> Hi Jon, >>>> >>>> Looks OK overall >>>> >>>> Any thoughts on centering some of the column values such as in >>>> RoundingMode at some point? >>>> >>>> >>>> DateTimeFormatter looks much nicer :-) >>>> >>>> Best >>>> Lance >>>> >>>> >>>>> On Aug 11, 2017, at 2:28 PM, Jonathan Gibbons >>>>> > >>>>> wrote: >>>>> >>>>> Please review the following changes to fix accessibility and HTML >>>>> issues in the >>>>> java.math, java.text and java.time packages. >>>>> >>>>> Mostly, it's "more of the same", setting scope=row|col on tables. >>>>> >>>>> One bigger change is in DateTimeFormatter, to change a >>>>> preformatted ASCII >>>>> table into a standard HTML table. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186153 >>>>> Webrev: http://cr.openjdk.java.net/~jjg/8186153/webrev.00/ >>>>> >>>>> API: http://cr.openjdk.java.net/~jjg/8186153/api.00/ >>>>> >>>>> >>>>> -- Jon >>>> >>>> >>>> >>>> >>>> >>>> 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 brian.burkhalter at oracle.com Fri Aug 11 21:25:40 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Aug 2017 14:25:40 -0700 Subject: JDK 10 RFR of 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if Engilsh Locale unavailable In-Reply-To: References: Message-ID: Subject: s/Engilsh/English/ On Aug 11, 2017, at 2:22 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8186157 > > This change is intended to put a branch in the test which will fail if the English Locale is unavailable on the system with a view toward detecting a configuration problem as opposed to an actual test failure. From Lance.Andersen at oracle.com Fri Aug 11 21:32:22 2017 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 17:32:22 -0400 Subject: JDK 10 RFR of 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if Engilsh Locale unavailable In-Reply-To: References: Message-ID: <2848F874-6995-4366-A040-AED4926EB699@oracle.com> +1 -- 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 Sent from my iPhone > On Aug 11, 2017, at 5:25 PM, Brian Burkhalter wrote: > > Subject: s/Engilsh/English/ > >> On Aug 11, 2017, at 2:22 PM, Brian Burkhalter wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8186157 >> >> This change is intended to put a branch in the test which will fail if the English Locale is unavailable on the system with a view toward detecting a configuration problem as opposed to an actual test failure. > From huizhe.wang at oracle.com Fri Aug 11 21:59:47 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 11 Aug 2017 14:59:47 -0700 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <038b01d31279$081e69b0$185b3d10$@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> <038b01d31279$081e69b0$185b3d10$@oracle.com> Message-ID: <9a53d906-0e6b-8eb7-256e-5eec6e32134e@oracle.com> Thanks Frank for looking into and verifying the relevant tests. We have a rich set of tests that have been very helpful with this update. I've addressed a number of failures during the work, but it's true that Bug8003147Test never failed. Best regards, Joe On 8/11/2017 1:08 AM, Frank Yuan wrote: > Hi Joe and Daniel > >>> So far so good, most of them still seem to be present in >>> your changes, but I have a doubt about these two: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8062608 >>> https://bugs.openjdk.java.net/browse/JDK-8064516 >>> >>> Has the issue been fixed upstream in a different way, or >>> is the issue no longer relevant, or is it going to appear >>> again with this patch? >> Good catch! The original patch came from BCEL, so I indeed assumed this >> update would get things the right way. As I double-checked, it turns out >> the additional patches as you listed above fixed issues that BCEL 6.0 >> hasn't. These issues were revealed by JRocket, did not affect JAXP, >> however, they are still good changes that we shall keep. I've gone >> through both of the above to put these changes back into the code. >> > IIUC JDK-8062608 and JDK-8064516 are related to JDK-8003147 but for JRocket, the first webrev(http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/) looks different with the fix of JDK-8003147, however we have the relevant test in the repo, i.e. http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/tip/test/javax/xml/jaxp/unittest/parsers/Bug8003147Test.java, since all tests were passed, I assume the first webrev worked for JDK-8003147, certainly the second webrev looks good too :) > > Thanks > Frank > From huizhe.wang at oracle.com Fri Aug 11 22:00:19 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 11 Aug 2017 15:00:19 -0700 Subject: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release In-Reply-To: <4ff20adb-f51c-464d-f416-be72fb4d3c63@oracle.com> References: <96a277e2-481e-4fba-e95e-e1e3932fef25@oracle.com> <02821d18-a1bb-f395-8ce1-88785e7ba825@oracle.com> <3f5b3c02-9aad-9367-9901-200025fbf4f4@oracle.com> <4ff20adb-f51c-464d-f416-be72fb4d3c63@oracle.com> Message-ID: Thanks Daniel! Best regards, Joe On 8/11/2017 3:31 AM, Daniel Fuchs wrote: > Hi Joe, > > Thanks, looks fine now! > > best regards, > > -- daniel > > On 10/08/2017 04:13, huizhe wang wrote: >> >> On 8/9/2017 6:30 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> This not an easy patch to review ;-) >> >> Indeed, took several minutes just to copy the webrevs :-) >> >>> >>> Thanks for explaining how you arrived at the final result. >>> The method you used as described below seems right. >>> >>> I haven't clicked through all the files, but instead I had a >>> look at all the JIRA issues revealed by: >>> >>> hg log -k share/classes/com/sun/org/apache/bcel | grep summary | >>> grep -v Merge >>> >>> to see if any of them might have been reverted/invalidated. >>> So far so good, most of them still seem to be present in >>> your changes, but I have a doubt about these two: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8062608 >>> https://bugs.openjdk.java.net/browse/JDK-8064516 >>> >>> Has the issue been fixed upstream in a different way, or >>> is the issue no longer relevant, or is it going to appear >>> again with this patch? >> >> Good catch! The original patch came from BCEL, so I indeed assumed >> this update would get things the right way. As I double-checked, it >> turns out the additional patches as you listed above fixed issues >> that BCEL 6.0 hasn't. These issues were revealed by JRocket, did not >> affect JAXP, however, they are still good changes that we shall keep. >> I've gone through both of the above to put these changes back into >> the code. >> >>> >>> Also looking at the JDK fixes brought my attention to >>> java.xml/share/classes/jdk/xml/internal/SecuritySupport.java >>> >>> Your changes are adding these two methods: >>> I don't know what they are for - and I am not sure they would >>> work (the brutal cast to ListResourceBundle is dubious). >>> Fortunately they don't seem to be called by the new code (I >>> grepped the global patch file). Can you remove them? >> >> This is because I removed >> com/sun/org/apache/bcel/internal/util/SecuritySupport.java that is no >> longer used by any classes in our version of BCEL. However, a XPath >> class (XPATHMessages.java) was still using it, I therefore moved the >> getResourceBundle method that was used into the jdk util class before >> removing the one in bcel. >> >> The ListResourceBundle cast was needed since the XPATHMessages >> variable was originally declared ListResourceBundle. I've changed >> that to ResourceBundle and removed the cast. >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev01/ >> >> Thanks, >> Joe >> >>> >>> 234 /** >>> 235 * Gets a resource bundle using the specified base name, >>> the default locale, and the caller's class loader. >>> 236 * @param bundle the base name of the resource bundle, a >>> fully qualified class name >>> 237 * @return a resource bundle for the given base name and >>> the default locale >>> 238 */ >>> 239 public static ListResourceBundle getResourceBundle(String >>> bundle) { >>> 240 return getResourceBundle(bundle, Locale.getDefault()); >>> 241 } >>> 242 >>> 243 /** >>> 244 * Gets a resource bundle using the specified base name and >>> locale, and the caller's class loader. >>> 245 * @param bundle the base name of the resource bundle, a >>> fully qualified class name >>> 246 * @param locale the locale for which a resource bundle is >>> desired >>> 247 * @return a resource bundle for the given base name and >>> locale >>> 248 */ >>> 249 public static ListResourceBundle getResourceBundle(final >>> String bundle, final Locale locale) { >>> 250 return >>> AccessController.doPrivileged((PrivilegedAction) >>> () -> { >>> 251 try { >>> 252 return >>> (ListResourceBundle)ResourceBundle.getBundle(bundle, locale); >>> 253 } catch (MissingResourceException e) { >>> 254 try { >>> 255 return >>> (ListResourceBundle)ResourceBundle.getBundle(bundle, new >>> Locale("en", "US")); >>> 256 } catch (MissingResourceException e2) { >>> 257 throw new MissingResourceException( >>> 258 "Could not load any resource bundle >>> by " + bundle, bundle, ""); >>> 259 } >>> 260 } >>> 261 }); >>> 262 } >>> >>> best regards, >>> >>> -- daniel >>> >>> On 09/08/2017 00:43, huizhe wang wrote: >>>> Please review an update to BCEL release 6.0 [1]. >>>> >>>> The sources are basically that from the release bundle with the >>>> following exceptions: >>>> >>>> * Classes that were not included in the original version are >>>> excluded; >>>> * Classes that are deprecated in BCEL 6.0 are removed; >>>> * Classes that are used only for the above classes are also removed; >>>> * Many fields were deprecated in BCEL 6.0 in order to discourage >>>> direct references, in the JDK, I've removed such deprecation and >>>> instead made them private/final. >>>> * BCEL 6.0 applied 'final' to global/local variables pretty >>>> extensively, which were the only changes to many of the classes. >>>> * A few Transform classes were updated to adopt to BCEL 6.0. >>>> * JDK-8162527 [JAXP] XSLT: Investigate why bumping the default class >>>> file version to 49 (Java 5.0) or higher for bytecode generation >>>> doesn't work [2] has not been resolved as of this update. >>>> Additional >>>> change [3] is needed before we can move up to possibly Java 5.0. >>>> >>>> >>>> BCEL has been a very old component. This update therefore removed a >>>> large amount of warnings (900+), which is very helpful to the >>>> cleaning effort. >>>> >>>> All tests passed, including the JCK. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8163121 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8163121/webrev/ >>>> >>>> >>>> [1] https://archive.apache.org/dist/commons/bcel/RELEASE-NOTES.txt >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8162527 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8185991 >>>> >>>> Thanks, >>>> Joe >>>> >>> >> > From jonathan.gibbons at oracle.com Fri Aug 11 22:52:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Aug 2017 15:52:47 -0700 Subject: RFR: JDK-8186156: Fix a11y and HTML issues in java.net and javax.net packages Message-ID: <598E353F.1060609@oracle.com> Please review the following fix for accessibility and HTML issues in the java.net and javax.net packages. The only edit of note is that a table was simply removed from the top of URLConnection. The table was an "HTML art" depiction of actions on a timeline, complete with an ASCII-art time arrow. My initial reaction was to replace it with an ordered list ... but then I noticed the table was already immediately followed by the explanatory list I would have written. So the table was effectively redundant, and it seemd best to remove it. JBS: https://bugs.openjdk.java.net/browse/JDK-8186156 Webrev: http://cr.openjdk.java.net/~jjg/8186156/webrev.00 API: http://cr.openjdk.java.net/~jjg/8186156/api.00 -- Jon From igor.ignatyev at oracle.com Fri Aug 11 23:05:34 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 11 Aug 2017 16:05:34 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: <9C9EF5E5-DD06-4202-BCB0-992D55C1954D@oracle.com> Hi Mandy, thank you for your review. although jdk.test.lib.compiler.CompilerUtils is easy to use, it introduces dependency on jdk.compiler module and currently FragmentMetaspaceSimple.java depends only on java.base module and I would prefer it remain so. Thanks, -- Igor > On Aug 11, 2017, at 12:47 PM, mandy chung wrote: > On 8/10/17 9:02 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html > hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java > 26 * @library /test/lib classes > 27 * @build test.Empty > 28 * @run driver ClassFileInstaller test.Empty > > jdk.test.lib.compiler.CompilerUtils is easy to use. I would suggest > to convert these implicit compile+copy steps into an explicit > setup step to compile ${test.src}/test/Empty.java into > the destination directory. It'd be easy to read and understand. > > Bumping up jtreg version is fine. > > Mandy From lance.andersen at oracle.com Fri Aug 11 23:12:22 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Aug 2017 19:12:22 -0400 Subject: RFR: JDK-8186156: Fix a11y and HTML issues in java.net and javax.net packages In-Reply-To: <598E353F.1060609@oracle.com> References: <598E353F.1060609@oracle.com> Message-ID: <3C6A1D22-8EAC-46A0-9CF3-96B38B4CF04D@oracle.com> +1 > On Aug 11, 2017, at 6:52 PM, Jonathan Gibbons wrote: > > Please review the following fix for accessibility and HTML issues in the java.net and javax.net packages. > > The only edit of note is that a table was simply removed from the top of URLConnection. The table was an "HTML art" depiction of actions on a timeline, complete with an ASCII-art time arrow. My initial reaction was to replace it with an ordered list ... but then I noticed the table was already immediately followed by the explanatory list I would have written. So the table was effectively redundant, and it seemd best to remove it. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186156 > Webrev: http://cr.openjdk.java.net/~jjg/8186156/webrev.00 > API: http://cr.openjdk.java.net/~jjg/8186156/api.00 > > -- Jon 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 Aug 11 23:40:03 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 11 Aug 2017 16:40:03 -0700 Subject: RFR: JDK-8186156: Fix a11y and HTML issues in java.net and javax.net packages In-Reply-To: <598E353F.1060609@oracle.com> References: <598E353F.1060609@oracle.com> Message-ID: <01bf7e39-2e70-5a8e-a810-b09221277503@oracle.com> On 8/11/17 3:52 PM, Jonathan Gibbons wrote: > Please review the following fix for accessibility and HTML issues in > the java.net and javax.net packages. > > The only edit of note is that a table was simply removed from the top > of URLConnection. The table was an "HTML art" depiction of actions on > a timeline, complete with an ASCII-art time arrow. My initial reaction > was to replace it with an ordered list ... but then I noticed the > table was already immediately followed by the explanatory list I would > have written. So the table was effectively redundant, and it seemd > best to remove it. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186156 > Webrev: http://cr.openjdk.java.net/~jjg/8186156/webrev.00 > API: http://cr.openjdk.java.net/~jjg/8186156/api.00 The table in URLConnection does look redundant. I think it's okay to remove it. src/java.base/share/classes/java/net/URLPermission.java + *

    + *
  • "POST,GET,DELETE" + *
  • "GET:X-Foo-Request,X-Bar-Request" + *
  • "POST,GET:Header1,Header2" + *
It may be good to add

in the next sentence "The first example..." Otherwise looks fine. Mandy From david.holmes at oracle.com Fri Aug 11 23:43:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Aug 2017 09:43:09 +1000 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: <309c24aa-36d5-0c8e-20c6-73f30cfc9b6a@oracle.com> References: <309c24aa-36d5-0c8e-20c6-73f30cfc9b6a@oracle.com> Message-ID: <41d92349-0b3c-2e40-fb24-32ad9ee67628@oracle.com> On 12/08/2017 5:14 AM, Stuart Marks wrote: > In general, I'm in favor of ensuring that wording in various bits of the > specification is well aligned. I don't see specifically what would need > to be improved in this case, though. If you start trying to align things too much you end up rewriting a heap of stuff. I would not be concerned with the differences between LockSupport/Condition and Object.wait wording. If anything should be aligned it is perhaps the awkwardly formed docs for wait(long, int) which only lists 2 reasons for waking, then adds "and of course interrupt and spurious wakeup can also happen" [sic] That is in a way consistent with wait(long) only listing 4 reasons and then adding the note about spurious wakeups. Cheers, David >> Can we align the wording with existing wording in either LockSupport or >> Condition? > > The various LockSupport.park methods have a similar bullet list, and > among them is the following: > > * The call spuriously (that is, for no reason) returns. > > But note this says that the park call returns, whereas the wait call > does NOT necessarily return because of spurious wakeup; it's merely > removed from the wait set. Thus the proposed text says > > * Thread T is awakened spuriously. (See below.) > > and subsequent paragraphs talk about removal from wait set, competing to > re-acquire the lock, and spurious wakeup. > > >> There's also an existing paragraph in Condition that goes "When >> waiting upon >> a Condition, a spurious ... " > > This paragraph from the Condition specification says, > >> When waiting upon a Condition, a "spurious wakeup" is permitted to >> occur, in >> general, as a concession to the underlying platform semantics. This has >> little practical impact on most application programs as a Condition >> should >> always be waited upon in a loop, testing the state predicate that is >> being >> waited for. An implementation is free to remove the possibility of >> spurious >> wakeups but it is recommended that applications programmers always assume >> that they can occur and so always wait in a loop. > > whereas the one in Object.wait(long) says: > >> A thread can also wake up without being notified, interrupted, or >> timing out, >> a so-called spurious wakeup. While this will rarely occur in practice, >> applications must guard against it by testing for the condition that >> should >> have caused the thread to be awakened, and continuing to wait if the >> condition is not satisfied. In other words, waits should always occur in >> loops, like this one: >> ? >> synchronized (obj) { >> while () >> obj.wait(timeout); >> ... // Perform action appropriate to condition >> } > > These mostly say the same thing, though the Condition spec talks about > the underlying implementation, whereas the Object.wait spec is strongly > oriented toward the application programmer. I think this is ok. > > If there's some bit of wording that needs to be corrected somewhere, > please suggest it. > > s'marks > From hboehm at google.com Sat Aug 12 00:58:22 2017 From: hboehm at google.com (Hans Boehm) Date: Fri, 11 Aug 2017 17:58:22 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: <41d92349-0b3c-2e40-fb24-32ad9ee67628@oracle.com> References: <309c24aa-36d5-0c8e-20c6-73f30cfc9b6a@oracle.com> <41d92349-0b3c-2e40-fb24-32ad9ee67628@oracle.com> Message-ID: Any chance the example code in the documentation that is quoted below could also be adjusted to e.g. synchronized (obj) { while () { ; obj.wait(); } ... // Perform action appropriate to condition } and similarly for the nanos case? It has long bothered me that the documentation for java.lang.Object recommends buggy code. If there are frequent notifyAll()s signalling the establishment of other conditions, the current example code is badly broken in a way that's not obvious to every user. On Fri, Aug 11, 2017 at 4:43 PM, David Holmes wrote: > On 12/08/2017 5:14 AM, Stuart Marks wrote: > >> In general, I'm in favor of ensuring that wording in various bits of the >> specification is well aligned. I don't see specifically what would need to >> be improved in this case, though. >> > > If you start trying to align things too much you end up rewriting a heap > of stuff. I would not be concerned with the differences between > LockSupport/Condition and Object.wait wording. > > If anything should be aligned it is perhaps the awkwardly formed docs for > wait(long, int) which only lists 2 reasons for waking, then adds "and of > course interrupt and spurious wakeup can also happen" [sic] That is in a > way consistent with wait(long) only listing 4 reasons and then adding the > note about spurious wakeups. > > Cheers, > David > > > Can we align the wording with existing wording in either LockSupport or >>> Condition? >>> >> >> The various LockSupport.park methods have a similar bullet list, and >> among them is the following: >> >> * The call spuriously (that is, for no reason) returns. >> >> But note this says that the park call returns, whereas the wait call does >> NOT necessarily return because of spurious wakeup; it's merely removed from >> the wait set. Thus the proposed text says >> >> * Thread T is awakened spuriously. (See below.) >> >> and subsequent paragraphs talk about removal from wait set, competing to >> re-acquire the lock, and spurious wakeup. >> >> >> There's also an existing paragraph in Condition that goes "When waiting >>> upon >>> a Condition, a spurious ... " >>> >> >> This paragraph from the Condition specification says, >> >> When waiting upon a Condition, a "spurious wakeup" is permitted to occur, >>> in >>> general, as a concession to the underlying platform semantics. This has >>> little practical impact on most application programs as a Condition >>> should >>> always be waited upon in a loop, testing the state predicate that is >>> being >>> waited for. An implementation is free to remove the possibility of >>> spurious >>> wakeups but it is recommended that applications programmers always assume >>> that they can occur and so always wait in a loop. >>> >> >> whereas the one in Object.wait(long) says: >> >> A thread can also wake up without being notified, interrupted, or timing >>> out, >>> a so-called spurious wakeup. While this will rarely occur in practice, >>> applications must guard against it by testing for the condition that >>> should >>> have caused the thread to be awakened, and continuing to wait if the >>> condition is not satisfied. In other words, waits should always occur in >>> loops, like this one: >>> ? >>> synchronized (obj) { >>> while () >>> obj.wait(timeout); >>> ... // Perform action appropriate to condition >>> } >>> >> >> These mostly say the same thing, though the Condition spec talks about >> the underlying implementation, whereas the Object.wait spec is strongly >> oriented toward the application programmer. I think this is ok. >> >> If there's some bit of wording that needs to be corrected somewhere, >> please suggest it. >> >> s'marks >> >> From martinrb at google.com Sat Aug 12 01:24:57 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Aug 2017 18:24:57 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: Thanks for working on Object.wait. Doc writing is never easy, especially in Object.java. In the original proposed patch, the word "also" ends up weird, because spurious wakeup *was* in the list above; we need to do something about that. On Fri, Aug 11, 2017 at 11:25 AM, Stuart Marks wrote: > This is an old spec bug. The Object.wait spec lists several different > reasons a thread could be awakened, but it omits spurious wakeup -- even > though spurious wakeup is described later on. The fix is simply to add > spurious wakeup to the list. > > There is some discussion in the original bug report: > > https://bugs.openjdk.java.net/browse/JDK-6344935 > > Patch appended below. > > Thanks, > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1502475871 25200 > # Fri Aug 11 11:24:31 2017 -0700 > # Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e > # Parent 27b08ab97a607df3a4abff83d8d1a2a1882e5bf1 > 6344935: Clarify Object.wait javadoc with respect to spurious wakeups > Reviewed-by: XXX > > diff -r 27b08ab97a60 -r ebd66cd27b29 src/java.base/share/classes/ja > va/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java Thu Aug 03 > 09:04:47 2017 -0700 > +++ b/src/java.base/share/classes/java/lang/Object.java Fri Aug 11 > 11:24:31 2017 -0700 > @@ -318,7 +318,7 @@ > * place itself in the wait set for this object and then to relinquish > * any and all synchronization claims on this object. Thread > T > * becomes disabled for thread scheduling purposes and lies dormant > - * until one of four things happens: > + * until one of five things happens: > *

    > *
  • Some other thread invokes the {@code notify} method for this > * object and thread T happens to be arbitrarily chosen as > @@ -330,7 +330,9 @@ > *
  • The specified amount of real time has elapsed, more or less. > If > * {@code timeout} is zero, however, then real time is not taken into > * consideration and the thread simply waits until notified. > + *
  • Thread T is awakened spuriously. (See below.) > *
> + *

> * The thread T is then removed from the wait set for this > * object and re-enabled for thread scheduling. It then competes in > the > * usual manner with other threads for the right to synchronize on the > > From david.holmes at oracle.com Sat Aug 12 01:29:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Aug 2017 11:29:09 +1000 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: <309c24aa-36d5-0c8e-20c6-73f30cfc9b6a@oracle.com> <41d92349-0b3c-2e40-fb24-32ad9ee67628@oracle.com> Message-ID: <05099cd8-85e6-edd6-ee4f-a8ea68cd3211@oracle.com> On 12/08/2017 10:58 AM, Hans Boehm wrote: > Any chance the example code in the documentation that is quoted below > could also be adjusted to e.g. > > synchronized (obj) { > while () { > ; > obj.wait(); > } > ... // Perform action appropriate to condition > } > > and similarly for the nanos case? > > It has long bothered me that the documentation for java.lang.Object > recommends buggy code. If there > are frequent notifyAll()s signalling the establishment of other > conditions, the current example code is badly > broken in a way that's not obvious to every user. You mean because it does not recompute the timeout and so will possibly wait longer than intended? David > > On Fri, Aug 11, 2017 at 4:43 PM, David Holmes > wrote: > > On 12/08/2017 5:14 AM, Stuart Marks wrote: > > In general, I'm in favor of ensuring that wording in various > bits of the specification is well aligned. I don't see > specifically what would need to be improved in this case, though. > > > If you start trying to align things too much you end up rewriting a > heap of stuff. I would not be concerned with the differences between > LockSupport/Condition and Object.wait wording. > > If anything should be aligned it is perhaps the awkwardly formed > docs for wait(long, int) which only lists 2 reasons for waking, then > adds "and of course interrupt and spurious wakeup can also happen" > [sic] That is in a way consistent with wait(long) only listing 4 > reasons and then adding the note about spurious wakeups. > > Cheers, > David > > > Can we align the wording with existing wording in either > LockSupport or > Condition? > > > The various LockSupport.park methods have a similar bullet list, > and among them is the following: > > * The call spuriously (that is, for no reason) returns. > > But note this says that the park call returns, whereas the wait > call does NOT necessarily return because of spurious wakeup; > it's merely removed from the wait set. Thus the proposed text says > > * Thread T is awakened spuriously. (See below.) > > and subsequent paragraphs talk about removal from wait set, > competing to re-acquire the lock, and spurious wakeup. > > > There's also an existing paragraph in Condition that goes > "When waiting upon > a Condition, a spurious ... " > > > This paragraph from the Condition specification says, > > When waiting upon a Condition, a "spurious wakeup" is > permitted to occur, in > general, as a concession to the underlying platform > semantics. This has > little practical impact on most application programs as a > Condition should > always be waited upon in a loop, testing the state predicate > that is being > waited for. An implementation is free to remove the > possibility of spurious > wakeups but it is recommended that applications programmers > always assume > that they can occur and so always wait in a loop. > > > whereas the one in Object.wait(long) says: > > A thread can also wake up without being notified, > interrupted, or timing out, > a so-called spurious wakeup. While this will rarely occur in > practice, > applications must guard against it by testing for the > condition that should > have caused the thread to be awakened, and continuing to > wait if the > condition is not satisfied. In other words, waits should > always occur in > loops, like this one: > ? > synchronized (obj) { > while () > obj.wait(timeout); > ... // Perform action appropriate to condition > } > > > These mostly say the same thing, though the Condition spec talks > about the underlying implementation, whereas the Object.wait > spec is strongly oriented toward the application programmer. I > think this is ok. > > If there's some bit of wording that needs to be corrected > somewhere, please suggest it. > > s'marks > > From martinrb at google.com Sat Aug 12 01:33:53 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Aug 2017 18:33:53 -0700 Subject: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups In-Reply-To: References: Message-ID: OK, I'll try my hand as well at making forward progress: diff --git a/src/java.base/share/classes/java/lang/Object.java b/src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java +++ b/src/java.base/share/classes/java/lang/Object.java @@ -334,7 +334,7 @@ * The thread T is then removed from the wait set for this * object and re-enabled for thread scheduling. It then competes in the * usual manner with other threads for the right to synchronize on the - * object; once it has gained control of the object, all its + * object; once it has regained control of the object, all its * synchronization claims on the object are restored to the status quo * ante - that is, to the situation as of the time that the {@code wait} * method was invoked. Thread T then returns from the From amaembo at gmail.com Sun Aug 13 13:27:36 2017 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 13 Aug 2017 20:27:36 +0700 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation Message-ID: Please review the preliminary implementation for Stream foldLeft and foldRight operations: http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ This implementation has no tests yet. Before writing them I'd like to be sure that this enhancement could be accepted in general (or probably foldLeft is accepted and foldRight is not?) Could anybody sponsor it when it will be complete? Thank you in advance! Tagir Valeev. From forax at univ-mlv.fr Sun Aug 13 19:45:12 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Aug 2017 21:45:12 +0200 (CEST) Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: References: Message-ID: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> Hi Tagir, foldLeft (and foldRight) were intentionally not included in the Stream API because as you know, their semantics is too strong to be useful for parallel streams. regards, R?mi ----- Mail original ----- > De: "Tagir Valeev" > ?: "core-libs-dev" > Envoy?: Dimanche 13 Ao?t 2017 15:27:36 > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation > Please review the preliminary implementation for Stream foldLeft and > foldRight operations: > > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ > > This implementation has no tests yet. Before writing them I'd like to > be sure that this enhancement could be accepted in general (or > probably foldLeft is accepted and foldRight is not?) Could anybody > sponsor it when it will be complete? > > Thank you in advance! > > Tagir Valeev. From amaembo at gmail.com Mon Aug 14 00:58:18 2017 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 14 Aug 2017 07:58:18 +0700 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> References: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> Message-ID: Hello, Remi! Yes, I know. But times change and old decisions could be reconsidered. After all, forEachOrdered was included and its semantics is essentially the same as in foldLeft with respect to parallel streams. With best regards, Tagir Valeev. 14 ???. 2017 ?. 2:45 AM ???????????? "Remi Forax" ???????: > Hi Tagir, > foldLeft (and foldRight) were intentionally not included in the Stream API > because as you know, their semantics is too strong to be useful for > parallel streams. > > regards, > R?mi > > ----- Mail original ----- > > De: "Tagir Valeev" > > ?: "core-libs-dev" > > Envoy?: Dimanche 13 Ao?t 2017 15:27:36 > > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation > > > Please review the preliminary implementation for Stream foldLeft and > > foldRight operations: > > > > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ > > > > This implementation has no tests yet. Before writing them I'd like to > > be sure that this enhancement could be accepted in general (or > > probably foldLeft is accepted and foldRight is not?) Could anybody > > sponsor it when it will be complete? > > > > Thank you in advance! > > > > Tagir Valeev. > From jaroslav.tulach at oracle.com Mon Aug 14 17:06:52 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 14 Aug 2017 19:06:52 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <14332343.G5UyyslDlL@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> Message-ID: <3471900.phhlVALLFS@pracovni> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: > On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > > On 27/07/2017 10:07, Jaroslav Tulach wrote: > > > Yes, it seems like a desirable goal to let Graal compiler work with just > > > java.base. Is there a description how to build JDK9/10 with just > > > java.base > > > that I could follow and test against? > > > > You can use jlink to create a run-time image that only contains > > java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base > > --output smalljre). > > Status update: I've just tried to run Graal compiler against JDK9 with only > java.base and jdk.internal.vm.ci modules, and there are some problems. I > need to resolve them first before I provide updated version of my patch. FYI: As of https://github.com/graalvm/graal/commit/ ca9071941a1be7f1a3725529ecc231ff621d5ed0 the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/ PropertyChangeListener required a bit of work. -jt From cushon at google.com Mon Aug 14 20:07:46 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 14 Aug 2017 13:07:46 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: On Mon, Jul 31, 2017 at 11:41 AM, Liam Miller-Cushon wrote: > On Fri, Jul 28, 2017 at 3:30 PM, Martin Buchholz > wrote: > >> It looks like this will test only the year, not all the date fields. >> Shouldn't that be s/25/16/ ? >> Does this code handle the "true" epoch of 1980-01-01 ? >> > > It does now, thanks: > http://cr.openjdk.java.net/~cushon/8184940/webrev.02/ > > This raises the question of what it should do if a day or month is zero > but year/month/day are not all zero. Is 1980-0-0 special, or should > 1980-0-1 and 1980-1-0 also be tolerated for compatibility with JDK 8? > As discussed offline, there are no known instances of tools deliberately writing zip archives where a day or month is '0' other than 1980-0-0. So the current approach seems better than continuing to interpret e.g. 1980-1-0 as 1979-12-31 or 1980-0-1 as 1979-12-01. From paul.sandoz at oracle.com Mon Aug 14 22:06:33 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Aug 2017 15:06:33 -0700 Subject: RFR JDK-8184120 : javax.transaction.xa.Xid constants reference obsolete method names In-Reply-To: <2F650FC9-7DD4-4BD4-BBB4-F97024481240@oracle.com> References: <2F650FC9-7DD4-4BD4-BBB4-F97024481240@oracle.com> Message-ID: > On 11 Aug 2017, at 11:30, Lance Andersen wrote: > > Hi all > > The following change was addressed in the JTA 1.0.1B update but looks like the field descriptions were missed when the method names changed. > > The CSR for this change has also been approved. > +1 Paul. From martinrb at google.com Mon Aug 14 22:57:19 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Aug 2017 15:57:19 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: Reviewed! Please push to jdk10/jdk10/jdk. On Mon, Aug 14, 2017 at 1:07 PM, Liam Miller-Cushon wrote: > On Mon, Jul 31, 2017 at 11:41 AM, Liam Miller-Cushon > wrote: > >> On Fri, Jul 28, 2017 at 3:30 PM, Martin Buchholz >> wrote: >> >>> It looks like this will test only the year, not all the date fields. >>> Shouldn't that be s/25/16/ ? >>> Does this code handle the "true" epoch of 1980-01-01 ? >>> >> >> It does now, thanks: >> http://cr.openjdk.java.net/~cushon/8184940/webrev.02/ >> >> This raises the question of what it should do if a day or month is zero >> but year/month/day are not all zero. Is 1980-0-0 special, or should >> 1980-0-1 and 1980-1-0 also be tolerated for compatibility with JDK 8? >> > > As discussed offline, there are no known instances of tools deliberately > writing zip archives where a day or month is '0' other than 1980-0-0. So > the current approach seems better than continuing to interpret e.g. > 1980-1-0 as 1979-12-31 or 1980-0-1 as 1979-12-01. > From cushon at google.com Tue Aug 15 00:24:40 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 14 Aug 2017 17:24:40 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: The changeset is attached. (I don't have commit access.) On Mon, Aug 14, 2017 at 3:57 PM, Martin Buchholz wrote: > Reviewed! > > Please push to jdk10/jdk10/jdk. > > On Mon, Aug 14, 2017 at 1:07 PM, Liam Miller-Cushon > wrote: > >> On Mon, Jul 31, 2017 at 11:41 AM, Liam Miller-Cushon >> wrote: >> >>> On Fri, Jul 28, 2017 at 3:30 PM, Martin Buchholz >>> wrote: >>> >>>> It looks like this will test only the year, not all the date fields. >>>> Shouldn't that be s/25/16/ ? >>>> Does this code handle the "true" epoch of 1980-01-01 ? >>>> >>> >>> It does now, thanks: >>> http://cr.openjdk.java.net/~cushon/8184940/webrev.02/ >>> >>> This raises the question of what it should do if a day or month is zero >>> but year/month/day are not all zero. Is 1980-0-0 special, or should >>> 1980-0-1 and 1980-1-0 also be tolerated for compatibility with JDK 8? >>> >> >> As discussed offline, there are no known instances of tools deliberately >> writing zip archives where a day or month is '0' other than 1980-0-0. So >> the current approach seems better than continuing to interpret e.g. >> 1980-1-0 as 1979-12-31 or 1980-0-1 as 1979-12-01. >> > > From martinrb at google.com Tue Aug 15 01:15:02 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Aug 2017 18:15:02 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: OK, I pushed. From brian.goetz at oracle.com Tue Aug 15 14:49:44 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 15 Aug 2017 10:49:44 -0400 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> References: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> Message-ID: <39acca88-edde-fb60-d380-ae6125e6b513@oracle.com> It's an overstatement to say that forEachOrdered/foldLeft cannot exploit parallelism. If I have a stream: stream.parallel() .map(e -> expensiveFn(e)) .forEachOrdered(e -> ...); We still can (and do) perform the mapping in parallel even if we cannot perform the folding step yet. See ForEachOps.ForEachOrderedTask. On 8/13/2017 3:45 PM, Remi Forax wrote: > Hi Tagir, > foldLeft (and foldRight) were intentionally not included in the Stream API because as you know, their semantics is too strong to be useful for parallel streams. > > regards, > R?mi > > ----- Mail original ----- >> De: "Tagir Valeev" >> ?: "core-libs-dev" >> Envoy?: Dimanche 13 Ao?t 2017 15:27:36 >> Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation >> Please review the preliminary implementation for Stream foldLeft and >> foldRight operations: >> >> http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ >> >> This implementation has no tests yet. Before writing them I'd like to >> be sure that this enhancement could be accepted in general (or >> probably foldLeft is accepted and foldRight is not?) Could anybody >> sponsor it when it will be complete? >> >> Thank you in advance! >> >> Tagir Valeev. From magazin9 at gmail.com Sat Aug 12 02:36:18 2017 From: magazin9 at gmail.com (Krunoslav Magazin) Date: Sat, 12 Aug 2017 04:36:18 +0200 Subject: java.util.stream 'map' method, proposal of method name change Message-ID: Hi. When using java.util.stream 'map' method my opinion is that 'replaceWith' as method name would better describe what method do. 'map' method is applied on input stream, returns output stream but returned stream elements are return values from 'map' method Function argument. We continue our work with output stream so mapping with input stream have no meaning. Input stream is replaced with output stream which elements are outputs of Function. After that point we can forgot about input stream. Example of usage: now - stream.map(e -> e+2).. // read: map input stream with output stream containing elements resulting from function (e -> e+2) proposed - stream.replaceWith(e -> e+2).. // read: replace input stream with output stream containing elements resulting from function (e -> e+2) With 'map' method number of elements is the same but we do not make assumptions what passed Function will do (specialization) until the moment we pass Function implementation as method argument.. I will appreciate any comments. Best regards, Krunoslav Magazin From jbluettduncan at gmail.com Tue Aug 15 16:51:00 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Tue, 15 Aug 2017 17:51:00 +0100 Subject: java.util.stream 'map' method, proposal of method name change In-Reply-To: References: Message-ID: Hi Krunoslav, I think the reason the method was named `map` rather than `replaceWith` or an equivalent name, is because `map` is a well-known name for this sort of *higher-order function*. The name itself has been around in functional programming languages like Haskell and Scala and programming models like MapReduce for decades. Thus it would make sense to me that the writers of `java.util.stream` named it `map` to follow the Principle of least astonishment . (Why was it named that way? I admit I do not know, but someone else may be able to explain.) Hope this helps. Best regards, Jonathan On 12 August 2017 at 03:36, Krunoslav Magazin wrote: > Hi. When using java.util.stream 'map' method my opinion is that > 'replaceWith' as method name would better describe what method do. > 'map' method is applied on input stream, returns output stream but > returned stream elements are return values from 'map' method Function > argument. We continue our work with output stream so mapping with > input stream have no meaning. Input stream is replaced with output > stream which elements are outputs of Function. After that point we can > forgot about input stream. > > Example of usage: > now - stream.map(e -> e+2).. // read: map input stream with > output stream containing elements resulting from function (e -> e+2) > proposed - stream.replaceWith(e -> e+2).. // read: replace input > stream with output stream containing elements resulting from function > (e -> e+2) > > With 'map' method number of elements is the same but we do not make > assumptions what passed Function will do (specialization) until the > moment we pass Function implementation as method argument.. > > I will appreciate any comments. > Best regards, > Krunoslav Magazin > From brian.goetz at oracle.com Tue Aug 15 20:04:55 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 15 Aug 2017 16:04:55 -0400 Subject: java.util.stream 'map' method, proposal of method name change In-Reply-To: References: Message-ID: <1508035b-24a9-2ad7-6b13-2dd3f43d4521@oracle.com> Naming is a deeply subjective thing; whatever names we chose, invariably someone (or many someones) would come along and say "why didn't you choose X." Sometimes there's a good reason why the proposed X is clearly worse; sometimes its just a subjective association. But of course, we have to pick one name that is good enough for all Java developers, even if it is not ideal from some subjective viewpoints. Names like `replaceWith` were actually considered, and rejected for a good reason: words like "replace" have a connotation a mutative update. This would be a good fit for in-place mutative methods like `List.replaceAll(T -> T)`, but a worse choice for a stream method. (You're free to disagree, of course.) Regardless, changing method names on core abstractions like List or Stream is completely out of the question; this would be both a binary- and source-incompatible change (existing compiled classfiles would stop working; existing sources couldn't be recompiled.) And adding an alias with a different name would be silly, unless the old name were so egregiously inappropriate as to be dangerous. On 8/11/2017 10:36 PM, Krunoslav Magazin wrote: > Hi. When using java.util.stream 'map' method my opinion is that > 'replaceWith' as method name would better describe what method do. > 'map' method is applied on input stream, returns output stream but > returned stream elements are return values from 'map' method Function > argument. We continue our work with output stream so mapping with > input stream have no meaning. Input stream is replaced with output > stream which elements are outputs of Function. After that point we can > forgot about input stream. > > Example of usage: > now - stream.map(e -> e+2).. // read: map input stream with > output stream containing elements resulting from function (e -> e+2) > proposed - stream.replaceWith(e -> e+2).. // read: replace input > stream with output stream containing elements resulting from function > (e -> e+2) > > With 'map' method number of elements is the same but we do not make > assumptions what passed Function will do (specialization) until the > moment we pass Function implementation as method argument.. > > I will appreciate any comments. > Best regards, > Krunoslav Magazin From forax at univ-mlv.fr Wed Aug 16 12:26:52 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Aug 2017 12:26:52 +0000 Subject: java.util.stream 'map' method, proposal of method name change In-Reply-To: References: Message-ID: On August 15, 2017 6:51:00 PM GMT+02:00, Jonathan Bluett-Duncan wrote: >Hi Krunoslav, > >I think the reason the method was named `map` rather than `replaceWith` >or >an equivalent name, is because `map` is a well-known name for this >sort of *higher-order >function*. The name itself has been around in functional programming >languages like Haskell and Scala and programming models like MapReduce >for >decades. > >Thus it would make sense to me that the writers of `java.util.stream` >named >it `map` to follow the Principle of least astonishment >. > >(Why was it named that way? I admit I do not know, but someone else may >be >able to explain.) the name comes from Lisp https://en.m.wikipedia.org/wiki/Map_(higher-order_function) > >Hope this helps. > >Best regards, >Jonathan Remi > >On 12 August 2017 at 03:36, Krunoslav Magazin >wrote: > >> Hi. When using java.util.stream 'map' method my opinion is that >> 'replaceWith' as method name would better describe what method do. >> 'map' method is applied on input stream, returns output stream but >> returned stream elements are return values from 'map' method Function >> argument. We continue our work with output stream so mapping with >> input stream have no meaning. Input stream is replaced with output >> stream which elements are outputs of Function. After that point we >can >> forgot about input stream. >> >> Example of usage: >> now - stream.map(e -> e+2).. // read: map input stream with >> output stream containing elements resulting from function (e -> e+2) >> proposed - stream.replaceWith(e -> e+2).. // read: replace input >> stream with output stream containing elements resulting from function >> (e -> e+2) >> >> With 'map' method number of elements is the same but we do not make >> assumptions what passed Function will do (specialization) until the >> moment we pass Function implementation as method argument.. >> >> I will appreciate any comments. >> Best regards, >> Krunoslav Magazin >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From forax at univ-mlv.fr Wed Aug 16 12:33:34 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Aug 2017 12:33:34 +0000 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: <39acca88-edde-fb60-d380-ae6125e6b513@oracle.com> References: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> <39acca88-edde-fb60-d380-ae6125e6b513@oracle.com> Message-ID: <845B63AF-2528-4254-99A3-09DC9200B1E6@univ-mlv.fr> :) let say that fold left is not as useful as one may think when used in parallel. Remi On August 15, 2017 4:49:44 PM GMT+02:00, Brian Goetz wrote: >It's an overstatement to say that forEachOrdered/foldLeft cannot >exploit >parallelism. If I have a stream: > > stream.parallel() > .map(e -> expensiveFn(e)) > .forEachOrdered(e -> ...); > >We still can (and do) perform the mapping in parallel even if we cannot > >perform the folding step yet. See ForEachOps.ForEachOrderedTask. > >On 8/13/2017 3:45 PM, Remi Forax wrote: >> Hi Tagir, >> foldLeft (and foldRight) were intentionally not included in the >Stream API because as you know, their semantics is too strong to be >useful for parallel streams. >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Tagir Valeev" >>> ?: "core-libs-dev" >>> Envoy?: Dimanche 13 Ao?t 2017 15:27:36 >>> Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation >>> Please review the preliminary implementation for Stream foldLeft and >>> foldRight operations: >>> >>> http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ >>> >>> This implementation has no tests yet. Before writing them I'd like >to >>> be sure that this enhancement could be accepted in general (or >>> probably foldLeft is accepted and foldRight is not?) Could anybody >>> sponsor it when it will be complete? >>> >>> Thank you in advance! >>> >>> Tagir Valeev. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From forax at univ-mlv.fr Wed Aug 16 12:56:30 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Aug 2017 12:56:30 +0000 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: References: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> Message-ID: <3E297D42-5829-43FD-A499-E577C815BE46@univ-mlv.fr> Yes, reconsidering old decision is healthy, but you need provide some data/good reason to explain what has changed. By example, I'm curious about the number of occurrences of forEachOrdered in the wild, given that fold left (a kind of reduce) will be even less used than a forEachOrdered (a kind of forEach). R?mi On August 14, 2017 2:58:18 AM GMT+02:00, Tagir Valeev wrote: >Hello, Remi! > >Yes, I know. But times change and old decisions could be reconsidered. >After all, forEachOrdered was included and its semantics is essentially >the >same as in foldLeft with respect to parallel streams. > >With best regards, >Tagir Valeev. > >14 ???. 2017 ?. 2:45 AM ???????????? "Remi Forax" >???????: > >> Hi Tagir, >> foldLeft (and foldRight) were intentionally not included in the >Stream API >> because as you know, their semantics is too strong to be useful for >> parallel streams. >> >> regards, >> R?mi >> >> ----- Mail original ----- >> > De: "Tagir Valeev" >> > ?: "core-libs-dev" >> > Envoy?: Dimanche 13 Ao?t 2017 15:27:36 >> > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation >> >> > Please review the preliminary implementation for Stream foldLeft >and >> > foldRight operations: >> > >> > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ >> > >> > This implementation has no tests yet. Before writing them I'd like >to >> > be sure that this enhancement could be accepted in general (or >> > probably foldLeft is accepted and foldRight is not?) Could anybody >> > sponsor it when it will be complete? >> > >> > Thank you in advance! >> > >> > Tagir Valeev. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From xueming.shen at oracle.com Wed Aug 16 19:36:55 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 16 Aug 2017 12:36:55 -0700 Subject: RFR JDK-8186227: jdk/nio/zipfs/ZeroDate.java fails on Windows with "IllegalArgumentException: Illegal character in opaque part at index 13" Message-ID: <59949ED7.4010305@oracle.com> Hi Martin, Confirmed it fixed the issue on windows platforms. issue: https://bugs.openjdk.java.net/browse/JDK-8186227 webrev: http://cr.openjdk.java.net/~sherman/8186227 Please help review the change. Thanks, Sherman From Roger.Riggs at Oracle.com Wed Aug 16 20:01:36 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 16 Aug 2017 16:01:36 -0400 Subject: RFR JDK-8186227: jdk/nio/zipfs/ZeroDate.java fails on Windows with "IllegalArgumentException: Illegal character in opaque part at index 13" In-Reply-To: <59949ED7.4010305@oracle.com> References: <59949ED7.4010305@oracle.com> Message-ID: <2a2edcdc-e3f8-6f75-53a1-52b8d5649c1c@Oracle.com> Hi Sherman, Looks good Regards, Roger On 8/16/2017 3:36 PM, Xueming Shen wrote: > Hi Martin, > > Confirmed it fixed the issue on windows platforms. > > issue: https://bugs.openjdk.java.net/browse/JDK-8186227 > webrev: http://cr.openjdk.java.net/~sherman/8186227 > > Please help review the change. > > Thanks, > Sherman From tom.w.hood at gmail.com Wed Aug 16 20:30:28 2017 From: tom.w.hood at gmail.com (Tom Hood) Date: Wed, 16 Aug 2017 13:30:28 -0700 Subject: Manifest Add-Exports vs. command line --add-exports Message-ID: Hi, I need a little help understanding the difference between "Add-Exports:" in a jar's manifest vs. the command line arg --add-exports. I can get --add-exports to work, but not Add-Exports. JDK Version: 9 build 181 windows 64 Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare- for-jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an alternative to --add-exports Our webstart-launched app requires a long list of --add-module and/or --add-exports command line options. The list is long enough that it exceeds a limit on number of args and webstart fails to launch the app with the popup "too many args to run". Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access java.base/sun.security.action by adding --add-exports=java.base/sun.security.action=ALL-UNNAMED to the java-vm-args in the jnlp. However, that one additional arg pushed it over the edge and exceeded the limit. This is the full j2se element in our jnlp: I then removed the last --add-exports to keep under the arg limit and instead added an Add-Exports line to the jai_imageio.jar META-INF/MANIFEST.MF Add-Exports: java.base/sun.security.action That doesn't appear to be taking affect. Am I using it incorrectly? Thanks, -- Tom From vicente.romero at oracle.com Wed Aug 16 20:47:24 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 16 Aug 2017 16:47:24 -0400 Subject: RFR: 8186314: code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change Message-ID: Hi, Please review the fix for issue [1]. The fix can be found at [2]. The fix is minimal, reproduced below: --- old/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.403085344 -0400 +++ new/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.323085347 -0400 @@ -890,7 +890,7 @@ needsSave(); } - static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); + static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); @Override public Iterator getAttachments() { It doesn't imply any semantic change to the existing code. The reason for the change is that the initialization expression was being accepted by javac due to a bug in the parser. Once the bug gets fixed, the old code will stop compiling. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8186314 [2] http://cr.openjdk.java.net/~vromero/8186314/webrev.01/ /Hello, />>>//>>>/Please review the fix to the following issue: />>>//>>>/https://bugs.openjdk.java.net/browse/JDK-8160199 />>>//>>>/The fix is located at: />>>//>>>/http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ />>>//>>>/The gist of the issue was that the script code has not been properly />>>/treated in macOS specific code. Since it shares the same code with />>>/other Unix, the locale format should follow POSIX, such as />>>/az-Cyrl-AZ needing to be az_AZ at Cyrl. />>>//>>>/Naoto/ From ropalka at redhat.com Wed Aug 16 21:03:36 2017 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 16 Aug 2017 23:03:36 +0200 Subject: Manifest Add-Exports vs. command line --add-exports In-Reply-To: References: Message-ID: Hi Tom, Add-Exports option in manifest is used if and only if jar is executed via 'java -jar your.jar' command. The manifest Add-Exports option is ignored for jars on classpath. Rio On Wed, Aug 16, 2017 at 10:30 PM, Tom Hood wrote: > Hi, > > I need a little help understanding the difference between "Add-Exports:" in > a jar's manifest vs. the command line arg --add-exports. I can get > --add-exports to work, but not Add-Exports. > > JDK Version: 9 build 181 windows 64 > > Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare- > for-jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an > alternative to --add-exports > > Our webstart-launched app requires a long list of --add-module and/or > --add-exports command line options. The list is long enough that it > exceeds a limit on number of args and webstart fails to launch the app with > the popup "too many args to run". > > Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access > java.base/sun.security.action by adding > --add-exports=java.base/sun.security.action=ALL-UNNAMED > to the java-vm-args in the jnlp. However, that one additional arg pushed > it over the edge and exceeded the limit. > > This is the full j2se element in our jnlp: > > java-vm-args="--add-modules=java.corba --add-exports > java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports > java.desktop/sun.swing=ALL-UNNAMED --add-exports > java.desktop/sun.awt=ALL-UNNAMED --add-exports > java.desktop/sun.awt.image=ALL-UNNAMED --add-exports > java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports > java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports > java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports > java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se > curity.action=ALL-UNNAMED"/> > > I then removed the last --add-exports to keep under the arg limit and > instead added an Add-Exports line to the jai_imageio.jar > META-INF/MANIFEST.MF > > Add-Exports: java.base/sun.security.action > > That doesn't appear to be taking affect. Am I using it incorrectly? > > Thanks, > -- Tom > -- -- Richard Opalka Principal Software Engineer Red Hat JBoss Middleware Mobile: +420 731 186 942 E-mail: ropalka at redhat.com From tom.w.hood at gmail.com Wed Aug 16 21:12:30 2017 From: tom.w.hood at gmail.com (Tom Hood) Date: Wed, 16 Aug 2017 14:12:30 -0700 Subject: Manifest Add-Exports vs. command line --add-exports In-Reply-To: References: Message-ID: I found Alan's video (time: about 27:35) that goes with the slides pdf link and he mentions the Add-Exports line need to go in the manifest of the jar with the Main-Class. I just now tried that and it still didn't take effect. I'm still getting the same error: java.lang.IllegalAccessError: class com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter (in unamed module @0x52a256fc) cannot access class sun.security.action.GetPropertyAction (in module java.base) because module java.base does not export sun.security.action to unnamed module @0x52a256fc at com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.[PNMImageWriter.java:85] The META-INF/MANIFEST.MF looks like this: Manifest-Version: 1.0 Trusted-Library: true Application-Library-Allowable-Codebase: * Application-Name: TheName Permissions: all-permissions *Add-Exports: java.base/sun.security.action* Created-By: 1.6.0_24 (Sun Microsystems Inc.) Caller-Allowable-Codebase: * Main-Class: path.to.TheMainClass Codebase: * Name: path/to/a/file.class SHA1-Digest: thedigest (many more such class+digest pairs) Should this work or am I using it incorrectly? Thanks, -- Tom On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood wrote: > Hi, > > I need a little help understanding the difference between "Add-Exports:" > in a jar's manifest vs. the command line arg --add-exports. I can get > --add-exports to work, but not Add-Exports. > > JDK Version: 9 build 181 windows 64 > > Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-for- > jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an > alternative to --add-exports > > Our webstart-launched app requires a long list of --add-module and/or > --add-exports command line options. The list is long enough that it > exceeds a limit on number of args and webstart fails to launch the app with > the popup "too many args to run". > > Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access > java.base/sun.security.action by adding --add-exports=java.base/sun.security.action=ALL-UNNAMED > to the java-vm-args in the jnlp. However, that one additional arg pushed > it over the edge and exceeded the limit. > > This is the full j2se element in our jnlp: > > java-vm-args="--add-modules=java.corba --add-exports > java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports > java.desktop/sun.swing=ALL-UNNAMED --add-exports > java.desktop/sun.awt=ALL-UNNAMED --add-exports > java.desktop/sun.awt.image=ALL-UNNAMED --add-exports > java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports > java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports > java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports > java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se > curity.action=ALL-UNNAMED"/> > > I then removed the last --add-exports to keep under the arg limit and > instead added an Add-Exports line to the jai_imageio.jar > META-INF/MANIFEST.MF > > Add-Exports: java.base/sun.security.action > > That doesn't appear to be taking affect. Am I using it incorrectly? > > Thanks, > -- Tom > > From tom.w.hood at gmail.com Wed Aug 16 21:14:00 2017 From: tom.w.hood at gmail.com (Tom Hood) Date: Wed, 16 Aug 2017 14:14:00 -0700 Subject: Manifest Add-Exports vs. command line --add-exports In-Reply-To: References: Message-ID: Thanks Richard. Sorry I didn't see your post before hitting send. So does this mean there is no workaround for a webstart app that requires a lot of the --add-export options? On Wed, Aug 16, 2017 at 2:12 PM, Tom Hood wrote: > I found Alan's video (time: > about 27:35) that goes with the slides pdf link and he mentions the > Add-Exports line need to go in the manifest of the jar with the > Main-Class. I just now tried that and it still didn't take effect. I'm > still getting the same error: > > java.lang.IllegalAccessError: class com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter > (in unamed module @0x52a256fc) cannot access class sun.security.action.GetPropertyAction > (in module java.base) because module java.base does not export > sun.security.action to unnamed module @0x52a256fc > at com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.< > init>[PNMImageWriter.java:85] > > The META-INF/MANIFEST.MF looks like this: > > Manifest-Version: 1.0 > Trusted-Library: true > Application-Library-Allowable-Codebase: * > Application-Name: TheName > Permissions: all-permissions > *Add-Exports: java.base/sun.security.action* > Created-By: 1.6.0_24 (Sun Microsystems Inc.) > Caller-Allowable-Codebase: * > Main-Class: path.to.TheMainClass > Codebase: * > > Name: path/to/a/file.class > SHA1-Digest: thedigest > > (many more such class+digest pairs) > > Should this work or am I using it incorrectly? > > Thanks, > -- Tom > > On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood wrote: > >> Hi, >> >> I need a little help understanding the difference between "Add-Exports:" >> in a jar's manifest vs. the command line arg --add-exports. I can get >> --add-exports to work, but not Add-Exports. >> >> JDK Version: 9 build 181 windows 64 >> >> Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jd >> k9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an >> alternative to --add-exports >> >> Our webstart-launched app requires a long list of --add-module and/or >> --add-exports command line options. The list is long enough that it >> exceeds a limit on number of args and webstart fails to launch the app with >> the popup "too many args to run". >> >> Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access >> java.base/sun.security.action by adding --add-exports=java.base/sun.security.action=ALL-UNNAMED >> to the java-vm-args in the jnlp. However, that one additional arg pushed >> it over the edge and exceeded the limit. >> >> This is the full j2se element in our jnlp: >> >> > java-vm-args="--add-modules=java.corba --add-exports >> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports >> java.desktop/sun.swing=ALL-UNNAMED --add-exports >> java.desktop/sun.awt=ALL-UNNAMED --add-exports >> java.desktop/sun.awt.image=ALL-UNNAMED --add-exports >> java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports >> java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports >> java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports >> java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se >> curity.action=ALL-UNNAMED"/> >> >> I then removed the last --add-exports to keep under the arg limit and >> instead added an Add-Exports line to the jai_imageio.jar >> META-INF/MANIFEST.MF >> >> Add-Exports: java.base/sun.security.action >> >> That doesn't appear to be taking affect. Am I using it incorrectly? >> >> Thanks, >> -- Tom >> >> > From martinrb at google.com Wed Aug 16 22:35:17 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Aug 2017 15:35:17 -0700 Subject: RFR JDK-8186227: jdk/nio/zipfs/ZeroDate.java fails on Windows with "IllegalArgumentException: Illegal character in opaque part at index 13" In-Reply-To: <59949ED7.4010305@oracle.com> References: <59949ED7.4010305@oracle.com> Message-ID: Thanks! On Wed, Aug 16, 2017 at 12:36 PM, Xueming Shen wrote: > Hi Martin, > > Confirmed it fixed the issue on windows platforms. > > issue: https://bugs.openjdk.java.net/browse/JDK-8186227 > webrev: http://cr.openjdk.java.net/~sherman/8186227 > > Please help review the change. > > Thanks, > Sherman > From amaembo at gmail.com Thu Aug 17 06:07:57 2017 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 17 Aug 2017 13:07:57 +0700 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: <3E297D42-5829-43FD-A499-E577C815BE46@univ-mlv.fr> References: <661536009.923051.1502653512737.JavaMail.zimbra@u-pem.fr> <3E297D42-5829-43FD-A499-E577C815BE46@univ-mlv.fr> Message-ID: Hello, R?mi! People don't use forEachOrdered not because they don't care about order, but because they don't care about parallelism and forEach does the same (for sequential stream) with a shorter name. Similar to foldLeft. Currently people often use reduce instead of missing foldLeft, feeding reduce with non-associative operation, identity element violating identity properties and specifying a bogus combiner, because they just don't care about parallelism. Here are some examples: https://github.com/TheDIM47/RestSample/blob/1cc0c6f9f4c6a1980b608ddcbc743dcb3f17eeb9/src/main/java/com/juliasoft/rest/CalculatorService.java#L20 .reduce(values[0], (x, y) -> x - y); -- associativity is clearly violated https://github.com/mary-mogreen/java8_training/blob/8b0bb9e87905def30757b7d8aedbb950b936b24d/src/ch02/ex10/StreamUtils.java#L19 .reduce(0.0, (x, y) -> {count.incrementAndGet();return x + y;}); -- op has side-effect and will definitely yield the wrong result in parallel Well it's hard to search through github as it's filled with student projects. Nevertheless people sometimes recommend to use reduce when no combiner is possible: https://stackoverflow.com/a/43660838 Note that answer is upvoted and accepted, so you may expect that similar code appears in the wild. Some libraries even provide a "convenient" no-combiner which throws: https://github.com/poetix/protonpack/blob/0ba7e9d4eb63de3e7d40755c562e9a64b05ea927/src/main/java/com/codepoetics/protonpack/collectors/CollectorUtils.java#L125 Also people often try to use non-associative op in reduce and wonder why it works incorrectly in parallel: https://stackoverflow.com/q/32799937 https://stackoverflow.com/q/33375335 You may only guess how many people use reduce incorrectly in real projects. Were foldLeft alternative present, people would use it and their code would be correct (though not so fast) even when .parallel() is specified. Sometimes people ask questions where the answer would be "Use foldLeft... ah, it doesn't exist": https://stackoverflow.com/q/30736587 With best regards, Tagir Valeev. On Wed, Aug 16, 2017 at 7:56 PM, Remi Forax wrote: > Yes, > reconsidering old decision is healthy, but you need provide some data/good > reason > to explain what has changed. > By example, I'm curious about the number of occurrences of forEachOrdered in > the wild, given that fold left (a kind of reduce) will be even less used > than a forEachOrdered (a kind of forEach). > > R?mi > > > > On August 14, 2017 2:58:18 AM GMT+02:00, Tagir Valeev > wrote: >> >> Hello, Remi! >> >> Yes, I know. But times change and old decisions could be reconsidered. >> After all, forEachOrdered was included and its semantics is essentially the >> same as in foldLeft with respect to parallel streams. >> >> With best regards, >> Tagir Valeev. >> >> 14 ???. 2017 ?. 2:45 AM ???????????? "Remi Forax" >> ???????: >>> >>> Hi Tagir, >>> foldLeft (and foldRight) were intentionally not included in the Stream >>> API because as you know, their semantics is too strong to be useful for >>> parallel streams. >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>> > De: "Tagir Valeev" >>> > ?: "core-libs-dev" >>> > Envoy?: Dimanche 13 Ao?t 2017 15:27:36 >>> > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation >>> >>> > Please review the preliminary implementation for Stream foldLeft and >>> > foldRight operations: >>> > >>> > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ >>> > >>> > This implementation has no tests yet. Before writing them I'd like to >>> > be sure that this enhancement could be accepted in general (or >>> > probably foldLeft is accepted and foldRight is not?) Could anybody >>> > sponsor it when it will be complete? >>> > >>> > Thank you in advance! >>> > >>> > Tagir Valeev. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From aleksej.efimov at oracle.com Thu Aug 17 13:38:40 2017 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 17 Aug 2017 14:38:40 +0100 Subject: RFR: 8186314: code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change In-Reply-To: References: Message-ID: Hi Vicente, The change looks good to me (not a reviewer). Best, Aleksei On 08/16/2017 09:47 PM, Vicente Romero wrote: > Hi, > > Please review the fix for issue [1]. The fix can be found at [2]. The > fix is minimal, reproduced below: > > --- old/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.403085344 -0400 > +++ new/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.323085347 -0400 > @@ -890,7 +890,7 @@ > needsSave(); > } > > - static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > + static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > > @Override > public Iterator getAttachments() { > > It doesn't imply any semantic change to the existing code. The reason > for the change is that the initialization expression was being > accepted by javac due to a bug in the parser. Once the bug gets fixed, > the old code will stop compiling. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8186314 > [2] http://cr.openjdk.java.net/~vromero/8186314/webrev.01/ > > /Hello, />>>//>>>/Please review the fix to the following issue: />>>//>>>/https://bugs.openjdk.java.net/browse/JDK-8160199 />>>//>>>/The fix is located at: />>>//>>>/http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ > />>>//>>>/The gist of the issue was that the script code has not been properly />>>/treated in macOS specific code. Since it shares the same code with />>>/other Unix, the locale format should follow POSIX, such as />>>/az-Cyrl-AZ needing to be az_AZ at Cyrl. > />>>//>>>/Naoto/ From lance.andersen at oracle.com Thu Aug 17 15:16:41 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 17 Aug 2017 11:16:41 -0400 Subject: RFR: 8186314: code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change In-Reply-To: References: Message-ID: <229C071B-42DE-4D61-B954-74FBA1CE77D3@oracle.com> Looks OK > On Aug 16, 2017, at 4:47 PM, Vicente Romero wrote: > > Hi, > > Please review the fix for issue [1]. The fix can be found at [2]. The fix is minimal, reproduced below: > > --- old/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.403085344 -0400 > +++ new/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.323085347 -0400 > @@ -890,7 +890,7 @@ > needsSave(); > } > - static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > + static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > @Override > public Iterator getAttachments() { > > > It doesn't imply any semantic change to the existing code. The reason for the change is that the initialization expression was being accepted by javac due to a bug in the parser. Once the bug gets fixed, the old code will stop compiling. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8186314 > [2] http://cr.openjdk.java.net/~vromero/8186314/webrev.01/ > > /Hello, />>>//>>>/Please review the fix to the following issue: />>>//>>>/https://bugs.openjdk.java.net/browse/JDK-8160199 />>>//>>>/The fix is located at: />>>//>>>/http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ />>>//>>>/The gist of the issue was that the script code has not been properly />>>/treated in macOS specific code. Since it shares the same code with />>>/other Unix, the locale format should follow POSIX, such as />>>/az-Cyrl-AZ needing to be az_AZ at Cyrl. />>>//>>>/Naoto/ > 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 Thu Aug 17 18:54:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Aug 2017 11:54:34 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <3471900.phhlVALLFS@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: Hi Jaroslav, What we should do with 8182701? Do you still need JVMCI changes? Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): https://bugs.openjdk.java.net/browse/JDK-8186158 Thanks, Vladimir On 8/14/17 10:06 AM, Jaroslav Tulach wrote: > On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>> java.base. Is there a description how to build JDK9/10 with just >>>> java.base >>>> that I could follow and test against? >>> >>> You can use jlink to create a run-time image that only contains >>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>> --output smalljre). >> >> Status update: I've just tried to run Graal compiler against JDK9 with only >> java.base and jdk.internal.vm.ci modules, and there are some problems. I >> need to resolve them first before I provide updated version of my patch. > > FYI: As of > https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 > the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only > modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. > > -jt > > From ramanand.patil at oracle.com Thu Aug 17 19:06:52 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 17 Aug 2017 12:06:52 -0700 (PDT) Subject: RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type Message-ID: <304c0e8b-f911-4be4-ad75-51e606215f49@default> Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048738.html JDK10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/6256e94781f5 The usage of shared secrets is removed as compared to the original fix since the ObjectInputFilter is accessible in the jdk.internal.misc package. Regards, Ramanand. From Roger.Riggs at Oracle.com Thu Aug 17 21:17:45 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Aug 2017 17:17:45 -0400 Subject: RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type In-Reply-To: <304c0e8b-f911-4be4-ad75-51e606215f49@default> References: <304c0e8b-f911-4be4-ad75-51e606215f49@default> Message-ID: Hi Ramanand, Looks fine. Thanks for the cleanup around the shared secrets. Roger On 8/17/2017 3:06 PM, Ramanand Patil wrote: > Hi All, > > Please review this webrev for jdk8u backport. > Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ > > Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 > JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048738.html > JDK10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/6256e94781f5 > > The usage of shared secrets is removed as compared to the original fix since the ObjectInputFilter is accessible in the jdk.internal.misc package. > > > Regards, > Ramanand. From martinrb at google.com Fri Aug 18 01:22:20 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Aug 2017 18:22:20 -0700 Subject: """error: module testng reads package test from both test and testng""" Message-ID: When I run the jtreg test java/lang/ModuleTests/addXXX I fail with direct: error: module testng reads package test from both test and testng In the javac command line I see: --add-modules testng,jcommander but ... testng and jcommander aren't modules; they're just garden variety jar files. Running jtreg 4.2-b07. From john.r.rose at oracle.com Fri Aug 18 01:32:47 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Aug 2017 18:32:47 -0700 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: References: Message-ID: On Aug 13, 2017, at 6:27 AM, Tagir Valeev wrote: > > Please review the preliminary implementation for Stream foldLeft and > foldRight operations: > > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ I think s.foldLeft(op) is the same as s.sequential().reduce(op). If that's the case, there's no need for it, except in documentation. A quick, inexpert read of package-info.java suggests to me that the encounter order of a sequential ordered stream is stable, and therefore the result of executing a reduce on such a stream should always produce the same order of operations. Which order? Well of course, the one given in the javadoc. Which is an implementation of your foldLeft, minus the unnecessary buffering. The foldRight operation is not a natural stream operation. It needs to operate in reverse sequential order, which a stream doesn't support. Better to make the buffering required for that reversal explicit to the user, IMO. I know it's a case of brief notation vs. "picky" explicitness; in this case the pickiness wins because there is an extra O(N) copy hiding in the pretty brevity. To me I think foldRight belongs (and also foldLeft) in Arrays and Collections, alongside sort. One reason we are being slow to add that sort of thing is because we plan to change our genericity story. Finally, although I can't quarrel too much with Scala's choice of terms, I find it hard to tell which is which. (I'm also left-handed.) Personally find foldLeft (and foldl) hard to remember, and would prefer something that makes it clear that you are processing elements from left to right. So foldFromLeft would help me. But in that case it should just be reduceFromLeft, since we already have reduce (which means place the brackets wherever). ? John From john.r.rose at oracle.com Fri Aug 18 01:46:01 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Aug 2017 18:46:01 -0700 Subject: RFR: JDK-8133680 add Stream.foldLeft() terminal operation In-Reply-To: References: Message-ID: <5650CCD9-DD08-484D-B467-EFC01ACFC8D4@oracle.com> On Aug 17, 2017, at 6:32 PM, John Rose wrote: > > Better to make the buffering required for > that reversal explicit to the user, IMO. I know it's a case of > brief notation vs. "picky" explicitness; in this case the pickiness > wins because there is an extra O(N) copy hiding in the pretty > brevity. One more thought: These concerns could be balanced by giving Stream a reverse() operation. Then reverse().reduce() with a suitable lambda would give you foldRight. The reversed stream would be in sequential mode, of course. Unless the stream is already pointed at a reversible data source, the user will know that it is an expensive operation, requiring the original stream to be run forward into a buffer. So: s .foldLeft(op) == s .sequential() .reduce(op) (Isn't the .sequential() guaranteed to be a no-op if the source is a list or array and there is no parallel transform??) And: s .foldRight(op) == s .reverse() .reduce((x,y)->op.apply(y,x)) To me that seems to hit the right balance between convenience and clarity of performance model. From shihua.guo at oracle.com Fri Aug 18 02:03:21 2017 From: shihua.guo at oracle.com (Eric Guo) Date: Fri, 18 Aug 2017 10:03:21 +0800 Subject: RFR: 8186314: code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change In-Reply-To: References: Message-ID: <990dba6c-eda8-e2a9-27ab-dbaf892b4d34@oracle.com> Hi Vicente, It looks good to me. Regards, Eric (Shihua Guo) On 17/08/2017 04:47, Vicente Romero wrote: > Hi, > > Please review the fix for issue [1]. The fix can be found at [2]. The > fix is minimal, reproduced below: > > --- old/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.403085344 -0400 > +++ new/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java 2017-08-16 16:31:21.323085347 -0400 > @@ -890,7 +890,7 @@ > needsSave(); > } > > - static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > + static private final Iterator nullIter = Collections.EMPTY_LIST.iterator(); > > @Override > public Iterator getAttachments() { > > It doesn't imply any semantic change to the existing code. The reason > for the change is that the initialization expression was being > accepted by javac due to a bug in the parser. Once the bug gets fixed, > the old code will stop compiling. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8186314 > [2] http://cr.openjdk.java.net/~vromero/8186314/webrev.01/ > > /Hello, />>>//>>>/Please review the fix to the following issue: />>>//>>>/https://bugs.openjdk.java.net/browse/JDK-8160199 />>>//>>>/The fix is located at: />>>//>>>/http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ > />>>//>>>/The gist of the issue was that the script code has not been properly />>>/treated in macOS specific code. Since it shares the same code with />>>/other Unix, the locale format should follow POSIX, such as />>>/az-Cyrl-AZ needing to be az_AZ at Cyrl. > />>>//>>>/Naoto/ From adinn at redhat.com Fri Aug 18 10:02:47 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Aug 2017 11:02:47 +0100 Subject: java.util.stream 'map' method, proposal of method name change In-Reply-To: References: Message-ID: <77734ac3-c0a1-efe2-745b-02058b68381c@redhat.com> On 16/08/17 13:26, Remi Forax wrote: > the name comes from Lisp > https://en.m.wikipedia.org/wiki/Map_(higher-order_function) Actually, the Lisp usage comes from mathematics: https://en.wikipedia.org/wiki/Map_(mathematics) Since the original conception of Lisp was lambda calculus realised as a programming language it should be no surprise that Lispers chose their terminology from abstract algebra. 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 sean.coffey at oracle.com Fri Aug 18 12:44:22 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 18 Aug 2017 13:44:22 +0100 Subject: RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type In-Reply-To: <304c0e8b-f911-4be4-ad75-51e606215f49@default> References: <304c0e8b-f911-4be4-ad75-51e606215f49@default> Message-ID: <61e5ef61-ddc0-6233-f22c-f34efc57fa8a@oracle.com> Looks good. Regards, Sean. On 17/08/17 20:06, Ramanand Patil wrote: > Hi All, > > Please review this webrev for jdk8u backport. > Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ > > Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 > JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048738.html > JDK10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/6256e94781f5 > > The usage of shared secrets is removed as compared to the original fix since the ObjectInputFilter is accessible in the jdk.internal.misc package. > > > Regards, > Ramanand. From Roger.Riggs at Oracle.com Fri Aug 18 14:48:16 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Aug 2017 10:48:16 -0400 Subject: RFR 8173817: StackOverflowError in "process reaper" thread Message-ID: Please review a change to the process reaper completion handler's choice of an anonymous inner class for more consistent stack usage.? Additional background and discussion in the issue 8173817 [1]. Webrev: ?? http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8173817/ Issue: [1] ? https://bugs.openjdk.java.net/browse/JDK-8173817 Thanks, Roger From vladimir.kozlov at oracle.com Fri Aug 18 18:49:44 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 11:49:44 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ On 8/18/17 7:12 AM, Jaroslav Tulach wrote: Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if we want the Graal compiler to expose its MBean in a lazy way. I am offering new webrev for review. It contains following changes: Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge between JVMCI and jdk.management. Adding new module was a bit tricky, but with great help of Jan Lahoda I even managed to register it as a boot module. I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I fixed the non-standard location of JVMCIMXBean class. I changed the interface to use Map, so the compiler is able to expose more than a single bean. That's it. I am looking forward to your review comments. -jt Here are original changes for reference: http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ On 8/17/17 11:54 AM, Vladimir Kozlov wrote: > Hi Jaroslav, > > What we should do with 8182701? Do you still need JVMCI changes? > > Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): > https://bugs.openjdk.java.net/browse/JDK-8186158 > > Thanks, > Vladimir > > On 8/14/17 10:06 AM, Jaroslav Tulach wrote: >> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>>> java.base. Is there a description how to build JDK9/10 with just >>>>> java.base >>>>> that I could follow and test against? >>>> >>>> You can use jlink to create a run-time image that only contains >>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>>> --output smalljre). >>> >>> Status update: I've just tried to run Graal compiler against JDK9 with only >>> java.base and jdk.internal.vm.ci modules, and there are some problems. I >>> need to resolve them first before I provide updated version of my patch. >> >> FYI: As of >> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 >> the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only >> modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. >> >> -jt >> >> From doug.simon at oracle.com Fri Aug 18 19:11:28 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 18 Aug 2017 21:11:28 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: <7E1AB15F-D365-4145-B31F-0931FC389EF9@oracle.com> Hi Jaroslav, In general, thanks for pushing through with this change. I don't think JVMCIMXBeans should be in the hotspot-agnostic jdk.vm.ci.services.internal package since it has a direct reference to HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot. In HotSpotJVMCRuntime.java: 558 public String mbeanName() { 568 public Object mbean() { Any reason these methods don't follow the conventions of other getter methods in this class (i.e. getMBeanName() and getMBean())? 95 /** Name of the {@link MBeanInfo MBean} representing the internals This should be: /** * Gets the name of the ... Same comment for mbean() method. Also {@code null} is used in JVMCI instead of null. -Doug > On 18 Aug 2017, at 20:49, Vladimir Kozlov wrote: > > Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ > > On 8/18/17 7:12 AM, Jaroslav Tulach wrote: > > Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if > we want the Graal compiler to expose its MBean in a lazy way. I am offering > new webrev for review. It contains following changes: > > Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge between > JVMCI and jdk.management. Adding new module was a bit tricky, but with great help of Jan > Lahoda I even managed to register it as a boot module. > > I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I fixed > the non-standard location of JVMCIMXBean class. > > I changed the interface to use Map, so the compiler is able to expose more > than a single bean. > > That's it. I am looking forward to your review comments. > -jt > > Here are original changes for reference: > > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > On 8/17/17 11:54 AM, Vladimir Kozlov wrote: >> Hi Jaroslav, >> What we should do with 8182701? Do you still need JVMCI changes? >> Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): >> https://bugs.openjdk.java.net/browse/JDK-8186158 >> Thanks, >> Vladimir >> On 8/14/17 10:06 AM, Jaroslav Tulach wrote: >>> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >>>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>>>> java.base. Is there a description how to build JDK9/10 with just >>>>>> java.base >>>>>> that I could follow and test against? >>>>> >>>>> You can use jlink to create a run-time image that only contains >>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>>>> --output smalljre). >>>> >>>> Status update: I've just tried to run Graal compiler against JDK9 with only >>>> java.base and jdk.internal.vm.ci modules, and there are some problems. I >>>> need to resolve them first before I provide updated version of my patch. >>> >>> FYI: As of >>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 >>> the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only >>> modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. >>> >>> -jt >>> >>> From stuart.marks at oracle.com Fri Aug 18 19:59:25 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 18 Aug 2017 12:59:25 -0700 Subject: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads Message-ID: <45d8384d-91ae-3a01-7e1f-c17477d42e71@oracle.com> Hi all, Well nothing is ever simple, is it? Prompted by David Holmes' comments, I looked at the other overloads of wait(), and I agree that they're in need of cleanup. I decided to put the most complete version of the specification into the wait(timeout, nanos) overload, and then I simply redefined the other overloads wait(timeout) and wait() in terms of the first. This avoids redundancies that creep in when what ought to be the same specification is replicated across different overloads (which is probably how the specs for these methods diverged in the first place). I've incorporated comments from Martin Buchholz and Hans Boehm. I've done a little bit of rewriting where I thought it was necessary, particularly in the lead sentences of the specs. Plus I added a few editorial cleanups. Since this has gotten bigger, here's a webrev: http://cr.openjdk.java.net/~smarks/reviews/6344935/webrev.1/ Please review. Thanks. s'marks From forax at univ-mlv.fr Fri Aug 18 20:44:28 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 18 Aug 2017 22:44:28 +0200 (CEST) Subject: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads In-Reply-To: <45d8384d-91ae-3a01-7e1f-c17477d42e71@oracle.com> References: <45d8384d-91ae-3a01-7e1f-c17477d42e71@oracle.com> Message-ID: <1572964208.629198.1503089068318.JavaMail.zimbra@u-pem.fr> looks good. It's better than the previous wording. cheers, R?mi ----- Mail original ----- > De: "Stuart Marks" > ?: "core-libs-dev" > Envoy?: Vendredi 18 Ao?t 2017 21:59:25 > Objet: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads > Hi all, > > Well nothing is ever simple, is it? Prompted by David Holmes' comments, I looked > at the other overloads of wait(), and I agree that they're in need of cleanup. I > decided to put the most complete version of the specification into the > wait(timeout, nanos) overload, and then I simply redefined the other overloads > wait(timeout) and wait() in terms of the first. This avoids redundancies that > creep in when what ought to be the same specification is replicated across > different overloads (which is probably how the specs for these methods diverged > in the first place). > > I've incorporated comments from Martin Buchholz and Hans Boehm. I've done a > little bit of rewriting where I thought it was necessary, particularly in the > lead sentences of the specs. Plus I added a few editorial cleanups. > > Since this has gotten bigger, here's a webrev: > > http://cr.openjdk.java.net/~smarks/reviews/6344935/webrev.1/ > > Please review. Thanks. > > s'marks From paul.sandoz at oracle.com Fri Aug 18 23:11:46 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 18 Aug 2017 16:11:46 -0700 Subject: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity Message-ID: Hi, Please review this API enhancement for MethodHandle.invokeWithArguments to support jumbo-arity and for BSM invocation to be specified in terms of MethodHandle.invokeWithArguments: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8185992-invoke-with-arguments-jumbo/webrev/ This patch is brought to you by John Rose and initially reviewed by myself. It?s low hanging fruit that is the first deliverable from the JEP 309: Dynamic Class-File Constants [1] effort. A CSR is underway. Paul. [1] http://openjdk.java.net/jeps/309 From hboehm at google.com Fri Aug 18 23:55:28 2017 From: hboehm at google.com (Hans Boehm) Date: Fri, 18 Aug 2017 16:55:28 -0700 Subject: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads In-Reply-To: <1572964208.629198.1503089068318.JavaMail.zimbra@u-pem.fr> References: <45d8384d-91ae-3a01-7e1f-c17477d42e71@oracle.com> <1572964208.629198.1503089068318.JavaMail.zimbra@u-pem.fr> Message-ID: Agreed. Thanks! Nit: It looked to me like one of the closing brackets in the apiNote was misindented. On Fri, Aug 18, 2017 at 1:44 PM, Remi Forax wrote: > looks good. > It's better than the previous wording. > > cheers, > R?mi > > ----- Mail original ----- > > De: "Stuart Marks" > > ?: "core-libs-dev" > > Envoy?: Vendredi 18 Ao?t 2017 21:59:25 > > Objet: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait > overloads > > > Hi all, > > > > Well nothing is ever simple, is it? Prompted by David Holmes' comments, > I looked > > at the other overloads of wait(), and I agree that they're in need of > cleanup. I > > decided to put the most complete version of the specification into the > > wait(timeout, nanos) overload, and then I simply redefined the other > overloads > > wait(timeout) and wait() in terms of the first. This avoids redundancies > that > > creep in when what ought to be the same specification is replicated > across > > different overloads (which is probably how the specs for these methods > diverged > > in the first place). > > > > I've incorporated comments from Martin Buchholz and Hans Boehm. I've > done a > > little bit of rewriting where I thought it was necessary, particularly > in the > > lead sentences of the specs. Plus I added a few editorial cleanups. > > > > Since this has gotten bigger, here's a webrev: > > > > http://cr.openjdk.java.net/~smarks/reviews/6344935/webrev.1/ > > > > Please review. Thanks. > > > > s'marks > From jonathan.gibbons at oracle.com Sat Aug 19 00:03:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 18 Aug 2017 17:03:31 -0700 Subject: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base Message-ID: <59978053.1040006@oracle.com> Please review these fixes for various minor documentation issues in the java.base module. The changes are mostly in java.util and its subpackages, but there is some minor cleanup in previously updated packages as well. The primary focus is on addressing accessibility issues. In addition, some doc files have been converted to HTML5. As with all recent fixes like this, there should be no change to the underlying specifications. JBS:https://bugs.openjdk.java.net/browse/JDK-8186466 Webrev:http://cr.openjdk.java.net/~jjg/8186466/webrev.00/index.html API:http://cr.openjdk.java.net/~jjg/8186466/api.00/overview-summary.html -- Jon, the Javadoc Janitor Here are more detailed notes on the changes: src/java.base/share/classes/java/lang/String.java Some greek text that previously used discrete image files for the characters has been updated to use Unicode characters, specified with HTML entities. All related image files in the doc-files subdirectory have now been removed. src/java.base/share/classes/java/lang/doc-files/ValueBased.html The file is trivially updated to HTML 5. src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html The file is updated to HTML 5. src/java.base/share/classes/java/time/format/DateTimeFormatter.java Two missing quote marks are added. The quotes are regrettably necessary: some of the examples contain spaces, and some cells have more than one example, src/java.base/share/classes/java/util/Deque.java The tables are made accessible. Where reasonable, the tables are converted to the de-facto standard "striped" style. src/java.base/share/classes/java/util/Queue.java A table is made accessible, and converted to the de-facto standard "striped" style. src/java.base/share/classes/java/util/ResourceBundle.java A preformatted list is converted to a semantic list. The tables are made accessible. Where reasonable, the tables are converted to the de-facto standard "striped" style. Line 3458 and following. Previously, the comment did not display correctly because javadoc incorrectly treated the dot in this string "'.'" as the end of the first sentence! The minimal fix would be to change that string to "{@code .}", but that would be stylistically inconsistent with the rest of the comment. There are too many occurrences of ... in the file as a whole to change them all at this time, so the compromise is just to replace the occurrences in this comment. Introducing more cleanup for existing uses of ... is a topic for another day. src/java.base/share/classes/java/util/concurrent/BlockingDeque.java The tables are made accessible. In the second table, the "Insert"/"Remove"/"Examine" headings are moved from embedded rows to a new left-most column for consistency with other similar tables. src/java.base/share/classes/java/util/concurrent/BlockingQueue.java The table is made accessible. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java The table is made accessible. src/java.base/share/classes/java/util/doc-files/coll-designfaq.html The file is updated to HTML 5. The name attributes, which each duplicated the id attribute on the same enclosing element, are removed. src/java.base/share/classes/java/util/doc-files/coll-index.html The file is trivially updated to HTML 5. src/java.base/share/classes/java/util/doc-files/coll-overview.html The file is updated to HTML 5. A style is added for the table declared in this file. An alternative edit, to import and use the main javadoc stylesheet was consider, but caused too many other visual issues. Eventually, we should change all doc-files/*.html files to use the standard stylesheet(s). src/java.base/share/classes/java/util/doc-files/coll-reference.html The file is updated to HTML 5. src/java.base/share/classes/java/util/regex/Pattern.java This was the hardest file to update; in particular, the main table listing the supported pattern constructs. Several solutions were attempted, such as splitting the table up into smaller tables, and moving the subheadings to a new column on the left. As the saying goes, this solution is the worst, except for all the others. It has the singular advantage of preserving the existing visual appearance for most users, even if the source code is somewhat dominated by the attributes to make the table accessible, and to retain the same visual presentation. This table, and some of tables in the Collections API, highlight the shortcomings in javadoc's support for custom styles when it is really, really needed. In principle, all of the style attributes in the main table could be placed much more succintly in some local stylesheet. The other edits in this file are more obvious and straightforward. src/java.base/share/classes/java/util/spi/CalendarNameProvider.java The tables are made accessible. Again, custom stylesheets would simplify the source code. src/java.base/share/classes/java/lang/doc-files/*.gif (deleted) See comments above for src/java.base/share/classes/java/lang/String.java. The files src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc*.gif appear to be orphaned relics of earlier versions of the API. The images exist in releases at least as far back as 1.4, and look like they might have been part of some mathematical representation of a string hash function, although I've not been able to track down where the images were used. From naoto.sato at oracle.com Sat Aug 19 00:19:36 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 18 Aug 2017 17:19:36 -0700 Subject: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base In-Reply-To: <59978053.1040006@oracle.com> References: <59978053.1040006@oracle.com> Message-ID: Hi Jon, Thank you for the cleanup! I looked at j.l.String, j.t.DateTimeFormatter, and j.u.ResourceBundle and all look good. BTW, I just noticed that in ResourceBundle, line 1330 and so on, there is a new column "Index" introduced. Is this intentional? Naoto On 8/18/17 5:03 PM, Jonathan Gibbons wrote: > Please review these fixes for various minor documentation issues in the > java.base module. > The changes are mostly in java.util and its subpackages, but there is > some minor cleanup > in previously updated packages as well. > > The primary focus is on addressing accessibility issues. In addition, > some doc files have > been converted to HTML5. As with all recent fixes like this, there > should be no change to > the underlying specifications. > > JBS:https://bugs.openjdk.java.net/browse/JDK-8186466 > Webrev:http://cr.openjdk.java.net/~jjg/8186466/webrev.00/index.html > API:http://cr.openjdk.java.net/~jjg/8186466/api.00/overview-summary.html > > -- Jon, the Javadoc Janitor > > > Here are more detailed notes on the changes: > > src/java.base/share/classes/java/lang/String.java > Some greek text that previously used discrete image files for the > characters > has been updated to use Unicode characters, specified with HTML > entities. > All related image files in the doc-files subdirectory have now been > removed. > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html > The file is trivially updated to HTML 5. > > src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html > > The file is updated to HTML 5. > > src/java.base/share/classes/java/time/format/DateTimeFormatter.java > Two missing quote marks are added. > The quotes are regrettably necessary: some of the examples contain > spaces, > and some cells have more than one example, > > src/java.base/share/classes/java/util/Deque.java > The tables are made accessible. > Where reasonable, the tables are converted to the de-facto standard > "striped" style. > > src/java.base/share/classes/java/util/Queue.java > A table is made accessible, and converted to the de-facto standard > "striped" style. > > src/java.base/share/classes/java/util/ResourceBundle.java > A preformatted list is converted to a semantic list. > The tables are made accessible. > Where reasonable, the tables are converted to the de-facto standard > "striped" style. > Line 3458 and following. Previously, the comment did not display > correctly > because javadoc incorrectly treated the dot in this string > "'.'" > as the end of the first sentence! The minimal fix would be to > change that > string to "{@code .}", but that would be stylistically inconsistent > with the rest of the comment. There are too many occurrences of > ... in the file as a whole to change them all at this > time, > so the compromise is just to replace the occurrences in this comment. > Introducing more cleanup for existing uses of ... is a > topic for another day. > > src/java.base/share/classes/java/util/concurrent/BlockingDeque.java > The tables are made accessible. > In the second table, the "Insert"/"Remove"/"Examine" headings > are moved from embedded rows to a new left-most column > for consistency with other similar tables. > > src/java.base/share/classes/java/util/concurrent/BlockingQueue.java > The table is made accessible. > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java > The table is made accessible. > > src/java.base/share/classes/java/util/doc-files/coll-designfaq.html > The file is updated to HTML 5. > The name attributes, which each duplicated the id attribute on > the same enclosing element, are removed. > > src/java.base/share/classes/java/util/doc-files/coll-index.html > The file is trivially updated to HTML 5. > > src/java.base/share/classes/java/util/doc-files/coll-overview.html > The file is updated to HTML 5. > A style is added for the table declared in this file. > An alternative edit, to import and use the main javadoc stylesheet > was consider, but caused too many other visual issues. > Eventually, we should change all doc-files/*.html files to use the > standard stylesheet(s). > > src/java.base/share/classes/java/util/doc-files/coll-reference.html > The file is updated to HTML 5. > > src/java.base/share/classes/java/util/regex/Pattern.java > This was the hardest file to update; in particular, the main > table listing the supported pattern constructs. Several solutions > were attempted, such as splitting the table up into smaller tables, > and moving the subheadings to a new column on the left. > As the saying goes, this solution is the worst, except for all > the others. It has the singular advantage of preserving the > existing visual appearance for most users, even if the > source code is somewhat dominated by the attributes to > make the table accessible, and to retain the same visual > presentation. This table, and some of tables in the Collections > API, highlight the shortcomings in javadoc's support for > custom styles when it is really, really needed. In principle, all > of the style attributes in the main table could be placed > much more succintly in some local stylesheet. > The other edits in this file are more obvious and straightforward. > > src/java.base/share/classes/java/util/spi/CalendarNameProvider.java > The tables are made accessible. > Again, custom stylesheets would simplify the source code. > > src/java.base/share/classes/java/lang/doc-files/*.gif (deleted) > See comments above for > src/java.base/share/classes/java/lang/String.java. > The files > src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc*.gif > appear to be orphaned relics of earlier versions of the API. > The images exist in releases at least as far back as 1.4, and look > like they might have been part of some mathematical representation of > a string hash function, although I've not been able to track down > where the images were used. From jonathan.gibbons at oracle.com Sat Aug 19 00:37:14 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 18 Aug 2017 17:37:14 -0700 Subject: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base In-Reply-To: References: <59978053.1040006@oracle.com> Message-ID: <5997883A.5060106@oracle.com> Hi Naoto, Thanks for checking out the changes. On 08/18/2017 05:19 PM, Naoto Sato wrote: > Hi Jon, > > Thank you for the cleanup! I looked at j.l.String, > j.t.DateTimeFormatter, and j.u.ResourceBundle and all look good. > > BTW, I just noticed that in ResourceBundle, line 1330 and so on, there > is a new column "Index" introduced. Is this intentional? Yes. It is intentional, although I'm open to better suggestions for the column header, or for other presentations. Conceptually, the information is a list of pairs. The text that precedes the info describes it as "the sequence of locale-format combinations to be used to call |control.newBundle|. ". HTML can't do a list of pairs as such, and so a table is used. But for accessibility, there must be some subset of each row which together uniquely define the row, and so can be used as row headers for the data cells in that row. Typically, the first element is the the unique element. But that is not so in this case ... worse: there is no such column whose cells define the row. Both columns contain duplicates. That means the only combination that uniquely defines the row is the entire row, which would mean the table would be all header cells and no data cells! I went with a solution to add a new column which identifies the position in the sequence. If you don't like the extra column, the alternative would be a bulleted or numbered list, with the two items of the pair separated by commas or some other punctuation, as in: * Locale("de", "DE"), java.class * Locale("de", "DE") , java.properties * Locale("de"), java.class * Locale("de"), java.properties * Locale(""), java.class * Locale(""), java.properties (In my mail client, that looks like a bulleted list; I don't know how well it will travel through the mail system.) -- Jon > > Naoto > > On 8/18/17 5:03 PM, Jonathan Gibbons wrote: >> Please review these fixes for various minor documentation issues in >> the java.base module. >> The changes are mostly in java.util and its subpackages, but there is >> some minor cleanup >> in previously updated packages as well. >> >> The primary focus is on addressing accessibility issues. In addition, >> some doc files have >> been converted to HTML5. As with all recent fixes like this, there >> should be no change to >> the underlying specifications. >> >> JBS:https://bugs.openjdk.java.net/browse/JDK-8186466 >> Webrev:http://cr.openjdk.java.net/~jjg/8186466/webrev.00/index.html >> API:http://cr.openjdk.java.net/~jjg/8186466/api.00/overview-summary.html >> >> -- Jon, the Javadoc Janitor >> >> >> Here are more detailed notes on the changes: >> >> src/java.base/share/classes/java/lang/String.java >> Some greek text that previously used discrete image files for >> the characters >> has been updated to use Unicode characters, specified with HTML >> entities. >> All related image files in the doc-files subdirectory have now >> been removed. >> >> src/java.base/share/classes/java/lang/doc-files/ValueBased.html >> The file is trivially updated to HTML 5. >> >> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html >> >> The file is updated to HTML 5. >> >> src/java.base/share/classes/java/time/format/DateTimeFormatter.java >> Two missing quote marks are added. >> The quotes are regrettably necessary: some of the examples >> contain spaces, >> and some cells have more than one example, >> >> src/java.base/share/classes/java/util/Deque.java >> The tables are made accessible. >> Where reasonable, the tables are converted to the de-facto standard >> "striped" style. >> >> src/java.base/share/classes/java/util/Queue.java >> A table is made accessible, and converted to the de-facto standard >> "striped" style. >> >> src/java.base/share/classes/java/util/ResourceBundle.java >> A preformatted list is converted to a semantic list. >> The tables are made accessible. >> Where reasonable, the tables are converted to the de-facto standard >> "striped" style. >> Line 3458 and following. Previously, the comment did not display >> correctly >> because javadoc incorrectly treated the dot in this string >> "'.'" >> as the end of the first sentence! The minimal fix would be to >> change that >> string to "{@code .}", but that would be stylistically inconsistent >> with the rest of the comment. There are too many occurrences of >> ... in the file as a whole to change them all at >> this time, >> so the compromise is just to replace the occurrences in this >> comment. >> Introducing more cleanup for existing uses of ... is a >> topic for another day. >> >> src/java.base/share/classes/java/util/concurrent/BlockingDeque.java >> The tables are made accessible. >> In the second table, the "Insert"/"Remove"/"Examine" headings >> are moved from embedded rows to a new left-most column >> for consistency with other similar tables. >> >> src/java.base/share/classes/java/util/concurrent/BlockingQueue.java >> The table is made accessible. >> >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java >> The table is made accessible. >> >> src/java.base/share/classes/java/util/doc-files/coll-designfaq.html >> The file is updated to HTML 5. >> The name attributes, which each duplicated the id attribute on >> the same enclosing element, are removed. >> >> src/java.base/share/classes/java/util/doc-files/coll-index.html >> The file is trivially updated to HTML 5. >> >> src/java.base/share/classes/java/util/doc-files/coll-overview.html >> The file is updated to HTML 5. >> A style is added for the table declared in this file. >> An alternative edit, to import and use the main javadoc stylesheet >> was consider, but caused too many other visual issues. >> Eventually, we should change all doc-files/*.html files to use the >> standard stylesheet(s). >> >> src/java.base/share/classes/java/util/doc-files/coll-reference.html >> The file is updated to HTML 5. >> >> src/java.base/share/classes/java/util/regex/Pattern.java >> This was the hardest file to update; in particular, the main >> table listing the supported pattern constructs. Several solutions >> were attempted, such as splitting the table up into smaller tables, >> and moving the subheadings to a new column on the left. >> As the saying goes, this solution is the worst, except for all >> the others. It has the singular advantage of preserving the >> existing visual appearance for most users, even if the >> source code is somewhat dominated by the attributes to >> make the table accessible, and to retain the same visual >> presentation. This table, and some of tables in the Collections >> API, highlight the shortcomings in javadoc's support for >> custom styles when it is really, really needed. In principle, all >> of the style attributes in the main table could be placed >> much more succintly in some local stylesheet. >> The other edits in this file are more obvious and straightforward. >> >> src/java.base/share/classes/java/util/spi/CalendarNameProvider.java >> The tables are made accessible. >> Again, custom stylesheets would simplify the source code. >> >> src/java.base/share/classes/java/lang/doc-files/*.gif (deleted) >> See comments above for >> src/java.base/share/classes/java/lang/String.java. >> The files >> src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc*.gif >> appear to be orphaned relics of earlier versions of the API. >> The images exist in releases at least as far back as 1.4, and look >> like they might have been part of some mathematical >> representation of >> a string hash function, although I've not been able to track down >> where the images were used. From martinrb at google.com Sat Aug 19 01:35:34 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Aug 2017 18:35:34 -0700 Subject: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base In-Reply-To: <59978053.1040006@oracle.com> References: <59978053.1040006@oracle.com> Message-ID: Thanks as usual for the modern html lessons. Looks good. Things I wonder about: - I expected to find scope= attributes in BlockingDeque.java tables. TIL about colgroup and rowgroup. (or does headers=... make that redundant?) - I see "font-style: italic" but that seems rather low-level and I expected something higher level. - I was surprised by 178 * {@link #peek() peek()} 179 * {@link #peekFirst() peekFirst()} because these two cells are "parallel" and so I expected them to have similar definitions. I can see they are "related" and the headers= makes that clear, but it still feels slightly wrong to make one of them a and the other a . From jonathan.gibbons at oracle.com Sat Aug 19 16:10:04 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 19 Aug 2017 09:10:04 -0700 Subject: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base In-Reply-To: References: <59978053.1040006@oracle.com> Message-ID: <8aea3745-9f2a-cca5-524b-14eeacb027e7@oracle.com> On 8/18/17 6:35 PM, Martin Buchholz wrote: > Thanks as usual for the modern html lessons. Looks good. > > Things I wonder about: > - I expected to find scope= attributes in BlockingDeque.java tables. > TIL about colgroup and rowgroup. (or does headers=... make that > redundant?) > - I see "font-style: italic" but that seems rather low-level and I > expected something higher level. > - I was surprised by > > 178 * {@link > #peek() peek()}179 * {@link > #peekFirst() peekFirst()} > > because these two cells are "parallel" and so I expected them to have > similar definitions. I can see they are "related" and the headers= > makes that clear, but it still feels slightly wrong to make one of > them a and the other a . Hi Martin, We're dealing with the intersection of rules and standards here. I personally agree with your queasiness about the distinction between th/td for "similar" cells but ... The general intent is that every data cell (td) in a table has to identify the header cells (th) that provide details about the row and column in which that data cell appears. This implies that every column has header cells that describe the column and that every row has header cells that define the row. There's also an implication of uniqueness. The header cells for each row/column in the table must be unique. There are two alternative ways to associate data cells with header cells. 1. The "easiest" way, for most tables, is to put scope={row,col} etc on the header cells. 2. The more flexible way, for complex tables, is to put id= on header cells and headers="list-of-ids" on data cells. In HTML 4, the rules were more lax about the distinction between header cells and data cells. In HTML 5, the rules are more strict. In HTML, you can only put scope=row|col on a header (th) cell, and the headers attribute on a data cell (td) can only refer to ids on header cells (th). This is the reason that so many tables throughout these changes have had data cells converted to header cells, which in turn leads to using styles to get/retain the desired visual presentation. Now for BlockingDequeue, as here: http://cr.openjdk.java.net/~jjg/8186466/api.00/java/util/concurrent/BlockingDeque.html It's really two tables in one: an upper table, for "First Element (Head)" and a lower table, for "Last Element (Tail)". It's not a candidate for using the scope attribute because of the split nature of the table. With reference to a similarly structured table elsewhere in the API, I was advised by an expert in Oracle's Accessibility Office that some screen readers would read all the column headers for a cell, and not just those that might visually seem to be applicable. So, with the simple solution ruled out, there were 3 possibilities for this table. 1. Split it into two tables. That might work OK for this table, because of the similar content, but the general problem of using distinct tables is that to have the tables use the same widths, you generally have to fix the widths, as compared to letting the tables be sized automatically. If you don't specify widths, the tables will generally end up with different geometries leading to unaligned columns and/or a ragged right edge. 2. Move the subheaders (the First Element and Last Element cells) to a new column on the left, with appropriate rowspan attributes, and remove the second row of the italic headings. Then, the table becomes simple enough to use scope=row|col, at the cost of making the table wider. That would probably work in this case, but it would conflict with the pattern of Insert/Remove/Examine cells in the first column, as in other tables in related classes. 3. Use the headers attribute instead of the scope attribute. Although it leads to more complex markup, it has the advantage of preserving the authors' original layout. As for your comment about using style="font-weight:italic"... You say it seems low level and you expected something higher level. In this case, the higher level you are looking for is that the enclosing HTML tag was changed from to . But "unfortunately", the default style for a is bold text, and so I changed it to italic using a style attribute, to preserve the original presentation. It would be wrong to use (See https://www.w3.org/International/questions/qa-b-and-i-tags ) and somewhat wrong to use because that would indicate that these headings are to be emphasized more than other headings. If the entire page was a standalone HTML document, this would be a classic use of a table-specific style, setting an id on the table node, and then providing out-of-line style info in either a