No problem, let's move it - should I prepare another webrev, or will you
move it by yourself?
Thanks
Miran
On 31/03/14 18:38, Chris Hegarty wrote:
Miran,
If you agree, I would like to move the test ( before pushing ) to
jdk/test/javax/xml/ws (/ebcdic). This is where other jaxws tests live,
On 1 Apr 2014, at 09:34, Miroslav Kos miroslav@oracle.com wrote:
No problem, let's move it - should I prepare another webrev, or will you move
it by yourself?
No webrev update needed. I’ll just move it.
Thanks,
-Chris.
Thanks
Miran
On 31/03/14 18:38, Chris Hegarty wrote:
Miran,
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html)
has better value as .. a
syntax for
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
Am 01.04.2014 11:28, schrieb Bruce Chapman:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
HI all,
Looking for a reviewer for the following javadoc clarification when using
java.sql.Time.toLocalTime/ValueOf.
Here is the webrev which has been had its ccc approved
ljanders-mac:sql ljanders$ hg diff
diff -r fab6896b880f src/share/classes/java/sql/Time.java
---
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038795
Webrev corresponding:
http://cr.openjdk.java.net/~yan/8038795/webrev.00/
Just a minor cleanup of javadoc to avoid tidy warnings; no other code
affected.
Thanks.
Regards,
Alexander
I think you are looking for jmx-dev so forwarding to that list.
On 01/04/2014 13:51, alexander stepanov wrote:
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038795
Webrev corresponding:
Hi Alan, Volker,
Thanks for sharing the info and for testing on AIX. Here's the updated
webrev that hopefully includes the correct dispatch on os.name logic.
I included Solaris as an alternative to SunOS since I saw this in
some documents on Internet. If this is superfluous, I can remove it:
Hi Peter,
Yup, I'll give this a whirl.
-Rob
On 01/04/14 14:16, Peter Levart wrote:
Hi Alan, Volker,
Thanks for sharing the info and for testing on AIX. Here's the updated
webrev that hopefully includes the correct dispatch on os.name
logic. I included Solaris as an alternative to SunOS
Thanks!
On 01.04.2014 16:57, Alan Bateman wrote:
I think you are looking for jmx-dev so forwarding to that list.
On 01/04/2014 13:51, alexander stepanov wrote:
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038795
Webrev
On 01/04/2014 12:35, Lance Andersen wrote:
HI all,
Looking for a reviewer for the following javadoc clarification when using
java.sql.Time.toLocalTime/ValueOf.
The wording looks okay to me, I just wondering whether the Note might
be better as an @apiNote.
-Alan.
On 01/04/2014 14:31, alexander stepanov wrote:
Thanks!
I should have said that the changes look okay to me. I just assume the
removal of the /p isn't really necessary.
-Alan.
Hi Alexander,
Looks good.
I think I would remove the leading p in
http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html
as well. If you don't please check that the generated javadoc for
JMXPrincipal.java still looks good.
On 01/04/2014 14:16, Peter Levart wrote:
Hi Alan, Volker,
Thanks for sharing the info and for testing on AIX. Here's the updated
webrev that hopefully includes the correct dispatch on os.name
logic. I included Solaris as an alternative to SunOS since I saw
this in some documents on Internet.
Paul, thanks for review.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/
Best regards,
Vladimir Ivanov
On 4/1/14 1:44 PM, Paul Sandoz wrote:
Hi Vladimir,
This looks good. Minor stuff below.
I too prefer *_TYPE instead of Int/Float/Void etc as those are not v.
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 kills the benefits.
I don't think MethodType helps with profiling in any way. It
I did not think apiNote was for spec specific clarifications?
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPhone
On Apr 1, 2014, at 9:30 AM, Alan Bateman
On 04/01/2014 03:26 PM, Rob McKenna wrote:
Hi Peter,
Yup, I'll give this a whirl.
-Rob
Thanks Rob.
On 01/04/14 14:16, Peter Levart wrote:
Hi Alan, Volker,
Thanks for sharing the info and for testing on AIX. Here's the
updated webrev that hopefully includes the correct dispatch on
Hi Volker, Masayoshi,
Thanks a lot for your review, here's the updated patch, could you pls take
a look?
http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis volker.simo...@gmail.comwrote:
Hi Jonathan,
thanks for doing this change. Please find
On 4/1/14 4:41 PM, alexander stepanov wrote:
Hello,
Please see the updated webrev here:
http://cr.openjdk.java.net/~yan/8038795/webrev.01/
Thanks Alexander,
It looks good!
-- daniel
I just assume the removal of the /p isn't really necessary.
Yes, probably. That was done just to make
Hi everybody,
I'd like to ask for review of following tests:
http://cr.openjdk.java.net/~mkos/8032884/jdk.01/
Original bug (already fixed): Bug:
https://bugs.openjdk.java.net/browse/JDK-8032884
Issue fixing the bug (bulk update):
https://bugs.openjdk.java.net/browse/JDK-8036030
The test
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 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Every implementation will be carrying around the support for all the
other platforms.
A
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.
Thank you, Paul.
Best regards,
Vladimir Ivanov
On 4/1/14 7:42 PM, Paul Sandoz wrote:
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.
Mac OSX testing was clean.
-Rob
On 01/04/14 16:43, Peter Levart wrote:
On 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Every
On 01/04/2014 14:49, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Every implementation will be carrying around the support for all the
other platforms.
A build
Best regards,
Vladimir Ivanov
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.
The problem is Accessor.checkCast is called from
Then it sounds as if the three of us, at least, are very much in agreement
about what is the appropriate scope for such a “naked dot” feature.
—Guy
On Apr 1, 2014, at 7:26 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 01.04.2014 11:28, schrieb Bruce Chapman:
Slightly preceding Ulf's coin
The tests looks fine to me.
Trivially, you could eliminate the shell script and run xic from
ProcessBuilder?
Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With
the other jaxws tests, or is xjc different.
-Chris,.
On 1 Apr 2014, at 16:21, Miroslav Kos
On 04/01/2014 05:43 PM, Peter Levart wrote:
On 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Every implementation will be carrying around the
On 04/01/2014 05:51 PM, Rob McKenna wrote:
Mac OSX testing was clean.
-Rob
Thanks again Rob.
Regards, Peter
On 01/04/14 16:43, Peter Levart wrote:
On 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include
On 04/01/2014 12:04 PM, Peter Levart wrote:
On 04/01/2014 05:43 PM, Peter Levart wrote:
On 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Hi,
A minor point, but the Enum for LaunchMechanism can be simpler; the
defined enum values (1,2,3)
are never used and can be removed along with the extra constructor.
With the refactoring so f0ar, this seems more complex and harder to
understand.
At least in the non-merged version all (and
On Tue, Apr 1, 2014 at 6:37 PM, Guy Steele guy.ste...@oracle.com wrote:
Then it sounds as if the three of us, at least, are very much in agreement
about what is the appropriate scope for such a naked dot feature.
Am 01.04.2014 11:28, schrieb Bruce Chapman:
More formally, the naked dot (at
Hello,
The plague of serial warnings in the jdk repo is nearly eradicated.
Please review the fix below if address to a few of the holdouts.
Thanks,
-Joe
diff -r b6997dd0667e src/share/classes/sun/tools/java/AmbiguousClass.java
--- a/src/share/classes/sun/tools/java/AmbiguousClass.java
Hello,
With the serial warnings cleanup of the JDK drawing to completion,
please review the patch below which addresses some lingering issues in
jconsole and jstat.
Thanks,
-Joe
diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/Tab.java
---
39 matches
Mail list logo
