Re: API review of VarHandles

Hi Paul, I found a typo (which was probably caused by unconscious influence from jigsaw ;-). Search for "Java Memory Module"... Regards, Peter On 01/21/2016 11:42 PM, Paul Sandoz wrote: Hi This is a request to review the VarHandles API. The code reviews and pushes will occur separately, an

Re: ClassFileTransformer does not apply to anonymous classes

On 21/01/16 22:14, Rafael Winterhalter wrote: > Hi Andrew, > if there is any update on the matter, I would of course love to hear about it. > Unfortunately, I never received an answer to my question, but maybe I > picked the wrong list. > Thank you for your support on this issue! I'm pretty sure t

RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

Gentle Reminder! Original Message Subject: [9u-dev] 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods Date: Wed, 20 Jan 2016 18:12:24 +0530 From: shilpi rastogi Organization: Oracle Corporation To: core-libs-dev@openjdk

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

> On 22 Jan 2016, at 01:39, Mandy Chung wrote: > > >> On Jan 21, 2016, at 3:49 PM, Steve Drach wrote: >> I suspected this is a bike shed candidate. I think Release._9 is nicer and it conveys the same information in a less cluttered way than Release.RELEASE_9. >>> Yes a bike

Fwd: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

Gentle Reminder! Original Message Subject: [9u-dev] 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods Date: Wed, 20 Jan 2016 18:12:30 +0530 From: shilpi rastogi Organization: Oracle Corporation To: core-libs-dev@openjdk.java.net

Re: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

Hi Shilpi, Can you also double check Lookup.unreflectSpecial, it’s documentation might require updating too. Separating the “or” statements with a comma would help readability in the JavaDoc (same applies to the the patch for findVirtual). Paul. > On 22 Jan 2016, at 10:22, shilpi rastogi wro

JEP 280 (Indify String Concat) integration

Hi, I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks come clean. In theory, we would like to integrate with some "optimal" concat strategy switched b

Re: JEP 280 (Indify String Concat) integration

Looks a fine approach to me. Getting code in earlier and tested, even initially under the less optimal strategy, is good in terms of exposure. Paul. > On 22 Jan 2016, at 10:31, Aleksey Shipilev > wrote: > > Hi, > > I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9:

Re: API review of VarHandles

On 22/01/16 00:01, Vitaly Davidovich wrote: > I think the get/setOpaque methods need a bit more explanation ("opaque" is > an odd naming choice, IMO). Specifically, it says the operations are done > in program order but have no effect on inter-thread ordering/visibility. > Is this spec verbiage fo

Re: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

Hi Shilpi, Similar to the previous patch, can you double check Lookup.unreflect. Not sure how far you wanna go in this case, but checking i think would be useful. 860 *or if the method is {@code private} method of interface s/method of interface/method

Re: RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

On 21/01/16 17:45, Mark Sheppard wrote: Thanks Sean i can revert the isClosed(), I put them in to make the access consistent I'd question if the synchronized isClosed() and setClosed(boolean) helper methods are needed at all. The volatile closed boolean variable should be enough to manage thi

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley wrote: > On 22/01/16 00:01, Vitaly Davidovich wrote: > > I think the get/setOpaque methods need a bit more explanation ("opaque" > is > > an odd naming choice, IMO). Specifically, it says the operations are > done > > in program order but have no effect

RFR 8147984: WindowsTerminal should support function keys

Hello, I'd like to enhance the WindowsTerminal in jdk.internal.le with function keys handling. The intent is so that jshell can bind actions for shortcuts including function keys. The patch for adding the function keys support is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ A

RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

Hi, this patch removes some arguably unnecessary Enum[0] constants from EnumMap, EnumSet, and an associated test. The one in EnumMap was unused, while the one in EnumSet was only used for serialization purposes. Doing this for performance seems questionable[1]. During testing I discovered

Re: Stream.findFirst for unordered source optimization

