Jason,
On 2016-07-15 22:25, Jason T. Greene wrote:
Claes,
I ask that you take a look at the extensive arguments I have presented on the
topic of reflection. The assumption you seem to make is that the use case of
reflective access to internal packages is wrong, poor programming practice, or
an error.
That couldn't be further from the truth.
I'm refraining from such generalization - although I do take the view
that most reflective *and* static uses of JDK internals comes at a cost
and that replacing such uses with public - or at least officially
supported - APIs should be the preferred long term solution, since
it'll give the internals more leeway to change and improve.
I hope that you can somewhat agree with that, and that a platform which
is able to evolve - be it by adding, changing or even removing code -
will live a healthier life in the long term.
The use cases are widely adopted by the industry, and they enable rich and
powerful programming models that developers depend on.
I assume you're referring to some specific concern here, which I hope
can be discussed more in-depth either in a new thread or where it's
already been brought up.
I was personally hoping to be able to promote the jigsaw model to developers,
but the technology as it is currently defined is insufficient to meet the
demands of today, let alone tomorrow. I am still holding out hope this will be
addressed,l.
There are surely open questions, and I too hope they can be addressed
in a manner satisfactory to most, if not all.
/Claes
On Jul 15, 2016, at 3:11 PM, Claes Redestad <claes.redes...@oracle.com> wrote:
On 2016-07-15 20:24, Gregg Wonderly wrote:
On Jul 14, 2016, at 6:23 PM, Eric Johnson <e...@tibco.com> wrote:
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.
More rigorous versioning could help mediate this so that when my introspecting
code which works on JDK7 is deployed on JDK8, it would not run if I declared a
version dependency on JDK7. We currently have versioning that works with newer
JDKs by default, without the ability to declare that only one JDK works.
http://openjdk.java.net/jeps/238 allows graceful transition from
introspecting code and other hacks to supported APIs in 9, 10 etc.
Believe me, I understand how ugly many people in the JDK development team feel
it is for all this reflection to be done, and how responsible they seem to
feel, given the direction JigSaw is going, to try and keep people from
“breaking” their own software. But practically, they are taking that risk.
Leave them in the dust by ignoring their dependencies. But, don’t shut the
door on long term solutions evolving from that experimentation/introspection
which allows the platform to become better because they help you understand
that an API change is actually in order because there is a use case that was
missed in the original JDK design.
What will happen if JigSaw is deployed as it is today, is that people will
elect to use something else. They literally will run as fast as they can to a
“place” where participation is in their control, not some outside party.
Think of the Boston Tea Party. From Hamilton lyrics, “Why should some tiny
island on the other side of the world set the price of tea?” Making the JDK
seem like a King of overlord with all kinds of limits applied will make people
really mad. Also from Hamilton, “I’ll kill your family to remind you of my
love” is sort of how people look at this kind of “control” and “overreach” of
responsibility in software. It’s like JDK-9 shuts down all kinds of
responsibilities and totally disrupts interactions that used to feel friendly
and inviting and instead makes them feel like a teach standing over you with a
ruler, smacking your hand every time you try and touch something they don’t
want you to.
Sorry if this sounds rude, but it seems like you're all arguing some straw man
idea of jigsaw rather than the actual implementation,
in addition to going slightly off-topic.
It's still perfectly possible to break through to non-exported
packages: it will simply require use of either new flags
(addExports/addReads, upgraded modules etc) or use of the newly added
extensions to the reflection API. And as has been stated again and again
elsewhere: setAccessible and friends are not going anywhere soon.
Rather than an unfriendly or even despotic attempt to wrest control
from free developer souls, I find it quite agreeable to give
module/library/JDK authors a stronger way of saying "this is
internal, please keep out". Unless there is a security manager
prohibiting you, but hey, no change there.
What will break is the ability for libraries to go ahead and do this
without explicit approval from the "deployer", application owner, user.
Currently plenty of libraries take these freedoms on the behalf of that
guy or gal, who might not even be aware of the library authors decision
to cut corners. Some of these people might not think it's worth the
cost or risk of breaking future compatibility for some convenience, a
few points on a benchmark or whatever other reason.
As we're being emotional: I feel good about the way jigsaw brings
control back to the application owner to do more informed decisions and
to library authors to be more confident about evolving their code, and
hope that someday you will feel that there's actually a big deal of
common sense invested into jigsaw.
Now, can we go back to arguing about public vs package private?
/Claes
