Re: ClassFileTransformer does not apply to anonymous classes

Hi John, thank you for your answer. As I said before, I do understand the concept behind resolving lambda expressions at runtime to not represent "real classes". I do however still disagree with your assertion. On the opposite, I argue that the fact that nobody can expect a certain form of impleme

Re: API review of VarHandles

> On 26 Jan 2016, at 22:46, Brian Goetz wrote: > > I think that expectation is just out of date (if not outright mistaken.) > Yes, j.l.i was originally called "java.dyn", but prior to shipping *7* we > renamed it to j.l.i precisely because it had turned into a general > customizable linkage

Re: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

>From the name of the test and looking at the code, running in English only is fine. Stephen On 27 January 2016 at 05:53, Masayoshi Okutsu wrote: > Looks OK to me. But I'd like some java.time people to review this change > to see if the intention of this test is to run only in English. > > Thank

RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

Hello, Earlier there was a discussion on this mail alias about the spin loop hint proposal [1]. Based on the feedback from that discussion some changes were incorporated and the JEP has been filed [2]. There seems to be a consensus on the API side. The JEP is now in a draft state and I hope t

Re: RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

Hi Ivan, > Please review the upcoming API changes: > http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ I think the semicolon at the end of the line 887 is not needed, e.g: 887 public static void onSpinWait() {}; should be 887 public static void onSpinWait() {} Best regards, Andrej G

RFR (L) JEP 280: Indify String Concatenation (integration)

Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks are clean. Code changes are happening simultaneously in four

Re: RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

Indeed, thanks! New webrev http://cr.openjdk.java.net/~ikrylov/8147844.jdk.01/ On 27/01/2016 16:48, Andrej Golovnin wrote: Hi Ivan, Please review the upcoming API changes: http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ I think the semicolon at the end of the line 887 is not needed, e.g:

Re: RFR:8146218: Producing streams in java.time?

Hi Stephen, On 1/26/2016 8:57 AM, Stephen Colebourne wrote: While there is no blocking reason why the concept could not be pulled up to ChronoLocalDate, the method signatures would differ. LocalDate::datesUntil(LocalDate) LocalDate::datesUntil(LocalDate, Period) ChronoLocalDate::datesUntil(Chr

Re: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

+1 On 1/27/2016 5:26 AM, Stephen Colebourne wrote: From the name of the test and looking at the code, running in English only is fine. Stephen On 27 January 2016 at 05:53, Masayoshi Okutsu wrote: Looks OK to me. But I'd like some java.time people to review this change to see if the intentio

Re: RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

On 27/01/2016 14:10, Ivan Krylov wrote: Indeed, thanks! New webrev http://cr.openjdk.java.net/~ikrylov/8147844.jdk.01/ Can you add @since 9 too? -Alan.

Re: RFR:8146218: Producing streams in java.time?

On 27 January 2016 at 15:13, Roger Riggs wrote: > On 1/26/2016 8:57 AM, Stephen Colebourne wrote: >> Thus, adding the ChronoLocalDate methods later will make two additional >> methods available on LocalDate (as they will not override). > > Since all the calendars are built on the same 24hour days

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

I think it quite reasonable to push everything to jdk9/dev. Paul. > On 27 Jan 2016, at 14:55, Aleksey Shipilev > wrote: > > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi all, Thanks for the suggestions. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8141452/webrev.01/ Regards, Nadeesh TV On 1/25/2016 10:24 PM, Roger Riggs wrote: Hi Stephen, Nadeesh, TimeUnit.toChronoUnit is a static method. It seems redundant to have to pass an instance

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

JDK changes looks good! Best regards, Vladimir Ivanov On 1/27/16 4:55 PM, Aleksey Shipilev wrote: Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, th

Re: RFR:8146218: Producing streams in java.time?

Hi Stephen, Tagir, On 1/27/2016 10:30 AM, Stephen Colebourne wrote: On 27 January 2016 at 15:13, Roger Riggs wrote: On 1/26/2016 8:57 AM, Stephen Colebourne wrote: Thus, adding the ChronoLocalDate methods later will make two additional methods available on LocalDate (as they will not override

Re: RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

Updated to http://cr.openjdk.java.net/~ikrylov/8147844.jdk.02/ The sample JavaDoc has been updated too: http://ivankrylov.github.io/onspinwait/api/java/lang/Runtime.html#onSpinWait-- Alan, Thank you. On 27/01/2016 18:20, Alan Bateman wrote: On 27/01/2016 14:10, Ivan Krylov wrote: Indeed, t

JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

Hello! Small but important change for review: updating the JNI_VERSION and in so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y (see code/bug for details). Bug: https://bugs.openjdk.java.net/browse/JDK-8145098 hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> I'm still wondering about the phrase "root entry" as it continues to give the > impression (to me anyway) that it's a resource in the root directory. I think > "root" works in the JEP because it deals with simple resources like A.class > and B.class that are in the root directory but it's con

RFR: 8147607: Remove test library dependency on sun.security.tools.jarsigner.Main

Please review a small change to the zipfs test library. Issue: https://bugs.openjdk.java.net/browse/JDK-8147607 Webrev: http://cr.openjdk.java.net/~sdrach/8147607/webrev This change uses the p

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Just an FYI: I'm working on moving all of this to the Hotspot Copy class and bridging to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The implementation is working, and the preliminary performance numbers beat the pants off of any of the suggested Bits.c implementations (yay!)

Re: RFR:8146218: Producing streams in java.time?

Hello! It should be noted that there's already a precedent in JDK where method returning stream is subclassed and returns the stream of more concrete objects. I'm speaking about ZipFile and JarFile: public class ZipFile { public Stream stream() {...} } public class JarFile extends ZipFile {

Re: RFR:8146218: Producing streams in java.time?

Hi Tagir, After the discussion, I agree. The only addition I would like to see in the tests to add or modify a test so that the it explicitly requires the Stream at compile time. None of the new tests check that the result type signatures are as expected. Thanks, Roger On 1/27/16 11:28 PM,

Re: RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()

HI Ivan, On 27/01/2016 11:31 PM, Ivan Krylov wrote: Hello, Earlier there was a discussion on this mail alias about the spin loop hint proposal [1]. Based on the feedback from that discussion some changes were incorporated and the JEP has been filed [2]. There seems to be a consensus on the API