Please consider this trivial code C.java:
public class C {
public static void main(String[] args) throws Exception {
System.out.println("main() execution started");
}
}
> ls
C.java
Similar to a previous discussion[1] while doing random testing, I ended
up compiling C.java
Hi, Daniel
Thank you for the reviewing and comments, inline and update webrev as below,
thanks
http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
> On 13 Sep 2018, at 5:43 PM, Daniel Fuchs wrote:
>
> Hi Chris,
>
> Thanks a lot for writing this test!
>
> 60 serverSocket = new
Thanks Daniel.
I changed the return of writeUTF16Surrogate so that it is clearer within
writeUTF16Surrogate when an additional index increment is needed. Other
corresponding changes are in ToHTMLStream and ToTextStream where similar
calls to the method are made. It's been an issue in some
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
Thus change looks okay to me. This class is
Hi Igor,
Looks good to me!
Jc
On Thu, Sep 13, 2018 at 5:08 PM Igor Ignatyev
wrote:
> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> > 478 lines changed: 3 ins; 319 del; 156 mod;
>
> Hi all,
>
> could you please review the next clean up in jdk testlibrary which removes
>
http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> 478 lines changed: 3 ins; 319 del; 156 mod;
Hi all,
could you please review the next clean up in jdk testlibrary which removes
jdk.testlibrary.Utils class?
webrev:
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
s'marks
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
Hello Severin,
On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
Hi Severin,
Sorry I'm a bit confused now.
Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
HIGH. But now it will be LOW due to:
45 ifneq
I checked and the copying of java.exe was done in the now legacy jre
installer, so from what I can tell, there is no longer a need for static
linking.
/Erik
On 2018-09-13 09:14, Erik Joelsson wrote:
Hello,
Reading that bug, it seems the problem is when the installer copies
java.exe into
Thanks, Ioi.
Calvin
On 9/13/18, 4:06 PM, Ioi Lam wrote:
Looks good. Thanks!
Ioi
On Sep 10, 2018, at 11:42 AM, Calvin Cheung wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8190737
webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
Please review this change for handling
Looks good. Thanks!
Ioi
> On Sep 10, 2018, at 11:42 AM, Calvin Cheung wrote:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>
> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>
> Please review this change for handling long path specified in the
> -Xbootclasspath/a
http://openjdk.java.net/jeps/343
- Mark
On 9/13/18, 3:36 PM, Xueming Shen wrote:
Anthony,
I don't see/recall there was any response to my last review comment
[1]. The proposed
change in webrev.05 [2], in which it forces the internal system
property sun.jnu.encoding
to be always "utf8", is incomplete and incorrect (see my comment
Anthony,
I don't see/recall there was any response to my last review comment [1].
The proposed
change in webrev.05 [2], in which it forces the internal system property
sun.jnu.encoding
to be always "utf8", is incomplete and incorrect (see my comment [3] for
why).
file.encoding: how to
Looks good. I like the change of making setCause final.
Jason
From: mandy chung
Sent: Thursday, September 13, 2018 3:50 PM
To: Jason Mehrens; joe darcy; Peter Levart
Cc: core-libs-dev
Subject: Re: RFR JDK-8209553: ExceptionInInitializerError can have a
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
The client code has a "com.sun.awt.SecurityWarning" class which at some
point in the past,
On 9/13/18 12:47 PM, Jason Mehrens wrote:
Hi Mandy,
Like in previous patches, I advocated for using 'super.getCause()' in
writeObject to avoid any subclass hooking into serialization. I even lean
towards the legacy getXXX methods call super.getCause too so they are
compatible with
Hi Mandy,
Like in previous patches, I advocated for using 'super.getCause()' in
writeObject to avoid any subclass hooking into serialization. I even lean
towards the legacy getXXX methods call super.getCause too so they are
compatible with previous behavior.
Does Throwable.setCause need a
Looks good Mandy...
> On Sep 13, 2018, at 2:44 PM, mandy chung wrote:
>
> A few exception classes such as ExceptionInInitializerError,
> InvocationTargetException,
> etc were defined prior to the exception chaining facility and provides the
> API to get
> the cause of the exception. These
On 2018-09-12 19:33, naoto.s...@oracle.com wrote:
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
Looks good to me.
/Magnus
As to the duplicated "common" in the dependency, yes
Thank you Roger!
The fix addresses the issue with System.currentTimeMillis() and
returning early from sleep()/join(), so it looks good!
I think it's better to wrap the line 1304 up to improve readability.
Maybe import j.u.c.TimeUnit.NANOSECONDS, so that `TimeUnit.' could be
omitted?
No
On 8/16/18 4:48 PM, joe darcy wrote:
On 8/15/2018 5:10 PM, mandy chung wrote:
On 8/15/18 3:20 PM, Peter Levart wrote:
Hi Mandy,
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and
A few exception classes such as ExceptionInInitializerError,
InvocationTargetException,
etc were defined prior to the exception chaining facility and provides
the API to get
the cause of the exception. These classes keep its legacy serial field e.g.
ExceptionInInitializerError::exception to get
Hi Naoto,
The code to extract from CLDR data looks fine.
+1
Thanks, Roger
On 9/12/2018 1:33 PM, naoto.s...@oracle.com wrote:
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
As to the
Hi Sherman,
I'll change the comment to:
130 fname, /* path name in multibyte char */
thanks,
Calvin
On 9/12/18, 6:52 PM, Xueming Shen wrote:
Hi Calvin,
I believe I was thinking of keeping the "getPrefixed" as an
implementation details and
instead exporting a "A"
+1
-- Jon
On 9/13/18 10:21 AM, Roger Riggs wrote:
Hi,
Defining a SearchPath class does have a number of benefits as Mark
outlined.
Consider:
public class SearchPath {
public static SearchPath of(String searchPath) {...}
public static SearchPath of(List elements) {...}
public Stream
Hi,
Defining a SearchPath class does have a number of benefits as Mark outlined.
Consider:
public class SearchPath {
public static SearchPath of(String searchPath) {...}
public static SearchPath of(List elements) {...}
public Stream stream() {...}
public List asList() {...}
public
Hello,
Reading that bug, it seems the problem is when the installer copies
java.exe into the Windows system directory. In that case, it may not
have access to the msvcr re-distributables. I will try to find out if
our installers are still doing this.
/Erik
On 2018-09-13 06:32, Alan
On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
:
Apparently, someone was trying to get rid of dll dependencies from
java.exe. Why that would be desirable it does not say. Neither why
this should not apply to all other launchers. (Perhaps there were not
that many in these days?)
Do
On Windows, we compile two versions of libjli, one normal dynamic dll,
and one static library *). Then when we create our launchers, we link
with the normal, dynamic libjli for all launchers, except java.exe and
javaw.exe, which are linked with the static library.
The build system needs to do
Hi Chris,
Thanks a lot for writing this test!
60 serverSocket = new ServerSocket(0);
69 env.put(Context.PROVIDER_URL,
String.format("ldap://localhost:%d/;,
For robustness of the test I would suggest using
InetAddress.getLoopbackAddress() explicitly, to
avoid having the
Hi Joe,
On 13/09/2018 00:25, Lance Andersen wrote:
Hi Joe,
The change seems reasonable
Agreed. However the following condition in ToStream::handleEscaping
is a bit cryptic:
1155 if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
1156 i++ ; // process two input
On 2018/9/13 3:36 PM, Alan Bateman wrote:
On 12/09/2018 08:22, Amy Lu wrote:
test/jdk/java/util/ServiceLoader/basic/basic.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209772
webrev:
On Thu, 2018-09-13 at 11:00 +1000, David Holmes wrote:
> Correction ...
>
> On 13/09/2018 8:31 AM, David Holmes wrote:
> > On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
> > > On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> > > > But I don't understand why the optimization setting is
On 12/09/2018 08:22, Amy Lu wrote:
test/jdk/java/util/ServiceLoader/basic/basic.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209772
webrev: http://cr.openjdk.java.net/~amlu/8209772/webrev.00/
This looks okay to me but
On 11/09/2018 17:04, Stephen Colebourne wrote:
:
This is a broader question for new methods in the JDK, not just this
one. I don't think anyone has come up with a "style guide" for when to
use Stream returning as opposed to list-returning methods.
What I can say is that I think List is the
Please have a review for below new added test to cover JDK-8205330, thanks
This test used dummy ldap server to simulate the scenario to send “Notice of
Disconnection” after binding, it will repeat InitialDirContext() for 1000 times
(normally the NPE bug should be hit less than 100 times run,
37 matches
Mail list logo
