Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

> On Nov 24, 2015, at 2:20 PM, Daniel D. Daugherty > wrote: > > You use both 'this.anchor' and 'anchor'. Seems inconsistent. Oh yeah. I took out “this.” from it. diff --git a/src/java.base/share/classes/java/lang/StackStreamFactory.java

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

On 11/24/15 1:52 PM, Mandy Chung wrote: The value of anchor is an address and it’s an unsigned value. The check should be fixed to handle unsigned value. diff --git a/src/java.base/share/classes/java/lang/StackStreamFactory.java b/src/java.base/share/classes/java/lang/StackStreamFactory.java

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

The failed tests now passed with fast debug and product build (manually verified on solaris x64 and sparcv9 machines). JPRT job to run all core tests with fast debug and product build is in progress. Mandy > On Nov 24, 2015, at 12:52 PM, Mandy Chung wrote: > > The

Re: RFR: jsr166 jdk9 integration wave 2

On Tue, Nov 24, 2015 at 2:30 PM, Peter Levart wrote: > > What do you think of exception cloning? > > Making copies of java objects has historically been troublesome (e.g. Cloneable). I have made clones of objects often in tests via deserialization + reserialization, but

Re: RFR: jsr166 jdk9 integration wave 2

On 11/24/2015 06:38 PM, Martin Buchholz wrote: Peter: Thanks. I finally got around to thinking about this. Your argument against mutating the source Future is a good one. Even though the extra information will prove useful, you've convinced me that changing the past in this way is going

Re: RFR: 8143165 Add Statement.isSimpleIdentifier and update enquoteLiteral

Looks good, Lance. Have a great holiday when all these improvements are done :-) Best, Joe On 11/24/2015 11:48 AM, Lance Andersen wrote: Hi, Please provide a review for http://cr.openjdk.java.net/~lancea/8143165/webrev.00/. This adds Statement.isSimpleIdentifier, adds a throws

Re: RFR: 8143165 Add Statement.isSimpleIdentifier and update enquoteLiteral

+1 On 11/24/2015 5:18 PM, Lance Andersen wrote: Hi Roger Thank you for the feedback On Nov 24, 2015, at 4:11 PM, Roger Riggs > wrote: Hi Lance, Statement.java: - "contains a {@code null} character or double quote, and is not a

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Paul, Thanks for the review! Updated webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.01/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.01/ More reviews, please :) Comments below: On 11/24/2015 05:16 PM, Paul Sandoz wrote: >> On 19 Nov 2015, at 21:58, Aleksey

Re: RFR: 8143165 Add Statement.isSimpleIdentifier and update enquoteLiteral

Hi Roger Thank you for the feedback On Nov 24, 2015, at 4:11 PM, Roger Riggs wrote: > Hi Lance, > > Statement.java: > - "contains a {@code null} character or double quote, and is not a simple SQL > identifier." > > The "," is not needed and changes the semantics if it

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On Nov 24, 2015, at 3:27 PM, Stuart Marks wrote: > > But in the hypothetical value-typed future, we might want to return value > types from at least some of the factory methods. Value types have no notion > of identity, so we don't want to make any statements that lead

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 09:08 PM, Ulf wrote: Hi, Am 24.11.2015 um 18:27 schrieb Peter Levart: On 11/24/2015 06:22 PM, Peter Levart wrote: .. for addressing DigitOnes and DigitTens it is ok and might be faster, as you say. If DigitOnes and DigitTens are extended for 28 ignored zero slots, it may

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 07:50 PM, Ulf wrote: > Am 24.11.2015 um 12:07 schrieb Aleksey Shipilev: >> Thanks for reviews, Ivan, John, Sherman and Paul! >> >> I am pushing this change now. > > I know, I'm late, but have you ever tried? : No, but you can try it yourself. OpenJDK workspace has tests covering

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

Looks good. Thanks, Serguei On 11/24/15 14:37, Mandy Chung wrote: On Nov 24, 2015, at 2:20 PM, Daniel D. Daugherty wrote: You use both 'this.anchor' and 'anchor'. Seems inconsistent. Oh yeah. I took out “this.” from it. diff --git

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