Hi Tagir, Thanks for looking at this. I would prefer if a boolean was passed into the task constructor e.g.: @Override public O evaluateParallel(PipelineHelper helper, Spliterator spliterator) { // This takes into account the upstream ops flags and the termi

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 01/22/2016 02:34 PM, Claes Redestad wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8148044 > Webrev: http://cr.openjdk.java.net/~redestad/8148044/webrev.01/ -1, sorry. I would actually suggest keeping the ZERO_ARRAY in Enum*, because enums often have small cardinality, and there dodgin

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 12:53, Alan Bateman wrote: On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionUID, which needs to be added. I assume this is not needed, it already has: @SuppressWarnings("serial") // No serialVersionUID due to

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionUID, which needs to be added. I assume this is not needed, it already has: @SuppressWarnings("serial") // No serialVersionUID due to usage of serial proxy pattern -Alan

Re: API review of VarHandles

On Thursday, January 21, 2016, Brian Goetz wrote: > > I am baffled as to how the original language syntax proposal of using some >> trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new >> bytecodes was considered unacceptable; looking at this API, I know that >> none of the aforem

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 12:56, Claes Redestad wrote: On 2016-01-22 12:53, Alan Bateman wrote: On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionUID, which needs to be added. I assume this is not needed, it already has: @SuppressWar

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 12:57, Aleksey Shipilev wrote: On 01/22/2016 02:34 PM, Claes Redestad wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8148044 Webrev: http://cr.openjdk.java.net/~redestad/8148044/webrev.01/ -1, sorry. I would actually suggest keeping the ZERO_ARRAY in Enum*, because enums

Re: Ephemerons

Hi Mandy, Thanks for noticing this post. I think Ephemerons would be a nice tool that would solve some "memory leak" problems people have when using data structures with weak references. On 01/20/2016 05:20 PM, Mandy Chung wrote: Hi Peter, This is interesting and useful for cases when key/v

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 01/22/2016 03:19 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8148044/webrev.02/ This one's good. -Aleksey

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 13:25, Aleksey Shipilev wrote: On 01/22/2016 03:19 PM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8148044/webrev.02/ This one's good. -Aleksey Thanks! /Claes

Re: API review of VarHandles

On 01/22/2016 11:15 AM, Vitaly Davidovich wrote: > I'm guessing opaque is compiler only fence because a method that a > compiler doesn't inline (as an example) is considered "opaque" to > the compiler and serves like a fence. Perhaps that's how opaque > ended up here. At any rate, I think it's a

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley wrote: > On 01/22/2016 11:15 AM, Vitaly Davidovich wrote: > > > I'm guessing opaque is compiler only fence because a method that a > > compiler doesn't inline (as an example) is considered "opaque" to > > the compiler and serves like a fence. Perhaps tha

Re: API review of VarHandles

On 01/22/2016 03:08 PM, Vitaly Davidovich wrote: > The VarHandle API isn't ergonomic like Unsafe; this being for power users > is irrelevant to the ergonomics of the API. Instead, it's fairly verbose > with setup ceremony. Now, I personally don't mind that too much and more > interested in the fe

Re: API review of VarHandles

On 01/21/2016 07:32 PM, Brian Goetz wrote: I am baffled as to how the original language syntax proposal of using some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new bytecodes was considered unacceptable; looking at this API, I know that none of the aforementioned metrics w

Re: Ephemerons

Hi Peter, On 22/01/16 12:10, Peter Levart wrote: > Thanks for noticing this post. ... Hey, I noticed it too! I think it's a good proposal very clearly explained and well thought through (as so often when you post). I have not commented because I don't really have a good use case against which to

Re: JEP 280 (Indify String Concat) integration

Yes, it's time to integrate that code, thumb up ! BTW, once the second part will be done, varargs calls should be the next target, see https://bugs.openjdk.java.net/browse/JDK-8013269. Rémi - Mail original - > De: "Paul Sandoz" > Cc: compiler-...@openjdk.java.net, "Java Core Libs" >

Re: API review of VarHandles

On Friday, January 22, 2016, Aleksey Shipilev wrote: > On 01/22/2016 03:08 PM, Vitaly Davidovich wrote: > > The VarHandle API isn't ergonomic like Unsafe; this being for power users > > is irrelevant to the ergonomics of the API. Instead, it's fairly verbose > > with setup ceremony. Now, I pers

Re: API review of VarHandles

On 01/22/2016 04:51 AM, Andrew Haley wrote: On 22/01/16 00:01, Vitaly Davidovich wrote: I think the get/setOpaque methods need a bit more explanation ("opaque" is an odd naming choice, IMO). Specifically, it says the operations are done in program order but have no effect on inter-thread orderi

Re: API review of VarHandles

On Friday, January 22, 2016, David M. Lloyd wrote: > On 01/21/2016 07:32 PM, Brian Goetz wrote: > >> >> I am baffled as to how the original language syntax proposal of using >>> some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two >>> new bytecodes was considered unacceptable; lo

Re: API review of VarHandles

Which existing Atomic* classes? I take it you mean the field updaters and not AtomicInteger and friends. The biggest issue with field updaters is their performance, for me. I take it you mean something else by "costs" though? Having to specify the target (field) as a string is annoying, and I do

Re: API review of VarHandles

On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: Experts need control more than anything else. This is not to say they'll be happy with a subpar API but control typically means lots of details so there's a limit on how abstracted the API can be. As mentioned, given the API provides low level co

Re: API review of VarHandles

On 01/22/2016 04:54 PM, David M. Lloyd wrote: > The costs are both performance and memory overhead. The > Atomic*FieldUpdaters are good for memory usage and reasonably usable, > but suffer from performance problems and generics issues. Hopefully, not anymore: http://shipilev.net/blog/2015/faste

Re: API review of VarHandles

So in this regard, VH ought to be better since it will have performance like Unsafe (rather than field updaters - is that accurate by the way? Is VH on par with Unsafe for issuing atomic ops?) and not have the memory bloat of the instance atomic classes. Generics is a non-issue for VH. I do agree

Re: API review of VarHandles

The costs are both performance and memory overhead. The Atomic*FieldUpdaters are good for memory usage and reasonably usable, but suffer from performance problems and generics issues. The "regular" Atomic* classes have good usability (including with generic types) and generally very good perf

Re: API review of VarHandles

On 01/22/2016 07:57 AM, Aleksey Shipilev wrote: On 01/22/2016 04:54 PM, David M. Lloyd wrote: The costs are both performance and memory overhead. The Atomic*FieldUpdaters are good for memory usage and reasonably usable, but suffer from performance problems and generics issues. Hopefully, not

Re: ClassFileTransformer does not apply to anonymous classes

On 1/22/16 4:11 AM, Andrew Dinn wrote: On 21/01/16 22:14, Rafael Winterhalter wrote: Hi Andrew, if there is any update on the matter, I would of course love to hear about it. Unfortunately, I never received an answer to my question, but maybe I picked the wrong list. Thank you for your support

Re: API review of VarHandles

+1, good stuff Aleksey (I had actually seen chatter about this change on one of these openjdk lists, but people have already moved away from the field updaters), except every time I think about final instance fields not being treated as constants I get sad :). The other wrinkle is the "am I lucky

