Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-22 Thread Alan Bateman
On Fri, 20 Nov 2020 20:12:31 GMT, Stuart Marks wrote: >> Marked as reviewed by mchung (Reviewer). > > I think the current deprecation wording is actually too specific regarding > the raciness between TG destruction and created-but-not-started threads. > That's just one of the flaws of thread gr

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-22 Thread Alan Bateman
On Fri, 20 Nov 2020 21:23:35 GMT, Peter Levart wrote: >> Thanks Remi. > > I agree solution 1 is the best after all things considered. I"m also okay with with option 1, which is essentially the original proposal exception that it defines the method on InnovocationHandler instead of Proxy. Thank

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v3]

2020-11-22 Thread Alan Bateman
These methods > should be terminally deprecated so they can be degraded in a future release > and eventually removed. > > CSR with more information: https://bugs.openjdk.java.net/browse/JDK-8256644 Alan Bateman has updated the pull request with a new target base due to a merge or a

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan wrote: > If you agree, I can file an issue. Yes, make sense to separate this out, esp. permission targets such as "stopThread" where all usages are in deprecated methods. However, I don't expect "modifyThreadGroup" would be deprecated, at least not

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs wrote: >> Alan Bateman has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains four addi

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
These methods > should be terminally deprecated so they can be degraded in a future release > and eventually removed. > > CSR with more information: https://bugs.openjdk.java.net/browse/JDK-8256644 Alan Bateman has updated the pull request with a new target base due to a merge or a

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan wrote: > I think it would be useful in the javadoc of the RuntimePermission targets > (stopThread, etc) to add a note/link that the corresponding method that the > permission applies to is terminally deprecated. Something as simple as "Note > that

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is in

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 03:27:54 GMT, Mandy Chung wrote: >> Good point -- case added. > > Looks good. testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with --illegal-access=

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: > I'm somewhat surprised by the extent of the other changes given the basic > change here is to deprecate the option and change its default. I literally > expected to see only 2 simple changes to the functional code: the deprecation > warni

RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-19 Thread Alan Bateman
This change terminally deprecates the following methods defined by java.lang.ThreadGroup - stop - destroy - isDestroyed - setDaemon - isDaemon The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Alan Bateman
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1299

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default

2020-11-19 Thread Alan Bateman
On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aa

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

2020-11-16 Thread Alan Bateman
On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this > iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of > cast conversions with respect to sealed type hierarchies >

Re: RFR: 8253280: Use class name as class loading lock

2020-11-14 Thread Alan Bateman
Robert, I think you need to start a discussion on serviceability-dev about the diagnostic challenges in this area before proposing API changes to java.lang.management that have wider implications and potential interop issues. It might be that your starting point is the thread dump instead. -

Re: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when reflect method invoked from different threads [v6]

2020-11-14 Thread Alan Bateman
On Sat, 14 Nov 2020 12:53:26 GMT, Hui Shi wrote: >> @huishi-hs See the "Integration blocker" section in the PR body; you have a >> JBS issue and PR title mismatch. > > After review PR/commit title is changed to align with JBS title to add ready > label Can you sync up your branch (the bot is s

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]

2020-11-13 Thread Alan Bateman
On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase.

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v6]

2020-11-13 Thread Alan Bateman
On Fri, 13 Nov 2020 03:50:09 GMT, Hui Shi wrote: >> …AccessorImpl object >> >> We met real problem when using protobuf with option optimized for code size, >> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883 >> >> Optimize solution is adding a new boolean field to detect concurre

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v5]

2020-11-12 Thread Alan Bateman
On Thu, 12 Nov 2020 04:23:37 GMT, Hui Shi wrote: >> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java >> line 44: >> >>> 42: private DelegatingConstructorAccessorImpl parent; >>> 43: private int numInvocations; >>> 44: private int generated; >> >>

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

2020-11-11 Thread Alan Bateman
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: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v5]

2020-11-11 Thread Alan Bateman
On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi wrote: >> …AccessorImpl object >> >> We met real problem when using protobuf with option optimized for code size, >> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883 >> >> Optimize solution is adding a new boolean field to detect concurre

Re: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence

2020-11-10 Thread Alan Bateman
On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen wrote: > Hi, > > Please review the fix for JDK-8256018 which addresses the issue that the > update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use > Reference.reachabilityFence to ensure that direct byte buffer are kept kept > a

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v26]