On 25/11/2015 10:06 AM, Mandy Chung wrote: On Nov 24, 2015, at 3:45 PM, Peter Levart wrote: On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: Hi, while working on an issue to clean up a code in java.base module using reflection to access RuntimeMXBean (from

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

FWIW. The entire webrev with this patch: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.05/ Mandy > On Nov 24, 2015, at 12:54 PM, Mandy Chung wrote: > > The failed tests now passed with fast debug and product build (manually > verified on solaris x64 and

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 8:55 AM, Peter Levart wrote: Hi Stuart, Since those factory methods construct general purpose immutable collections, I miss methods that act as copy constructors (general purpose collection implementations should have them, says recommendation): public static List

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

Hi, The ProcessHandle.current().info().arguments() has the operating system's view of the command and arguments. Which may differ from what is passed to main[] args. Perhaps for current() it should be special cased to exactly and always match main(args) but that's a different question. If

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 8:06 AM, Paul Benedict wrote: *) List.of() says it returns "the newly created list" but it actually returns the same empty list regardless. I don't think you want to imply a new list is actually constructed for each call. *) Map.of() same comment as above *) Set.of() same comment

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

> On Nov 24, 2015, at 6:24 PM, David Holmes wrote: > > On 25/11/2015 10:06 AM, Mandy Chung wrote: >> >>> On Nov 24, 2015, at 3:45 PM, Peter Levart wrote: >>> >>> >>> >>> On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: Hi,

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

> On Nov 24, 2015, at 6:28 PM, David Holmes wrote: > > Hi Mandy, > > Seems okay. > > I presume when you say the anchor is unsigned, you mean it represents an > external unsigned value? So -1 is the only sentinel value being used? Anchor is an internal unsigned

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 7:03 AM, Remi Forax wrote: The other way to detect collision instead of checking the size if to use the return value of put, it should be null if it's a new key, but the code is maybe less readable. Yes. This is just a "skeleton" implementation, so I'm not terribly interested in

Re: 8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

Hi Mandy, Seems okay. I presume when you say the anchor is unsigned, you mean it represents an external unsigned value? So -1 is the only sentinel value being used? Thanks, David On 25/11/2015 8:37 AM, Mandy Chung wrote: On Nov 24, 2015, at 2:20 PM, Daniel D. Daugherty

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On Nov 23, 2015, at 10:26 PM, Stuart Marks wrote: > > Please review these API and implementation changes that comprise the first > integration of JEP 269. I intend to push this under the "initial API and > skeleton implementation" subtask, JDK-8139232. Please

RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting

http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ > 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg Hi, Could you please review the webrev[0] for JEP 279[1]? The scope of the JEP is an implementation of a library which uses jtreg timeout handler and observer extension points to

8143911: java/lang/StackWalker tests fail on Solaris with IllegalStateException

The value of anchor is an address and it’s an unsigned value. The check should be fixed to handle unsigned value. diff --git a/src/java.base/share/classes/java/lang/StackStreamFactory.java b/src/java.base/share/classes/java/lang/StackStreamFactory.java ---

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

> On Nov 24, 2015, at 3:45 PM, Peter Levart wrote: > > > > On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: >> Hi, >> >> while working on an issue to clean up a code in java.base module using >> reflection to access RuntimeMXBean (from java.management module) in

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 3:17 AM, Chris Hegarty wrote: This is looking very good, and simple. Nice. Great, thanks. Sorry if this has come up already, but is the "@return the newly created xxx” too restrictive? Will it require the implementation to return a NEW instance of xxx for each invocation, even

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 3:30 AM, Peter Levart wrote: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151123/overview-summary.html Why do EnumSet.of(...) javadocs get this additional line: Specified by: of in interface Set> Since static interface methods are not inheritable, their

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mark, Memory is an increasingly critical resource, we should be giving developers more tools to manage their use of memory. The Weak and Soft reference forms of the cleaner make it easier to be aware of and respond to increased memory pressure. The management of memory is not

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: Hi, while working on an issue to clean up a code in java.base module using reflection to access RuntimeMXBean (from java.management module) in order to get hold of the VM arguments (yes, this won't work with module boundaries in place) it

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

Hi Steve, The change looks fine. thanks, Sherman On 11/18/2015 01:27 PM, Steve Drach wrote: Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

RFR: 8143165 Add Statement.isSimpleIdentifier and update enquoteLiteral

Hi, Please provide a review for http://cr.openjdk.java.net/~lancea/8143165/webrev.00/. This adds Statement.isSimpleIdentifier, adds a throws SQLException to Statement.enquoteLiteral and includes a few additional tests Best Lance Lance Andersen| Principal Member of Technical Staff |

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 05:20 PM, Paul Sandoz wrote: >> On 24 Nov 2015, at 15:17, Aleksey Shipilev >> wrote: >> Oh no, I don't. Pre-integration JPRT runs exposed an opaque dependency >> on Integer.sizeTable field from C2 OptimizeStringConcat. I added the >> field declaration

Re: RFR: 8143165 Add Statement.isSimpleIdentifier and update enquoteLiteral

Hi Lance, Statement.java: - "contains a {@code null} character or double quote, and is not a simple SQL identifier." The "," is not needed and changes the semantics if it is present. +1518: - "The string is between 1 and 128 characters in length" You might want to add the word inclusive,

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Hi, Am 24.11.2015 um 18:27 schrieb Peter Levart: On 11/24/2015 06:22 PM, Peter Levart wrote: .. for addressing DigitOnes and DigitTens it is ok and might be faster, as you say. If DigitOnes and DigitTens are extended for 28 ignored zero slots, it may save the upper bound check too.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015/11/24 5:42 -0800, peter.lev...@gmail.com: > On 11/24/2015 02:12 PM, Peter Levart wrote: >> What is actually the reason for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8024421 >> >> to have the resolution: "Won't Fix"? > > ...I see there are further developments on

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 06:22 PM, Peter Levart wrote: On 11/24/2015 06:11 PM, Peter Levart wrote: byte r = (byte)((q * 100 - i) & 0x7F); // byte allows the compiler to use byte wide addressing opcodes // which have smaller footprint and are potentially faster

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 06:11 PM, Peter Levart wrote: byte r = (byte)((q * 100 - i) & 0x7F); // byte allows the compiler to use byte wide addressing opcodes // which have smaller footprint and are potentially faster // .. & 0x7F may additionally save

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 05:50 PM, Ulf wrote: Hi, Am 24.11.2015 um 12:07 schrieb Aleksey Shipilev: Thanks for reviews, Ivan, John, Sherman and Paul! I am pushing this change now. I know, I'm late, but have you ever tried? : static void getChars(int i, int index, byte[] buf) { // int q,

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Hi, Am 24.11.2015 um 12:07 schrieb Aleksey Shipilev: Thanks for reviews, Ivan, John, Sherman and Paul! I am pushing this change now. I know, I'm late, but have you ever tried? : static void getChars(int i, int index, byte[] buf) { // int q, r;// superfluous //

Re: RFR: jsr166 jdk9 integration wave 2

Peter: Thanks. I finally got around to thinking about this. Your argument against mutating the source Future is a good one. Even though the extra information will prove useful, you've convinced me that changing the past in this way is going to lead to trouble (like time travel always does in

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 11/23/15 10:44 AM, Frederic Parain wrote: Karen, Thank you for your review, my answers are in-lined below. New Webrevs (including some fixes suggested by Paul Sandoz): http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ src/cpu/sparc/vm/frame_sparc.cpp (old) L635: if

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mark, Memory is an increasingly critical resource, we should be giving developers more tools to manage their use of memory. The Weak and Soft reference forms of the cleaner make it easier to be aware of and respond to increased memory pressure. The management of memory is not

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

2015/11/24 9:05 -0800, roger.ri...@oracle.com: > The arguments may contain sensitive information so the method will need > a SecurityManager > check and appropriate permission. Yes, definitely. > The method name should be more > appropriate; the JRE is not

Re: Reference.reachabilityFence

> > The choice of reachabilityFence was in part motivated by hearing > about mistakes in using C# keepAlive where people would place keepAlive > before uses of fields, rather than after them. A more accurate name > should reduce this error in Java. I don't see how reachabilityFence would help

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On Nov 24, 2015, at 8:46 AM, Karen Kinnear wrote: > Doug, > > I have been thinking about this more from the perspective of the original > problem > we set out to solve I apologize if this has already been considered -- but for a lot well designed systems,

Re: Reference.reachabilityFence

> On 24 Nov 2015, at 18:08, mark.reinh...@oracle.com wrote: > > 2015/11/24 1:32 -0800, paul.san...@oracle.com: >>> On 24 Nov 2015, at 01:31, mark.reinh...@oracle.com wrote: >>> This seems eminently reasonable, but why does it belong in the >>> java.lang.ref.Reference class? It has nothing

Re: RFR: 8085984 Add JDBC Sharding API

Some comments: General *) Shouldn't the javadocs be put mentions of null in {@code null} tags? *) Many methods are documented to throw SQLFeatureNotSupportedException when sharding isn't supported, but the error message actually says "XYZ not implemented". Well I think that places an immediate

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

On 11/24/15 4:21 AM, Aleksey Shipilev wrote: On 11/24/2015 09:26 AM, Stuart Marks wrote: Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/ * It is mildly puzzling why the HashMap initial capacity is different from the number of elements you are about to push

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, Since those factory methods construct general purpose immutable collections, I miss methods that act as copy constructors (general purpose collection implementations should have them, says recommendation): public static List copyOf(Collection collection); public static Set

Re: Reference.reachabilityFence

2015/11/24 1:32 -0800, paul.san...@oracle.com: >> On 24 Nov 2015, at 01:31, mark.reinh...@oracle.com wrote: >> This seems eminently reasonable, but why does it belong in the >> java.lang.ref.Reference class? It has nothing (directly) to do >> with reference objects. >> >> java.lang.Runtime,

[preview] Adding java.lang.Runtime.getVMArguments() method

Hi, while working on an issue to clean up a code in java.base module using reflection to access RuntimeMXBean (from java.management module) in order to get hold of the VM arguments (yes, this won't work with module boundaries in place) it was pointed out that this functionality should be

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Am 24.11.2015 um 17:50 schrieb Ulf: ... and better use char/short[] to save footprint and the compiler calculating the table offset with charPos<<1. Note additionally: In this case the raw table length will be = 200, so compiler can use cheap byte-wide addressing mode opcodes. -Ulf

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

Hi Jaroslav, The arguments may contain sensitive information so the method will need a SecurityManager check and appropriate permission. The method name should be more appropriate; the JRE is not just the VM. Perhaps commandArguments() or something that related to the process command

Re: Reference.reachabilityFence

On 11/24/2015 09:09 AM, Andrew Haley wrote: Bikeshedding, On 11/24/2015 01:07 PM, Vitaly Davidovich wrote: How about keepAlive? Reference.keepAlive(Object) reads better, IMO. It does indeed. Imperative names for methods almost always read better, IMO. And although we probably don't don't

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Hello Please, review modified webrev. I have added methods getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; I removed previously added

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Doug, I have been thinking about this more from the perspective of the original problem we set out to solve, which was identified in the concurrent hash map usage, at the time in the class loading logic. While the class loading logic has changed, I think we have enough experience with this

RE: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Can the Javadoc for of() (no args) be enhanced to spell out the cost/garbage semantics? Collections.emptyList() does a great job of that: * @implNote * Implementations of this method need not create a separate List * object for each call. Using this method is likely to have

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Consider: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int)

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Aleksey, in http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.01/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java.html there are a number of internal strategy classes that will set up a number of MethodHandles in bulk once initialized: 1561 private static

Re: Reference.reachabilityFence

> On 24 Nov 2015, at 01:31, mark.reinh...@oracle.com wrote: > > 2015/11/23 8:38 -0800, paul.san...@oracle.com: >> Please review the addition of Reference.reachabilityFence contributed >> by Aleksey, Doug and myself: >> >> >>

Re: Reference.reachabilityFence

Bikeshedding, On 11/24/2015 01:07 PM, Vitaly Davidovich wrote: > How about keepAlive? Reference.keepAlive(Object) reads better, IMO. It does indeed. Imperative names for methods almost always read better, IMO. And although we probably don't don't much care about C#, it too uses the name

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

> On 24 Nov 2015, at 15:17, Aleksey Shipilev > wrote: > > On 11/24/2015 02:07 PM, Aleksey Shipilev wrote: >> On 11/24/2015 03:35 AM, John Rose wrote: >>> On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev >>>

Re: Reference.reachabilityFence

On 24/11/2015 7:32 PM, Paul Sandoz wrote: On 24 Nov 2015, at 01:31, mark.reinh...@oracle.com wrote: 2015/11/23 8:38 -0800, paul.san...@oracle.com: Please review the addition of Reference.reachabilityFence contributed by Aleksey, Doug and myself:

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, On 11/24/2015 09:26 AM, Stuart Marks wrote: > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/ * It is mildly puzzling why the HashMap initial capacity is different from the number of elements you are about to push -- need to spell out that we are

Re: Reference.reachabilityFence

On 24/11/2015 11:00 PM, Vitaly Davidovich wrote: One can look at reachabilityFence in same light as requesting gc or finalization, both of which live in Runtime. I don't quite see how they are "in the same light". Both of those are requests for specific system services to be executed (and

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, The other way to detect collision instead of checking the size if to use the return value of put, it should be null if it's a new key, but the code is maybe less readable. There are several instance of @SafeVarargs @SuppressWarnings("varargs") if you use @SafeVarargs you should

Re: RFR: 8140344: add support for 3 digit update release numbers

You would think, but this fix isn't in jdk_util.c in 6. The test isn't in 6 either though. -Rob On 24/11/15 04:39, David Holmes wrote: On 24/11/2015 12:24 AM, Rob McKenna wrote: Thanks David, I'll mark this 9-na. (bcc'ing verona-dev) Something similar was fixed in 7

