On Feb 27, 2014, at 8:02 PM, Peter Levart peter.lev...@gmail.com wrote:
On 02/27/2014 04:06 PM, Paul Sandoz wrote:
Back then I presented an alternative solution which solves that:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018457.html
...and as can be seen
On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz he...@javaspecialists.eu
wrote:
I have never used this in the wild, but rather have moved over to the
ReentrantLock when I needed that particular functionality.
However, I do see a place for this ability. As I wrote in here:
On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko sergey.kukse...@oracle.com wrote:
Brian, Mike.
Could you explain what is the problem with the old caching?
String is immutable, BigDecimal is immutable. So we have data race at that
place, but it is safe data race. What is the problem if we
Hi Florian,
Thanks for doing this.
Do you have any more context on what RPMs/jars are using what methods of
Unsafe? such information would be useful to correlated with that on maven
central.
I think i can guess some aspects e.g.:
monitorEnter | (Ljava/lang/Object;)V
On Feb 28, 2014, at 10:11 PM, John Rose john.r.r...@oracle.com wrote:
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think
On Mar 5, 2014, at 3:04 PM, Doug Lea d...@cs.oswego.edu wrote:
A few comments on catching up with this discussion...
Same here, back from a holiday last week.
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
Built-in monitors are heavily optimized for typical
Hi,
Eye-balled the changes, nothing obvious popped out. Looks good.
It's very minor, and should not block the code going back, but occured is a
common misspelling of occurred.
Paul.
On Mar 12, 2014, at 10:24 PM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Hello,
Appreciate if
, at 2:12 PM, John Rose john.r.r...@oracle.com wrote:
I think that we've covered all the angles, and that we can remove it.
– John
On Mar 12, 2014, at 1:44 PM, Paul Sandoz paul.san...@oracle.com wrote:
Currently i cannot find any external uses of it.
On Feb 28, 2014, at 11:29 PM, Martin Buchholz marti...@google.com wrote:
Are word-size reads in ByteBuffer actually intrinsified? I could find no
evidence for that. Perhaps this is an important missing optimization for
hotspot to make?
I see DirectByteBuffer, but not garden-variety
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUnsigned.
An explosion of methods on Arrays for all types (plus to/from versions)
would
On Mar 13, 2014, at 1:57 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
On Mar 13, 2014, at 5:26 PM, Andrew Haley a...@redhat.com wrote:
A quick solution is to leverage Unsafe within a
ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
used (as Aleksey says in [1]) for put/get as well, which i presume
is likely to be much easier/quicker to
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/
It required some surgical work on tests to shove in the Arrays.asList test
case, since it is a
On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
FYI, this change isn't limited to only bytecode assembly improvements, but
also contains caching of lambda forms for setters/getter of typed arrays.
Do you mean for MethodHandles.arrayElementGetter/Setter? If
On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
You are looking at the other fix (8037210).
The correct link is [1].
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the array
setter/getter
On Mar 14, 2014, at 4:46 PM, Martin Buchholz marti...@google.com wrote:
Looks good to me.
Thanks.
I'm willing to believe for-loop over array is as efficient as fortran-style
loop
+for (E e : a) {
+action.accept(e);
+}
Yeah, i previously
On Mar 15, 2014, at 12:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 14.03.2014 17:10, schrieb Paul Sandoz:
I'm willing to believe for-loop over array is as efficient as fortran-style
loop
+for (E e : a) {
+action.accept(e);
+}
Yeah, i
...@oracle.com wrote:
On 3/17/14 7:41 PM, Paul Sandoz wrote:
On Mar 15, 2014, at 12:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 14.03.2014 17:10, schrieb Paul Sandoz:
I'm willing to believe for-loop over array is as efficient as
fortran-style loop
+for (E e
On Mar 17, 2014, at 9:57 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 17.03.2014 17:08, schrieb mark.reinh...@oracle.com:
2014/3/17 1:41 -0700, paul.san...@oracle.com:
On Mar 15, 2014, at 12:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
...
I more like the given style with less spaces:
3854
On Mar 17, 2014, at 6:21 PM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Hello,
Please review fix for adding back @SuppressWarnings tag
http://cr.openjdk.java.net/~ksrini/8037529/webrev.0/
removed inadvertently with the push for
http://cr.openjdk.java.net/~ksrini/8037221/
Hi,
Simple patch to align code with spec for stream/spliterator factory methods on
Arrays and spliterator methods on Spliterators, and make the next release of
the JCK happy:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/
After 9 it should go back to 8u20.
On Mar 24, 2014, at 1:28 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 24/03/2014 11:44, Paul Sandoz wrote:
Hi,
Simple patch to align code with spec for stream/spliterator factory methods
on Arrays and spliterator methods on Spliterators, and make the next release
of the JCK happy
I started working on a patch to remove the monitor related methods on Unsafe,
and was thinking this is gonna be easy, it kind of is, but there is some
curious code for the registration of the native methods:
On Mar 24, 2014, at 6:37 PM, Joel Borggrén-Franck joel.fra...@oracle.com
wrote:
Hi Paul,
I would guess this is because of the HSX model where we could use the same VM
with different majors of the JDK. Would that make sense?
I was wondering about too, but does that still apply to JDKs
On Mar 24, 2014, at 7:49 PM, Staffan Larsen staffan.lar...@oracle.com wrote:
We have abandoned the HSX model. From JDK 8 one version of Hotspot will be
tied to one version of the JDK. This looks like old code that has not been
cleaned up.
Thanks, yes, looks like we can clean this up and
On Mar 24, 2014, at 8:30 PM, Mike Duigou mike.dui...@oracle.com wrote:
The other issue here, and why this thread has gone on so long, is that we've
been trying to establish what the best idiom is (for 2014-) for this lazy
initialization situation so that we can reuse it with less thought
On Mar 25, 2014, at 9:34 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 24, 2014, at 7:49 PM, Staffan Larsen staffan.lar...@oracle.com wrote:
We have abandoned the HSX model. From JDK 8 one version of Hotspot will be
tied to one version of the JDK. This looks like old code that has
On Mar 25, 2014, at 2:37 PM, Staffan Larsen staffan.lar...@oracle.com wrote:
(Adding hotspot-runtime-dev since some changes are in hotspot code).
On 25 mar 2014, at 14:20, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 25, 2014, at 9:34 AM, Paul Sandoz paul.san...@oracle.com wrote
On Mar 26, 2014, at 5:21 AM, David Holmes david.hol...@oracle.com wrote:
Mike,
On 26/03/2014 6:37 AM, Mike Duigou wrote:
Hello all;
Recently HotSpot gained additional support for transactional memory,
https://bugs.openjdk.java.net/browse/JDK-8031320. This patch is a
libraries
Hi Vladimir,
This looks good. Minor stuff below.
I too prefer *_TYPE instead of Int/Float/Void etc as those are not v. friendly
for static imports.
Paul.
LambaForm:
--
private static int fixResult(int result, Name[] names) {
if (result == LAST_RESULT)
result =
On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the
array setter/getter support, definitely simplified. IIUC the mh.viewAsType
will now handle the appropriate
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Unfortunately, additional profiling doesn't work for Accessor.checkCast case.
The problem is Accessor.checkCast is called from multiple places, so type
profile is very likely to be polluted. And it
On Apr 1, 2014, at 3:57 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul, thanks for review.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/
+1
Paul.
On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
On 4/1/14 7:29 PM, Paul Sandoz wrote:
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Unfortunately, additional profiling doesn't work for Accessor.checkCast
case
On Apr 2, 2014, at 4:16 PM, Paul Sandoz paul.san...@oracle.com wrote:
Regarding redundant null check, do you have a test case so I can play with
it myself?
I will send something to you later today or tomorrow.
Still plan to send you something today :-) but later on...
See below
On Apr 4, 2014, at 1:42 AM, Mike Duigou mike.dui...@oracle.com wrote:
I could live with that change in behaviour, but this change completely
breaks the fail-fast semantics of the iterators in some cases! If you don't
update modCount until after the change is complete, the iterator may
Hi,
Reviews of two patches in the queue.
Paul.
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.02/
Looks good, though I don't claim to understand all the nuances around casts and
JVM/bytecode correctness. Minor stuff below.
InvokerByteCodeGenerator:
--
Unused method:
static
Hi,
https://github.com/cowtowncoder/java-uuid-generator
JDK's java.util.UUID has flawed implementation of compareTo(), which uses
naive comparison of 64-bit values.
Anyone familiar with the JDK UUID implementation care to comment?
Paul.
On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
The issue is that the comparison is done upon the signed most significant and
least significant long values.
At minimum UUIDs should be compared as if they were 128-bit unsigned values.
Thanks.
Beyond that, version
On Apr 8, 2014, at 1:53 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Thanks, Chris.
I have to do one more iteration:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/
I have to revert changes related to BMH::reinvokerTarget.
Removal of reinvokerTarget in generated
On Apr 8, 2014, at 9:15 PM, Mike Duigou mike.dui...@oracle.com wrote:
For the case of incorrect signed comparison is it sticking around because
there is code dependent on the current broken behaviour?
Probably even if the dependence is implicit such as expecting a particular
iteration
On Apr 8, 2014, at 4:53 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul, thanks for the feedback!
See my answers inline.
Updated webrevs:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.03/
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.02/
Both look OK.
Is
On Apr 11, 2014, at 1:24 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Hello,
This is a minor amplification of information already contained in the javadoc.
Issue:https://bugs.openjdk.java.net/browse/JDK-8035427
Patch:
On Apr 11, 2014, at 8:54 AM, Peter Levart peter.lev...@gmail.com wrote:
Hi,
Code that relies on UUIDs to have a natural order, say chronological, is
relying on being given the particular type of UUIDs that have the time
built-in. When given mixed-type or non-time-based UUIDs, such code
On Apr 11, 2014, at 4:56 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Apr 11, 2014, at 12:30 AM, Paul Sandoz paul.san...@oracle.com wrote:
Does such a non-normative change require a CCC? I think the changes could be
placed under an @apiNote tag.
Personally I would think
…
As there was no response to the message included below I am simply re-posting
it.
Thanks,
Brian
On Mar 25, 2014, at 7:19 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Mar 25, 2014, at 1:58 AM, Paul Sandoz paul.san...@oracle.com wrote:
This is another example of a stable variable
On Apr 15, 2014, at 12:54 AM, Mike Duigou mike.dui...@oracle.com wrote:
Should we proceed forward despite these understood limitations? My vote is a
very soft Yes.
I think we can proceed, things are not made any worse for the cases we care
about, and i think we can slightly improve things
Hi Otávio,
On Apr 21, 2014, at 3:06 PM, Otávio Gonçalves de Santana otavioj...@java.net
wrote:
Hello everyone, one question.
Conditions that always returns true, is 'if' necessary?
I can imagine it is a left over from hacking in the fast path. IMHO better to
remove the if and comment the
On Apr 22, 2014, at 3:18 AM, Wang Weijun weijun.w...@oracle.com wrote:
If I copy a file to another I can
try (src = open(ifile); dest = open(ofile)) {
while (!src.EOF) dest.write(src.read());
}
but what if there are multiple destinations? Is there something like
Not that i am
Hi Otávio,
These look like good finds. I bet there are lots more of them.
IntelliJ reports 284 possible uses in src/share/classes (see the
'StringBuffer' may be 'StringBuilder' migration aid), but i have not verified
all those. Perhaps we should do this more systematically over all the Java
On Apr 22, 2014, at 2:48 PM, David M. Lloyd david.ll...@redhat.com wrote:
If the methods were final, AFAICT it'd be more like this:
public final ByteBuffer position(int newPosition) {
// iirc super upcall is already bytecoded as invokespecial
invokespecial
Hi Frank,
On Apr 22, 2014, at 12:10 PM, Frank van Heeswijk fvheesw...@outlook.com wrote:
Hello,
First of all, this is the first time I am sending a mail to any java mailing
list,
Welcome!
so please correct me if I did something wrong.
I am a regular visitor and answered on
On Apr 23, 2014, at 1:48 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Hello,
Issue:https://bugs.openjdk.java.net/browse/JDK-8026236
Patch:http://cr.openjdk.java.net/~bpb/8026236/webrev.00/
This test provides a rudimentary verification of isProbablePrime() by:
Hi Peter,
IMHO such security manager usage by the test is v. fragile and we should try
and find a safer alternative if possible.
However, there may also be an issue with lambda form code. (About a month ago i
too was looking, internally, at this kind of issue and thought there was a
On Apr 25, 2014, at 12:04 PM, Peter Levart peter.lev...@gmail.com wrote:
This is a ping for any Reviewer and also a question for Vladimir.
Hello Vladimir,
What do you think about the classloader issue in the resolving of classes in
MemberName.getMethodType() described below?
I looked
On Apr 23, 2014, at 11:06 AM, Peter Levart peter.lev...@gmail.com wrote:
Hi,
I propose a patch for:
https://bugs.openjdk.java.net/browse/JDK-8040892
+1, nice use of putIfAbsent. Just double checking, did you run the stream unit
tests?
I think key step was to separate map merge and
Hi Otávio,
Is there anyway you can experiment with publishing a webrev to dropbox or
github, preferably so that it is browsable, otherwise the zip?
Unfortunately the patches are hard to review, especially in response to reviews
where code is updated.
I realize until you have an openjdk
On Apr 27, 2014, at 2:22 PM, Claes Redestad claes.redes...@oracle.com wrote:
Possibly a few bytes in static class footprint, sure. Maybe this is something
javac should optimize (javap on some trivial examples suggests this doesn't
happen) rather than trying to root out all suboptimal cases,
On Apr 25, 2014, at 7:31 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi Paul,
To make any sense of null return from the mergeFunction, which could mean
that an entry with that key is absent from resulting map, such Collector
would have to keep some more state - the collecting map (which
On Apr 28, 2014, at 12:30 PM, Peter Levart peter.lev...@gmail.com wrote:
You could use the null return from Map.merge() as a signal to throw NPE, but
this is only 100% safe in to*Map() methods that don't take a mapSupplier.
Collections.toConcurrentMap(, SupplierM mapSupplier) could be
On Apr 28, 2014, at 7:53 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Firstly, I was informed that there are not supposed to be binary files in the
jdk9/jdk/test tree. My webrev listed in the above post includes one such
file, a GZIPped text file of prime numbers. Apparently this
On May 2, 2014, at 9:22 PM, Mike Duigou mike.dui...@oracle.com wrote:
Thanks Martin and Martin;
I have corrected this along with some additional documentation updates:
http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/
+1.
Paul.
On May 3, 2014, at 6:55 PM, Joe Darcy joe.da...@oracle.com wrote:
Hi Brian,
I think the parsePrimes method would be better with a different name since no
parsing is occurring anymore.
Yes, and there is no need for the try block.
(The use of BitSet.stream() also reminds me we can
Hi,
https://bugs.openjdk.java.net/browse/JDK-8042355
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/
This is an optimization to ensure that sorted() in sequential pipelines does
not aggressively push all sorted elements downstream if the pipeline is known
On May 5, 2014, at 11:17 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Joe / Paul,
Thanks for the comments. This an aggregate response to your two messages. An
updated version of the patch is here:
http://cr.openjdk.java.net/~bpb/8026236/webrev.03/
I believe that it
On May 6, 2014, at 11:30 AM, Florian Weimer fwei...@redhat.com wrote:
On 05/05/2014 03:16 PM, Paul Sandoz wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8042355
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/
This is an optimization to ensure
Hi,
This is a request for review of Otavio's patch replacing StringBuffer with
StringBuilder within OpenJDK. (I also need to review it.)
It covers many areas and i have grouped the patches into such areas to aid
reviewing. When commenting please including core-libs.
Jtreg tests showed no
On May 12, 2014, at 12:42 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas to aid
reviewing. When commenting please including core-libs.
The groupings are a bit odd
Yeah, definitely
On Apr 26, 2014, at 12:56 PM, Otávio Gonçalves de Santana otavioj...@java.net
wrote:
When a String has length just one, could be replaced by equivalent
character literals, gaining some performance enhancement.
I found 107 changes.
This looks good to me, just one small issue:
---
On May 12, 2014, at 1:00 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
src/share/classes/sun/misc/UUDecoder.java
126 StringBuilder x = new StringBuilder();
Is only filled, but doesn't seem to be used anyhow.
Maybe just delete it?
Thanks, i will take a look at this and your
On May 12, 2014, at 4:07 PM, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi Paul,
I looked at -management and the changes there look good.
There is just some two spaces vs four space formatting in
On May 13, 2014, at 11:34 AM, Seán Coffey sean.cof...@oracle.com wrote:
thanks for the comments. I hit a build issue when introducing some lambda
syntax to the corba repo : https://bugs.openjdk.java.net/browse/JDK-8042932
That's fixed now and I can continue with the corba push. I've
On May 13, 2014, at 1:10 PM, Sergey Bylokhov sergey.bylok...@oracle.com wrote:
Hi, Paul.
adding 2d-dev@
media: sound/awt/swing part looks fine.
Thanks.
Note that this part of the fix should be pushed to client forest.
Which classes exactly from here:
HI Phil,
Thanks for looking at this.
On May 13, 2014, at 11:15 PM, Phil Race philip.r...@oracle.com wrote:
Paul,
I don't see why you changed the variable names in some cases.
Note it's not me :-) I am, mostly, the proxy.
See here where one change is only one line since you left it alone
On May 14, 2014, at 12:47 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Tobias, I agree with your evaluation.
V. tricky one to track down!
From @Stable:
* It is (currently) undefined what happens if a field annotated as stable
* is given a third value. In practice, if the JVM
On May 14, 2014, at 8:01 PM, Joel Borggren-Franck joel.fra...@oracle.com
wrote:
Hi,
Here is a fix for: https://bugs.openjdk.java.net/browse/JDK-8038994
In short, getAnnotatedFoo.getType() is supposed to return the same Type
as getGenericFoo(). This wasn't the case for a type variable
On May 16, 2014, at 10:53 AM, Joel Borggren-Franck joel.fra...@oracle.com
wrote:
On 2014-05-15, Paul Sandoz wrote:
The non test code looks good to me:
Not totally sure about the test approach:
48 @Test(dataProvider = data)
49 public void testClass(Class? c, String method
On May 14, 2014, at 11:05 AM, Alan Bateman alan.bate...@oracle.com wrote:
:
This code is under src/share/classes, so it's not clear to me what classes i
can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is
there a list online somewhere?
Out of all the classes here:
On May 16, 2014, at 5:05 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 05/16/2014 01:56 PM, Tobias Hartmann wrote:
Hi,
thanks to everyone for the feedback.
Is it sufficient then to use synchronized (lambdaForms) { ... } in
setCachedLambdaForm(..) and a normal read in
On May 16, 2014, at 8:33 PM, Phil Race philip.r...@oracle.com wrote:
On 5/16/2014 5:13 AM, Paul Sandoz wrote:
On May 14, 2014, at 11:05 AM, Alan Bateman alan.bate...@oracle.com wrote:
:
This code is under src/share/classes, so it's not clear to me what classes
i can modify and push
On May 19, 2014, at 6:18 PM, Phil Race philip.r...@oracle.com wrote:
On 5/19/2014 12:50 AM, Alan Bateman wrote:
On 19/05/2014 07:53, Paul Sandoz wrote:
If i don't have permission to push to the client repo (which might be
likely) i will need to hand over the patch to yourself or Sergey
On May 22, 2014, at 1:34 AM, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
http://cr.openjdk.java.net/~kvn/8035974/webrev
https://bugs.openjdk.java.net/browse/JDK-8035974
Contributed by James Cheng and modified by me.
Looks good to me.
Paul.
To use intrinsics to accelerate SHA
Hi,
I am wondering if it may be more reliable to attempt creation of a new file in
the read only directory rather than checking for the root user name?
Paul.
On May 27, 2014, at 3:19 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
https://bugs.openjdk.java.net/browse/JDK-8035186
On May 27, 2014, at 3:53 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
What you suggest is much cleaner. Thanks!
Updated version:
http://cr.openjdk.java.net/~vlivanov/8035186/webrev.01/
Don't you need to trap the exception? e.g.:
try {
Path test =
On May 27, 2014, at 6:16 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Good catch!
One more iteration:
http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/
Looks good.
Some minor points, no need for another review round either way:
- don't need the nested try blocks in
On May 28, 2014, at 1:20 AM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Hello,
Please review the following webrev which updates internal ASM to v5.0.3, the
individual bug fixes are
listed in the JBS issue for reference,
On Jun 3, 2014, at 1:48 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote:
Hi
Can I get a review for this small fix for
https://bugs.openjdk.java.net/browse/JDK-8039916
Webrev here: http://cr.openjdk.java.net/~jfranck/8039916/webrev.01/
Since this is the second issue like this
On Jun 4, 2014, at 12:25 PM, Paul Sandoz paul.san...@oracle.com wrote:
You might consider the following a more streamy way, not tested! up to you :-)
private static Object[][] provider() {
Stream? extends Executable s = filterData(Test.class.getMethods(),
null);
s
On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
https://bugs.openjdk.java.net/browse/JDK-8032400
http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/
Consider the following hierarchy:
class T1{int m() { return 1; }}
class T2
On Jun 6, 2014, at 1:17 AM, John Rose john.r.r...@oracle.com wrote:
Reviewed.
This is not a requirement, but I would prefer (in general) to see less test
logic in ASM-generated bytecode and more in Java. I am guessing that the
invokeExact call could have been replaced by a simple
, nor
an explicit white-list of Java package names (external yes, internal no).
On May 20, 2014, at 7:45 AM, Paul Sandoz paul.san...@oracle.com wrote:
On May 19, 2014, at 6:18 PM, Phil Race philip.r...@oracle.com wrote:
On 5/19/2014 12:50 AM, Alan Bateman wrote:
On 19/05/2014 07:53, Paul
On Jun 24, 2014, at 2:42 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This changeset corrects a reported problem with the lists returned by
Collections.checkedList(). Since Java 8 the replaceAll() method on checked
lists has erroneously allowed the operator providing
On Jun 17, 2014, at 6:52 PM, Joel Borggrén-Franck joel.fra...@oracle.com
wrote:
Hi,
Can I get a review for this fix and javadoc clarification for
https://bugs.openjdk.java.net/browse/JDK-8044629
The problem is with potentially annotated receiver parameters, they only
exist for inner
On Jun 23, 2014, at 10:23 PM, Mandy Chung mandy.ch...@oracle.com wrote:
The loadLibrary implementation is missing to wrap the call
to File.getCanonicalPath method with doPrivileged block.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
Looks ok to me.
Paul.
On Jun 24, 2014, at 8:25 PM, Mike Duigou mike.dui...@oracle.com wrote:
On Jun 24 2014, at 01:18 , Paul Sandoz paul.san...@oracle.com wrote:
Additionally the javadoc is updated to inform users that a
ClassCastException may result if the proposed replacement is unacceptable.
No users
On Jun 19, 2014, at 7:39 PM, Claes Redestad claes.redes...@oracle.com wrote:
Hi,
an updated webrev with reworked, public methods is available here:
http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
Reviews are yet again appreciated!
I think if (s == null) or
On Jun 26, 2014, at 3:29 PM, Andrej Golovnin andrej.golov...@gmail.com wrote:
Hi Paul,
Seems fine to me (pending a full test run).
Just a syntax niggle in the following, too many brackets:
+++ new/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
2014-06-14
On Jun 26, 2014, at 6:53 PM, Claes Redestad claes.redes...@oracle.com wrote:
On 06/25/2014 06:43 PM, Paul Sandoz wrote:
On Jun 19, 2014, at 7:39 PM, Claes Redestad claes.redes...@oracle.com
wrote:
Hi,
an updated webrev with reworked, public methods is available here:
http
On Jun 27, 2014, at 9:06 AM, Kasper Nielsen kaspe...@gmail.com wrote:
Hi,
I'm trying to understand how the Spliterator.characteristics are maintained
across stream operations and I'm a bit confused. Maybe someone here can
clear it up for me
Internally in the stream pipeline we keep track
On Jun 27, 2014, at 1:58 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This changeset corrects an issue with the Collections.checkedQueue() utility
method added in Java 8. The wrapper implementation incorrectly calls add() on
the wrapped queue rather than offer().
I
101 - 200 of 2479 matches
Mail list logo
