Re: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15

I skimmed over the webrev, the changes seem fine. Thanks for updating the record serialization tests that use ASM. -Chris. > On 17 Apr 2020, at 21:28, Vicente Romero wrote: > > ping, any other comment? are we ready to push this change? > > Vicente > > On 4/13/20 11:05 AM, Vicente Romero wro

Re: RFR: JDK-8243168 Remove addition preview adornment from String::stripIndent and String::translateEscapes

> On 20 Apr 2020, at 16:07, Jim Laskey wrote: > > Cleaning up the JavaDoc. > > webrev: http://cr.openjdk.java.net/~jlaskey/8243168/webrev-00 > > jbs: https://bugs.openjdk.java.net/browse/JDK-8243168 >

Re: RFR 15 8243099: Adding ADQ support to JDK

Vladimir, > On 18 Apr 2020, at 00:13, Ivanov, Vladimir A > wrote: > > Hello everyone, > I would like to add support for the Application Device Queue (ADQ) technology > to the JDK. > > The JBS entry and webrev were created for this improvement: > JBS: https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Maurizio, > On 23 Apr 2020, at 21:33, Maurizio Cimadamore > wrote: > > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc > I’m still working my way through this update ( BTW it’s looking very good ), but an initial comment on the API. The access modes of MemorySegm

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Maurizio, > On 30 Apr 2020, at 15:35, Maurizio Cimadamore > wrote: > > Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will > feature", and also add a link between "access modes" to the access mode > section of the javadoc, to make it more navigable. Done. https://c

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

