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
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
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
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()) {
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
, 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
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
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
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
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
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
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
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(),
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
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
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
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”-
: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
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
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)
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
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
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,
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
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
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,
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
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
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
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
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
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
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
, 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
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
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
36 matches
Mail list logo