RFR: 5050783: Throwable convenience method: String getStackTraceString()

Hello, I am Ivan from the Bulgarian Java User Group. As part of our Adopt OpenJDK efforts, we organized hackathon beginning of this month in Sofia. There we worked on the following JIRA issue: https://bugs.openjdk.java.net/browse/JDK-5050783 Unfortunately none of us has author privileges, so

Re: RFR(S): 8067471: Use private static final char[0] for empty Strings

Thanks Ivan! I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/. Best Regards, Lev

Re: RFR: 5050783: Throwable convenience method: String getStackTraceString()

Hi, seems like a reasonable convenience method. :-) Process stuff: OCA/JSPA signing aside, the patch needs to be submitted in its entirety to some part of the OpenJDK infrastructure before it can be accepted. Attaching the patch in an e-mail to this mailing list is acceptable for a small

Re: Lower overhead String encoding/decoding

On 12/30/14 3:25 PM, Richard Warburton wrote: Hi, Thanks for looking at this patch and agreeing to sponsor - I've pushed fixes for these issues at: http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/ http://cr.openjdk.java.net/%7Erwarburton/string-patch-webrev-10/

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

Just to followup, I've analyzed the whole PIT run. The second one's call stack is identical to: JDK-8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke So, really the only problem is the use of Asserts in your test case. Brad

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

To the actual proposal: http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/ Overall, I'm ok with what's proposed. This is more straightforward to parse/understand than trying to adjust NativeSeedGenerator to create/call directly (e.g. UNIX: new

Re: Explicit Serialization API and Security

Not quite, the constructor signature is the same for super and child classes. ReadSerial is a container for each serialized Object in an ObjectInputStream that provides and controlls access to serial fields, identified by name, type and calling class, such that each class has it's own

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

If we look at using purely store fences and purely load fences in the initialized flag example as in this discussion, I think it's worth distinguishing too possible scenarios: 1) We guarantee some form of dependency-based ordering, as most real computer architectures do. This probably