At least someone replied to my question.
On 7/14/16 5:44 AM, Russell Gold wrote:
On Jul 12, 2016, at 1:31 PM, Eric Johnson <e...@tibco.com> wrote:
What infuriates me is that in all this discussion, I don't see anyone talking about a
threat analysis. What are we trying to protect, from whom, and why? I see comments about
how implementation details of the JRE (such as "com.sun" packages) must be
hidden, but without reference to the threats that cause a problem.
It’s primarily a maintenance issue, IMO. It is common that we provide classes
and methods that are intended to be used from elsewhere inside a product, but
which we do not want users to see. That is, it is much the same as the reason
you use “private” for class internals - if everything is publicly accessible,
people use it, and you cannot refactor your code without breaking theirs.
If the entire aim is just a maintenance issue, then I assert that
compiler changes should be sufficient. At that point, anyone who fires
up runtime reflection to work around the compiler gets the benefits and
the costs that they deserve. Benefits include the ability to leverage
code in the guts of any library or the JRE that the authors decided they
didn't want to publish. And they embrace the likelihood that it will
break in the future.
I don't feel a huge need to argue about language design. Other people
can battle over the contentious issues of what is appropriate for
language constructs. That could be module boundaries with metadata, it
could be new keywords like "friend", or even package level declarations
(more like OSGi). I suspect we'll all adopt to the "best" solution
determined by those who want to improve the language.
To make this more concrete, Scala could introduce some kind of scoping
mechanism completely unfamiliar to existing Java developers. Few people,
if any, would be upset that it was merely a compile-time enforcement,
and the runtime didn't enforce the new capability. Same should be true
of Java itself. For one possible framing, perhaps I ought to be able to
compile a module-based application and yet run it on Java 8 without
modification?
So yes, modules for the compiler, if that's what Oracle thinks is best
for the language, I can live with it. Need not affect the runtime, though!
However, like I said in my original email, I believe genuine security
issues can be found in this quicksand. The JRE has valid reasons to
prevent access to implementation details. That reduces the possible
attack footprint, and also strengthens the walls of the "sandbox" that
Java puts up (more code to tunnel through before getting to the
vulnerable chunk). And it seems pretty clear, from the CVEs found
<https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html>
in the JRE, that these changes should happen regardless of whether or
not the runtime has a security manager installed, because it is common
enough to run without one. To pick an example from another language, you
can't run Ruby without having "taint" support on.
In other words, the Jigsaw runtime change to enforce module boundaries
amounts to /always/ running with some sort of security manager. If you
frame the implementation that way, though, then it is clear that
alternate implementations might be quite valuable - especially in a
transition phase from prior versions of Java.
While this discussion is ostensibly about reflection and accessibility,
I'm viewing it as really about what kind of security manager is the
minimum allowed at runtime.
I applaud Oracle's effort to tackle the unpleasant task of imposing (on
us) a mandatory minimum security monitor on the JRE classes. However, to
date, Jigsaw is imposing one specific model of mandatory minimum
security on all of us, without entertaining alternate solutions. That's
what I find enormously frustrating. It is pretty clear to me from the
discussions on this mailing list that the one they've enforced so far is
the wrong one, at least if Java 9 is going to be adopted widely.