2020-11-10 Thread Alan Bateman
On Mon, 9 Nov 2020 16:07:13 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation (see JEP 393 [1]). This >> iteration focus on improving the usability of the API in 3 main ways: >> >> * fi

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v22]

2020-11-08 Thread Alan Bateman
On Thu, 5 Nov 2020 17:14:16 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation (see JEP 393 [1]). This >> iteration focus on improving the usability of the API in 3 main ways: >> >> * fi

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

2020-11-08 Thread Alan Bateman
On Wed, 4 Nov 2020 07:45:09 GMT, Alan Bateman wrote: >>> The javadoc for copyFrom isn't changed in this update but I notice it >>> specifies IndexOutOfBoundException when the source segment is larger than >>> the receiver, have other exceptions been ex

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod…

2020-11-05 Thread Alan Bateman
On Thu, 5 Nov 2020 09:07:13 GMT, Aleksey Shipilev wrote: >> …AccessorImpl object >> >> We met real problem when using protobuf with option optimized for code size, >> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883 >> >> Optimize solution is adding a new boolean field to detect

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

2020-11-04 Thread Alan Bateman
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. Looks okay. Given some of the changes in the pipeline then we might be want to think about deprecating these methods soon too. ---

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

2020-11-03 Thread Alan Bateman
On Mon, 2 Nov 2020 11:26:51 GMT, Maurizio Cimadamore wrote: >> I looked through the changes in this update. >> >> The shared memory segment support looks sound and the mechanism to close a >> shared memory segment is clever (albeit a bit surprising at first that it >> does global handshake to

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

2020-11-01 Thread Alan Bateman
On Thu, 29 Oct 2020 14:13:40 GMT, Maurizio Cimadamore wrote: >>> @mcimadamore, if you pull from current master, you would get the Linux >>> x86_32 tier1 run "for free". >> >> Just did that - I also removed TestMismatch from the problem list in the >> latest iteration, and fixed the alignment

Re: RFR: 8248122: java.base should not handle JavaFX application in a specific way

2020-10-31 Thread Alan Bateman
On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri wrote: > JavaFX is no longer a part of OpenJDK. It makes sense to not treat it > specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX > specific code. > > Further investigation reveals that some JavaFX specific code is also

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

2020-10-28 Thread Alan Bateman
On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A

Re: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with ---illegal-access=deny [v2]

2020-10-27 Thread Alan Bateman
On Tue, 27 Oct 2020 15:27:39 GMT, Roger Riggs wrote: >> To access the internal security APIs to lookup known OIDs the test needs to >> open java.base/sun.security.util. > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > simpli

Re: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with ---illegal-access=deny

2020-10-27 Thread Alan Bateman
On Tue, 27 Oct 2020 14:11:48 GMT, Roger Riggs wrote: > To access the internal security APIs to lookup known OIDs the test needs to > open java.base/sun.security.util. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/881

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Alan Bateman
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: 8159746: (proxy) Support for default methods

2020-10-22 Thread Alan Bateman
On Thu, 22 Oct 2020 00:24:59 GMT, Mandy Chung wrote: >> Hi Peter, thanks for coming with these alternatives. The need for new >> `InvocationHandler2` and `InvocationHandler2.SuperInvoker` APIs and the >> complexity of `plevart:proxy-default-method-alt-api2` look unpleasing in >> order to kee

Re: RFR: 8254078: DataOutputStream is very slow post-disabling of Biased Locking [v7]

2020-10-22 Thread Alan Bateman
On Thu, 22 Oct 2020 09:08:31 GMT, Andrew Haley wrote: >> DataOutputStream is very slow post-disabling of Biased Locking. This >> was discovered when benchmarking a transaction library, which showed >> significant performance loss when moving to JDK 15. WIth some small >> changes to DataOutputStre

Re: Integrated: 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

2020-10-14 Thread Alan Bateman
On Wed, 14 Oct 2020 14:04:07 GMT, Claes Redestad wrote: > Wrong intrinsic name used, causing a build breakage Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/654

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

2020-10-13 Thread Alan Bateman
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v4]

2020-10-13 Thread Alan Bateman
On Tue, 13 Oct 2020 11:40:36 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8159746: (proxy) Support for default methods

2020-09-28 Thread Alan Bateman
On Sun, 27 Sep 2020 17:09:03 GMT, Peter Levart wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with t

Re: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697

2020-09-24 Thread Alan Bateman
On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote: > JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. > @requires tests the OS RAM size, but you can > easily have the x86_32 host with more than 4G ram, yet JVM would fail to > acquire that heap size. Need to check

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