Re: Reference.reachabilityFence

One can look at reachabilityFence in same light as requesting gc or finalization, both of which live in Runtime. sent from my phone On Nov 24, 2015 7:54 AM, "David Holmes" wrote: > On 24/11/2015 7:32 PM, Paul Sandoz wrote: > >> >> On 24 Nov 2015, at 01:31,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, On 11/23/2015 11:32 PM, mark.reinh...@oracle.com wrote: ( Finally getting back to this, after too many weeks of travel ... ) 2015/10/20 11:28 -0700, roger.ri...@oracle.com: Sorry for the silence, JavaOne preparations and the availability of folks who wanted to review have stretched things

Re: Reference.reachabilityFence

If we're going to bikeshed placement of the method, I'd like to propose a different name for the method. The "fence" part of the name doesn't make much sense and is a common term used in memory ordering discussions. How about keepAlive? Reference.keepAlive(Object) reads better, IMO. sent from

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 03:35 AM, John Rose wrote: > On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev > > wrote: >> >> Okay, here it is (only tests changed): >> http://cr.openjdk.java.net/~shade/8136500/webrev.06/ >>

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Stuart, This is looking very good, and simple. Nice. Sorry if this has come up already, but is the "@return the newly created xxx” too restrictive? Will it require the implementation to return a NEW instance of xxx for each invocation, even of() ? -Chris. On 24 Nov 2015, at 06:26, Stuart Marks

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, API spec (basically List, Map, and Set): http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151123/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151123/overview-summary.html Why do EnumSet.of(...) javadocs get this additional line:

