Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

On 9/5/19 5:09 PM, Brent Christian wrote: Updated webrev: http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ jvm.h 349 * Link the 'arg' class (unless ClassForNameDeferLinking is set) I suggest to drop "(unless ...)" phrase because the flag is temporary. jni.cpp The implementation o

Re: Comments on jpackage (JEP 343)

I use a very similar workflow, but I’m building for all platforms. I want the image to produce a simple zipped version of the app, and I want all the installer/bundles/packages as well. I also agree with all of the “would be nice to haves” - Particularly service/daemon support. I also agree w

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi Brent, Some quick reply below. On 9/5/19 5:09 PM, Brent Christian wrote: Hi, David On 9/5/19 12:52 AM, David Holmes wrote: Good to see this all come together :) :) So to clarify for others any current caller to find_class_from_class_loader that passes true for "init" was already imp

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

On 9/4/19 2:12 PM, Brent Christian wrote: There is also a CSR[2] in need of review. The javadoc for Lookup::findClass: "In particular, the method first attempts to load the requested class" I think this sentence is no longer needed together with your change.  What about: /** -

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi, Joe @jls tags added (and as long as we're in Class.java, I added @jls to the 3-arg Class.forName(), which has an equivalent paragraph). Updated webrev: http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ Thanks, -Brent On 9/5/19 3:30 PM, Joe Darcy wrote: Hello, For the doc changes i

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi, David On 9/5/19 12:52 AM, David Holmes wrote: Good to see this all come together :) :) So to clarify for others any current caller to find_class_from_class_loader that passes true for "init" was already implicitly asking for a linked class (as you must be linked before you can be init

Re: JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial

++1 > On Sep 5, 2019, at 4:00 PM, Lance Andersen wrote: > > +1 >> On Sep 5, 2019, at 6:43 PM, Joe Darcy wrote: >> >> Hello, >> >> As spotted by Martin, please review the addition of an @since tag to the >> new-in-JDK-14 java.io.Serial type; patch below. >> >> Thanks, >> >> -Joe >> >> diff

Re: JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial

+1 > On Sep 5, 2019, at 6:43 PM, Joe Darcy wrote: > > Hello, > > As spotted by Martin, please review the addition of an @since tag to the > new-in-JDK-14 java.io.Serial type; patch below. > > Thanks, > > -Joe > > diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java > --- a/sr

JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial

Hello, As spotted by Martin, please review the addition of an @since tag to the new-in-JDK-14 java.io.Serial type; patch below. Thanks, -Joe diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java --- a/src/java.base/share/classes/java/io/Serial.java    Thu Sep 05 11:12:12 2019

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hello, For the doc changes in MethodHandle, please supplement the paragraph 1937  * 1938  * Note that this method throws errors related to loading and linking as 1939  * specified in Sections 12.2 and 12.3 of The Java Language 1940  * Specification. with @jls

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Hi Stuart! Thanks for the comments, and please see my answers inline: On 9/5/19 1:18 PM, Stuart Marks wrote: Conceptually I think having the restriction is fine. If we were designing this as a new feature, I'd recommend putting in the restrictions from the very beginning. However, since th

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Thank you Martin again! Here's the updated webrev without the lower-case control char ids: http://cr.openjdk.java.net/~igerasim/8230365/03/webrev/ I've also filed a CSR to record the changes in bahavior: https://bugs.openjdk.java.net/browse/JDK-8230675 Could you please help review it? On 9/

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Conceptually I think having the restriction is fine. If we were designing this as a new feature, I'd recommend putting in the restrictions from the very beginning. However, since the old behavior has been out there for 20 years, my main concern is compatibility. Having system properties to cont

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Hello Bernd! Thank you for your comments! I'm going to proceed with only the restriction part of the change for now, so no blind conversion of lower-case control chars will happen. A system property will allow the users to return to the previous less restrictive behavior, should they decide

Re: jdk-14-jpackage+1-33 on jdk.java.net

Problem with running WiX through a Continuous Integration Build System. It works perfectly fine logging into the Windows desktop with remote desktop, open my Cygwin console and execute Gradle. Our Jenkins CI runs into a problem at the end when WiX is running validation on the built installer. > W

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

Hi, Thanks for your comments, Lance and Pavel. The copyright will be updated before pushing, as Daniel suggested. To address the tag alignment, I adjusted the replacement from '@exception' -> '@throws' to '@exception' -> 'throws   ', where the added whitespace preserves the original alignment

Re: Reply： what to do next to fix JDK-8230557. thanks

Hi Peter! On 9/5/19 7:24 AM, Peter Levart wrote: Hi Ivan, On 9/5/19 11:22 AM, Ivan Gerasimov wrote: Hello! BitSet is known to be flawed in many ways:?0?2 its size(), length(), cardinality() and nextClearBit?6?7() can return meaningless negative values. I was thinking about disallowing set

Re: RFR(s): 8228580: DnsClient TCP socket timeout

* Milan Mimica: > On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >> >> If you use the initial UDP timeout (one second, I think), the kernel >> will not complete the TCP handshake if the initial SYN segment is lost >> because the retransmit delay during the handshake is longer than that. > > W

Re: Comments on jpackage (JEP 343)

Hi Rachel, Thank you for your feedback. I created https://bugs.openjdk.java.net/browse/JDK-8230668 record to track work on your suggestions. - Alexey On 9/5/2019 8:50 AM, Rachel Greenham wrote: (Sorry for non-threading, i read the digest) As you've been lacking feedback from people using t

Reply： what to do next to fix JDK-8230557. thanks

Hi, can we make `size()` and `length()` as deprecated, then write new methods ? Best. -- 原始邮件 -- 发件人: "Peter Levart"https://bugs.openjdk.java.net/browse/JDK-8230557 >> >> >> >> *Describe: * >> >> the return type of the method BitSet#size is int,

Re: RFR(s): 8228580: DnsClient TCP socket timeout

On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: > > If you use the initial UDP timeout (one second, I think), the kernel > will not complete the TCP handshake if the initial SYN segment is lost > because the retransmit delay during the handshake is longer than that. We could set a higher timeo

Re: jdk-14-jpackage+1-33 on jdk.java.net

I have done some investigation myself. Found this blog post regarding ampersand in WiX: http://robmensching.com/blog/posts/2008/4/21/how-to-escape-the-ampersand-in-wix-and-msi-ui/ I tried the solution suggested there. The build works, but the vendor is not display correctly in Windows. The Publis

8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF

https://bugs.openjdk.java.net/browse/JDK-8230342 http://cr.openjdk.java.net/~bpb/8230342/webrev.00/ When the last line is read by readLine() the line number is incremented due to the EOF but not when read() or read(char[]) is used. The specification states it is incremented on line terminators o

Re: RFR(s): 8228580: DnsClient TCP socket timeout

I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomi

RFR: 8230662: Remove dead code from MethodTypeForm

Hi, I noticed some unused methods in java.lang.invoke.MethodTypeForm and ended up with a rather substantial cleanup after pulling that particular thread for a bit: http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ https://bugs.openjdk.java.net/browse/JDK-8230662 Testing: tier1-3 Thanks! /C

Re: Reply： what to do next to fix JDK-8230557. thanks

Hi Ivan, On 9/5/19 11:22 AM, Ivan Gerasimov wrote: Hello! BitSet is known to be flawed in many ways:?0?2 its size(), length(), cardinality() and nextClearBit?6?7() can return meaningless negative values. I was thinking about disallowing setting any index greater than (Integer.MAX_VALUE - 63

Re: Reply： what to do next to fix JDK-8230557. thanks

Hi , On 9/5/19 10:16 AM, wrote: Hi, Peter. I understand your point, but I think it's unreasonable for the reason that source code compatibility problem, it's really a bug. Unfortunately, when such bug is out in the wild for so long, it becomes a feature. It would be unreas

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

On 9/5/19 1:36 AM, David Holmes wrote: Hi Dan, With my CSR Group member hat on On 5/09/2019 8:06 am, Daniel D. Daugherty wrote: Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better as

Re: Comments on jpackage (JEP 343)

(Sorry for non-threading, i read the digest) As you've been lacking feedback from people using the jpackage EA builds, here's mine FWIW. I've been quiet because it's been working well enough for us. That said, our needs and process probably simplify matters in that: 1. We're only producing

Re: Comments on jpackage (JEP 343)

Thank you very much for the detailed feedback. see inline for Change Requests created or associated with each point . /Andy On 9/3/2019 2:58 PM, mark.reinh...@oracle.com wrote: I spent some time last week playing with the jpackage tool, using build 14-jpackage+1-35 from https://jdk.java.net/

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

Hi Julia, I think the fix is fine overall I noticed that the copyright was not updated in all of the files modified, which may be OK in this case, but I typically change it when I made minor changes as well. Not a big deal. The only other question is I am wondering if we want to align the te

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

Julia, Trivially update the copyright years and pay attention to not-so-trivial things like: 8157682: @inheritDoc doesn't work with @exception I'd suggest comparing "before" and "after" javadoc visually to make sure no funny business is going on. -Pavel > On 5 Sep 2019, at 11:40, Julia B

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

..this time with the right link! On 05/09/2019 11:40, Julia Boes wrote: Hi, This change replaces all occurrences of the @exception tag in java.base with the @throws tag. The tags are synonyms but @throws is the newer preferred option [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-82306

RFR: 8230648: Replace @exception tag with @throws in java.base

Hi, This change replaces all occurrences of the @exception tag in java.base with the @throws tag. The tags are synonyms but @throws is the newer preferred option [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8230648 Webrev: http://corelibs-linux-1.ie.oracle.com/~jboes/webrevs/8230648/w

Re: Comments on jpackage (JEP 343)

Could you please also revive the UserJvmOptionsService, that (for very unclear reasons) was removed together with JavaFX? Since the functionality provided by the UserJvmOptionsService requires some cooperation with the launcher created by jpackage, I can't see how I could implement some work-ar

Re: Reply： what to do next to fix JDK-8230557. thanks

Hello! BitSet is known to be flawed in many ways:?0?2 its size(), length(), cardinality() and nextClearBit?6?7() can return meaningless negative values. I was thinking about disallowing setting any index greater than (Integer.MAX_VALUE - 63), for example by throwing OutOfMemoryError. We cou

Reply?? what to do next to fix JDK-8230557. thanks

Hi, Peter. the length method return a negative number too   Best, lamber-ken -- -- ??: "Peter Levart"https://bugs.openjdk.java.net/browse/JDK-8230557 >> >> *Describe: * >> the return type of the method BitSet#size is int, so the method may >>

Reply?? what to do next to fix JDK-8230557. thanks

Hi, Peter. I understand your point, but I think it's unreasonable for the reason that source code compatibility problem, it's really a bug. User can't understand why the size method return a negative number.   Best, lamber-ken --  -- ??: "Pe

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi Brent, Good to see this all come together :) A couple of comments below. On 5/09/2019 7:12 am, Brent Christian wrote: Hi, Please review my fix for JDK-8212117[1].  The webrev is here: http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ So to clarify for others any current caller to

Re: 回复： 回复： what to do next to fix JDK-8230557. thanks

Hi 未来阳光, As David has pointed out, your proposed fix would break binary and source compatibility of BitSet.size() method, so it is not acceptable. BitSet API allows addressing individual bits using non-negative 'int' typed indexes (analogous to indexes of Java arrays). The range of indexes i