Re: ClassFileTransformer does not apply to anonymous classes

Hi Coleen, thanks for looking into this. My original mail was the following: Hello everybody, classes that are loaded via Unsafe::defineAnonymousClass are not transformed by a registered ClassFileTransformer. At the same time, it is possible to retransform / redefine such an anonymous classes usi

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

Claes, On 22/01/16 12:07, Claes Redestad wrote: On 2016-01-22 12:56, Claes Redestad wrote: On 2016-01-22 12:53, Alan Bateman wrote: On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionUID, which needs to be added. I assume this i

Re: ClassFileTransformer does not apply to anonymous classes

On 22/01/2016 14:00, Coleen Phillimore wrote: Can you send the question again? I didn't see it. I also mostly look at JVM code and rarely deal with the Java side. The question was asked about ClassFileTransformer which is implemented by the JPLIS agent via the JVM TI CFLH event. So I think

Re: JEP 280 (Indify String Concat) integration

Hi Aleksey, Good work. Nice to see this integrated. If StringConcatException ever gets thrown, will it propagate out of the concatenation expression execution? If yes, then it should probably be an unchecked exception, right? Regards, Peter On 01/22/2016 10:31 AM, Aleksey Shipilev wrote:

Re: API review of VarHandles

Agreed; it's a building block, not an assembled piece. On Friday, January 22, 2016, Brian Goetz wrote: > > The VarHandle API isn't ergonomic like Unsafe; this being for power users >> is irrelevant to the ergonomics of the API. Instead, it's fairly verbose >> with setup ceremony. Now, I persona

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

On 21/01/16 22:55, Felix Yang wrote: Hi Chris, your fix is cool. I will assign the bug to you:) a comment on this fix. The test changed system SecurityManager and it is not executed with othervm mode. I think you need to rollback the change after test. I will revert the change and h

Re: API review of VarHandles

The VarHandle API isn't ergonomic like Unsafe; this being for power users is irrelevant to the ergonomics of the API. Instead, it's fairly verbose with setup ceremony. Now, I personally don't mind that too much and more interested in the features it provides but I'm not surprised by David's

