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

Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I would think I am now expected to register my instances with a Cleaner and provide a Runnable

Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

On 12/8/15 1:11 AM, Brian Burkhalter wrote: The only point of the threads is to provoke a race condition so I don’t know that it matters in this case. Nonetheless I updated the test case per the suggestion and verified that it still provokes the failure in the build not containing the patch.

RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

Dear all, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ The change removes the sun.invoke.anon package and one pertaining test. Thanks, Michael -- Dr.

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

Hi Roger, Sorry I had no choice but to look at this more closely ... and apologies as this is very late feedback ... I only looked at the API not the details of the implementation. On 8/12/2015 4:50 AM, Roger Riggs wrote: Hi David, Thanks for the comments, Updated the javadoc and webrev

Re: RFR 8144675: Add a filtering collector

Hi, Looks good. Just minor comments. Would you mind limiting the text (not the example code) in the JavaDoc to the 80 limit? Collectors — 455 * Adapts a {@code Collector} accepting elements of type {@code T} which is filtered by filtering predicate to 456 * each input element

Re: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

Looks good -Sundar On 12/8/2015 3:07 PM, Michael Haupt wrote: Dear all, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ The change removes the sun.invoke.anon package and one pertaining

Re: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

(... please ignore the "and sponsor" part ...) > Am 08.12.2015 um 10:37 schrieb Michael Haupt : > > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 > Webrev:

Re: RFR 8144675: Add a filtering collector

Hi Stefan, Thank you for pointing out. I've just updated: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.03/ Regards, shinyafox(Shinya Yoshida) 2015-12-08 21:08 GMT+09:00 Stefan Zobel : > Hi shinyafox, > > minor typo in the code example: > > >

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

Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize. IMO Cleaners are better when you do not want the instance of an object to be accessible at all before you clean

Re: RFR 8144675: Add a filtering collector

