Volker,
I’ve look at the following files:
src/share/native/sun/management/DiagnosticCommandImpl.c:
nit: “legel” - “legal” (two times)
In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you
allow dcmd_info_array to become NULL, then
On 15/01/2014 06:24, David Holmes wrote:
I'm not a fan of runtime checks of this kind though if it is only a
very samll number of values it might be okay.
Another option would be to make those classes into templates as done
with Version.java.template and substitute the right values at build
On Jan 14, 2014, at 8:56 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Please see the updated webrev
http://cr.openjdk.java.net/~bpb/8030814/webrev.3/.
Hopefully my verbose description of the very clever overflow test is accurate
and understandable. Also, I cleaned up the
On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman alan.bate...@oracle.comwrote:
On 15/01/2014 06:24, David Holmes wrote:
I'm not a fan of runtime checks of this kind though if it is only a very
samll number of values it might be okay.
Another option would be to make those classes into
Hi Sherman,
Thanks for comments, here are some answers:
the answer to (1)-(3) is that i do whatever the
JarOutputStream/ZipOutputStream
of the current JDK does and for a reason - there was a request from
couple of customers
to make native unpack200 results binary identical to the results
Sherman et all,
self-correction regarding the flags, i misread the specification so
flags are: always support UTF-8 file encoding (bit 11) and using EOS
marker for the compressed files(bit 4).
/Alex
On 1/15/14 18:26, Alexander Zuev wrote:
Hi Sherman,
Thanks for comments, here are some
On 1/15/14 18:34, Alexander Zuev wrote:
Sherman et all,
self-correction regarding the flags, i misread the specification so
flags are: always support UTF-8 file encoding (bit 11) and using EOS
marker for the compressed files(bit 4).
Damn my fast fingers - not bit 4, bit 3 and it tells we are
Kumar,
thanks for your findings. See my comments inline.
On 1/15/14 2:10, Kumar Srinivasan wrote:
Hi Alex,
zip.cpp: (nit) I would keep the hex values to be in upper case just
like the others for
consistency, not a big deal.
Fixed.
typo: + // Zip64 END
Hello,
the new webrev with all the typos and comments fixed can be found at
http://cr.openjdk.java.net/~kizune/8029646/webrev.01/
/Alex
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm
when invoking a method from Object declared in an interface.
The problem is the following:
(1)
On 2014-01-15, at 10:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
The fix is targeted for 8. Will be also integrated into 9.
Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist,
nashorn, jruby.
Vladimir,
Did you test also on defmeth, or has that been
Looks good to me
-Sundar
On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce incorrect bytecode for a
LambdaForm when invoking a method from
Given the identified items are changed accordingly is this approved?
Thanks,
Brian
- Original Message -
From: joe.da...@oracle.com
To: brian.burkhal...@oracle.com
Cc: core-libs-dev@openjdk.java.net
Sent: Tuesday, January 14, 2014 7:28:11 PM GMT -08:00 US/Canada Pacific
Subject: Re: JDK
David, thanks for looking at the fix.
Good suggestion. Just ran tests on default methods - all pass.
Best regards,
Vladimir Ivanov
On 1/15/14 7:44 PM, David Chase wrote:
On 2014-01-15, at 10:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
The fix is targeted for 8. Will be also
Sundar, thank you.
Best regards,
Vladimir Ivanov
On 1/15/14 7:48 PM, A. Sundararajan wrote:
Looks good to me
-Sundar
On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
Hi Staffan,
thanks for the review. Please find my comments inline:
On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen
staffan.lar...@oracle.comwrote:
Volker,
I’ve look at the following files:
src/share/native/sun/management/DiagnosticCommandImpl.c:
nit: “legel” - “legal” (two times)
In
Hi Alan,
thanks for the suggestion. That's fine for me. I've copied the empty SCTP
stubs from the macosx to the aix directory as well and updated the make
file accordingly (in the patch for 8031581: PPC64: Addons and fixes for
AIX to pass the jdk regression tests).
Therefore, the changes to the
Yes :-)
-Joe
On 01/15/2014 08:04 AM, Brian Burkhalter wrote:
Given the identified items are changed accordingly is this approved?
Thanks,
Brian
- Original Message -
From: joe.da...@oracle.com
To: brian.burkhal...@oracle.com
Cc: core-libs-dev@openjdk.java.net
Sent: Tuesday, January
On 1/15/14 7:01 AM, Alexander Zuev wrote:
Hello,
the new webrev with all the typos and comments fixed can be found at
http://cr.openjdk.java.net/~kizune/8029646/webrev.01/
/Alex
(1) jarmagic can be just a static constant somewhere or a stack
variable. not big deal though.
(2) the test
Changeset: 9e91793fd516
Author:vlivanov
Date: 2014-01-15 20:48 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e91793fd516
8031502: JSR292: IncompatibleClassChangeError in LambdaForm for
CharSequence.toString() method handle type converter
Reviewed-by: sundar, lagergren,
[I’m resending something I sent earlier today to Vladimir directly.]
On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce
On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis volker.simo...@gmail.com
wrote:
On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
volker.simo...@gmail.com wrote:
Hi Staffan,
thanks for the review. Please find my comments inline:
On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen
On 1/15/14 21:34, Xueming Shen wrote:
On 1/15/14 7:01 AM, Alexander Zuev wrote:
Hello,
the new webrev with all the typos and comments fixed can be found
at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/
/Alex
(1) jarmagic can be just a static constant somewhere or a stack
Yes, that looks like a good solution.
/Staffan
On 15 jan 2014, at 17:34, Volker Simonis volker.simo...@gmail.com wrote:
Hi Staffan,
thanks for the review. Please find my comments inline:
On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen staffan.lar...@oracle.com
wrote:
Volker,
I’ve
On 15 jan 2014, at 18:27, Volker Simonis volker.simo...@gmail.com wrote:
On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
volker.simo...@gmail.com wrote:
Hi Staffan,
thanks for the review. Please find my comments inline:
On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen
On 15 jan 2014, at 18:52, Volker Simonis volker.simo...@gmail.com wrote:
On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis volker.simo...@gmail.com
wrote:
On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
volker.simo...@gmail.com wrote:
Hi Staffan,
thanks for the review. Please find
Chris,
Thanks for looking into this. See my answers inline.
Best regards,
Vladimir Ivanov
On 1/15/14 9:51 PM, Christian Thalinger wrote:
[I’m resending something I sent earlier today to Vladimir directly.]
On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Hi Martin,
A followup, what is the subtlety that makes it beneficial to wrap
even a single statement in a do {} while (0)?
It makes sense for macros with multiple statements but not for a single
statement substitution of expressions.
For a single statement (w/o ';'), it seems like a redundant
Issue: https://bugs.openjdk.java.net/browse/JDK-6667086
Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/
According to micro-benckmarks, there is no statistically significant
performance change due to applying this patch but the code definitely looks
cleaner.
Thanks,
Brian
Hi Alex,
Kumar,
thanks for your findings. See my comments inline.
On 1/15/14 2:10, Kumar Srinivasan wrote:
Hi Alex,
zip.cpp: (nit) I would keep the hex values to be in upper case just
like the others for
consistency, not a big deal.
Fixed.
typo: + //
Hi Peter/David, we could finally get a trace of exception with fastdebug
build and ReferenceHandler modified (with runImpl() added and called
from run()). The logs, disassembled code is available in JIRA
https://bugs.openjdk.java.net/browse/JDK-8022321 as attachments.
Observations from the
There is an inconsistency in searching classes vs resources if
bootclasspath contains an empty path. Empty path on bootclasspath is
skipped by the bootstrap class loader when searching classes while it
defaults to current working directory when searching resources as the
application class
On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Chris,
Thanks for looking into this. See my answers inline.
Best regards,
Vladimir Ivanov
On 1/15/14 9:51 PM, Christian Thalinger wrote:
[I’m resending something I sent earlier today to Vladimir
Please review this minor test improvement to replace spawning /bin/cp
to copy files with NIO Files.copy.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/
Thanks, Roger
[1]https://bugs.openjdk.java.net/browse/JDK-8031961
On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote:
Hi Peter/David, we could finally get a trace of exception with fastdebug
build and ReferenceHandler modified (with runImpl() added and called
from run()). The logs, disassembled code is available in JIRA
35 matches
Mail list logo