Re: ClassFileTransformer does not apply to anonymous classes

On 1/22/16 7:29 AM, Alan Bateman wrote: On 22/01/2016 14:00, Coleen Phillimore wrote: Can you send the question again? I didn't see it. I also mostly look at JVM code and rarely deal with the Java side. The question was asked about ClassFileTransformer which is implemented by the JPLIS age

Re: ClassFileTransformer does not apply to anonymous classes

You are right. It is observed for all JDK8u releases and persists in the current builds of JDK9. Best regards, Rafael 2016-01-22 16:15 GMT+01:00 Daniel D. Daugherty : > On 1/22/16 7:29 AM, Alan Bateman wrote: >> >> >> On 22/01/2016 14:00, Coleen Phillimore wrote: >>> >>> Can you send the question

Re: ClassFileTransformer does not apply to anonymous classes

Rafael, What you are seeing are just consequences. My impression is that VM anonymous class redefinition/retransformation works mostly by accident. The real problem is that current API (both JVMTI and java.lang.instrument) doesn't serve for them well. When VM anonymous class is defined, a u

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

Hi Claes, I'm not sure it helps much, but making the ZERO_LENGTH_ENUM_ARRAY package-private (instead of private) will eliminate the need for the accessor. It is not mutable so there's no extra risk. Roger On 1/22/2016 10:44 AM, Claes Redestad wrote: On 2016-01-22 15:22, Chris Hegarty wr

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 15:22, Chris Hegarty wrote: Claes, On 22/01/16 12:07, Claes Redestad wrote: On 2016-01-22 12:56, Claes Redestad wrote: On 2016-01-22 12:53, Alan Bateman wrote: On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionU

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

> On 22 Jan 2016, at 15:44, Claes Redestad wrote: > > > > On 2016-01-22 15:22, Chris Hegarty wrote: >> Claes, >> >> On 22/01/16 12:07, Claes Redestad wrote: >>> On 2016-01-22 12:56, Claes Redestad wrote: On 2016-01-22 12:53, Alan Bateman wrote: >> > On 22/01/2016 11:34, Claes Redest

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

Hi Roger, right, I accidentally eliminated the accessor by (re-/)moving the constant which altered the serialization shape, which was the issue here. Widening the field to package-private would have caused the same issue. Thanks! /Claes On 2016-01-22 16:50, Roger Riggs wrote: Hi Claes, I'

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 16:50, Chris Hegarty wrote: +1 to your latest webrev. I just wanted to understand the reason for the serial version UID change, which you have provided. -Chris. Thanks! /Claes

OpenJDK8: java.util.stream.Stream.onClose

Dear core-libs-devs, I was playing around with streams and onClose and ran into an example with odd behavior (well, I found it odd, see example below). I was wondering if you could point me to prior discussions on semantics of intermediate operations and the semantics of Stream.onClose. A bit of

Re: ClassFileTransformer does not apply to anonymous classes

Hi Vladimir, thank you for your response. While I completely understand your view from a VM implementor's point of view, as a practicioner I would recommend against it. Not being able to instrument lambda expressions puts a severe limitation onto using the instrumentation API alltogether. For exam

Re: JEP 280 (Indify String Concat) integration

On 01/22/2016 05:44 PM, Peter Levart wrote: > If StringConcatException ever gets thrown, will it propagate out of the > concatenation expression execution? If yes, then it should probably be > an unchecked exception, right? StringConcatException is modeled after LambdaConversionException: it cover

Re: ClassFileTransformer does not apply to anonymous classes

Rafael, First of all, I'd like to agree on the terminology. There's some confusion there. Anonymous term is ambiguous in Java. There are anonymous classes on language level and there's Unsafe.defineAnonymousClass() which produce anonymous-in-VM-sense classes. I prefer to call them VM anonymou

Re: OpenJDK8: java.util.stream.Stream.onClose

Hi Carsten, If you read the documentation further on down it states: * first exception, since an exception cannot suppress itself.) May * return itself. The same applies to parallel/sequential/unordered. For these cases it would be rather inefficient to create new stages in the pipeline, for e

Re: Ephemerons

Peter, I've been following Ephemerons in other GC'ed environments, and wondering when someone will bring it up for Java. Happy to see attentions given to it. The "conditional weak reference hashmap/table/dictionary" use case seems to be a common primary motivator, and it's a very valid one. Giv

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

