> On 20 Jun 2023, at 06:26, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's > just OpenJDK is also undoing years of tested and hardened API's,
You probably meant that as a bad thing, but I read it as thank you for serving your users! Our duty is to maximise the utility of the JDK. The reality of the economics of software — in this case, the finite resources available to us — demands that we work on features with a relatively high ratio of utility to cost and that we do not work on features with a relatively low ratio of utility to cost. And by “utility” I mean economic utility, i.e. the total value to the ecosystem. If someone invented a galactic teleporter that no one uses, even for silly reasons — say, they don’t like its colour — its economic utility is zero. Let me put it bluntly and only somewhat inaccurately: Every feature added to Java over the past few years is one that we believe will serve at least a million Java developers (directly or indirectly); in fact, most features added to Java have had a million users in other languages before even being considered for addition to Java based on their technical merits (of course, the calculus changes depending on cost). > that we're expected to come up with DIY solutions for, with zero care from > OpenJDK and some very bad examples of alternative solutions, The alternative solutions are the ones preferred by the vast majority of users who, I would assume, think they are superior solutions. We are simply unable to also provide a separate solution, let alone such an expensive one, for a very small minority. It would be unfair to most of our users. > not to mention a completely wrong assessment of SM based on an outdated > poorly maintained implementation, with lack of use and maintenance burden > (when the community is willing but not allowed to maintain it) as > justification for it's removal. The community has not shown any willingness to maintain SM. As with other features, we only ever keep something to be maintained by others if they show both the commitment and the requisite ability (e.g. the JDK ports and GCs that are not maintained by Oracle). There are other companies beside Oracle that regularly contribute substantial, excellent work to OpenJDK, but to date none of them do so at the scale required for this, and we’re talking companies that pay several developers to work full time on OpenJDK. And that’s not even the worst of it. One of the things that makes SM so costly is that it’s not a separable feature but a cross-cutting concern that every JDK developer working primarily in the core-libraries area needs to worry about it when working on many changes in many areas. I don’t think you’ve begun to appreciate the enormity of this task, but even you complained that injecting doPrivileged calls in keeping up with all the changes to the JDK is too much work and that’s before studying the test suite that tests all of these places. > > SecurityManager is just an authorization layer (that allows assigning > different levels of trust), not a magic wand designed to solve all security > problems (or sandbox, it was only a component in the sandbox, along with > bytecode verification and ClassLoader visibility), to be discarded because it > doesn't solve some other unrelated security flaw, it's an Non Functional > Requirement, it doesn't bring in any revenue for Oracle, nor does it for many > other development projects, so management have knocked it on the head, we get > it. You don’t get it, because it wasn't management. The technical leadership decided to remove SM on the advice of our security experts because they’ve judged that it’s harming our users by demanding too much effort for something that too few people want to use. If management gave us fifty more developers tomorrow to employ as we please, we still wouldn’t be able to maintain SM because our responsibility to our users would still demand that we use those resources for things that would give our users more utility. Even the most security-conscious of our users have shown a clear preference for other solutions. Your argument is that you know better than the market, but one of the world’s most popular mainstream languages cannot be led in this way. Perhaps you believe that better marketing would make the market see the light, but we have a hard enough time educating our users about features that a million others already enjoy in other languages, and an even harder time educating them about more unique features (such as strong encapsulation) that in a few short years have already paid more dividends than SM. Imagine how hard it would be to convince them of an approach that’s been abandoned after a couple of decades by the users of *both* popular platforms that adopted it. > > We know that Oracle intends to remove authorization from the Java platform, > we also know that there is nothing we can say to convince Oracle it's a bad > idea, the only thing management will understand is bad consequences, such as > bad news headlines. I understand that Oracle needs to monetize Java If you mean that a small group of users is unable to convince us to do what they wish at the expense of most of our users, then you’re right. You say “monetize Java”, but what that really means is that you understand — without acknowledging — that most people don’t find your solution to be superior and don’t want it. I fully sympathise with the frustration when the wider public doesn’t share our views as I frequently experience it myself, but you seem to blaming us for acting rationally and accepting the reality of the market we serve. > the only thing management will understand is bad consequences, such as bad > news headlines. I think what they’ll understand is actual demand. Get some real traction then we can talk again. > > We've been working hard at implementing authorization for many years, to > protect against attacks, but suddenly the threat is gone? Yeah right, > there's a bridge in Brooklyn for sale. That is untrue, and you speak as if it’s 1996, not 2023. The threat is not gone, but the vast majority of those writing secure servers prefer other solutions to address such threats, in particular those provided at the OS level. That approach has pros and cons and we could argue on the intellectual merits of both approaches all day, but no one can deny that the economic utility of the popular approach is much higher than the one you like. Maybe you’re right and you know better than everyone else, but in that case it’s not us that you need to convince; you need to convince the market. BTW, we’re not removing authorisation from the Java platform. Most Java applications have authorisation and virtually none of them use SM. What you mean is removing independent checks from low level operations inside the JDK. > > The decision has been made, it's final, the debate is over, we're just > waiting for the removal notice now. How about someone raise a JEP to remove > security manager, targeting a particular release version (preferably 22, but > so be it if it's 21) so we can remove uncertainty and notify our users of the > versions of Java we'll be supporting going forward? Then it's over and we > can stop worrying about it. We will (try to) follow the same process we follow for all changes, including more impactful ones. We don’t yet know what changes will be in JDK 22, let alone later releases. When we do, so will everyone else. I hope we’ll find ways to improve our process in the future so that it will inconvenience you less. — Ron
