Hi Sherman,
Not a full review, I browsed the code very quickly and noticed one thing:
JrtFileSystem
—
167 private static final Set supportedFileAttributeViews
168 = Collections.unmodifiableSet(
169 new HashSet(Arrays.asList("basic", "jrt")));
Use Set.of.
> On 13 Apr 2016, at 16:39, Michael Haupt wrote:
>
> Dear all,
>
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150824
> Webrev: http://cr.openjdk.java.net/~mhaupt/8150824/webrev.00/
>
> The actual bug was fixed with the push for 8150829; this change merely
> co
jrt-fs.jar code has to run on jdk8 as well. Cannot use jdk9 API.
-Sundar
On 4/14/2016 2:23 PM, Paul Sandoz wrote:
> Hi Sherman,
>
> Not a full review, I browsed the code very quickly and noticed one thing:
>
> JrtFileSystem
> —
>
> 167 private static final Set supportedFileAttributeViews
>
On 14/04/2016 09:53, Paul Sandoz wrote:
Hi Sherman,
Not a full review, I browsed the code very quickly and noticed one thing:
JrtFileSystem
—
167 private static final Set supportedFileAttributeViews
168 = Collections.unmodifiableSet(
169 new HashSet(
> On 14 Apr 2016, at 11:09, Sundararajan Athijegannathan
> wrote:
>
> jrt-fs.jar code has to run on jdk8 as well. Cannot use jdk9 API.
>
Ah, ok.
Thanks,
Paul.
Looks good
-Sundar
On 4/14/2016 12:25 AM, Xueming Shen wrote:
> Hi,
>
> Please hep review the cleanup changes for jrtfs implementation.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8147460
> webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev
>
> Simple benchmark [1] has been run bo
On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote:
Hi,
On 2016/04/14 9:34, David Holmes wrote:
Hi,
On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote:
Hi David,
Thanks for your comment.
I exported new JVM function to set native thread name, and JLI uses it
in new webrev.
First the launcher belongs
Hi Stuart,
you are not the first one to try to change the integers defined in
org.objectweb.asm.Opcodes, those values are compared by ref (not by value)
inside ASM.
You're patch will change the behavior of any Interpreters that also use some
Integers created by Integer.valueOf() because valueOf
That is an interesting question which I haven't had time to check - sorry. If
the main thread is considered a JNI-attached thread then my suggestion wont
work. If it isn't then my suggestion should work (but it means we have an
inconsistency in our treatment of JNI-attached threads :( )
I ran
Hi Stuart,
Outside of the comments from Remi regarding ASM, the other changes look fine to
me and the wordsmithing looks good.
I assume we are going to want to go back and add the JDK release of
deprecation for all methods. If so, I will get to the JDBC ones shortly.
Best
Lance
> On Apr 13
Hi,
Comments:
jvm.h: The function names are too similar but perform different functions:
-JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName
- The first function applies to the current thread, the second one a
specific java thread.
It would seem useful for there to be a comment somewhere
Hi Paul,
I wanted to try using VarHandles for code internal to JDK but there's a
problem with MethodHandles.lookup(). It doesn't allow the caller class
loaded by the bootstrap class loader and located in either java.* or
sun.* (but not sun.invoke.*) packages:
private static void che
Hi Peter,
You found that annoying restriction :-) at this point i think this is mostly
redundant.
This is something i planned to update and limit the restriction to code within
j.l.invoke and sun.invoke packages.
I'll follow up with a patch soon to unblock, but feel free to beat me to it if
y
Hi Stuart,
in previous versions of Java, escape analysis did not seem to work
particularly well with Integer.valueOf(int) values, since the objects of
course could come from the Integer Cache. Thus if the Integer object
did not escape from your method, it could get eliminated entirely. Not
On 14/04/2016 02:50, Stuart Marks wrote:
Hi all,
Please review this first round of deprecation changes for the
java.lang package. This changeset includes the following:
- a set of APIs being newly deprecated
- a set of already-deprecated APIs that are "upgraded" to
forRemoval=true
- ad
Roger,
Thanks for your comment!
David,
I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM
function this way.
I tried to call Thread#setName() after initializing VM (before calling main
method),
I could set native thread name.
However, DestroyJavaVM() calls Attach
Hi,
Looks good. Minor comments.
CachedRowSetImpl
—
1966 return ((Float.valueOf(value.toString())).floatValue());
Use Float.parseFloat ?
2010 return
((Double.valueOf(value.toString().trim())).doubleValue());
Use Double.parseDouble ?
ExpressionExecuter
—
86
Mandy,
The webrev has been updated in-place
http://cr.openjdk.java.net/~chegar/8137058/
http://cr.openjdk.java.net/~chegar/8137058/jdk_incremental.diffs
All 'core', 'pit', and 'hotspot' testsets have been successfully run on
Mac, Linux, Windows, and Solaris.
On 13 Apr 2016, at 18:43, Mandy C
I've been tempted by the dark side, when a class needs a value AND a
lock (or an "identity"). Instead of doing
final String val = "foo";
final Object lock = new Object();
one can "optimize" this ("why can't we have both?") to
final String valAndLock = new String("foo");
and there are surely fo
Or, better, don’t do that in ASM, and instead use .equals()?
> On Apr 14, 2016, at 9:21 AM, Remi Forax wrote:
>
> Hi Stuart,
> you are not the first one to try to change the integers defined in
> org.objectweb.asm.Opcodes, those values are compared by ref (not by value)
> inside ASM.
> You'r
[re-post, including jigsaw list]
Hi,
Please hep review the cleanup changes for jrtfs implementation.
issue: https://bugs.openjdk.java.net/browse/JDK-8147460
webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev
Simple benchmark [1] has been run both on jimage and the "exploded modules"
d
+1
> On Apr 14, 2016, at 2:47 PM, Xueming Shen wrote:
>
>
> [re-post, including jigsaw list]
>
> Hi,
>
> Please hep review the cleanup changes for jrtfs implementation.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8147460
> webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev
>
> On Apr 14, 2016, at 10:38 AM, Chris Hegarty wrote:
>
> Mandy,
>
> The webrev has been updated in-place
> http://cr.openjdk.java.net/~chegar/8137058/
> http://cr.openjdk.java.net/~chegar/8137058/jdk_incremental.diffs
>
Looks good. Thanks for making the change.
> All 'core', 'pit', and 'h
Hi Alan,
Adds the missing name in the launchModeNames array
purely for display/debugging purposes.
Please review:
http://cr.openjdk.java.net/~ksrini/8154212/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8154212
Thanks
Kumar
PS: running jprt tests in parallel.
On 14/04/2016 19:09, Kumar Srinivasan wrote:
Hi Alan,
Adds the missing name in the launchModeNames array
purely for display/debugging purposes.
Please review:
http://cr.openjdk.java.net/~ksrini/8154212/webrev.00/
Sorry, I missed that when we changed the launcher. The patch and adding
test c
+1, looks fine to me also.
Roger
On 4/13/2016 6:46 AM, Thomas Stüfe wrote:
Thanks Dmitry!
On Wed, Apr 13, 2016 at 12:00 PM, Dmitry Samersoff
mailto:dmitry.samers...@oracle.com>> wrote:
Thomas,
Looks good for me!
-Dmitry
On 2016-04-13 12:12, Thomas Stüfe wrote:
> Hi
The Analyzer/Interpreter API is public so using equals instead of == will
likely summon some strange bugs.
It will also have an impact in term of performance because currently there is
no virtual call in the part of the algo that does the analysis.
cheers,
Rémi
Le 14 avril 2016 19:13:42 CE
On 13/04/2016 19:55, Xueming Shen wrote:
Hi,
Please hep review the cleanup changes for jrtfs implementation.
I'm skimmed through the changes and it looks very good.
My only concern is that we might have not enough tests for jrtfs to
exercise it completely. I just checked the coverage it is
Sure, there is some inconvenience. But neither of these reasons seem to rise
to the level of "good reasons not to fix it".
Depending on the identity of boxes is problematic and will surely get worse in
the future. Best to get clean now!
Sent from my iPhone
> On Apr 14, 2016, at 2:17 PM, Ré
On 04/14/2016 11:57 AM, Alan Bateman wrote:
On 13/04/2016 19:55, Xueming Shen wrote:
Hi,
Please hep review the cleanup changes for jrtfs implementation.
I'm skimmed through the changes and it looks very good.
My only concern is that we might have not enough tests for jrtfs to exercise it
On 14/04/2016 20:07, Xueming Shen wrote:
:
There is a test that passing a null filter into
Files.newDirectoryStream(path, filter)
and then FileSystemProvider.newDirectoryStream(...), to mean "no
filter". My reading
of the spec suggests it should get a NPE. (to use the
nweDirectoryStream(dir
Thanks!
I would avoid ever using an empty environment; too much chance for
trouble; I vaguely recall windows being unhappy without SystemRoot,
for example. So I would always inherit the current environment (but
maybe that's what doExec does?!)
+final Map envMap = new HashMap<>();
On Thu
On 4/14/16 6:21 AM, Remi Forax wrote:
you are not the first one to try to change the integers defined in
org.objectweb.asm.Opcodes, those values are compared by ref (not by value)
inside ASM.
You're patch will change the behavior of any Interpreters that also use some
Integers created by Integ
On 4/14/16 6:49 AM, Lance Andersen wrote:
Outside of the comments from Remi regarding ASM, the other changes look fine to
me and the wordsmithing looks good.
Hi Lance, thanks for the looking this over.
I assume we are going to want to go back and add the JDK release of deprecation
for all m
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work particularly
well with Integer.valueOf(int) values, since the objects of course could come
from the Integer Cache. Thus if the Integer object did not escape from your
method, it cou
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work
particularly
well with Integer.valueOf(int) values, since the objects of course
could come
from the Integer Cache. Thus if the Integer object did not escape
from your
method, it coul
On 4/14/16 8:30 AM, Paul Sandoz wrote:
CachedRowSetImpl
—
1966 return ((Float.valueOf(value.toString())).floatValue());
Use Float.parseFloat ?
2010 return
((Double.valueOf(value.toString().trim())).doubleValue());
Use Double.parseDouble ?
I'm mostly reluctant to
On 4/14/16 10:10 AM, Martin Buchholz wrote:
I've been tempted by the dark side, when a class needs a value AND a
lock (or an "identity"). Instead of doing
final String val = "foo";
final Object lock = new Object();
one can "optimize" this ("why can't we have both?") to
final String valAndLock
On 04/14/2016 11:57 AM, Alan Bateman wrote:
On 13/04/2016 19:55, Xueming Shen wrote:
Hi,
Please hep review the cleanup changes for jrtfs implementation.
I'm skimmed through the changes and it looks very good.
My only concern is that we might have not enough tests for jrtfs to exercise it
Hello,
In response to the review comments from Dmitry and Brian, I've prepared
another iteration of the webrev:
http://cr.openjdk.java.net/~darcy/4851642.1/
Summary of the changes:
* Renamed the method to "fma" to follow the precedent of the C library.
* Added API note citing IEEE 754 op
Hi Joe,
This all looks good aside from the “@code fusedMac” in the javadoc of which I
believe you are aware.
Brian
On Apr 14, 2016, at 5:14 PM, joe darcy wrote:
> In response to the review comments from Dmitry and Brian, I've prepared
> another iteration of the webrev:
>
>http://cr.open
Hi Brian,
On 4/14/2016 5:55 PM, Brian Burkhalter wrote:
Hi Joe,
This all looks good aside from the “@code fusedMac” in the javadoc of
which I believe you are aware.
Doh! s/fusedMac/fma in my working copy.
Thanks for the review,
-Joe
Hi Joe,
It looks good except a guard expression in the line Math:1550
(tmp == 0.0 && a == 0.0 || b == 0.0)
Variables a and b occur asymmetrically in this expression.
A symmetrical expression would be either
(a == 0.0 || b == 0.0)
or
(product.signum() == 0)
On Fri, Apr 15, 2016 at 3:14 AM, joe dar
On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote:
Roger,
Thanks for your comment!
David,
I'll wait to see what Kumar thinks about this. I don't like exposing
a new JVM function this way.
I tried to call Thread#setName() after initializing VM (before calling
main method),
I could set native th
Hi Dmitry,
On 4/14/2016 7:43 PM, Dmitry Nadezhin wrote:
Hi Joe,
It looks good except a guard expression in the line Math:1550
(tmp == 0.0 && a == 0.0 || b == 0.0)
Variables a and b occur asymmetrically in this expression.
A symmetrical expression would be either
(a == 0.0 || b == 0.0)
or
(produ
Vladimir Ivanov wrote:
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work
particularly
well with Integer.valueOf(int) values, since the objects of course
could come
from the Integer Cache. Thus if the Integer object did not escape
f
Does anyone here know the answer?
It will be quite useful for me if I am either authoring an internal class or
using it when implementing a public API.
Thanks
Max
> Begin forwarded message:
>
> From: Wang Weijun
> Subject: How do I import a sun.* class in jshell
> Date: April 13, 2016 at 5:22
47 matches
Mail list logo
