Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, I strongly hope Paul and Cedric will be able to start the release process next week, if not we will have to do it the old way I think. what would help us a lot would be you testing the GROOVY_2_4_X branch with your build system to see if it really does solve your problem. Even if it is

Re: RFR: jsr166 jdk9 integration wave 13

On 12/15/2016 01:17 PM, Stefan Zobel wrote: I recently noticed that javac creates a synthetic class and a bridge constructor for SubmissionPublisher.ThreadPerTaskExecutor because its generated constructor is private. I don't know if it really matters but that could be avoided by declaring a

Re: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

Hi Hamlin, Yes, the logic would be clearer; and I would also remove the (now) redundant checking. Roger On 12/15/2016 9:42 PM, Hamlin Li wrote: Hi Roger, Daniel, Thank you for reviewing. On 2016/12/15 22:45, Roger Riggs wrote: Hi Hamlin, If this is supposed to fix the call from line

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Hi Abhijit, Please also fix the same error in DateTimeFormatter; line 300. I would use '24' as the example of the hour of day. It would emphasize that the range is 1-24. Roger On 12/16/2016 6:19 AM, Abhijit Roy wrote: Hi all, Please review the java doc fix for the below bug: Bug:

Re: RFR of JDK-8171298: ProblemList java/rmi/registry/readTest/readTest.sh due to JDK-7146543

Hi Hamlin, Looks fine. (Using a subtask for this kind of problem listing works well too; then it is clearly related to the original bug. And isn't an independent issue. Yes, task bugid can be used for commits). Thanks, Roger On 12/16/2016 12:04 AM, Hamlin Li wrote: Would you please

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Hi, Sorry, I meant DateTimeFormatterBuilder. Roger On 12/16/2016 9:28 AM, Roger Riggs wrote: Hi Abhijit, Please also fix the same error in DateTimeFormatter; line 300. I would use '24' as the example of the hour of day. It would emphasize that the range is 1-24. Roger On 12/16/2016 6:19

Re: Proposal: Add a type token class for representing generic types

> On Dec 16, 2016, at 8:18 AM, Gunnar Morling wrote: > > Hi, > > I'd like to suggest the addition of a type token class to the Java > class library, to be used for representing generic types such as > List. I don't have much clout on this list to throw around, but a huge

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Pushed to jdk9/dev. Should make b150. https://bugs.openjdk.java.net/browse/JDK-8171377 -Chris. > On 14 Dec 2016, at 11:58, Chris Hegarty wrote: > > Webrev updated in-place. > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > -Chris. > > On 13/12/16

Re: Duration isPositive missing?

Hi Steven, Yes, it does seem like an oversight. There are some other alternatives that might be considered. .toMillis() > 0// Might throw an exception for very large or small durations. I create an issue: 8171382 java.time.Duration missing isPositive method

Re: RFR: jsr166 jdk9 integration wave 13

Thanks, Stefan! The creation of these bridge classes seem like a misfeature/bug of javac. We should avoid them where possible. Every unnecessary class file makes every single java program a little slower to start up. We can discover such "bridge classes" heuristically by looking for "small"

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

Hi Joe, This looks fine to me. I’ve just a few picayune items: 1. FdLibm Line 649: I assume the weird “halF” (upper case F) is retained in order to match the original C code. 2. TEST.ROOT Line 30: The jtreg required version is reverted. 3. ExpTests Lines 65 and 69: The threshold values in

Duration isPositive missing?

Hi core-libs-dev, My coworker and I were just puzzling over the seemingly trivially missing java.time.Duration#isPositive There are already "isNegative" and "isZero" -- but for isPositive the best we came up with were awful things like !isZero() && !isNegative() !.negate().isNegative()

JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8148023 Patch: http://cr.openjdk.java.net/~bpb/8148023/webrev.00/index.html The method was not adhering to the specification [1] and was creating long file names which caused failures on all platforms. The

Re: Proposal: Add a type token class for representing generic types

Hi Gunnar, On 17/12/2016 2:18 AM, Gunnar Morling wrote: Hi, I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Sounds like something that falls within scope for the generic specialization work in Project

Re: RFR: jsr166 jdk9 integration wave 13

2016-12-16 20:58 GMT+01:00 Martin Buchholz : > Thanks, Stefan! > > The creation of these bridge classes seem like a misfeature/bug of javac. > We should avoid them where possible. Every unnecessary class file makes > every single java program a little slower to start up. We

Re: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac

On 16/12/16 03:43, Wang Weijun wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Thank you Max. Reviewed. -Chris.

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Jochen, thank you for the information! Is there any plan about a release? I also found no JIRA issue about this issue to link it against our JIRA: https://issues.apache.org/jira/browse/LUCENE-7596 The problem makes our build system unusable, so it would be very important to have a fix

Re: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

Hi Rob, Looks good to me too now. -- daniel On 16/12/16 03:21, Vyom Tewari wrote: Hi Rob, Code changes looks good to me. Thanks, Vyom On Thursday 15 December 2016 08:27 PM, Rob McKenna wrote: Gah, thanks Daniel. I originally worked this fix on 8u and neglected to remove synchronized

RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Hi all, Please review the java doc fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 Description: Incorrect documentation for DateTimeFormatter letter 'k' Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ I have just rectified and modified those

Re: RFR: jsr166 jdk9 integration wave 13

ThreadPerTaskExecutor() {} // prevents bridge class creation On Fri, Dec 16, 2016 at 12:21 PM, Stefan Zobel wrote: > > yes, I agree. It may be better to add a comment like in ArrayList.Itr: > > // prevent creating a synthetic constructor > > Otherwise someone

Re: RFR: jsr166 jdk9 integration wave 13

> On 16 Dec 2016, at 11:58, Martin Buchholz wrote: > > Thanks, Stefan! > > The creation of these bridge classes seem like a misfeature/bug of javac. It’s to work around the current access control rules enforced by the VM. The Java source world and the bytecode/VM world

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Chris, thanks, works perfectly. I compiled a JDK with this commit and Lucene's unmapping works. Thanks. https://github.com/apache/lucene-solr/compare/LUCENE-6989-v2 Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany

Proposal: Add a type token class for representing generic types

Hi, I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Actual class literals can only represent raw types. But often libraries have the need to apply some sort of configuration to specific generic types, link

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

Hi Brian, On 12/16/2016 10:43 AM, Brian Burkhalter wrote: Hi Joe, This looks fine to me. I’ve just a few picayune items: 1. FdLibm Line 649: I assume the weird “halF” (upper case F) is retained in order to match the original C code. Corrected. 2. TEST.ROOT Line 30: The jtreg required