> On 13 May 2020, at 13:12, Maurizio Cimadamore > wrote: > > Another iteration which addresses the latest CSR comments (the CSR has now > been approved): > > * make MemorySegment::withAccessModes/hasAccessMode throw > IllegalArgumentException in cases where the provided mask is invalid (thi

Re: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2

Hi Mandy, > On 14 May 2020, at 21:12, Mandy Chung wrote: > > MethodHandles::privateLookupIn should prepare for being called during early > startup when the module of java.base classes are not yet assigned. This bug > is uncovered by panama prototype converting NIO to use memory access API. >

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

> On 20 May 2020, at 15:01, Maurizio Cimadamore > wrote: > > Another very small iteration which fixes a gap in the javadoc specification > for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > > http://cr.

Re: RFR 8246040: java/foreign/TestAddressHandle fails on big endian platforms

> On 29 May 2020, at 12:21, Maurizio Cimadamore > wrote: > ... > > http://cr.openjdk.java.net/~mcimadamore/8246040_v1/webrev/ > LGTM. -Chris.

Re: RFR 8246095: Tweaks to memory access API

> On 28 May 2020, at 22:25, Maurizio Cimadamore > wrote: > > Hi, > this followup change includes a number of tweaks that have been added to the > memory access API while we were in the process of integrating it. Most of > them have been contributed by Chris (thanks!), and are all listed in

RFR [15] 8238763: ObjectInputStream readUnshared method handling of Records

This is a small change to ObjectInputStream, for 8238763 [1], to correctly handle readUnshared for records. Webrev: https://cr.openjdk.java.net/~chegar/8238763/webrev.00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8238763

Re: RFR 8246095: Tweaks to memory access API

LGTM. The illustrative example in asUnsigned is nice ( I should have thought of similar, D’oh! ) -Chris. > On 3 Jun 2020, at 15:25, Maurizio Cimadamore > wrote: > > Please review this delta patch; I realized that the previously submitted > patch had few issues: > > * copyright header on Te

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

Mandy, I think this looks good. Just a few minor comments... The spec wording is hard, since the method is offering a conditional initialization. I guess I expected to see something like “initializes targetClass, if it has not been initialized already”, or some such. The input and output is th

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

> On 4 Jun 2020, at 21:16, Mandy Chung wrote: > > ... > I finalized an updated CSR per all feedbacks which includes the deprecation > `sun.misc.Unsafe::shouldBeInitialized`. >https://bugs.openjdk.java.net/browse/JDK-8245871 > > updated webrev: > http://cr.openjdk.java.net/~mchung/jdk15/we

Re: RFR: JDK-8246098: API for Class::permittedSubclasses should clarify if returned elements are ordered or not

> On 10 Jun 2020, at 23:23, Vicente Romero wrote: > > Please review this small change to the API for > java.lang.Class::permittedSubclasses which clarifies that no particular order > of the returned elements should be assumed by clients. The related bug is at > [1], the webrev at [2] and th

Re: RFR: 8247532: Records deserialization is slow

Hi Peter, Thank you for doing this, it is really appreciated. I’m going to take this patch and run it in my local environment, after which I’ll post a reply here. > So WDYT? Since this is still a preview feature in JDK15, is it possible to > squeeze it into JDK15? I think that such a change is

Re: RFR: 8247532: Records deserialization is slow

quot;bug", right? That would be the categorisation that I would use. -Chris. > > Peter > > On 6/15/20 10:37 AM, Chris Hegarty wrote: >> Hi Peter, >> >> Thank you for doing this, it is really appreciated. I’m going to take this >> patch and run it in my local

Re: RFR: 8247532: Records deserialization is slow

Hi Peter, > On 14 Jun 2020, at 17:28, Peter Levart wrote: > > ... > > [2] > http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.01/ > I think that this is very good. It’s clever to build a chain of method handles that can be invoked with the stream field values. This is

Re: RFR: 8247532: Records deserialization is slow

> On 17 Jun 2020, at 07:08, Peter Levart wrote: > > > On 6/16/20 5:15 PM, Chris Hegarty wrote: >> The caching is on a per-stream-field shape basis, which should be consistent >> in the common case, but of course is not always guaranteed to be the case, >> h

Re: RFR: 8247532: Records deserialization is slow

> On 17 Jun 2020, at 06:44, Peter Levart wrote: >>> .. >> If there is a way for a test to compile several versions of the same >> (record) class and then produce byte streams with it, then we could simulate >> various class-evolution cases (field missing, surplus field, change of field >> ty

Re: RFR: 8247532: Records deserialization is slow

Peter, > On 17 Jun 2020, at 09:23, Chris Hegarty wrote: > >> On 17 Jun 2020, at 06:44, Peter Levart wrote: >>>> .. >>> If there is a way for a test to compile several versions of the same >>> (record) class and then produce byte streams with it,

RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

The MemorySegment::mismatch implementation added vectorized mismatch of long sizes. The implementation is trivial, but the starting point for a more optimized implementation, if needed. ArraysSupport::vectorizedMismatchLarge incorrectly returns the bitwise complement of the offset of the first m

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

geForBytes and drop the > log2ArrayIndexScale argument. Then expand later if need be. I still think the > method rightly belongs in ArraysSupport. Sounds reasonable. -Chris. > Paul. > >> On Jun 17, 2020, at 8:33 AM, Chris Hegarty wrote: >> >> The MemorySegment::mi

Re: (15) RFR: JDK-8247444: Trust final fields in records

> On 18 Jun 2020, at 13:43, Aleksey Shipilev wrote: > >> ... > > Again, JDK-8247532 is the writing on the wall: we don't need 3rd party > developers to tell if Record > serialization works fast in 15 -- we already know it does not. I disagree. JDK-8247532 is under review and well on its way

RFR [15] 8247789: Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

This is a small change to remove the use of reflection to fabricate "bad" serial data - in order to verify constructor invariants for record serialization tests. Instead, it is straight forward to just modify a single value in the byte stream, that results in the same. https://cr.openjdk.java.ne

Re: RFR [15] 8247789: Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

> On 18 Jun 2020, at 14:56, Roger Riggs wrote: > > Hi Chris, > > It may be prudent to check that the current value in the byte array is the > one you expect > before changing it. > That would help catch tests if something else changes the contents of the > stream. Good idea Roger. Done. ht

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

>>> should rely on other tests to ensure the intrinsic method is operating >>> efficiently. >>> >>> >>> 2) This method only works when operating on byte arrays. It will not work >>> correctly if operating on short or long arrays, since we are not

Re: RFR: 8247532: Records deserialization is slow

Peter, Thank you for taking the suggestion for additional test scenarios, improving coverage, and finding-and-fixing the issues in my hurried test builder (was only meant as a rough guide/idea). I agree with Claes, it would be good to include the microbenchmark in test/micro/.. I think this v

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

Paul pointed out an issue, off list, where subsequent subranges could still result in a call to the intrinsic. That is now fixed in-place and the test amended to cover the scenario. https://cr.openjdk.java.net/~chegar/8247696/webrev.01/ -Chris. > On 19 Jun 2020, at 11:56, Chris Hegarty wr

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 23 Jun 2020, at 10:17, Peter Levart wrote: > > ... > http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ Good stuff. Reviewed. I am going to take this latest change and run it through our internal build and test system. Will post the results here soon. -Chris

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 23 Jun 2020, at 10:46, Chris Hegarty wrote: > > > >> On 23 Jun 2020, at 10:17, Peter Levart wrote: >> >> ... >> http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ > > Good stuff. Reviewed. > > I am going t

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 23 Jun 2020, at 14:49, Peter Levart wrote: > > ... > > Ok, I'm going to push this to jdk15. Thank you Peter. This is a really nice change. As a follow on, and not for JDK 15, I observe that Class::isRecord0 / JVM_IsRecord shows up as consuming a significant amount of time, more than 10

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 24 Jun 2020, at 07:03, David Holmes wrote: > > Hi Chris, > > On 24/06/2020 2:30 am, Chris Hegarty wrote: >>> On 23 Jun 2020, at 14:49, Peter Levart wrote: >>> >>> ... >>> >>> Ok, I'm going to push this to jdk15. >>

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

poking the bear!). If we encode these single state bits into a modifiers-like value, then we can treat them as such (without needing them to be “real” modifiers). And this should address any potential bloating concerns. -Chris. > Regards, Peter > > > > On 6/24/20 10:20 AM,

RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

A micro-optimisation noticed when working on JDK-8247532. For further details see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067446.html Webrev: https://cr.openjdk.java.net/~chegar/8248233/webrev.00/ before: RecordSerializationBench.deserializeClasses10 avgt

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

> On 24 Jun 2020, at 17:15, Claes Redestad wrote: > > ... > It seems ObjectInputStream#isRecord(Class) is now unused. No need for > a new webrev if you choose to remove it. Good catch, now removed. > On 24 Jun 2020, at 17:25, Peter Levart wrote: > > Hi Chris, > > The patch looks good. > >

RFR [1]6 8248326 Add a minimal serialization test for local records

While working on some record serialization changes recently, I noticed that we don’t have any coverage for local records. Here is a simple extension to an existing records test. diff -r 4e186efa6cbf test/jdk/java/io/Serializable/records/BasicRecordSer.java --- a/test/jdk/java/io/Serializable/rec

Re: RFR [1]6 8248326 Add a minimal serialization test for local records

de, and this issue is narrowly focused on testing local records, then I’ll respectively decline the suggestion. If checking of the hash code is beneficial, we can consider it separately and in a larger context. -Chris. > best regards, > > -- daniel > > On 25/06/2020 16:01, Chris Heg

Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

> On 9 Jul 2020, at 23:23, [email protected] wrote: > > ... > > webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/ > Looks good. Reviewed. -Chris.

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

> On 1 Apr 2020, at 23:46, Paul Sandoz wrote: > > Hi, > > A prior email sent out a request for review of the Vector API in preparation > for JEP 338: Vector API (Incubator) [1] to be proposed for target: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >

Re: RFR 8251989: Hex encoder and decoder utility

> On 19 Aug 2020, at 22:14, Roger Riggs wrote: > > .. > JavaDoc: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html I like it Roger, very nice. A few minor comments/quibbles: Hex: - "Utilities to encode bytes to hex strings and decode hex strings to bytes.” - This

Re: RFR 8251989: Hex formatter and parser utility

Roger, > On 27 Aug 2020, at 02:34, Roger Riggs wrote: > > Please review updates to the formatting and parsing API based on the last > round of comments. > There are many changes, so it may be useful to read it as a fresh draft. > > - Rename classes: Encoder -> Formatter; Decoder -> Parser >