2020-09-24 Thread Alan Bateman
On 24/09/2020 09:59, Kim Barrett wrote: If possible, my preference would be to avoid the pragma cruft and write the code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't warn with or without asan. I've kind of lost track in the discussion of all the variants whether that's

Re: RFR: 8218685: jlink --list-plugins needs to be readable and tidy

2020-09-24 Thread Alan Bateman
On Wed, 23 Sep 2020 17:41:49 GMT, Ian Graves wrote: >> I'll shrink narrow those descriptions down to 80 characters. >> >> As to the abstract class, I think it'd make sense to have that implement >> getUsage, getName, and getDescription -- >> essentially combine all of those very similar things

Re: RFR: 8218685: jlink --list-plugins needs to be readable and tidy

2020-09-23 Thread Alan Bateman
On Wed, 23 Sep 2020 01:39:35 GMT, Ian Graves wrote: >> The output looks much better. Have you considered to sort them in >> alphabetical order of the plugin name? > > Yes! I had intended to but it looks like I got hung up making sure > non-documented plugins came last. Will push a change > for

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v5]

2020-09-23 Thread Alan Bateman
On Tue, 22 Sep 2020 20:57:00 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored >> the offset specified by >> Deflater.setDictionary. Mach5 jdk-t

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4]

2020-09-22 Thread Alan Bateman
On Mon, 21 Sep 2020 19:06:44 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored >> the offset specified by >> Deflater.setDictionary. Mach5 jdk-t

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v11]

2020-09-22 Thread Alan Bateman
On Tue, 22 Sep 2020 01:25:16 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on >> different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces >> ordering based on `Archive` module names to >> ensure stable files (and file sign

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v9]

2020-09-22 Thread Alan Bateman
On Tue, 22 Sep 2020 01:22:03 GMT, Ian Graves wrote: >> Whatever is easiest but 2 x copy tree would be simpler and the result should >> be two identical JDKs as reported in >> JDK-8252730. > > I misunderstood what you meant when I read it earlier today, apologies! The > new changes should addres

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v9]

2020-09-21 Thread Alan Bateman
On Mon, 21 Sep 2020 14:17:18 GMT, Ian Graves wrote: >> test/jdk/tools/jlink/JLinkReproducible3Test.java line 112: >> >>> 110: } >>> 111: } >>> 112: >> >> The update to ImageFileCreator looks good. >> >> A few nits in JLinkReproducible3Test: >> 1. Invoking copyJDKs with two destination loca

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3]

2020-09-21 Thread Alan Bateman
On Sun, 20 Sep 2020 22:22:47 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored >> the offset specified by >> Deflater.setDictionary. Mach5 jdk-t

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v9]

2020-09-19 Thread Alan Bateman
On Fri, 18 Sep 2020 20:40:28 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on >> different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces >> ordering based on `Archive` module names to >> ensure stable files (and file sign

Re: RFR: 8253208: Move CDS related code to a separate class

2020-09-19 Thread Alan Bateman
On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a > separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 src/java.base/share/classes/jdk/internal/misc/CDS.java line 42: > 40: public stat

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v3]

2020-09-16 Thread Alan Bateman
On Tue, 15 Sep 2020 14:30:03 GMT, Alan Bateman wrote: >> Ian Graves has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Comparator cleanup > > The update using flatMap looks good. I think we need to explore ad

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v3]

2020-09-15 Thread Alan Bateman
On Tue, 15 Sep 2020 13:40:29 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on >> different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces >> ordering based on `Archive` module names to >> ensure stable files (and file sign

Re: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming

2020-09-15 Thread Alan Bateman
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, mostly > in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: > Unnecessary import > src/java.naming/share/cla

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v2]

2020-09-15 Thread Alan Bateman
On Mon, 14 Sep 2020 22:54:34 GMT, Ian Graves wrote: >> Looks good to me. > > Updated to merge streams in line with @stuart-marks suggestion. There are several existing jlink tests that check that generated lib/modules is reproducible. Can we do more in these tests or add a new test that would i

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

2020-09-10 Thread Alan Bateman
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between >> a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I >> don't have a good general rule to su

Re: JDK-8252803: Add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit.

2020-09-10 Thread Alan Bateman
On 10/09/2020 10:44, Archana Nogriya wrote: Hi, I am requesting a proposal for the contribution to OpenJDK. I have created webrev with my changes. Moving to build-dev as that is normally where the linker options are discussed. I don't know if there is a significant need for Windows 32-bit bu

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

