On 14/06/2021 9:34 pm, 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.
I too suggested and support this approach.
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 this reason, I'm proposing a minimal change allowing us to implement
Guard::check hooks at existing check points within the JVM using the
security provider mechanism that can be back-ported and supported on all
LTS releases, without any new Java API's.
We require authorization layer functionality, I will be implementing it,
and it will be freely available under an AL2.0 license.
It would be nice to keep AccessController and AccessControlContext and
use a property to enable or disable the stack walk for those who don't
require it, however they are now marked for removal, so I'll be looking
at using wrapper classes around them, so their implementations can be
replaced at a later data.
Our current implementation is high scaling with minimal performance
impact, however I can't make any promises regarding future performance,
but hopefully it will come to be as performant as our current
implementation.
Regards, Peter.
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.
Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler
<ron.press...@oracle.com <mailto: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 <mailto: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 <mailto: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
>>
>>