Re: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3]

On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID Ma

Re: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs

On Tue, 15 Sep 2020 19:40:28 GMT, Phil Race wrote: >> This issue relates to JDK-8250639 '☂ Address reliance on default >> constructors in the java.desktop module'. The >> following classes have had an explicit no-arg constructor added, with a >> protected access modifier and accompanying API >>

Re: RFR: 8246774: Record Classes (final) implementation

On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: >> Hi Vicente, >> Please file a separate subtask for the javax.lang.model changes. This helps >> with the JSR 269 MR paperwork. >> Thanks, >> -Joe > > note: I have removed from the original patch the code related to > javax.lang.model, I w

Integrated: 8254161: Prevent instantiation of EnumSet subclasses through deserialization

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty wrote: > TL;DR add EnumSet::readObjectNoData() > > EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it > should strictly implement that pattern and demonstrate how best to > defend against inappropriate instan

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

On Thu, 15 Oct 2020 18:22:12 GMT, Roger Riggs wrote: >> Marked as reviewed by dfuchs (Reviewer). > > Please review the corresponding CSR: > https://bugs.openjdk.java.net/browse/JDK-8251991 Hi Roger, This looks very good. I have a few minor comments: 1. Add an explicit type parameter to t

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

On Fri, 16 Oct 2020 11:46:47 GMT, Chris Hegarty wrote: >> Please review the corresponding CSR: >> https://bugs.openjdk.java.net/browse/JDK-8251991 > > Hi Roger, > > This looks very good. > > I have a few minor comments: > > 1. Add an explicit type param

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs wrote: > Since the instances are immutable, it seemed useful to emphasize that only > the instance returned has the requested > change. Discarding the return value was incorrect programming. The original > instance is not modified. Understood, and

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

On Fri, 16 Oct 2020 15:22:37 GMT, Roger Riggs wrote: >> The HexFormat API currently uses an indexing model for arrays and strings >> based on an index and a length. >> Many other APIs in the JDK use an index model of `fromIndex` and `toIndex` >> (exclusive). >> >> They are equivalent and conve

Re: RFR: 8251989: Hex formatting and parsing utility [v6]

On Mon, 19 Oct 2020 22:52:31 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified parame

Re: RFR: 8251989: Hex formatting and parsing utility [v6]

On Mon, 12 Oct 2020 22:17:58 GMT, Marcono1234 wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Correct length of StringBuilder in formatHex; >> Correct bug in formatHex(char[], 2, 3) and add test for subranges of

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments

On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev wrote: >> Hi, >> >> Currently, if MethodHandles::permuteArguments is used with a reorder array >> that is the wrong size, or one of the indexes in it is out of bounds of the >> new type, we simply get the exception message: >> >> bad reor

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v2]

On Wed, 28 Oct 2020 13:32:19 GMT, Jorn Vernee wrote: >>> >>> >>> Seems like a reasonable change. Is there an already existing test for "bad" >>> permute args that could be expanded to discern the new exception message? >> >> There are several tests for permuteArguments, but none that explicit

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v3]

On Wed, 28 Oct 2020 14:57:44 GMT, Jorn Vernee wrote: >> Hi, >> >> Currently, if MethodHandles::permuteArguments is used with a reorder array >> that is the wrong size, or one of the indexes in it is out of bounds of the >> new type, we simply get the exception message: >> >> bad reorder a

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v3]

On Wed, 28 Oct 2020 14:30:30 GMT, Chris Hegarty wrote: >> I've added some negative tests that test for the different failure >> conditions. > > Thanks for adding additional test coverage @JornVernee. > > Writing a tight implementation of assertThrows is non-trivi

Re: RFR: 8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java

On Tue, 3 Nov 2020 23:55:24 GMT, Mandy Chung wrote: > test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record > class. > This test no longer needs to be run with --enable-preview. Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pul

Re: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung wrote: > Record classes are now a standard feature in 16. @SuppressWarnings can be > removed from sun.misc.Unsafe. Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1049

Re: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle combinator [v12]

