On 6/14/21 7:34 AM, Rafael Winterhalter wrote:
Why not add the property once this is the case, though? As it is now, I
read the 'forRemoval' property to indicate a problem that should be
instantly addressed. With Java 8 being a common baseline for libraries and
the version being supported until (at least) 2030, I don't see how this
removal would have a low impact within the next decade, if ever. Shouldn't
the property be set if the removal is within reach? To some degree, I would
expect that any deprecated API could be removed once it is no longer used.
>
As it is now, library maintainers face the choice of breaking their support
for current users that are on Java 8/11 and rely on the security manager,
or to remove their support to accommodate a Java release that might be many
years in the future. For my part, supporting the security manager seems to
be the right choice as things stand today. Over the years, I would expect
that fewer and fewer people rely on the security manager, where this
balance might shift. I would hope that the 'forRemoval' property would
serve as an indicator at that time to tell library maintainers that usage
of the security manager has decreased so much that it is time to remove the
library support, too. I see the reason for a strong signal, deprecation
already is such a signal, but if you give the full blow today, it is no
longer available in the future where it might be more relevant to give.
As Alan and others have mentioned, there is no immediate plan to remove
the APIs that SM-enabled libraries are typically dependent on, i.e.,
AccessController.doPrivileged and System.getSecurityManager. The APIs,
when degraded will behave as if the Security Manager was not enabled. It
isn't clear to me why that plan would have a high compatibility impact
for libraries.
And in JDK 17, the Security Manager will still be fully supported.
The 'forRemoval' property means that the API is earmarked for removal in
a future release. This is important, as it provides a clear warning bell
to those that are dependent on it that it will eventually be going away.
On the other hand, if an API is only deprecated, there is no intention
to remove it. Users usually can still expect the API to continue to work
as specified. It isn't as strong enough of a signal that it should not
be used and in my opinion would only delay the removal of the Security
Manager for many more years.
I also think it would be more confusing, and possibly wrong to degrade
or "stub" a deprecated API (one that is not marked forRemoval) such that
it is a no-op or basically no longer works as expected.
--Sean
Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler <
ron.press...@oracle.com>:
The JEP addresses this:
In future JDK releases, we will degrade the Security Manager APIs so
that they
remain in place but have limited or no functionality. ... This will allow
libraries
that support the Security Manager and were compiled against previous Java
releases
to continue to work without change or even recompilation. We expect to
remove the
APIs once the compatibility risk of doing so declines to an acceptable
level.
If your question is, when only few codebases will refer to the API and the
compatibility impact is low enough for it to be removed, what if some of
those
few libraries still want to support versions prior to the removal, the
answer is
the same as with all removals (MR-JARs, or multiple artefacts). By
definition,
the impact of complete removal when the impact is low, would be low.
— Ron
On 14 Jun 2021, at 09:38, Rafael Winterhalter <rafael....@gmail.com>
wrote:
One example for a currently necessary "doPrivileged" are Java agents
where
a class loading triggers agent code where the agent shares the stack with
any code that loads a class for the first time. Otherwise, Byte Buddy
wraps
anything that might require privileges as privileged action to allow
setting a policy that gives Byte Buddy for example access to class
loaders,
system properties or other things that the security manager currently
checks. There's many uses of the security manager throughout the library,
in the spirit of the API's invention.
I could, of course, rip this code out of the library. But this would make
it impossible for users that choose to use the functionality for now to
update their dependency. This would certainly hinder a smooth transition
as
library maintainers will always have people drag at both ends of the JDK
version range. After all, Java 8 is supported for another decade.
Multi-release jars are neither a feasible option. They are not globally
supported by all class loaders, and would require me to add a copy of an
adjusted class file for any Java version prior to the removal version or
upwards from there. I don't think that this should be addressed by
tooling
if keeping deprecated skeletons of the API can so easily avoid this
entire
problem for all libraries without the need to chase down maintainers.
Therefore, I really think that the SecurityManager and AccessController
APIs should remain as skeletons and be deprecated, but not be marked
forRemoval, especially without a clear roadmap for the actual removal
forward. And while I appreciate the clean up effort - I do think the
SecurityManager deprecation and feature removal is a right decision - I
find the attempt to remove this API will cause unnecessary breakage and
cause thousands of libraries to become unlinkable on future VM, without a
clear need for it. Discovering this breakage would also require manually
scanning the content of each library and affect all the big names in the
industry. This would require big waves of dependency updates, where such
updates sometimes will be impossible if only a single (transitive)
dependency has not catched up, including major names such as Spring,
Hibernate or Mockito. From experience, such major updating waves are
often
complex and therefore avoided, which will hinder adoption of future JVM
versions. This seems like a very high price to pay which could be easily
avoided by only keeping a handful of skeleton classes.
Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the first of several in a multi-release/multi-year effort.
It's way too early to give any guess as to when the APIs will be
removed. As the JEP says, future releases may degrade the SM APIs so
that System.getSM returns always returns null or
AccessController::doPriv just runs the action. This should mean that
libraries that are compiling to older releases should continue to
compile and run on those releases. When they run on some future release
that degrades the implementation then it will be as if there is no SM.
So I would say the impact is little to none for libraries for the
foreseeable future.
-Alan
On 13/06/2021 21:28, Rafael Winterhalter wrote:
I am currently looking into how I should address JEP 411 in my library
Byte
Buddy and I find it rather challenging. The problem I am facing is
that I
know of several users who rely on the security manager in their Java
8/11
applications. I would like to continue to support those users' use
cases
as
long as I support Java versions that contain the security manager,
which
will be for many years to come. At the same time, I would like to
address
the announced removal of the API and make sure that Byte Buddy can work
without it prior to the deadline when the library in its current state
would no longer link.
From my understanding of the intention of JEP 411, the API was supposed
to
be stubbed – similar to Android’s stubbing of the API - rather than
being
removed. However, with the announced deprecation for removal of
AccessController and SecurityManager, I understand that I would need to
fully remove the dispatching to work with future Java versions.
Furthermore, it is difficult to create a working facade for dispatching
to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a
utility
to a library, this utility would leak to any potential user. It would
therefore require package-private dispatchers for any relevant package,
which would lead to a lot of copy-paste to retain backwards
compatibility
(given that a library cannot assume to be run as a module).
Finally, removing the API would mean that Byte Buddy versions of the
last
ten years would no longer link in future JDKs. For Byte Buddy where new
Java versions often require an update, that might not be a big issue
but
many other libraries do support the API, I don’t feel it would be a
rather
severe restriction and cause unnecessary breakage if API is removed,
rather
than stubbed. I am thinking of libraries like Netty here which are
rather
omnipresent and would suddenly no longer link, a concept that is
unlikely
intuitive to a lot of developers.
Therefore, my question is: should SecurityManager, AccessController and
the
Policy APIs really be deprecated for removal? Rather, I think that the
APIs
should be deprecated, but be retained with stubbed implementations.
System.getSecurityMananger would then always return null.
System.setSecurityManager on the other hand could be deprecated for
removal. This way, existing code could continue to work as if the
security
manager is not active, which already is the common scenario and would
not
cause any disruption at the small price of keeping a handful of some
stubbed classes.
Thanks for advice on how this is intended to be handled by library
developers like me.
Best regards, Rafael
