Re: java.lang.reflect.Method.copyOf

> On 14 Oct 2015, at 16:15, Remi Forax wrote: > > - Mail original - >> De: "Paul Sandoz" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >>

Re: java.lang.reflect.Method.copyOf

Thanks Paul and Chris, very interesting indeed. regards, Rémi - Mail original - > De: "Chris Hegarty" > À: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev" > > Envoyé: Mercredi 14

Re: RFR: 6907252: ZipFileInputStream Not Thread-Safe

On 10/14/15 6:20 AM, Seán Coffey wrote: Looking to tighten up access between the java and native level zip library calls. This extra check should ensure that we don't hit SEGV on thread races. I've also taken the opportunity to make the ZStreamRef address variable volatile. I'm still getting

Re: RFR: JDK-8046565: Platform Logger API and Service

> On Oct 14, 2015, at 4:20 AM, Daniel Fuchs wrote: > > Hi Mandy, > > On 14/10/15 07:21, Mandy Chung wrote: >> >>> On Oct 8, 2015, at 5:26 AM, Daniel Fuchs wrote: >>> >>> webrev: >>>

RE: java.lang.reflect.Method.copyOf

Hi, Just as idea: Why not implement Cloneable for that purpose? Adding new methods does not look like a good idea. - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: core-libs-dev

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Some notes after reading follow-ups. One question is whether there should be a method that clues in the JVM about what change is being waited for. This is the territory of monitor-like constructions (see below), as opposed to the yield/sleep-like constructions that Gil was initially proposing.

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

Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev:

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

On 14/10/2015 17:07, Steve Drach wrote: Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Good to have tests this time :-) I see several JAR files in the webrev, shouldn't the tests create

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

On 14/10/2015 15:03, Roger Riggs wrote: Hi Alan, So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. For example, Netbeans. Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend

Re: java.lang.reflect.Method.copyOf

On 14 Oct 2015, at 15:15, Remi Forax wrote: > - Mail original - >> De: "Paul Sandoz" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >> >>>

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

On 10/14/2015 04:23 PM, Alan Bateman wrote: On 14/10/2015 15:03, Roger Riggs wrote: Hi Alan, So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. For example, Netbeans. Cleaner + Cleanable need to be public of course so maybe we

Re: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException

Hi Vyom, I will push this for you. best regards, -- daniel On 13/10/15 17:39, Mandy Chung wrote: On Oct 14, 2015, at 7:23 PM, vyom wrote: Hi All, Please find the updated code, i fixed the missing space.

RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

Please, review the following fix in core-libs area for the bug https://bugs.openjdk.java.net/browse/JDK-8133206 : http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.00/ The bug is a regression of the recent zlib 1.2.3 => 1.2.8 library update. One of our customers started to see

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

Hi Alan, Mandy, I looked at a few of the many uses of finalize and the likely changes. The zip Inflater and Deflater are relatively simple cases. Some finalizers are not used and can be removed. The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup

[9] RFR 8138838: docs cleanup for java.desktop

Sorry, just a reminder. If the activity is untimely, then could you please review the following minimum part of fix? http://cr.openjdk.java.net/~avstepan/8138838/webrev.min.00/index.html (some misprints + midget JDK-8138893 fixed). Thanks, Alexander On 10/5/2015 2:12 PM, Alexander Stepanov

Re: RFR: JDK-8046565: Platform Logger API and Service

On 14/10/15 18:13, Mandy Chung wrote: There are other methods having similar @throws that should be updated as well. Yes - sorry - I meant I would do it for the method that takes Object as well. When I started working on this I added a new LoggerPermission class similar to

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

> On 13 Oct 2015, at 22:43, Stephen Colebourne wrote: > > I'd prefer to see "this" mentioned: > > "If a value is not present, invoke the specified supplier to provide > the result, otherwise return {@code this}" > > While I understand the original form gave some spec

Re: RFC: draft API for JEP 269 Convenience Collection Factories

> On 14 Oct 2015, at 06:18, Stuart Marks wrote: > I'm not entirely sure what to take from this. If it were clearly exponential, > we could say with confidence that above a certain threshold there would be > vanishingly little benefit adding more arguments. But since

RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970

Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928 Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 BugId - https://bugs.openjdk.java.net/browse/JDK-8134928 webrev -