On Mon, 2 Nov 2020 11:22:07 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch adds an asExact() combinator to VarHandle, that will return a new >> VarHandle that performs exact type checks, similar to >> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, >> which can l

Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6]

> On 5 Nov 2020, at 18:11, Alex Buckley wrote: > > On 11/5/2020 4:45 AM, Jan Lahoda wrote: >> FWIW, a javadoc generated with the current version of the patch: >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html > > Allow me to draw people's attention to the PREVIEW lin

Re: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle combinator [v14]

On Tue, 10 Nov 2020 15:02:08 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch adds an asExact() combinator to VarHandle, that will return a new >> VarHandle that performs exact type checks, similar to >> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, >> which can

Re: RFR: 8256063: Module::getPackages on an unnamed module may return packages that are in a named module

On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung wrote: > If `Module::getPackages` is invoked on the unnamed module of a class loader > then the set of packages returned will include the packages of any named > modules > that are defined to that class loader. This is a spec and implementation bug.

Re: RFR: 8256477: Specialize heap memory segment implementations

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore wrote: > The current memory segment implementation defines a hierarchy with 3 concrete > classes: one for heap segments, one for native segments and one for mapped > segments. > > Since there can be many kinds of heap segments (e.g. create

Re: RFR: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected

On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote: > This PR sharpens the testing done by > test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after > @mcimadamore reported that the test was not catching an issue with memory > access var handles; namely that the implementation of w

Re: RFR: 6394787: Typos in javadoc of OIS.readObjectOverride and OOS.writeObjectOverride

+1 I can sponsor this for you Andrey. -Chris. > On 4 Jun 2019, at 07:56, Alan Bateman wrote: > > This looks right, I assume a cut&paste issue when the methods were originally > added. > > -Alan > > On 02/06/2019 12:23, Andrey Turbanov wrote: >> Hello. >> I would like to contribute a small

[ipv6] Re: SocketAddress.toString() and RFC 2732

Thanks for reporting this Chris, and Alan for filing an issue to track it. That issue is: https://bugs.openjdk.java.net/browse/JDK-8225499 ( which links to the IPv6-only work that Alan mentioned ) -Chris. > On 8 Jun 2019, at 07:38, Alan Bateman wrote: > > On 07/06/2019 19:46, Chris wrote:

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

[ adding net-dev ] Pavel, > On 18 Jun 2019, at 14:22, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8226303/webrev.00 This looks good. Just a few minor comments: 1) Please add the bug no. and a brief summary, to the test tags.

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

@summary Verifies that some of the standard BodyPublishers relay > exception >* rather than throw it >* @bug 8226303 > > Is that okay? Yes. > > 2) Done. > > Thanks. -Chris. >> On 18 Jun 2019, at 16:07, Chris Hegarty wrote: >> >>

Re: RFR: 8227587: Add internal privileged System.loadLibrary

> On 16 Jul 2019, at 14:48, Claes Redestad wrote: > > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ I think that this is good Claes. Reviewed. -Chris.

Re: DnsClient TCP socket timeout

> On 18 Jul 2019, at 10:16, Milan Mimica wrote: > > Hello list > > Have you ever considered the problem reported here: > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java I posted a comment on that SO thread yesterday, no reply since. -Chris

Re: DnsClient TCP socket timeout

ponentDirContext.p_getAttributes line: 235 > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 141 > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 129 > javax.naming.directory.InitialDirContext.getAttributes line: 142 > > On Thu, 18 Jul 2019 at 11:32, Milan

Re: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

> On 6 Aug 2019, at 21:04, Joe Darcy wrote: > > ... > Revised webev > > http://cr.openjdk.java.net/~darcy/8202385.5/ LGTM. -Chris.

Re: RFR: JDK-8139820: URLClassPath.FileLoader constructor redundantly checks protocol

> On 18 Aug 2019, at 23:18, Claes Redestad wrote: > > Hi, > > On 2019-08-18 21:22, Evgeny Mandrikov wrote: >> [1] https://cr.openjdk.java.net/~godin/8139820/webrev.00/ > > looks ok to me. +1 seems ok to me. -Chris

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

