Re: RFR: 8295231: Move all linking of native libraries to make
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote: > Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Marked as reviewed by ihse (Reviewer). Wow. I did not even know this was possible. Thank you for fixing this! I would have been mighty surprised if I were to learn that a library has more dependencies than the one in the makefile. @dholmes-ora The point is that we need to be consistent. If we would go that route, then *all* libraries should be loaded by pragmas. That could of course be an alternative, but I really see no upside to it. To do it like we currently do, load 99% of the libraries via make files, and then have few scattered pragmas, that's just bad. @TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well? - PR: https://git.openjdk.org/jdk/pull/10633
RFR: JDK-8295405 : Add cause in a couple of IllegalArgumentException and InvalidParameterException shown by sun/security/pkcs11 tests
We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see https://bugs.openjdk.org/browse/JDK-8295343 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6 The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace. - Commit messages: - JDK-8295405 Changes: https://git.openjdk.org/jdk/pull/10726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295405 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10726/head:pull/10726 PR: https://git.openjdk.org/jdk/pull/10726
Re: RFR: 8295231: Move all linking of native libraries to make
On Mon, 17 Oct 2022 09:24:58 GMT, Magnus Ihse Bursie wrote: > @TheShermanTanker Question: is this a Windows-specific thing, or are there > pragma-loaded libraries for other compilers as well? To my knowledge only Visual C++ has the ability to perform linking through pragmas, the comment pragma works by leaving a linker comment in the object file (hence the name), meaning this only works with the Visual C++ linker, so while clang does support this pragma with clang-cl, for the use cases in the JDK it wouldn't matter. gcc does not have an equivalent pragma (or provide support for linking from inside source files at all, for that matter) > If the methods are equivalent, I prefer linking via make file. There isn't any difference between the 2 unless the library is tampered with by `-nodefaultlib`, but I can only find that specified in https://github.com/openjdk/jdk/blob/a033aa5a3d9c63d72d11af218b9896b037fbd8de/make/autoconf/flags-other.m4#L38 and https://github.com/openjdk/jdk/blob/392f35df4be1a9a8d7a67a25ae01230c7dd060ac/make/autoconf/lib-hsdis.m4#L45, neither of which have an effect on the libraries in this changeset - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v2]
> Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - user32 - Mswsock.lib requirement - Changes: - all: https://git.openjdk.org/jdk/pull/10633/files - new: https://git.openjdk.org/jdk/pull/10633/files/cfa80528..54e6ec10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633 PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v3]
> Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Update Guid.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/10633/files - new: https://git.openjdk.org/jdk/pull/10633/files/54e6ec10..fe15f907 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633 PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v3]
On Sun, 16 Oct 2022 13:18:14 GMT, Alan Bateman wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update Guid.cpp > > src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38: > >> 36: >> 37: #include >> 38: #pragma comment(lib, "Mswsock.lib") > > I think this came about with one of the early Microsoft contributions to have > transferTo optionally use TransmitFile on Windows. This created the > dependency on Mswsock. It's not clear why a pragma was used though. I believe it may have had to do with explicitly showing the dependency as David suggests, I added a comment explaining this just in case - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v4]
> Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Julian Waters has updated the pull request incrementally with five additional commits since the last revision: - Update WinSysInfo.cpp - Update WinApp.cpp - Update MsiUtils.cpp - Update MsiDb.cpp - Update MsiCA.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/10633/files - new: https://git.openjdk.org/jdk/pull/10633/files/fe15f907..8afaf85d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02-03 Stats: 12 lines in 5 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633 PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v5]
> Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Update WindowsRegistry.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/10633/files - new: https://git.openjdk.org/jdk/pull/10633/files/8afaf85d..0779d1fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633 PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v4]
On Mon, 17 Oct 2022 14:31:46 GMT, Julian Waters wrote: >> Some external libraries required by native code are linked via linker >> comments embedded in pragmas. Searching for which libraries are linked can >> then become frustrating and confusing since they may be included in an >> obscure place, and for all relevant compilers there is no difference between >> specifying them from make and in a source file. The easiest solution is to >> just always link them from make and remove any source level linkage. > > Julian Waters has updated the pull request incrementally with five additional > commits since the last revision: > > - Update WinSysInfo.cpp > - Update WinApp.cpp > - Update MsiUtils.cpp > - Update MsiDb.cpp > - Update MsiCA.cpp Thanks all for the reviews, I placed comments where the pragmas used to be detailing the library required by the source file to address David's concerns - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v6]
> Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Formatting - Changes: - all: https://git.openjdk.org/jdk/pull/10633/files - new: https://git.openjdk.org/jdk/pull/10633/files/0779d1fa..4eb2eb7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633 PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v6]
> ### Summary of the change > This change introduces new system and security properties for specifying > factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider > implementations. > > These new properties allow more granular control over the set of object > factories allowed to reconstruct Java objects from LDAP and RMI contexts. > > The new factory filters are supplementing the existing > `jdk.jndi.object.factoriesFilter` global factories filter to determine if a > specific object factory is permitted to instantiate objects for the given > protocol. > > Links: > > - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556) > - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368) > > ### List of code changes > > - Implementation for two new system and security properties have been added > to the `com.sun.naming.internal.ObjectFactoriesFilter` class > - `java.security` and `module-info.java` files have been updated with a > documentation for the new properties > - To keep API of `javax.naming.spi.NamingManager` and > `javax.naming.spi.DirectoryManager` classes unmodified a new internal > `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All > `getObjectInstance` calls have been updated to use the new helper class. > > NamingManagerHelper changes > Changes performed to construct the `NamingManagerHelper` class: > - `DirectoryManager.getObjectInstance` -> > `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved > to the `NamingManagerHelper` class > - `NamingManager.getObjectInstance` -> > `NamingManagerHelper.getObjectInstance`. Methods responsible for > setting/getting object factory builder were moved to the > `NamingManagerHelper` class too. > > > ### Test changes > New tests have been added for checking that new factory filters can be used > to restrict reconstruction of Java objects from LDAP and RMI contexts: > - LDAP protocol specific test: > test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java > - RMI protocol specific test: > test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java > Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated > to allow test-specific factories filter used to reconstruct objects from the > test LDAP server. > > ### Testing > tier1-tier3 and JNDI regression/JCK tests not showing any failures related to > this change. > No failures observed for the modified regression tests. Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Update filter docs to match implementation. - Changes: - all: https://git.openjdk.org/jdk/pull/10578/files - new: https://git.openjdk.org/jdk/pull/10578/files/b3849168..4449dda1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=04-05 Stats: 10 lines in 3 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10578.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578 PR: https://git.openjdk.org/jdk/pull/10578
Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v5]
On Fri, 14 Oct 2022 17:45:50 GMT, Roger Riggs wrote: > In the general composition of filters, it is preferable that UNDECIDED is > treated as REJECTED. > That keeps unintentional holes in a filter from being permissive. That is a good point Roger. The "java.security" file was updated (4449dda) to match the `ObjectFactoriesFilter` implementation, ie the global filter treats UNDECIDED as REJECTED. Also, the CSR has been updated to highlight that. - PR: https://git.openjdk.org/jdk/pull/10578
Re: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
> This task converts 5 manual tests to automated tests. > > sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java > sun/security/provider/PolicyParser/ExtDirsChange.java > sun/security/provider/PolicyParser/ExtDirs.java > java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java > javax/crypto/CryptoPermissions/InconsistentEntries.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Refactored to use testng framework for test enviroment setup. - Changes: - all: https://git.openjdk.org/jdk/pull/10637/files - new: https://git.openjdk.org/jdk/pull/10637/files/5a47cacd..4911518e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=00-01 Stats: 83 lines in 2 files changed: 10 ins; 29 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/10637.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637 PR: https://git.openjdk.org/jdk/pull/10637
Re: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
On Fri, 14 Oct 2022 15:50:30 GMT, Bill Huang wrote:
>> test/jdk/java/security/Policy/Root/Root.java line 48:
>>
>>> 46: private static final Path TARGET = Paths.get(ROOT, ".java.policy");
>>> 47: public static void main(String[] args) throws Exception {
>>> 48: Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);
>>
>> Could you please use the testng framework for initial setup of test.
>
> This is a @driver test that copies the Root.policy file to the home directory
> before running the RootTest in a new JVM. The reason is that upon the start
> of the new JVM it loads the default system-wide policy file and the default
> user policy file which is the Root.policy we just copied. With the testng
> framework, there is no way to load the custom user policy file without
> reinstalling the security manager in the test, that said, it doesn't match
> what the manual test does.
Discussed with Mahendra offline, testng framework `@BeforeTest` performs test
setup in the client JVM before test starts in the other JVM. We can use testng
framework in this case to handle the policy file operations.
-
PR: https://git.openjdk.org/jdk/pull/10637
Re: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
> This task converts 5 manual tests to automated tests. > > sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java > sun/security/provider/PolicyParser/ExtDirsChange.java > sun/security/provider/PolicyParser/ExtDirs.java > java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java > javax/crypto/CryptoPermissions/InconsistentEntries.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: AssertThrows an exception in InconsistentEntries test. - Changes: - all: https://git.openjdk.org/jdk/pull/10637/files - new: https://git.openjdk.org/jdk/pull/10637/files/4911518e..cfb9f74d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01-02 Stats: 9 lines in 1 file changed: 1 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10637.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637 PR: https://git.openjdk.org/jdk/pull/10637
Re: RFR: JDK-8295405 : Add cause in a couple of IllegalArgumentException and InvalidParameterException shown by sun/security/pkcs11 tests
On Mon, 17 Oct 2022 10:42:18 GMT, Matthias Baesken wrote: > We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see > > https://bugs.openjdk.org/browse/JDK-8295343 > 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6 > > The exceptions generated by these tests sometimes miss the cause (causing > exception), it would be nice to have this added to get the complete exception > backtrace. There are several other files in the pkcs11 directory where cause is missing from the thrown exception. Might as well fix them all. - PR: https://git.openjdk.org/jdk/pull/10726
Re: RFR: 8295231: Move all linking of native libraries to make [v6]
On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters wrote: >> Some external libraries required by native code are linked via linker >> comments embedded in pragmas. Searching for which libraries are linked can >> then become frustrating and confusing since they may be included in an >> obscure place, and for all relevant compilers there is no difference between >> specifying them from make and in a source file. The easiest solution is to >> just always link them from make and remove any source level linkage. > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Formatting The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating. - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v6]
On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters wrote: >> Some external libraries required by native code are linked via linker >> comments embedded in pragmas. Searching for which libraries are linked can >> then become frustrating and confusing since they may be included in an >> obscure place, and for all relevant compilers there is no difference between >> specifying them from make and in a source file. The easiest solution is to >> just always link them from make and remove any source level linkage. > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Formatting Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v6]
On Mon, 17 Oct 2022 17:16:21 GMT, Alexey Semenyuk wrote: > The change looks harmless. Howevere I don't understand how searching for the > standard Windows libs can then become frustrating. I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293. - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: 8295231: Move all linking of native libraries to make [v6]
On Mon, 17 Oct 2022 17:37:11 GMT, Erik Joelsson wrote: > I believe this is part of the effort for > https://bugs.openjdk.org/browse/JDK-8288293. Agree. I'd prefer to have a different description of the bug though to make it clear that this is necessary for decoupling a compiler and an OS. - PR: https://git.openjdk.org/jdk/pull/10633
RFR: JDK-8293681 ResponseAPDU getData() method javadoc
https://bugs.openjdk.org/browse/JDK-8293681 - Commit messages: - first iteration Changes: https://git.openjdk.org/jdk/pull/10732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10732&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293681 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10732.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10732/head:pull/10732 PR: https://git.openjdk.org/jdk/pull/10732
Integrated: 8295231: Move all linking of native libraries to make
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote: > Some external libraries required by native code are linked via linker > comments embedded in pragmas. Searching for which libraries are linked can > then become frustrating and confusing since they may be included in an > obscure place, and for all relevant compilers there is no difference between > specifying them from make and in a source file. The easiest solution is to > just always link them from make and remove any source level linkage. This pull request has now been integrated. Changeset: 8d751de3 Author:Julian Waters Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/8d751de3198675b22704cdccafaff2fc0fdd3f59 Stats: 26 lines in 14 files changed: 3 ins; 6 del; 17 mod 8295231: Move all linking of native libraries to make Reviewed-by: ihse, erikj - PR: https://git.openjdk.org/jdk/pull/10633
Re: RFR: JDK-8293681 ResponseAPDU getData() method javadoc
On Mon, 17 Oct 2022 17:45:13 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8293681 Looks good. Thanks~ - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.org/jdk/pull/10732