java.lang.reflect.Method.copyOf

Hi, I was wondering if there is any reason for Method.copyOf (and friends) being package private. I'm trying to make a copy of a large number of Method objects in some performance sensitive code to avoid sharing the isAccessible flag. And while this is fairly fast. Class declaringClass =

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

Maybe "an optional equivalent to {@code this}" The original text is quite obtuse. Stephen On 14 October 2015 at 09:54, Paul Sandoz wrote: > >> On 13 Oct 2015, at 22:43, Stephen Colebourne wrote: >> >> I'd prefer to see "this" mentioned: >> >>

Re: Incomplete JavaDoc for Collections.synchronizedXYZ

Hi Tagir, Agreed. If you wanna send a patch to this list with updates to the other synchronized* methods i can review push it for you. Paul. > On 12 Oct 2015, at 15:18, Tagir F. Valeev wrote: > > Hello! > > With the introduction of Stream API the JavaDoc for >

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

On 10/14/2015 09:02 AM, Nikolay Gorshkov wrote: Please, review the following fix in core-libs area for the bug https://bugs.openjdk.java.net/browse/JDK-8133206 : http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.00/ The bug is a regression of the recent zlib 1.2.3 => 1.2.8 library

Re: JDK 9 RFR of JDK-8136799 Port fdlibm cbrt to Java

Hi Joe, On Oct 12, 2015, at 8:53 AM, joe darcy wrote: > Please review the next step of porting fdlibm to Java, the cbrt method: > >JDK-8136799 Port fdlibm cbrt to Java > http://cr.openjdk.java.net/~darcy/8136799.3/ FdLibm.java: * I assume that the diffs other than

Re: RFC: draft API for JEP 269 Convenience Collection Factories

On Oct 14, 2015, at 10:56 AM, Kevin Bourrillion wrote: > Anyway, since we created these methods, they became an attractive nuisance, > and thousands of users reach for them who would have been better off in > every way using an immutable collection. Our fondest desire is to one

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

>> The current test directory contains binary jar files. In fact in all the >> test directories, there are 52 binary .jar files. > I know but we need to work to remove those. I figured that might be the response, but thought it was worth the try ;-) > > >> I added three more. I thought

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

> On 14 Oct 2015, at 21:12, Steve Drach wrote: > >>> The current test directory contains binary jar files. In fact in all the >>> test directories, there are 52 binary .jar files. >> I know but we need to work to remove those. > > I figured that might be the response,

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

On 14/10/2015 17:28, Steve Drach wrote: The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I know but we need to work to remove those. I added three more. I thought about generating the jar files but the problem I

Re: java.lang.reflect.Method.copyOf

On Oct 14, 2015, at 3:38 AM, Remi Forax wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too > encapsulate it in a non mutable class, if possible. OK, I'll bite. Here's a way to make Method its own non-mutable encapsulation, a la List::set

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

The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. >>> I know but we need to work to remove those. >> >> I figured that might be the response, but thought it was worth the try ;-) >> > > A reasonable way forward

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

Steve, Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? -Sherman On 10/14/2015 09:07 AM, Steve Drach wrote: Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in

RE: RFC: draft API for JEP 269 Convenience Collection Factories

Hi, That’s intriguing since I wrote a collections library too, covering just Map/Set/List/Stream, with immutable/mutable versions and lots of convenience methods included, but I haven’t noticed such issues. My scope is a lot smaller, of course. It’s also not beholden to the way the

RE: RFC: draft API for JEP 269 Convenience Collection Factories

No, I meant the number should be limited by how many arguments (not including the last varargs array) it is possible to pass in registers without having to spill any of them on the stack on some widely-used architecture like x86-64, for example. This lets clients on it use its full

Re: RFR: JDK-8046565: Platform Logger API and Service

Addiitional comments: JdkLoggerProvider.java - should the GC’ed referent entries in the application SharedLoggers map be occasionally drained? BootstrapLogger.java In the BootstrapExecutors::join(Runnable r) method: try { getExecutor().submit(r).get(); } catch

Re: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970

I'd like to see an additional test case for the cases where rounding is *not* needed. Currently, there are only tests for where rounding is needed. It needs one more test line for after 1970 and one for before 1970. thanks Stephen On 14 October 2015 at 10:53, nadeesh tv