Here is an initial attempt to document these timeout/retry properties. It’s effectively the wording lifted from the tech notes [1], with “UDP” removed. I deliberately avoided describing the implementation. It serves little purpose, and in fact will greatly complicate the description, as well as

Re: RFR 8231314: java.time serialization warning cleanup

Roger, > On 20 Sep 2019, at 19:51, Roger Riggs wrote: > > Please review code cleanup that will remove the need to suppress soon to be > introduced > warnings [1] about static typing of serialization related fields. > A few of the implementation Ser classes that serialize java.time types are >

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

> On 24 Sep 2019, at 13:41, Milan Mimica wrote: > > Pavel, > > Deal. Handling early returns too: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/ LGTM -Chris

Re: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module

+1. Should the @serial javadoc tag be removed? -Chris. > On 26 Sep 2019, at 19:27, Roger Riggs wrote: > > Looks fine, Joe > >> On 9/26/19 1:51 PM, Joe Darcy wrote: >> Hello, >> >> Another part of the cleanup of library serialization usage ahead of >> augmented javac -Xlint warnings (JDK-8160

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, On 01/10/2019 21:26, Ivan Gerasimov wrote: Hello! The constructors of SocketPermission and FilePermission expect a String argument with comma-separated list of actions. If the list is malformed, then the constructors throw IllegalArgumentException. It turns out that the current impl

Re: JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag in NodeChangeEvent.java

> On 3 Oct 2019, at 01:09, Joe Darcy wrote: > > Hello, > > In response to the review of JDK-8231546: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062612.html > > it was noticed a field in NodeChangeEvent.java has an @serial javadoc tag, > but the class itself is @

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, > On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote: > > ... > > So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover > the addition of @throws paragraph in the javadoc of SocketPermission. > > I would really appreciate it, if someone helped to review it. > Since we’r

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, > On 4 Oct 2019, at 03:00, Ivan Gerasimov wrote: > > ... > > I've adopted your suggested changes and the test: > http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/ > LGTM. > CSR was also updated accordingly: > https://bugs.

Re: JDK 14 RF(pre)R: add section on "conditionally serializable" collections

This is a nice addition. LGTM. -Chris. On 05/10/2019 00:46, Stuart Marks wrote: On 10/3/19 8:32 AM, Joe Darcy wrote: In response to the recent and on-going review of serializable types in the base module and elsewhere, I thought it would be helpful if the collections specs discussed how col

Re: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with -Xcheck:jni

On 08/10/2019 17:17, Kiran Ravikumar wrote: Hi Guys, I am a new hire with the Oracle Java Platform Group and will be working mainly on JDK Update releases. Below is my first contribution. Looking forward to contribute more to the community. Please review the fix: Bug :https://bugs.openjdk

Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

Joe, On 05/10/2019 04:04, Joe Darcy wrote: Hello, Please review the revised fix:     http://cr.openjdk.java.net/~darcy/8231202.1/ Given the prior discussion in this thread, then I think this version looks fine ( which consists solely of warning suppressions ). -Chris.

Re: RFR: JEP 359-Records: serialization code and API changes

> On 21 Oct 2019, at 19:32, Vicente Romero wrote: > > Hi all, > > Please review the serialization changes to support records. > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/records.review/serialization/webrev.00/ Peter has raised an issue over on amber-spec-experts [1], which

Re: 8205132: Remove Thread.countStackFrames()

> On 23 Oct 2019, at 08:25, Alan Bateman wrote: > > > Thread::countStackFrames has been deprecated for 20+ years and has been > marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. > It's was never a well-defined method and I've been unable to find anything > that uses

Re: RFR: CSR Core-libs support for records

> On 4 Nov 2019, at 21:27, Florian Weimer wrote: > > ... > Right now, it appears to be possible to have a record implement > java.io.Serializable, and serialization will appear to work, but > because the names of the implicitly generated private fields are not > specified, it is not portable a

Re: RFR: CSR Core-libs support for records

> On 4 Nov 2019, at 23:22, Joe Darcy wrote: > ... > It isn't unreasonable for java.lang.Record to make some mention of the > special treatment by serialization. (As a point of reference, java.lang.Enum > does *not* reference the special handling of enums of serialization.) > > I think a refe

Re: JDK14 RFR of JDK-8234381: API docs should mention special handling of enums in serialization

LGTM Joe. -Chris. > On 19 Nov 2019, at 18:21, Joe Darcy wrote: > > Hello, > > Please review this small doc changes to more explicitly discuss the special > handling of enum types by serialization: > > JDK-8234381: API docs should mention special handling of enums in > serialization >

Re: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions

The change looks good to me Joe. Thanks for adding the catch-all clause. This will cover the “bad” record class file, where the canonical constructor is not present. -Chris. > On 26 Nov 2019, at 01:46, Joe Darcy wrote: > > Hello, > > Noticed in the context of doing some other reviews, the s

Re: JDK 14 RFR of JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec"

Looks good Joe. -Chris. > On 27 Nov 2019, at 15:44, Joe Darcy wrote: > > Hello, > > Please review the small doc RFE to address > > JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" > > Patch below; thanks, > > -Joe > > --- a/src/java.base/share/classes/java/lang/Cla

Re: RFR: JEP 359: Records (Preview) (full code)

Hi Joe, > On 3 Dec 2019, at 05:36, Joe Darcy wrote: > > ... > > As a non-essential cleanup, in > src/java.base/share/classes/java/io/ObjectOutputStream.java: > > 1444 final boolean isRecord = isRecord(obj.getClass()) ? true : > false; > 1445 if (isRecord) { > 1446

Re: RFR 8235359: Simplify method Class.getRecordComponents()

> On 5 Dec 2019, at 14:36, Harold Seigel wrote: > > Hi, > > Please review this small change to simplify Class.getRecordComponents() by > changing the return type of getRecordComponents0() to RecordComponent[]. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.

Re: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records"

LGTM. -Chris > On 5 Dec 2019, at 18:08, Joe Darcy wrote: > > Hello, > > Please review this small cleanup to records support in java.lang.Class: > > JDK-8235369: "Class.toGenericString need to be updated for records" > CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 > webrev

Re: JDK 14 RFR of JDK-8235514: Update record serialization tests to not use hard coded source versions

Thanks for doing this Joe. The changes look good. -Chris. > On 6 Dec 2019, at 21:15, Joe Darcy wrote: > > Hello, > > Please review the patch below to update to the records serialization tests to > avoid hard-coded values for the -source argument during programmatic > invocations of the compi

Re: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base

> On 8 Dec 2019, at 18:58, Joe Darcy wrote: > > Hello, > > Please review this small API changes for JDK 15: > > JDK-8230771: Remove terminally deprecated constructors in java.base > CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > webrev: http://cr.openjdk.java.net/~darcy/

Re: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed

> On 8 Dec 2019, at 10:48, Daniel Fuchs wrote: > > Hi Vyom, > > On 07/12/2019 03:36, Vyom Tiwari wrote: >> Changes looks OK to me, one minor bit you need to update @bug tag before >> pushing. > > We don't update @bug for test bugs (when the fix is in the > the test itself). Correct. Doing

RFR [14] 8235550: Clarify record reflective support specification

This is a review request for a change to add a clarification to the record related core reflection methods, that specifies what it means to be a record class and access to the record components. Discussed originally over on amber-spec-experts [1] I expanded the existing record reflection test and

RFR [14] 8235531: Update record serialization migration tests to not use hard coded source versions

In preparation for the imminent arrival of 15 to jdk/jdk, this change replaces the hardcoded source version, used to invoke the compiler programmatically, with the runtime feature version, similar to JDK-8235514. I tested this change along side the changes for 8225361 - "Start of release updates f

Re: RFR [14] 8235550: Clarify record reflective support specification

Maurizio, > On 10 Dec 2019, at 12:39, Maurizio Cimadamore > wrote: > > Looks good. Thank you. I updated and finalised the CSR. > Minor nits: > > * in getRecordComponents there are some utterings of "true", "false" and > "null" which are not surrounded by a {@code } block. > > * any reason as

  1   2   3   4   5   6   7   8   9   10   >