Re: zlib before 1.2.12 allows memory corruption (CVE-2018-25032)

Hi Bernd, Vitaly, Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This is our statement: "Based upon our analysis, OpenJDK/Corretto is not affected by CVE-2018-25032, because the zlib "memLevel" parameter is not settable and is fixed at 8, and the usage of the Z_FIXED strategy is

Re: JDK-8129988 introduces a new behavior when reading the javax.net.ssl.trustStore property.

Hi, I'd like to resurrect this old discussion which seems to have got lost. David has analyzed and described the behavioral differences introduced by JDK-8219988 around the handling of the "javax.net.ssl.trustStore" property pretty well in his initial mail (see below). The main difference is tha

Re: RFR: 8270317: Large Allocation in CipherSuite [v6]

On Fri, 23 Jul 2021 17:11:30 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark >> (cipherSuite) Mode CntScore Error Units >> CipherSuiteBench.b

Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

On Thu, 11 Mar 2021 16:33:10 GMT, Xue-Lei Andrew Fan wrote: >> This is my implementation for >> [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables >> creating of an SSL/TLS key log in the standardized [NSS Key Log >> Format](https://developer.mozilla.org/en-US/docs/Moz

Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

On Tue, 9 Mar 2021 17:18:39 GMT, SalusaSecondus wrote: > This is my implementation for > [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables > creating of an SSL/TLS key log in the standardized [NSS Key Log > Format](https://developer.mozilla.org/en-US/docs/Mozilla/Pro

Integrated: 8259582: Backout JDK-8237578 until all affected tests have been fixed

On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few > internal and external tests to fail (see > [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK

RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed

[JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn

Withdrawn: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

On Mon, 11 Jan 2021 17:24:23 GMT, Volker Simonis wrote: > JDK-8237578 exposes some SocketExceptions directly which were previously > wrapped inside an SSLException. The change updated one test to take this new > behaviour into account (i.e. TrustTrustedCert.java) but apparently missed

RFR: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

JDK-8237578 exposes some SocketExceptions directly which were previously wrapped inside an SSLException. The change updated one test to take this new behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other tests. The fix for the other tests is similar like the fix for Tr

Re: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6]

On Mon, 11 Jan 2021 12:00:09 GMT, Volker Simonis wrote: >> Clive Verghese has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > > Looks

Re: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6]

On Sun, 10 Jan 2021 06:56:17 GMT, Clive Verghese wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly >> being wrapped as SSLException. Some work for this was done in >> [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that >> change did no

Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985

On Thu, 29 Oct 2020 17:14:17 GMT, Xue-Lei Andrew Fan wrote: >> It seems that there exists a memory/performance regression that was >> introduced with JDK-8210985: Update the default SSL session cache size to >> 20480. >> >> The idea to limit the maixmum SSL session cache size by itself is good

Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985

On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote: > It seems that there exists a memory/performance regression that was > introduced with JDK-8210985: Update the default SSL session cache size to > 20480. > > The idea to limit the maixmum SSL session cache size by itself is good. > Un

Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985

On Thu, 29 Oct 2020 16:45:01 GMT, Christoph Langer wrote: >>> > Did you have a benchmark with various cache sizes (for example, from 1 to >>> > 10K) and various connections (for example from 1 to 10K) for those >>> > components (including TLS implementation) that use Cache? >>> >>> Nope, we've

Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985

On Thu, 29 Oct 2020 16:01:19 GMT, Christoph Langer wrote: >> Did you have a benchmark with various cache sizes (for example, from 1 to >> 10K) and various connections (for example from 1 to 10K) for those >> components (including TLS implementation) that use Cache? > >> Did you have a benchmark

Integrated: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

On Tue, 6 Oct 2020 10:02:09 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

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

On Wed, 14 Oct 2020 16:31:32 GMT, Lance Andersen wrote: > Mach5 run is clean :-) Thanks a lot Lance. Just waiting for the CSR to get approved now. - PR: https://git.openjdk.java.net/jdk/pull/520

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.java.n

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

On Tue, 13 Oct 2020 19:56:50 GMT, Lance Andersen wrote: >> Volker Simonis has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > >

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

On Wed, 14 Oct 2020 10:48:55 GMT, Volker Simonis wrote: >> test/jdk/java/util/zip/CopyZipFile.java line 104: >> >>> 102: // all these fields set to '-1'. >>> 103: InputStream is = new FileInputStream(ZIP_FILE); >>> 104:

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

On Tue, 13 Oct 2020 18:50:00 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 87: >> >>> 85: * >>> 86: * The current time will be used if the entry has no set >>> modification >>> 87: * time. >> >> I'm happy with the wording. Wha

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

On Tue, 13 Oct 2020 17:16:21 GMT, Lance Andersen wrote: >> Volker Simonis 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. > > test/jdk/java/util/z

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.java.n

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.java.n

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

On Mon, 12 Oct 2020 15:42:45 GMT, Lance Andersen wrote: >> Volker Simonis has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. The >> pull

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.ja

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

On Sun, 11 Oct 2020 22:14:18 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 189: >> >>> 187: * {@code ZipEntry.DEFLATED}) entries when {@link >>> ZipEntry#setCompressedSize(long)} >>> 188: * has not been explicitly called on the {@cod

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.java.n

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

On Wed, 7 Oct 2020 16:45:53 GMT, Volker Simonis wrote: >> I think as we start to move forward with the review and CSR, we should >> update the bug and PR description as the change >> is not a workaround but a change in behavior of the implementation > > I already change

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

uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158 > [2]: > https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86 > [3]: https://bugs.openjdk.java.n

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to ignore ZipEntry's compressed size

On Wed, 7 Oct 2020 16:09:47 GMT, Lance Andersen 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 a

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to ignore ZipEntry's compressed size

On Wed, 7 Oct 2020 15:34:32 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 97: >> >>> 95: * and re-compute its value automatically after the associted data >>> has been >>> 96: * completely deflated. >>> 97: * >> >> We probably

RFR: 8253952: Work around wrong usage of ZipOutputStream.putNextEntry() in user code

### 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 a ZipEntry obtained from `ZipInputStream.getNextEntry()`, `ZipFile.entries()`, `

Re: [8u] RFR: 8233223: Add Amazon Root CA certificates

On Thu, Dec 19, 2019 at 11:09 AM Severin Gehwolf wrote: > > Hi Volker, > > On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote: > > Hi Severin, > > > > not strictly a 8u "Reviewer" yet, but I've looked at your changes > > (this one and

Re: [8u] RFR: 8233223: Add Amazon Root CA certificates

Hi Severin, not strictly a 8u "Reviewer" yet, but I've looked at your changes (this one and 8232019) nevertheless :) They both look good, except that I can not verify the new "cacert" file because it is not in the patch (because it is binary). Not sure if it is necessary to upload the whole file

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Alan, thaks for looking at the javadoc/CSR. On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman wrote: > > On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > > > I’ve amended the jdk.zipfs module documentation in > src/jdk.zipfs/share/classes/module-info.java to document the new behavior > (

Re: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions)

Hi Alan, thanks for looking at this issue. I've dived into the ZipFS implementation during the last weeks and together with Christoph we've extended and improved both the implementation the test coverage. As Christoph already emphasized, this change is only for improving jdk.nio.zipfs without any

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Christoph, thanks for updating the change. I think it is in a good state now and ready to go! Also the documentation in the CSR for this issue ( https://bugs.openjdk.java.net/browse/JDK-8213082) is greatly appreciated and answers all the questions which have been raised so far. So if there are

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

/bugs.openjdk.java.net/browse/JDK-8213031 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ > > > > Thanks > > Christoph > > > > From: Langer, Christoph > Sent: Montag, 29. Okt

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

Hi Magnus, thanks for addressing this long standing issue! I haven't looked at the changes, but just want to share some general and historical notes: - Compiling with "-fvisibility=hidden" which hides all symbols expect the ones explicitly exported with "__attribute__((visibility("default")))" ha

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 7:55 PM, Magnus Ihse Bursie wrote: > > On 2017-12-05 18:33, Sean Mullan wrote: >> >> On 12/5/17 12:01 PM, Volker Simonis wrote: >>> >>> Hi Rajan, >>> >>> 'cacerts' is a binary file and I thought we have at le

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

Hi Rajan, 'cacerts' is a binary file and I thought we have at least the convention in the OpenJDK project that we don't want to check in binary artefact's if possible. One problem with 'cacerts' being a binary file is that we can not add a license and copyright to it. Another one is that it is ha

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 10:08 AM, Magnus Ihse Bursie wrote: > On 2017-12-05 09:44, Volker Simonis wrote: >> >> On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie >> wrote: >>> >>> On 2017-12-01 18:16, Volker Simonis wrote: >>>> >&g

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie wrote: > On 2017-12-01 18:16, Volker Simonis wrote: >> >> Hi Rajan, >> >> great to see this finally happen! >> >> I have just a quick question related to the tests. As far as I can >> see, the tests w

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Fri, Dec 1, 2017 at 7:09 PM, Sean Mullan wrote: > On 12/1/17 12:22 PM, Alan Bateman wrote: >> >> >> >> On 01/12/2017 17:16, Volker Simonis wrote: >>> >>> Hi Rajan, >>> >>> great to see this finally happen! >>> >>>

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Fri, Dec 1, 2017 at 6:22 PM, Alan Bateman wrote: > > > On 01/12/2017 17:16, Volker Simonis wrote: >> >> Hi Rajan, >> >> great to see this finally happen! >> >> I have just a quick question related to the tests. As far as I can >> see, the t

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

Hi Rajan, great to see this finally happen! I have just a quick question related to the tests. As far as I can see, the tests will only succeed if the OpenJDK will be build with the new open sourced, Oracle root certificates. But what if somebody is building the OpenJDK with his own set of root c

Re: JPMS Access Checks, Verification and the Security Manager

Thanks Alex, that makes sense. Regards, Volker On Fri, Jun 2, 2017 at 2:13 AM, Alex Buckley wrote: > On 5/24/2017 12:13 AM, Volker Simonis wrote: >> >> OK, so from what you say I understand that the verification errors I >> see with the Security Manager enabled are an imp

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:01 PM, Alex Buckley wrote: > On 5/23/2017 7:44 AM, Volker Simonis wrote: >> >> So maybe I rephrase my question a little more generally: >> >> Is it required for the verifier to do security and/or access checks >> during the verific

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:20 AM, Alan Bateman wrote: > Volker - one suggestion for your experiments is to change your JDK 8 > security properties file (java.security) to add "com.sun.crypto.provider." > to the value of the "package.access" property. That should mean you will get > the same Access

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:51 AM, David Holmes wrote: > On 23/05/2017 6:20 PM, Alan Bateman wrote: >> >> Volker - one suggestion for your experiments is to change your JDK 8 >> security properties file (java.security) to add "com.sun.crypto.provider." >> to the value of the "package.access" proper

JPMS Access Checks, Verification and the Security Manager

Hi, my question is if it is OK for a program which otherwise runs fine to fail during class verification if running with a security manager because of module access restrictions? As the following write-up got a little lengthy, I've also uploaded a html version for a nicer reading experience :) h

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

ote: >> >> Looks good. I will run hotspot compiler pre-integration testing and let >> you know results. >> >> Thanks, >> Vladimir >> >> On 3/30/16 3:29 AM, Volker Simonis wrote: >>> >>> Hi everybody, >>> >>> here fi

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

t let me > know when you are ready for code review on this piece. > > thanks > > Tony > > > > > On 03/29/2016 06:05 AM, Volker Simonis wrote: >> >> Hi Anthony, Vladimir, >> >> thanks for your evaluation. Should I open a new bug for the change in

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

Hi Anthony, Vladimir, thanks for your evaluation. Should I open a new bug for the change in AESCrypt or can we do it under the same bug id like the ppc-specific AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? I also think that the AESCrypt::sessionK type change change, although it

Re: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64

Resend to core-libs-dev to attract a broader audience :) On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis wrote: > Hi, > > can somebody please review the following trivial fix to enable the > pkcs11 tests for linux/ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/201

RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64

Hi, can somebody please review the following trivial fix to enable the pkcs11 tests for linux/ppc64: http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ https://bugs.openjdk.java.net/browse/JDK-8140514 The pkcs11 tests need to load the native library libnss3.so the location of which is sys

RFR(XS): 8132551: Initialize local variables before returning them in p11_convert.c

Hi, can somebody please review these trivial change which initializes local variables before they are returned as return values: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132551 https://bugs.openjdk.java.net/browse/JDK-8132551 Funny enough, this was objected by the Visual Studio compiler

RFR(S): 8035881: PPC64: Fix AIX build in ppc-aix-port/stage after syncing 7133499 and 8028293 from jdk8u

Hi, please review the following small AIX-only change for ppc-aix-port/stage (and eventually jdk8u) which became necessary after we have synced the following two changes from jdk8u: 8028293: Check local configuration for actual ephemeral port range 7133499: (fc) FileChannel.read not preempted by

RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev

Hi, please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8033154/ which fixes the AIX build after the integration of ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. I would ideally like to push this change to jdk9/hs-comp/jdk because that's the only repository where t

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

again, Volker > > Thanks, > > Artem > > On 11/20/2013 10:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on AIX >> <https://bugs.openjdk.jav

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

/sun/management/OperatingSystemImpl.c. Fortunately, my changes to UnixOperatingSystem_md.c described in the webrev apply cleanly to the new file (I've tested this locally). I'll update the webrev accordingly once I've collected some more feedback. Thank you and best regards, Volker On Wed, Nov 20, 2

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

6997010 > > Thanks, > Sean > > On 11/20/2013 01:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on >> AIX<https://bugs.openjdk.java.net/browse/

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

e AWT/2D guys. As far as I understood, you've now reviewed the 'core-lib'/'net' parts right? That would mean that I'll still need a review from the AWT/2D and the Security group - any volunteers:). Once again thanks a lot for your help, Volker On Fri, Nov 22, 2

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

will now call 'aix_close_init()' as suggested by Alan. The changes to src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c are now in src/solaris/native/sun/management/OperatingSystemImpl.c because that file was moved by an upstream change. On Wed, Nov 20, 2013 at 7:26 PM, Volk

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

tps://bugs.openjdk.java.net/browse/JDK-8024900) This change only contains the additional make changes which became necessary after I started to move AIX-specific files into their own jdk/src/aix/ directory. Everything else is already in place. I'll prepare and test a finaly webrev with all t

RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

Hi, this is the second review round for "8024854: Basic changes and files to build the class library on AIX". The previous reviews can be found at the end of this mail in the references section. I've tried to address all the comments and suggestio