2020-09-10 Thread Alan Bateman
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug >> ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your >> change, they can file the Enhancement

Re: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError

2020-09-10 Thread Alan Bateman
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder > classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` > methods are invoked > unco

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

2020-09-10 Thread Alan Bateman
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I >> believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@sinc

Re: RFR: 8251495: Clarify DOM documentation

2020-09-09 Thread Alan Bateman
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/100

Re: How to proceed with 8138732

2020-09-09 Thread Alan Bateman
On 09/09/2020 09:27, Philippe Marschall wrote: Hello I started working on 8138732 [2] as described in the issue [1]. However the question about the impact and coordination with other projects came up, eg.:  - projects that implement their own intrinsics  - Graal  - somebody else? How do we wan

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package

2020-09-07 Thread Alan Bateman
On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I > believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

2020-09-06 Thread Alan Bateman
On 04/09/2020 21:55, Aleksei Voitylov wrote: Alan, here is a simpler version which, for the two tests in question, refers to a local helper class with a native method: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/ If there is a preference to avoid JNI, there is yet another alternati

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

2020-09-04 Thread Alan Bateman
On 04/09/2020 05:37, Yumin Qi wrote: HI, Sundar   Thanks for review. On 9/3/20 6:34 PM, sundararajan.athijegannat...@oracle.com wrote: Looks good to me. Few minor comment: * traceFileStream (and even the preexisting mainArgument) is accessed only inside GenerateJLIClassesPlugin. Could be pr

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

2020-09-04 Thread Alan Bateman
On 04/09/2020 10:00, Alan Bateman wrote: On 04/09/2020 08:55, Aleksei Voitylov wrote: : Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered was to

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

2020-09-04 Thread Alan Bateman
On 04/09/2020 08:55, Aleksei Voitylov wrote: : Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered was to detect the libc of the OS with ldd in the test

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

2020-09-03 Thread Alan Bateman
On 01/09/2020 12:41, Aleksei Voitylov wrote: Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in libjli/java_md.c), and Build groups before moving the JEP to Proposed to Target: ht

Re: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354

2020-09-03 Thread Alan Bateman
On 03/09/2020 10:22, jiefu(傅杰) wrote: Hi all, JBS:https://bugs.openjdk.java.net/browse/JDK-8252740 Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ After JDK-8252354, properties whose keys or values are none strings won't be skipped any more. Instead, ClassCastException will be

Re: RFR 8252248: __SIGRTMAX is not declared in musl libc

2020-08-28 Thread Alan Bateman
On 28/08/2020 15:32, Alexander Scherbatiy wrote:   I run the java/nio/channels tests with the fix. There are five failed tests that fail with and without the fix:     java/nio/channels/DatagramChannel/AdaptorMulticasting.java java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java    

Re: RFR 8252248: __SIGRTMAX is not declared in musl libc

2020-08-28 Thread Alan Bateman
On 28/08/2020 12:25, Alexander Scherbatiy wrote: Hello, Could you review the updated fix:   http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/  - moving shared code to net_util_md.h is avoided  - INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX - 2 for Linux in NativeThrea

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

2020-08-26 Thread Alan Bateman
On 21/08/2020 19:23, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr

Re: RFR(L) 8244778 Archive full module graph in CDS

2020-08-26 Thread Alan Bateman
the changes. Replies to your questions are in-line below. (1) Integrated updates in the Java code from Alan Bateman. Thanks for incorporating these changes, I don't have any other comments on the module changes. I see Mandy has reviewed that part too. -Alan

Re: RFR: JDK-8252113: Move jfr man page into jfr module

2020-08-26 Thread Alan Bateman
On 20/08/2020 18:58, Adam Farley8 wrote: Hi All, Should jfr.1 be moved from java.base to the jdk.jfr module source directory, as indicated here? Webrev: http://cr.openjdk.java.net/~afarley/8252113/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8252113 Seems right, on the surface at lea

Re: RFR 8252248: __SIGRTMAX is not declared in musl libc

2020-08-26 Thread Alan Bateman
On 25/08/2020 18:00, Alexander Scherbatiy wrote: Hello, Could your review the fix for the issue:   Bug: https://bugs.openjdk.java.net/browse/JDK-8252248   Fix: http://cr.openjdk.java.net/~alexsch/8252248/webrev.00/ : The fix has been discussed on the portola-dev alias [2] where it was pointe

Re: 8245304: Re-examine ThreadLocal usage in java.math.BigDecimal

2020-08-11 Thread Alan Bateman
On 11/08/2020 18:32, Brian Burkhalter wrote: To fix [1], please consider [2] which replaces the ThreadLocal “threadLocalStringBuilderHelper” with straightforward use of a StringBuilderHelper instance. The initial capacity of the StringBuilder instance variable of StringBuilderHelper is also do

Re: SoftCleanable and WeakCleanable

2020-08-01 Thread Alan Bateman
On 01/08/2020 10:23, Florian Weimer wrote: Are jdk.internal.ref.SoftCleanable and jdk.internal.ref.WeakCleanable actually used? CleanerTest rests them, but I don't see any other mentions of these classes. Do you mean used outside of the cleaner implementation? Maybe you are looking to change th

Re: [PING?] RFR(S): 8248910: NPE when freeing the memory for a slice from a buffer

2020-07-31 Thread Alan Bateman
On 31/07/2020 02:45, Yangfei (Felix) wrote: Ping... Any suggestions? Can you bring this to nio-dev for discussion? I don't know what "Randoop" is but it seems to be using sun.nio.ch.Util directly. I think I'd like to understand if there is a case where we would actually attempt to free a sli

Re: RFR [16/java.xml] 8249643: Clarify DOM documentation

2020-07-28 Thread Alan Bateman
On 28/07/2020 18:25, Joe Wang wrote: Hello, Please review a doc clarification for the org.w3c.dom package. JBS: https://bugs.openjdk.java.net/browse/JDK-8249643 CSR: https://bugs.openjdk.java.net/browse/JDK-8249904 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8249643/webrev_02/ If there is

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

2020-07-24 Thread Alan Bateman
On 24/07/2020 12:48, Volker Simonis wrote: : I can't see much complexity here. If you look at the change you'll see that it's rather trivial. All it does is substituting some direct calls into the zlib library by indirect calls through function pointers. I don't think the JDK should be in the

Re: RFR JDK-8250219: Proxy::newProxyInstance spec should specify the behavior if a given proxy interface is hidden

2020-07-23 Thread Alan Bateman
On 23/07/2020 19:40, Mandy Chung wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8250224 Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/ This patch updates the `|Proxy::newProxyInstance` |spec to explicitly list that the given interfaces must be non-hidden in

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

2020-07-23 Thread Alan Bateman
On 23/07/2020 18:18, Volker Simonis wrote: Hi, can I please get some reviews for the following small enhancement which will allow you to configure different zlib implementations at VM start-up and get up to 100% better throughput for compression and about 50% better throughput for decompression

Re: [15] RFR(S) : 8249700 : java/io/File/GetXSpace.java should be added to exclude list, and not @ignore-d

2020-07-19 Thread Alan Bateman
On 19/07/2020 05:28, Igor Ignatyev wrote: : the patch also includes minimal changes to make the test runnable on macosx, which reveled that the test might fail on macos. 8249703 has been filed for that issue and the appropriate changes are done in ProblemList.txt. webrev: http://cr.openjdk.jav

Re: addon to 8230613: Better ASCII conversions ?

2020-07-16 Thread Alan Bateman
On 16/07/2020 13:19, Baesken, Matthias wrote: Hi Alan, I do not have such a test case . Is there one for the change 8230613 ? The only call to Punycode.encode in IDN.java is below and the coding intends to catch java.text.ParseException from Punycode.encode and then throws an IllegalArgume

Re: addon to 8230613: Better ASCII conversions ?

2020-07-16 Thread Alan Bateman
On 16/07/2020 11:53, Baesken, Matthias wrote: Hello, recent change https://hg.openjdk.java.net/jdk/jdk/rev/9e70cd55ae08 8230613: Better ASCII conversions Adjusted one place in file Punycode.java to throw the declared ParseException in public static StringBuffer encode(StringBuffer

Re: RFR: 8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent

2020-07-16 Thread Alan Bateman
On 16/07/2020 10:19, Roman Kennke wrote: : I've just run it again with my setup and it all passes. You ok with the patch? Yes, I think it's okay to push. -Alan

Re: RFR: 8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent

2020-07-16 Thread Alan Bateman
On 15/07/2020 20:47, Roman Kennke wrote: : Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the default for all GCs but Shenandoah, and has been that way forever. Do you mean +ExplicitGCInvokesConcurrent?) Just surprised that more tests aren't impacted. RMI DGC wouldn't work with

Re: RFR: 8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent

2020-07-15 Thread Alan Bateman
On 15/07/2020 18:20, rken...@redhat.com wrote: DirectBufferAllocTest is unreliable when running with +ExplicitGCInvokesConcurrent, because allocating DBB spreads System.gc() calls all over concurrent GC cycles. It becomes more reliable when running with -ExplicitGCInvokesConcurrent. (Shenandoah d

Re: request for review JDK-8242935

2020-07-13 Thread Alan Bateman
On 02/07/2020 20:34, Ivan Sipka wrote: Hi all, please review the following changeset: http://cr.openjdk.java.net/~iignatyev/isipka/8242935/webrev.00/ for the JBS issue https://bugs.openjdk.java.net/browse/JDK-8242935 which replaces Nashorn scripting engine in a service reload test with servic

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

2020-07-12 Thread Alan Bateman
On 12/07/2020 23:21, Joe Wang wrote: Hi all, Alan updated the bug to indicate it fails since JDK 9. Given we still have a couple days for JDK 15, I've rebased the patch to the jdk15 repo and would like to check in the patch into JDK 15 instead (and let it be sync-ed to 16). Here's the webrev

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

2020-07-02 Thread Alan Bateman
On 30/06/2020 14:51, Seán Coffey wrote: : During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). Yes, signing should be additive so the origina

Re: RFR(T): 8248358: ProblemList sun/nio/ch/TestMaxCachedBufferSize.java on macOSX

2020-06-25 Thread Alan Bateman
On 25/06/2020 22:45, Daniel D. Daugherty wrote: Here's the context diff: $ hg diff diff -r cf65909b98c5 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt    Thu Jun 25 15:00:59 2020 -0400 +++ b/test/jdk/ProblemList.txt    Thu Jun 25 17:39:01 2020 -0400 @@ -630,6 +630,8 @@  java/nio/chan

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

2020-06-23 Thread Alan Bateman
On 23/06/2020 19:03, Mandy Chung wrote: Small clarification about the parent of the system class loader in the ClassLoader class spec: diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java b/src/java.base/share/classes/java/lang/ClassLoader.java --- a/src/java.base/share/classe

Re: RFR: 8248131: Simplify ServicesCatalog provider handling

2020-06-23 Thread Alan Bateman
On 23/06/2020 09:56, Claes Redestad wrote: Hi, the current implementation of ServicesCatalog uses an internal providers method, which is only used to add ServiceProviders. Providing an addProviders method instead means we can streamline this, to the tune of a very small startup win. Bug:    ht

Re: RFR 8245302: Upgrade LogRecord to support long thread ids and remove its usage of ThreadLocal

2020-06-22 Thread Alan Bateman
On 19/06/2020 10:00, Rahul Yadav wrote: Thank you Alan, updated webrev. webrev : http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html You've addressed the issues that I pointed out, I don't think I have any other comments. -Alan

Re: Undocumented exceptions in java.net.http.HttpClient.newHttpClient()

2020-06-22 Thread Alan Bateman
On 22/06/2020 16:39, Sebastian Stenzel wrote: Certain users of my software run into problems with HttpClient.newHttpClient() on JDK 14.0.1 and I don't feel like I can handle it properly without catching Errors. Calling said method fails when encountering Selector.open(), which in its Windows-

Re: RFR: [15,docs] JDK-8247959,doclint errors in NIO code

2020-06-20 Thread Alan Bateman
On 20/06/2020 04:35, Jonathan Gibbons wrote: Please review some fixes to address issues found by doclint. Looks good.

Re: [PATCH] remove redundant initialization of volatile fields with default values

2020-06-19 Thread Alan Bateman
On 19/06/2020 05:57, Сергей Цыпанов wrote: Hello, while investigating an issue I've found out that assignment of default value to volatile fields slows down object instantiation. Yes, there's been several efforts over the years to eliminate the initializing volatile fields to their default

Re: RFR 8245302: Upgrade LogRecord to support long thread ids and remove its usage of ThreadLocal

2020-06-19 Thread Alan Bateman
On 18/06/2020 23:37, Rahul Yadav wrote: Hi Alan, Thank you for the feedback.I have updated the webrev. webrev : http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html This looks quite good. The comment in shortShortID has "any positive long less than Integer.MAX_VALUE" but i

<    5   6   7   8   9   10   11   12   13   14   >