Hello, sorry for being unpopular, but I just hate it to waste developer 
resources,

I realy think this deprecation message should be re-considered, it broke a lot 
of things, the amount of work to implement a caching solution feels like a 
waste of time and on top of it, there is no clear replacement strategy 
published yet.

I would restrict deprication (for removal if you really insist) to javadoc and 
not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no 
need to further damage java reputation by breaking perfectly working inter 
process interfaces. (This is btw true for all such warnings). And I also think 
top priority should be to publish a go-forward route which should not depend 
solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-r...@openjdk.java.net> im Auftrag von Daniel 
Fuchs <dfu...@openjdk.java.net>
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-...@openjdk.java.net <core-libs-...@openjdk.java.net>; 
security-dev@openjdk.java.net <security-dev@openjdk.java.net>
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager 
should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang <wei...@openjdk.org> wrote:

> Add a cache to record which sources have called `System::setSecurityManager` 
> and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
> 336:     }
> 337:

I wonder about the use of a WeakHashMap here. That may work well when the 
source is an interned string (a class name) which will be strongly referenced 
elsewhere and may be garbage collected if the class is unloaded, but in the 
case where it contains the name of the source jar then that string will only be 
referenced by the weak hashmap, and therefore it could be garbage collected any 
time - which would cause the mapping to be removed. In that case you cannot 
guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

Reply via email to