Thanks David!
Alejandro
On 11/3/2015 8:52 PM, David Holmes wrote:
Looks good to me!
Thanks,
David
On 4/11/2015 3:45 AM, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
Back
Looks good to me!
Thanks,
David
On 4/11/2015 3:45 AM, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
Background:
These changes introduce a new system property named "jdk.debu
Hello,
Please review the short patch below to address
JDK-8141359: @Deprecated on packages should be clarified
--- a/src/java.base/share/classes/java/lang/Deprecated.javaTue Nov
03 17:41:38 2015 -0800
+++ b/src/java.base/share/classes/java/lang/Deprecated.javaTue Nov
03 18:47:38 2
> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote:
>
> Hi Mandy,
>
> This is very nice work.
>
> Comments below, mostly minor stuff.
>
Thanks for the review.
I fixed most of the comments below. One question:
Is the name “StackStream" inappropriate and its subtypes? I prefer StackStream
t
> On Nov 3, 2015, at 2:08 PM, David M. Lloyd wrote:
>
>> I considered Optional>. I believe it is rare to have a JNI attached
>> thread calling StackWalker::getCallerClass from native. Most common cases
>> will find a caller class. Returning an Optional will force most common
>> uses to han
> On Nov 3, 2015, at 5:24 PM, Wang Weijun wrote:
>
> Curious that you added a new method called
> jarFile.getRuntimeVersionedEntry(entryName).
It’s new to JarFile, but not new to the changeset, it’s been in there since the
reviews started.
> Is this the *only* method you would call for a mul
Curious that you added a new method called
jarFile.getRuntimeVersionedEntry(entryName). Is this the *only* method you
would call for a multi-release jar? If so, is it still necessary to modify the
old getEntry() method?
Thanks
Max
> On Nov 4, 2015, at 1:11 AM, Steve Drach wrote:
>
> Webrev:
On 11/3/2015 3:42 PM, Daniel D. Daugherty wrote:
On 11/3/15 10:45 AM, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
jdk/src/java.base/share/classes/sun/misc/Version.java.te
On 11/3/15 10:45 AM, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
jdk/src/java.base/share/classes/sun/misc/Version.java.template
nit: L103: if (jdk_debug_level.s
Hi Mandy,
A couple of followups below...
On 11/3/2015 4:18 PM, Mandy Chung wrote:
On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote:
Hi Mandy,
On 11/2/2015 2:53 PM, Mandy Chung wrote:
On Oct 20, 2015, at 11:28 AM, Roger Riggs
wrote:
Updated Javadoc:
http://cr.openjdk.java.net/~rriggs/cl
> On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> Great API.
>
> One thing I noticed is method StackWalker.getCallerClass() which is described
> as equivalent to the following:
>
> walk((s) -> s.map(StackFrame::getDeclaringClass)
> .skip(2)
> .findFirst()).
> On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote:
>
> Hi Mandy,
>
> On 11/2/2015 2:53 PM, Mandy Chung wrote:
>>> On Oct 20, 2015, at 11:28 AM, Roger Riggs
>>> wrote:
>>>
>>> Updated Javadoc:
>>>
>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/
>> I’m happy with this API to provide an ea
On 11/03/2015 03:33 PM, Mandy Chung wrote:
On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is described
as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
Hi Alejandro,
On 2015-11-03 18:45, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
Looks good to me.
/Magnus
Background:
These changes introduce a new system property name
Thanks Magnus!
Alejandro
On 11/3/2015 12:24 PM, Magnus Ihse Bursie wrote:
Hi Alejandro,
On 2015-11-03 18:45, Alejandro E Murillo wrote:
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
Looks good to me
Hi,
This is a significant body of impressive work, well done all who worked on it.
String
—
148 * The instance field value is generally opaque to optimizing JIT
149 * compilers. Therefore, in performance-sensitive place, an explicit
150 * check of the static boolean {@code COM
Hi Mandy,
On 11/2/2015 2:53 PM, Mandy Chung wrote:
On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote:
Updated Javadoc:
http://cr.openjdk.java.net/~rriggs/cleaner-doc/
I’m happy with this API to provide an easy way to migrate away from finalizers.
Some thoughts:
1. For an existing finalizer
Hi Mandy,
I have pushed an update that adds the diagnosability tweaks
you asked me for in LoggerFinderLoader.
I also added a couple of new tests.
No changes in the API specification.
The sandbox JDK-8046565-branch and public links have been refreshed.
best regards,
-- daniel
sandbox branch JD
Please review the latest webrev that addresses the issue raised in Sherman’s
comments below, with my comments interspersed in-line. The changes between
this webrev and the last one are in the definition and use of the
ismultiRelease() method and the introduction of a configuration lock, the
bo
Hi all,
Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8138664
Issue- ZonedDateTime parse error for any date using 'GMT0' ZoneID
Solution - Handled the GMT0 separately in the parsing method
BugId - https://bugs.openjdk.java.net/browse/JDK-8138664
webrev - http://cr.openj
> On 3 Nov 2015, at 17:21, Roger Riggs wrote:
>
> Hi Paul,
>
> Thanks for the review.
>
> The webrev is updated in place:
> http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/
>
>
> I added an @apiNote to both onExit methods:
>
> * The process may be observed to have term
Please review these changes:
bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
Background:
These changes introduce a new system property named "jdk.debug" intended to
identify the type of the build. The build system has already been
mo
On 2.11.2015 19:06, Severin Gehwolf wrote:
Hi,
Thanks Jaroslav and Daniel for the reviews! Comments inline.
On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> Hi,
>
> On 2.11.2015 16:19, Daniel Fuchs wrote:
>> Hi Severin,
>>
>> Adding serviceability-...@openjdk.java.net into the loop
Hi Paul,
Thanks for the review.
The webrev is updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/
I added an @apiNote to both onExit methods:
* The process may be observed to have terminated with {@link #isAlive}
* before the ComputableFuture is comp
On 11/03/2015 02:20 PM, Daniel Fuchs wrote:
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
I would say there is no Java caller in that case and return
Optional.empty().
No Java caller mea
Hi,
Here's a demonstration that shows the "reachability" race:
import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;
/**
* A demonstration of WeakReference initialization race
*/
public class WeakRace extends WeakReference {
static volatile boolean pause;
int valu
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
cheers,
-- daniel
On 03/11/15 13:45, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which
On 2015-11-03 14:19, Paul Sandoz wrote:
On 28 Oct 2015, at 21:01, Claes Redestad wrote:
Hi,
while investigating startup and footprint for jigsaw, I found this unrelated
oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate
file paths determined to be equal when puttin
On 03/11/2015 13:19, Paul Sandoz wrote:
:
I am not an expert in this area, but something does not feel right that you
have modified things so the the key and value for a cache entry are the same.
Why bother caching in that is the case? I am missing something obvious here?
I mentioned to Clae
> On 31 Oct 2015, at 00:41, Roger Riggs wrote:
>
> Please review and comment on 3 clarifications to ProcessHandle and Process.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/
>
> 8138566: (Process) java.lang.Process.allChildren specification clarification
> -
> On 28 Oct 2015, at 21:01, Claes Redestad wrote:
>
> Hi,
>
> while investigating startup and footprint for jigsaw, I found this unrelated
> oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate
> file paths determined to be equal when putting them into its internal cac
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is
described as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
.skip(2)
.findFirst()).orElse(Thread.currentThread().getClass());
... the .orElse is presumab
> On 2 Nov 2015, at 18:37, Lance Andersen wrote:
>
> Hi,
>
> Need a reviewer for 8136496. The CCC has been approved.
>
> The webrev can be found at
> http://cr.openjdk.java.net/~lancea/8136496/webrev.00/
>
Looks ok.
Just a minor point:
+ * @implSpec
+ * The default implementation
Here's an old bug from the Good Riddance Dept.
The TLDR; version: The java-rmi launcher is broken and irrelevant, at
the same time. And has been since JDK6 or so.
Bug: https://bugs.openjdk.java.net/browse/JDK-6512052
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-6512052-remove-java-rmi-launche
On 03/11/2015 10:29, Magnus Ihse Bursie wrote:
Here's an old bug from the Good Riddance Dept.
The TLDR; version: The java-rmi launcher is broken and irrelevant, at
the same time. And has been since JDK6 or so.
Bug: https://bugs.openjdk.java.net/browse/JDK-6512052
WebRev:
http://cr.openjdk.ja
Hi Mandy,
This is very nice work.
Comments below, mostly minor stuff.
PlatformLogger.java
(and similar comments for duplicated code in LogRecord.java)
—
542 static final StackWalker stackWalker;
Use capitals for static variable.
556 private boolean lookingForLogger
36 matches
Mail list logo