Hi Martin, Thanks for adding the comments and @ignore. On readObject(), ok, you went ahead and rearranged some stuff. You hit a couple of the issues I had spotted, namely the multiple assignment to elementData and the potentially confusing reuse of the name 'elementData'. The other issue was

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 1/22/16 7:44 AM, Claes Redestad wrote: It would seem the assessment that serialVersionUID is not needed when using the serial proxy pattern might be misguided (or is this a bug in ObjectInputStream)? It is debate-able whether this is a test bug or not. But I think we should not change the

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

On Fri, Jan 22, 2016 at 10:03 AM, Stuart Marks wrote: > On readObject(), ok, you went ahead and rearranged some stuff. You hit a > couple of the issues I had spotted, namely the multiple assignment to > elementData and the potentially confusing reuse of the name 'elementData'. > > The other issue

Re: JDK RFR of 8147545: Remove sun.misc.ManagedLocalsThread from java.prefs

On 22 Jan 2016, at 20:17, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8147545 > Patch:http://cr.openjdk.java.net/~bpb/8147545/webrev.00/ Looks good to me. Thanks Brian. -Chris. > Replaced using of ManagedLocal

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 2016-01-22 19:43, Stuart Marks wrote: On 1/22/16 7:44 AM, Claes Redestad wrote: It would seem the assessment that serialVersionUID is not needed when using the serial proxy pattern might be misguided (or is this a bug in ObjectInputStream)? It is debate-able whether this is a test bug o

RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

Hi, All Can I have a review for bug: https://bugs.openjdk.java.net/browse/JDK-8147755 Webrev: http://cr.openjdk.java.net/~minqi/8147755/webrev-01/ Summary: When fix bug 8145148 to follow: JVMS-5.4.3.3 Method Resolution: " If C is an interface, method resolution throws an Incompa

JDK RFR of 8147545: Remove sun.misc.ManagedLocalsThread from java.prefs

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8147545 Patch: http://cr.openjdk.java.net/~bpb/8147545/webrev.00/ Replaced using of ManagedLocalsThread with a Thread created from the new constructor Thread(ThreadGroup,Runnable,String,long,boolean) with the

Re: JDK RFR of 8147545: Remove sun.misc.ManagedLocalsThread from java.prefs

Hello, I would name it more like "Preference Timer Shutdown Hook" and "Preference Dispatch Thread" and "Preference Flush Thread" (i.e. include the subsystem) + new Thread(null, null, "Sync Timer Thread", 0, false) Gruss Bernd -- http://bernd.eckenfels.net -Original Message- From: Ch

Re: JDK RFR of 8147545: Remove sun.misc.ManagedLocalsThread from java.prefs

Good suggestions but I already pushed it as-is. I can file a new issue for this … Thanks, Brian On Jan 22, 2016, at 12:53 PM, e...@zusammenkunft.net wrote: > I would name it more like "Preference Timer Shutdown Hook" and "Preference > Dispatch Thread" and "Preference Flush Thread" (i.e. inclu

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 1/22/16 12:30 PM, Claes Redestad wrote: Thanks Stuart! I've posted a webrev including your changes here: http://cr.openjdk.java.net/~redestad/8148044/webrev.03/ If there's a preference for this version I'll push it after the weekend. This looks good to me, thanks for updating it. I definit

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

On 1/22/16 12:02 PM, Martin Buchholz wrote: I went "by the book" as you suggested and now throw InvalidObjectException when size < 0. (But I've been saying for a decade: if we're serious about Serialization, it needs to be someone's full time job) "Admiral, if we go by the book, years could t

Re: Ephemerons

Hi Gil, Thanks for taking a look at the Ephemerons for Java. It's great to have a big mind joining the discussion. On 01/22/2016 07:12 PM, Gil Tene wrote: Peter, I've been following Ephemerons in other GC'ed environments, and wondering when someone will bring it up for Java. Happy to see at

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

Hi Alan, et. al., I’ve released a new webrev that addresses all the issues you raised. http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html Specifically: > For Release then I have to admit that I dislike _9 and wonder

Re: Ephemerons

> On Jan 22, 2016, at 2:49 PM, Peter Levart wrote: > > Hi Gil, > > Thanks for taking a look at the Ephemerons for Java. It's great to have a big > mind joining the discussion. > > On 01/22/2016 07:12 PM, Gil Tene wrote: >> Peter, >> >> I've been following Ephemerons in other GC'ed environmen