Re: java.lang.reflect.Method.copyOf

Given that j.l.r.Method is mutable, the best way to have performance is too encapsulate it in a non mutable class, if possible. As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and become mutable with Java 1.2, (yes, someone seriously fucked up !) so methods like copyOf

Re: RFC: draft API for JEP 269 Convenience Collection Factories

On 14 October 2015 at 10:38, Paul Sandoz wrote: >> On 14 Oct 2015, at 06:18, Stuart Marks wrote: >> I'm not entirely sure what to take from this. If it were clearly >> exponential, we could say with confidence that above a certain threshold >>

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Mandy, On 14/10/15 07:21, Mandy Chung wrote: On Oct 8, 2015, at 5:26 AM, Daniel Fuchs wrote: webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ System.Logger Several log methods throws NPE if the level is legible and the parameter is null.

Re: JDK 9 RFR of JDK-8136799 Port fdlibm cbrt to Java

Hi Brian, On 10/14/2015 1:34 PM, Brian Burkhalter wrote: Hi Joe, On Oct 12, 2015, at 8:53 AM, joe darcy > wrote: Please review the next step of porting fdlibm to Java, the cbrt method: JDK-8136799 Port fdlibm cbrt to Java

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

On 10/14/2015 1:56 PM, Steve Drach wrote: The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I know but we need to work to remove those. I figured that might be the response, but thought it was worth the try ;-) A

Re: java.lang.reflect.Method.copyOf

> On 14 Oct 2015, at 12:38, Remi Forax wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too > encapsulate it in a non mutable class, if possible. > > As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and > become

RE: RFC: draft API for JEP 269 Convenience Collection Factories

Hi, Alternatively you could create the variants whose parameters can be passed utilizing "all available registers", whatever that means in Java context. The rationale is that the reason for preferring variables over varargs is performance and this way there is no performance left on the

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

I agree on the separation between spin-hinting and monitor-like constructs. But not so much on the analogy to or use of the term "yield" to describe what is intended y spin hints. On the name choice: things that include the word "yield" vs. spinLoopHint():: While the spinYield() example in

CopyOnWriteArrayNavigableSet discussion on concurrency-interest

Hello all; For those that don't regularly read the JSR-166 concurrency-interest list (http://cs.oswego.edu/mailman/listinfo/concurrency-interest) I wanted to make note of a discussion there that some reading here may be interested in. I have recently proposed a new NavigableSet

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

>> Let’s try again, this time there are tests. Please review the following >> webrev that adds support for multi-release jars as specified in JEP-238. > Good to have tests this time :-) > > I see several JAR files in the webrev, shouldn't the tests create these so > that we don't have to check

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

On 10/14/15 4:04 PM, Steve Drach wrote: Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? It didn’t seem necessary. The root entries are the “public interface”, we’re just providing aliased entry contents. It does not sound right. The "exported public

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

Hi Alan, On 10/14/2015 9:35 AM, Alan Bateman wrote: On 14/10/2015 14:24, Roger Riggs wrote: Hi, Confirmed, the design and implementation encapsulate the cleanup so it can be run consistently at-most-once either at close or when it is unreferenced. It has not been a problem for

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

On 14/10/2015 14:54, Roger Riggs wrote: Being able to subclass the XXXCleanable classes allows more efficient implementation of the cleaners in both size and performance. The subclass adds the necessary state for the cleanup and implements the performCleanup method. Only a single object is

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

Hi Alan, So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module. For example, Netbeans. Roger On 10/14/2015 10:01 AM, Alan Bateman wrote: On 14/10/2015 14:54, Roger Riggs wrote: Being able to subclass the XXXCleanable classes allows

Re: java.lang.reflect.Method.copyOf

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev" > Envoyé: Mercredi 14 Octobre 2015 13:46:38 > Objet: Re: java.lang.reflect.Method.copyOf > > > > On 14 Oct 2015, at 12:38, Remi Forax wrote: > > > >

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

> Any reason the JarEntry.get/setSize() are the only ZipEntry methods get > overridden? It didn’t seem necessary. The root entries are the “public interface”, we’re just providing aliased entry contents. > > -Sherman > > On 10/14/2015 09:07 AM, Steve Drach wrote: >> Hi, >> >> Let’s try