New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

Gregg G Wonderly greggwon at cox.net
Fri May 12 23:42:00 UTC 2023



Sent from my iPhone

> On May 12, 2023, at 1:29 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> (Moving to the appropriate mailing lists for the discussion of this JEP)
….
> By physical necessity we sometimes inconvenience some users  because users have contradictory requirements. What we’re trying to estimate is just *how much* of an inconvenience will be caused by feature X or the lack of X when integrated over the entire ecosystem.

What doesn’t seem to be considered is what is the common set of users inconvenienced by multiple if not a majority of these “inconveniences”.

I find it petty that “we know best” or “it’s our way of the highway”  becoming a pretty common thing in the “evolution” of Java “by Oracle”.  The open-JDK community ultimately can end up quite distances from “Oracle Java”.

It seems there is an agenda and goal that Oracle is aiming for. My gut feeling is that it’s to get to a container like platform that smells like Java EE for small platforms where some of the most important features of Java will disappear or become even more burdensome.

The removal of the security manager is a big deal. Jini, now River has counted on mobile code, controlled by the security manager for decades. Visibility of many of the uses has always been problematic because of the benefits the speed of the platforms involved.  Racing platforms, trading platforms and even network cross routing have been happening.  But the announcement of the drop of the security manager pretty much shut the whole platform down.  A lot of time was committed, in the community, to create a new implementation that greatly improved the really poor use of locks and contested access scopes.  But once again, we see the “we know best” thing looming around such changes.

I think it would be very beneficial for Oracle to make some publicly visible statements about where it’s taking Java so that the community, could understand if there is an incongruity of that path and what uses the community has planned.


More information about the serviceability-dev mailing list