Re: Reference.reachabilityFence

It's requesting the runtime to extend the lifetime of an object that would otherwise be considered dead. It's true that no heavy lifting happens behind the scenes, unlike gc or finalization, but that's not the important part in my opinion. On Tue, Nov 24, 2015 at 8:14 AM, David Holmes

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/24/2015 02:12 PM, Peter Levart wrote: What is actually the reason for the following issue: https://bugs.openjdk.java.net/browse/JDK-8024421 to have the resolution: "Won't Fix"? ...I see there are further developments on this front: https://bugs.openjdk.java.net/browse/JDK-8071507

Re: RFR: 8085984 Add JDBC Sharding API

Quick clarification on my last point: createShardingKeyBuilder() is not guaranteed to be implemented ... even with sharding supported. This method is documented to be optional; it does not contain the usual "if sharding is not supported" warning but "if the driver does not support this method",

Re: Reference.reachabilityFence

Yes, I "stole" that name from .NET but it's a great, short and very accurate name. .NET goes a bit further by having a (static) GC class to house this method (amongst other GC related ones), but for java Reference (or whatever else) is good enough. On Tue, Nov 24, 2015 at 9:09 AM, Andrew Haley

Re: Code (Pre-)Review for JEP 280: Indify String Concat

> On 19 Nov 2015, at 21:58, Aleksey Shipilev > wrote: > > Hi, > > I would like to have a code pre-review for Indify String Concat changes. > For the reference, the rationale, design constraints, etc. are outlined > in the JEP itself: >

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 02:07 PM, Aleksey Shipilev wrote: > On 11/24/2015 03:35 AM, John Rose wrote: >> On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev >> > wrote: >>> >>> Okay, here it is (only tests changed): >>>

RFR(S): 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8143798 Webrev: http://cr.openjdk.java.net/~mhaupt/8143798/webrev.00/ The issue is an array iteration boundary bug in the JEP 274 implementation. Thanks, Michael -- Dr. Michael Haupt

Re: RFR(S): 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack

Looks good. Best regards, Vladimir Ivanov On 11/24/15 7:02 PM, Michael Haupt wrote: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8143798 Webrev: http://cr.openjdk.java.net/~mhaupt/8143798/webrev.00/ The issue is an array iteration boundary bug in the JEP

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

My comments: *) List.of() says it returns "the newly created list" but it actually returns the same empty list regardless. I don't think you want to imply a new list is actually constructed for each call. *) Map.of() same comment as above *) Set.of() same comment as above *)