Daniel,
I have added more tests and fixed a few issues
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.02/
I also created a test case similar to yours.
This patch applies on top of:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.02/
for JDK-8156680: jdeps im
Hi Iris,
is there a way to avoid to use regex when parsing the version ?
java.lang.Runtime.Version is used during the boot process, so now every Java
programs loads a bunch of classes related to java.util.regex even if they do
not use any regex or use another regex engine (like Nashorn or JRuby)
Hi.
Reviving this work from a few months back.
Please review the following changes to move jdk.Version to
jdk.lang.Runtime.Version.
Bug
8144062: Move jdk.Version to java.lang.Runtime.Version
https://bugs.openjdk.java.net/browse/JDK-8144062
webrev
http://cr.openjdk.java.net/~iris/
On 5/13/16 1:24 PM, Alan Bateman wrote:
On 13/05/2016 19:49, Xueming Shen wrote:
something like this?
http://cr.openjdk.java.net/~sherman/8147588/webrev/
Along these lines, yes.
Would it be cleaner if ZipFile_openAndDelete were rename to
ZipFile_open and used ZFILE_Open in libzip instead o
On 13/05/2016 19:49, Xueming Shen wrote:
something like this?
http://cr.openjdk.java.net/~sherman/8147588/webrev/
Along these lines, yes.
Would it be cleaner if ZipFile_openAndDelete were rename to ZipFile_open
and used ZFILE_Open in libzip instead of winFileHandleOpen in libjava?
Also giv
On 13 May 2016, at 19:04, Brian Burkhalter wrote:
> Correction: wrong link provided below:
>
> http://cr.openjdk.java.net/~bpb/8130679/webrev.02/
Looks good to me Brian.
-Chris.
> Sorry for the confusion.
>
> Brian
>
> On May 13, 2016, at 10:42 AM, Brian Burkhalter
> wrote:
>
>> I have
Hi Roger,
On May 13, 2016, at 11:44 AM, Roger Riggs wrote:
> Looks fine. Thanks for digging through all the cases.
Thanks & you’re welcome.
> The @see indenting is ok, but not really a thing. White space is should not
> be used/relied upon for formatting.
The public javadoc
http://downloa
On 5/13/16 3:27 AM, Alan Bateman wrote:
On 12/05/2016 20:16, Xueming Shen wrote:
Hi,
Please help review the proposed change for #8147588
issue: https://bugs.openjdk.java.net/browse/JDK-8147588
webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev
This is a regression on Windows platform
Hi Brian,
Looks fine. Thanks for digging through all the cases.
The @see indenting is ok, but not really a thing. White space is should
not be used/relied upon for formatting.
Roger
On 5/13/2016 2:34 PM, Brian Burkhalter wrote:
Hi Pavel,
On May 13, 2016, at 11:25 AM, Pavel Rappo wrote:
Hi Pavel,
On May 13, 2016, at 11:25 AM, Pavel Rappo wrote:
> This looks good!
Good good! Thanks!
>
> Could you please fix this tiny typo in-place?
>
> 145 * @throws IOException if the pipe is
> 146 *
Brian,
This looks good!
Could you please fix this tiny typo in-place?
145 * @throws IOException if the pipe is
146 * broken},
Correction: wrong link provided below:
http://cr.openjdk.java.net/~bpb/8130679/webrev.02/
Sorry for the confusion.
Brian
On May 13, 2016, at 10:42 AM, Brian Burkhalter
wrote:
> I have a third version of the patch here:
>
> http://cr.openjdk.java.net/~bpb/8130679/webrev.00/
>
> This one I b
Hello,
I have a third version of the patch here:
http://cr.openjdk.java.net/~bpb/8130679/webrev.00/
This one I believe addresses all the inconsistencies including the one in
https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight
weakening of the specification of the Writer
> On May 12, 2016, at 5:58 PM, David Holmes wrote:
>>
>> With all of the inherited methods @hidden, it looks like that section
>> is left out altogether.
>
> Okay, so I have to say @hidden seems to me to be seriously flawed! If a class
> has a method that can be called then IMHO that has to be
> On May 12, 2016, at 4:55 PM, Brent Christian
> wrote:
>
> Update to the test, and additional comments:
>
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/
>
+1
Mandy
Good idea.
Mandy
> On May 13, 2016, at 12:10 AM, Peter Levart wrote:
>
> Hi Brent,
>
>
> This looks good. It might also be a good idea to add a test that checks this
> new implementation detail (the unsynchronized get) that new code will become
> dependent upon, for example:
>
>
> /*
> *
Good point, Remi. I agree that it's redundant.
Best regards,
Vladimir Ivanov
On 5/13/16 4:51 PM, Remi Forax wrote:
Also instead of
MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V",
"(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/
Also instead of
MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V",
"(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;",
null, new String[] { "java/lang/Throwable" });
because the code is never read by a
MethodHandle vamh = prepareForInvoker(MH_checkCallerClass);
Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc});
+ assert Boolean.TRUE.equals(ok) : ok;
What I meant is to convert the whole test (inside try-catch block) into
an assert.
+UNSAFE.ensureCla
Note that there is a possible initialization circularity introduced by
this patch, which I think is harmless because:
- ThreadLocalRandom has just recently been enhanced to cope with such
situations - CHM needs ThreadLocalRandom in put() for example, when new
entry is being inserted, TLR invok
On 12/05/2016 20:16, Xueming Shen wrote:
Hi,
Please help review the proposed change for #8147588
issue: https://bugs.openjdk.java.net/browse/JDK-8147588
webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev
This is a regression on Windows platform triggered by the change for
https://bugs.
Hi,
One addition, maybe add to issue:
If this was added, jdk.dynalink module could use it, too - this was mentioned
by Attila already:
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
Uwe
-
Uwe Schindler
uschin
Hi,
OK, thanks for creating an issue!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Remi Forax [mailto:fo...@univ-mlv.fr]
> Sent: Friday, May 13, 2016 10:37 AM
> To: Uwe Sch
> On 13 May 2016, at 10:56, shilpi.rast...@oracle.com wrote:
>
> Thanks Paul!
>
> Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/
>
+1
Paul.
Thanks Paul!
Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/
Regards,
Shilpi
On 5/13/2016 2:09 PM, Paul Sandoz wrote:
assert Boolean.TRUE.equals(ok) : ok;
> On 13 May 2016, at 09:13, shilpi.rast...@oracle.com wrote:
>
> Thank you Vladimir for comments.
>
> Please review updated webrev
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/
>
Just one minor comment (last one i promise!):
1140 MethodHandle vamh = prepareForInvo
Hi Uwe,
I was planning to add a bug for this feature but it seems that Michael was
faster than me,
https://bugs.openjdk.java.net/browse/JDK-8156915
regards,
Rémi
- Mail original -
> De: "Uwe Schindler"
> À: "Michael Haupt" , "Core-Libs-Dev"
>
> Envoyé: Jeudi 12 Mai 2016 14:34:34
> O
Thank you Vladimir for comments.
Please review updated webrev
http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/
Regards,
Shilpi
On 5/12/2016 6:12 PM, Vladimir Ivanov wrote:
rankly speaking, I'd prefer [2] to be co
Hi Brent,
This looks good. It might also be a good idea to add a test that checks
this new implementation detail (the unsynchronized get) that new code
will become dependent upon, for example:
/*
* @test
* @bug 8029891
* @summary Test that the Properties.get() method does not synchronize
29 matches
Mail list logo