Hi Paul, Thank you for your review. (Especially, about doc comment, it's very helpful for non-native speaker like me ;) ) 2015-12-08 18:27 GMT+09:00 Paul Sandoz : > Hi, > > Looks good. > > Just minor comments. > > Would you mind limiting the text (not the example code) in

Re: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk

Looks good Sherman. I'll look after the possible zerror enhancement as part of https://bugs.openjdk.java.net/browse/JDK-8144055 I think printing just the file name itself without path is safe. We could decide whether installation of a security manager should be a factor for such cases. Zip

ConcurrentMap::compute clarification

Hi, I stumbled upon an interesting issue with default implementation of `compute(K key, BiFunction remappingFunction)` in JDK8 `ConcurrentMap`. According to its contract the default method implementation assumes map implementations do not support null values. This is the begin of the default

Re: RFR 8144675: Add a filtering collector

Thank you so much! I've updated in webrev.02. Best regard, shinyafox(Shinya Yoshida) 2015-12-08 20:25 GMT+09:00 Paul Sandoz : > > > On 8 Dec 2015, at 10:59, ShinyaYoshida wrote: > > > > Hi Paul, > > Thank you for your review. > > (Especially, about

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

But thinking more on this approach this is simply not scalable. A Cleaner per cleanable-class could result in hundreds of threads being active! And this certainly does not seem easier to use than finalization. What exactly are the advantages over finalization again? Thanks, David On

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

On 12/08/2015 09:22 AM, David Holmes wrote: Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I would think I am now expected to register my

Re: RFR 8144675: Add a filtering collector

> On 8 Dec 2015, at 10:59, ShinyaYoshida wrote: > > Hi Paul, > Thank you for your review. > (Especially, about doc comment, it's very helpful for non-native speaker like > me ;) ) > No problem. FWIW i am a native speaker and i find the documentation/specification the

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

On 8/12/2015 10:25 PM, Peter Levart wrote: On 12/08/2015 09:22 AM, David Holmes wrote: Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I

Re: Potential performance improvement for java.util.AbstractList?

sent from my phone On Dec 8, 2015 12:07 AM, "David Holmes" wrote: > > On 8/12/2015 1:39 AM, Rafael Winterhalter wrote: >> >> In this case, one might consider: >> >> if (o instanceof java.util.RandomAccess && (List)o).size() != size()) >>return false; > > > You'd also

Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

On 08/12/2015 00:11, Brian Burkhalter wrote: : http://cr.openjdk.java.net/~bpb/8143394/webrev.01/ wherein the sentence "This method will block if there is another thread blocking on the reader.” is added to the specification of

Re: RFR 8144675: Add a filtering collector

Hi shinyafox, minor typo in the code example: s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment Regards, Stefan 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : > Thank you so much! > I've updated in webrev.02. > > Best regard, > shinyafox(Shinya Yoshida) >

RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Many threads created by the platform are short lived and perform some simple async operation on behalf of the platform. These threads typically use/extend sun.misc.ManagedLocalsThread. This is a convenient internal API that can be used to create threads that do not wish to inherit initial values

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

On 08/12/15 00:19, Stuart Marks wrote: Hi Maurizio, Well, maybe we should add five more overloads to EnumSet.of()? (Only slightly joking here.) Setting aside the number of overloads, it would add N more overloads to Set.of(). I guess the erasure of > would be Enum, so there wouldn't be

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

On 8 Dec 2015, at 14:33, Roger Riggs wrote: > Hi Chris, > > Supporting the use case in Thread is a good addition. Thanks. > Adding an argument to the most flexible constructor of Thread bulks up > an already heavy weight constructor. Look at the cases being replaced,

8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the failing subtest out into its own file and excluded it on the (intermittently) failing platforms. http://cr.openjdk.java.net/~robm/8141370/webrev.01/ -Rob

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

(once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize.

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Hi Chris, Supporting the use case in Thread is a good addition. Adding an argument to the most flexible constructor of Thread bulks up an already heavy weight constructor. Look at the cases being replaced, none of them use all of the arguments. The stackSize, for example, is rarely used and

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Or perhaps a builder... On 12/08/2015 08:33 AM, Roger Riggs wrote: Hi Chris, Supporting the use case in Thread is a good addition. Adding an argument to the most flexible constructor of Thread bulks up an already heavy weight constructor. Look at the cases being replaced, none of them use

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

On 12/08/2015 07:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Thanks, just spotted that myself after attempting to run it in a loop via jtreg. (in case jtreg is somehow involved in causing the intermittent failure) Will be corrected pre-push. -Rob On 08/12/15 15:45, Daniel Fuchs wrote: Hey Rob, The @run line seems to be wrong in the new test

Re: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests

> On Dec 8, 2015, at 1:37 AM, Michael Haupt wrote: > > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ +1 Mandy

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

Hi, On 12/08/2015 08:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize

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

Hi Peter, Thanks for the example and explanations. For simple cleanup of specific state values, I probably would have used lambda instead of an explicit inner class but both styles use the same mechanism. The point about using a shared cleaner can be reinforced in the example too. public

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Hey Rob, The @run line seems to be wrong in the new test file: 26 * @run main/othervm LdapTimeoutTest cheers, -- daniel On 08/12/15 15:00, Rob McKenna wrote: Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the

Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

On Dec 8, 2015, at 5:22 AM, Alan Bateman wrote: >> Not sure whether this change requires CCC approval. >> > One suggestion is to use "while" rather than "if", otherwise looks okay I > think. An updated version with “while” instead of “if” is here:

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

On Dec 8, 2015, at 3:09 AM, David Holmes wrote: > > Question: what happens if an object is registered simultaneously with > multiple Cleaners? Do we need to warn the user against that? Aside: I like David's suggested "action" terminology. > Question: what happens if

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

On Dec 8, 2015, at 7:44 AM, David Holmes wrote: > But thinking more on this approach this is simply not scalable. A > Cleaner per cleanable-class could result in hundreds of threads being > active! That would indeed be awful. However, the scope of a Cleaner should not

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

On 12/08/2015 04:34 PM, Roger Riggs wrote: Hi Peter, Thanks for the example and explanations. For simple cleanup of specific state values, I probably would have used lambda instead of an explicit inner class but both styles use the same mechanism. The point about using a shared cleaner can

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

On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: > On 12/08/2015 04:34 PM, Roger Riggs wrote: >> >>private final Cleaner.Cleanable cleanable = cleaner.register(this, () >> -> fd.close()); > > Sorry Roger, but this example is flawed. This is tricky! The lambda

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

On 12/08/2015 07:25 PM, Kim Barrett wrote: On Dec 8, 2015, at 3:09 AM, David Holmes wrote: Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? Aside: I like David's suggested "action"

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

Hi Peter, Tricky indeed, the visibility of what is captured is too subtle. Even if the field is final, it captures this, not the value. I suppose it is more efficient not to copy field values. But other than recommending capturing only local variables and arguments, is there any other relevant

Re: Reference.reachabilityFence

> On 7 Dec 2015, at 18:58, mark.reinh...@oracle.com wrote: > > 2015/12/4 5:47 -0800, paul.san...@oracle.com: >>> On 3 Dec 2015, at 22:33, Mandy Chung wrote: On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote:

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

> On Dec 8, 2015, at 6:50 AM, Chris Hegarty wrote: > > > On 8 Dec 2015, at 14:33, Roger Riggs wrote: >> Adding an argument to the most flexible constructor of Thread bulks up >> an already heavy weight constructor. Look at the cases being

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

On Dec 8, 2015, at 2:26 PM, Peter Levart wrote: > > On 12/08/2015 07:25 PM, Kim Barrett wrote: >> On Dec 8, 2015, at 3:09 AM, David Holmes >> wrote: >> >>> Question: what happens if an object is registered simultaneously with >>> multiple

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

> On 8 Dec 2015, at 8:19 p.m., Mandy Chung wrote: > > >> On Dec 8, 2015, at 6:50 AM, Chris Hegarty wrote: >> >> >>> On 8 Dec 2015, at 14:33, Roger Riggs wrote: >>> Adding an argument to the most flexible constructor

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

> On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: > >> >> Since this is target for advanced users, what’s your thought of defining a >> new subclass extending Thread? > > I don't have a strong objection against a new subclass, but I seems like > overkill for

RFR JDK-8144958: changes by JDK-8142508 seems to have broken jtreg

Please help review the change for 8144958. issue: https://bugs.openjdk.java.net/browse/JDK-8144958 webrev: http://cr.openjdk.java.net/~sherman/8144958/ The changeset pushed this morning for 8142508 appears to trigger jtreg fail on some tests. ---

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

On 12/08/2015 07:44 PM, Kim Barrett wrote: On Dec 8, 2015, at 7:44 AM, David Holmes wrote: But thinking more on this approach this is simply not scalable. A Cleaner per cleanable-class could result in hundreds of threads being active! That would indeed be awful.

Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

HI all, Please review a fix for Bug - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts

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

On 9/12/2015 5:05 PM, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. Problem is that many people - myself included - would not have a clue when a lambda "captures this"! Is that part of

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Hm, In need of an API I would stick to an executor. Maybe (but thats likely not needed) have a common (caching) thread pool for such tasks. I would kt encourage using those stray thread classes. Gruss Bernd -- http://bernd.eckenfels.net -Original Message- From: Mandy Chung

Re: RFR JDK-8144958: changes by JDK-8142508 seems to have broken jtreg

Approved to back out the earlier changeset while the investigation is underway. Thanks, -Joe On 12/8/2015 4:40 PM, Xueming Shen wrote: Please help review the change for 8144958. issue: https://bugs.openjdk.java.net/browse/JDK-8144958 webrev: http://cr.openjdk.java.net/~sherman/8144958/ The

[rmi] supressStackTraces does not suppress suppressed exception

Hello I noticed that RMI servers honor the sun.rmi.server.suppressStackTraces system property only for the `cause` member, but not for the suppressed exception array. This seems to be not documented (and is most likely not wanted?) It looks like it does also not handle

Re: [rmi] supressStackTraces does not suppress suppressed exception

Hi Bernd, How very interesting. Thanks for pointing this out. You're right, suppressStackTraces should probably also suppress the stack traces for suppressed exceptions. (Kind of funny given the names, but the word "suppress" is being used in two different senses here.) I've filed this bug

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

Can we enhance java to allow specifying lambda capture and how the value is captured? :) This is very subtle to the point where I maybe wouldn't even encourage use of lambda in this context. sent from my phone On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > On

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

This has the same problem, doesn't it? The bottom line is if the lambda is () -> you're getting a capture of `this`. On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs wrote: > Hi, > > Another option that should always capture is to define a specific static > method with the

Re: Potential performance improvement for java.util.AbstractList?

Mon Dec 7 15:31:56 UTC 2015 Cédric Champeau : > I assume one reason it's done this way is that depending on the list > implementation you are using, getting the size might involve iterating over > all elements, so you would be iterating twice at worst case. If calling size() was a non-trivial

RE: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization

sent from my phone On Dec 8, 2015 9:52 PM, "Timo Kinnunen" wrote: > > Hi, > > > > Not encouraging the use of lambdas won’t stop people discovering lambda usage for this on their own anyways, then writing blog posts about their discovery, promoting it, extolling its

RE: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization

Hi, Not encouraging the use of lambdas won’t stop people discovering lambda usage for this on their own anyways, then writing blog posts about their discovery, promoting it, extolling its simplicity, encouraging others to use it too, etc… etc.. Let’s say I’ve forgotten about this issue and

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

Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable { private static final Cleaner cleaner = ...; // preferably a shared cleaner

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Yes but it won’t work for existing classes that extend Thread. Mandy > On Dec 8, 2015, at 1:08 PM, Roger Riggs wrote: > > Hi, > > Using a static factory method, in Thread, would I think be preferable to > creating a whole new class > and provide the opportunity to

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

Hi, Another option that should always capture is to define a specific static method with the needed values as arguments: public static class CleanerExample implements AutoCloseable { FileDescriptor fd = ...; private static final Cleaner cleaner = Cleaner.create();

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

On 12/08/2015 08:08 PM, Steven Schlansker wrote: On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: On 12/08/2015 04:34 PM, Roger Riggs wrote: private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); Sorry Roger, but this example

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Hi, Using a static factory method, in Thread, would I think be preferable to creating a whole new class and provide the opportunity to name it intuitively. $.02, Roger On 12/08/2015 03:53 PM, Mandy Chung wrote: On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: