Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Thu, 2 Sep 2021 09:59:51 GMT, Daniel Fuchs wrote: >> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" >> via an AppContext to support "applet logging isolation". The AppContext >> class became useless since the plugin and webstart are no longer supported >> and removed in jdk11. >> >> This is the request to delete the usage of AppContext in the LogManager and >> related tests. >> >> Tested by tier1/tier2/tier3 and jdk_desktop tests. > > test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1: > >> 1: /* > > Humm... There's no direct reference to AppContext here. Maybe this test > should be preserved? It uses it indirectly, the next line under security manager trigger creation of the appcontext: `ImageIO.read(is); // triggers calls to system loggers & creation of main AppContext` but I can preserve/rename it for sure. - PR: https://git.openjdk.java.net/jdk/pull/5326
Withdrawn: 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE
On Wed, 23 Jun 2021 20:15:39 GMT, Jack Hartstein wrote: > 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4577
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and > related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Right. I am also a bit uncomfortable about the inconsistency. That said - if everybody agrees that this should be done I have no objection. The changes to the java.util.logging implementation correspond to my expectation if this were to be carried through. test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1: > 1: /* Humm... There's no direct reference to AppContext here. Maybe this test should be preserved? - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Perhaps this isn't the change that requires the CSR but it then leaves an > inconsistent state where desktop supports AppContext still but other modules > don't ... Even java.desktop does not support it fully, since for a couple of years nobody care about appcontext when write a new code. Note that I mentioned the "threadgroup sandboxing" in the subject, which is not necessary implemented via Appcontext. The JavaBeans and JavaSound use the thread group directly, I plan to remove them as well. - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and > related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. @aivanov-jdk will help make sure the closed changes are pushed at exactly the same time as this gets pushed. - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and > related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ... - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and > related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. I believe we should have a CSR for this. It removes a long standing capability in the platform that was used by components such as plugin and webstart. - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and > related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. This fix requires coordinated closed changes so needs an Oracle sponsor. And actually is probably better handled entirely by an Oracle engineer because pushes need to be very co-ordinated. - PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped
On Thu, 2 Sep 2021 13:33:30 GMT, Fernando Guallini
wrote:
> This trivial change fixes the case 2 in test
> sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method
> testKeySpec is expecting a class object of type KeySpec as second argument in
> order to be reusable for multiple test scenarios, but then instead of using
> that argument the RSAPrivateKeySpec.class is hardcoded:
>
>
> private static void testKeySpec(KeyFactory factory, PrivateKey key, Class extends KeySpec> specClass) throws Exception {
> try {
> KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);
>
>
> it should be:
>
> `KeySpec spec = factory.getKeySpec(key, specClass);
> `
Marked as reviewed by mullan (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5351
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 The security related changes look fine to me. - Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328
