RE: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams

2017-04-06 Thread Timo Kinnunen
es, if the >>>>> previous match is >>>>> zero-width-match (the fist==last), we step one to the next cursor before >>>>> next >>>>> try. I know >>>> >>>> Interesting, I didn't know Matcher.find() advances the

RE: JDK 9 RFR(s): 8150488: add note toScanner.findAll()regardingpossible infinite streams

2017-04-04 Thread Timo Kinnunen
other regex engines. If a regex engine chosen for an implementation didn’t have infinite looping then that would have to be emulated! Sent from Mail for Windows 10 From: Stuart Marks Sent: Wednesday, April 5, 2017 07:50 To: Timo Kinnunen Cc: Xueming Shen; core-libs-dev@openjdk.java.net Subject

RE: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams

2017-04-04 Thread Timo Kinnunen
task is to find non-overlapping matches in a given input then it repeatedly returning the same empty match at the same location could even be considered a bug. Sent from Mail for Windows 10 From: Xueming Shen Sent: Wednesday, April 5, 2017 01:11 To: Stuart Marks Cc: Timo Kinnunen; core-libs-dev

RE: JDK 9 RFR(s): 8150488: add note to Scanner.findAll() regardingpossible infinite streams

2017-03-30 Thread Timo Kinnunen
Hi, I guess this somewhat contrived example also wouldn’t work? String s = "\\b\\w+|\\G|\\B"; String t = "Matcher m = Pattern.compile(s).matcher(t);\n"; Matcher m = Pattern.compile(s).matcher(t); while(m.find()) {

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-16 Thread Timo Kinnunen
implementation of threads as trivial as it should be. And who on earth could want to implement their own threading? Project Sumatra might. Sent from Mail for Windows 10 From: David Holmes Sent: Thursday, March 16, 2017 06:41 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-15 Thread Timo Kinnunen
, perhaps, but as Java 8 demonstrates it’s a bar that’s attainable. Sent from Mail for Windows 10 From: David Holmes Sent: Wednesday, March 15, 2017 11:38 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 15/03/2017

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-15 Thread Timo Kinnunen
replace it. Sent from Mail for Windows 10 From: David Holmes Sent: Wednesday, March 15, 2017 00:57 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 15/03/2017 12:01 AM, Timo Kinnunen wrote: > Hi, > > Fil

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-14 Thread Timo Kinnunen
10 From: Andrew Haley Sent: Tuesday, March 14, 2017 19:03 To: Timo Kinnunen; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 14/03/17 14:01, Timo Kinnunen wrote: > File handles aren’t that scarce of a resource, really, at least on > W

RE: Review request 8153912: StackFrame::getFileName andStackFrame::getLineNumber not needed

2017-03-14 Thread Timo Kinnunen
Hi, I was curious so I tried my hand at a couple of different implementations for getting a caller’s class. These were all run in JDK 1.8.0_102, VM 25.102-b14. I’m not sure our results agree, but neither am I sure how to properly compare them. And since you have no baseline score this makes c

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-14 Thread Timo Kinnunen
Hi, File handles aren’t that scarce of a resource, really, at least on Windows. On Windows threads are a lot scarcer resource than file handles, and I don’t recall anyone suggesting Java’s GC wasn’t suitable for managing that limited but crucially important resource. The question should then b

RE: RFR(m): 8140281 deprecate Optional.get()

2016-04-27 Thread Timo Kinnunen
Hi, Looking at real problems is good, and in this case there’s quite a few layers of issues underlying issues indeed. First the problem of the “get” method underlain by the deprecation issue. As mentioned, the name “get” is a good, proper name for a method. There are no problems with the name

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

2016-01-23 Thread Timo Kinnunen
Hi, The pipeline stages don’t really need to mutate themselves (as they can mutate the Stream if needed). So they should be shareable between Streams, alleviating some of cost of creating new copies of a Stream, right? -- Have a nice day, Timo Sent from Mail for Windows 10 From: Paul

RE: Map.Entry methods for streams

2016-01-15 Thread Timo Kinnunen
Hi, For completeness, having also the methods default Entry withKeyAsValue(NK newKey) { return new AbstractMap.SimpleEntry<>(newKey, getKey()); } public Entry withValueAsKey(NV newValue) { return new AbstractMap.SimpleEntry<>(getValue(),

RE: RFR: jsr166 jdk9 integration wave 2

2015-12-10 Thread Timo Kinnunen
This seems problematic to me, because it breaks the expectation that the most important part of the stack trace can be found at the bottom of the it. In this case, if someone subsequently wraps the original exception in their own Exception the causal chain then gets jumbled. I actually wish prin

RE: ConcurrentMap::compute clarification

2015-12-09 Thread Timo Kinnunen
Yes, I think the containsKey check is just not appropriate here. Doing the check means the information gained from reading oldValue becomes immediately stale. This means oldValue has to be read again. But reading oldValue means the information received from the check on whether the loop has to r

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

2015-12-08 Thread Timo Kinnunen
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 w

RE: RFR: jsr166 jdk9 integration wave 2

2015-12-03 Thread Timo Kinnunen
Hi, Following the single-threaded try-with-resources semantics very closely might not give the most useful result because there is at least one aspect that’s fundamentally different between these cases. That is, in the case where the “try”-stage (or block) completes normally but the “finally”-

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-19 Thread Timo Kinnunen
:12 To: Timo Kinnunen;John Rose Cc: OpenJDK Dev list Subject: Re: Proposed API for JEP 259: Stack-Walking API On 19/11/2015 11:36 PM, Timo Kinnunen wrote: > A point in favor of UnsupportedOperationException would be: if in the > future it becomes possible to have large parts of the JVM writ

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-19 Thread Timo Kinnunen
A point in favor of UnsupportedOperationException would be: if in the future it becomes possible to have large parts of the JVM written in Java or sun.tools becomes part of the J2SE API then having an instance of a VirtualMachine class as the caller of public static void main and Thread.run coul

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-18 Thread Timo Kinnunen
Hi, I’m happy to hear that, I was just about to post more convoluted examples against special-casing (i.e. new Thread(r).start(); vs. new Thread(r) {}.start(); vs. new Thread(new Thread(r)) {}.start(); vs. new Thread(new Thread(r)

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-15 Thread Timo Kinnunen
From: Peter Levart Sent: Sunday, November 15, 2015 20:15 To: Timo Kinnunen;David M. Lloyd;core-libs-dev@openjdk.java.net Subject: Re: Proposed API for JEP 259: Stack-Walking API On 11/15/2015 05:53 PM, Timo Kinnunen wrote: To be pedantic, there is always a caller, but not every caller is

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-15 Thread Timo Kinnunen
To be pedantic, there is always a caller, but not every caller is associated with a Java Class. StackWalker::getCallerClass can be thought as a convenience method for something like: Class callingMe = StackWalker.getCaller().getAsJavaClass(); >From this view-point we can determine that

RE: Code Review for JEP 259: Stack-Walking API

2015-11-13 Thread Timo Kinnunen
The metadata shown by jstack is available internally too, albeit getting access to it is a bit convoluted. Also using it for anything other than printing it out requires parsing it, as it’s in an undocumented text format. Sent from Mail for Windows 10 From: David M. Lloyd Sent: Thursday,

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-09 Thread Timo Kinnunen
Hi, My first thought would be that if we're running interpreted then we are already deep in the hole performance wise. If in addition we are class loading and initializing then our performance should be dominated by IO, a much deeper hole.  This isn't to say that class initializing cost isn't im

RE: RFR: updated draft API for JEP 269 Convenience CollectionFactories

2015-11-07 Thread Timo Kinnunen
Hi, I plotted the data and noticed a couple of things. First, for explicit arguments, performance looks to scale linearly only for 0, 1 and 2 arguments. After that, something changes and performance continues to scale linearly but in groups of two. Essentially, every even argument is passed fo

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-05 Thread Timo Kinnunen
eekCounter() { return Stream::count; } I’m not going to draw too many conclusions based on this one instance, but it’s an interesting outcome nonetheless. (also, somnambulate means sleepwalking) Sent from Mail for Windows 10 From: Maurizio Cimadamore Sent: Thursday, November 5,

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-05 Thread Timo Kinnunen
Hi, I tested all 6 combinations of Functions that a simple sanity-check StackWalker can call: Function, [any]> Function, [any]> Function, [any]> Function, [any]> Function, [any]> Function, [any]> Unfortunately there doesn’t appear to be any candidate for the walk-method that doesn’t ha

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-04 Thread Timo Kinnunen
Hi, I tested your version of the wildcard counter and it appears to be incompatible with one possible signature of the StackWalker.walk method. Here’s my code. Please see the line with ERROR comment: static class StackWalker { static class StackFrame implements CharSeq

RE: Proposed API for JEP 259: Stack-Walking API

2015-11-01 Thread Timo Kinnunen
ail for Windows 10 From: Mandy Chung Sent: Sunday, November 1, 2015 05:36 To: Timo Kinnunen Cc: Remi Forax;core-libs-dev@openjdk.java.net Subject: Re: Proposed API for JEP 259: Stack-Walking API In fact, T walk(Function, T> function, …) - without ? extends T change, You can do: Fu

RE: Proposed API for JEP 259: Stack-Walking API

2015-10-31 Thread Timo Kinnunen
Hi, Regarding “ I was pondering it and that’s why not changed in the last update. I agree with the upper bounded wildcard "? extends T” for the return type of the function. “ How does changing the type from “T” to “? extends T” aid the method caller in any way? If the caller has a Function

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

2015-10-19 Thread Timo Kinnunen
They are warnings in Eclipse and IntelliJ IDEA: “The static method foo() from the type A should be accessed directly” “The static method foo() from the type A should be accessed in a static way” “The static method foo() from the type A should be accessed directly” “Static method 'foo()' declared

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

2015-10-19 Thread Timo Kinnunen
Having one less import-statement that has to be written -- while editing a file -- by Content Assist/IntelliSense/Code Completion is a small improvement, but apart from that going from: ArrayList als = new ArrayList<>(Arrays.asList("a", "b", "c")); to: ArrayList als = new ArrayLis

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

2015-10-16 Thread Timo Kinnunen
Hi, Calling a static method of a superclass using the name of the subclass is already a warming in any decently configured IDE. Fixing such warnings is so trivial that having displayed the warning an IDE could do it automatically.  Such a code sample is not a convincing argument against static fa

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

2015-10-14 Thread Timo Kinnunen
, doesn’t limit lower-end runtimes and provides a hint about a typical performance profile one could expect. Sent from Mail for Windows 10 From: Rémi Forax Sent: Wednesday, October 14, 2015 14:16 To: Timo Kinnunen;Paul Sandoz Cc: core-libs-dev Subject: RE: RFC: draft API for JEP 269

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

2015-10-14 Thread Timo Kinnunen
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 Collections

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

2015-10-14 Thread Timo Kinnunen
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 table