> On Jul 15, 2016, at 3:10 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 <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.
But, it’s impossible for this ability to be removed. People will decompile modules, alter their declarations and make things accessible if they need access. There is no hope that JigSaw mechanisms can keep people out of your code. Once you release it, every bit of it is accessible, regardless of what JigSaw attempts to prohibit. As I said before, massive encryption and an hardened deployment environment, inaccessible to the developer will be the only way. Since the developer has to compile against something, this would require an interface only module deployment for compilation and a secondary hard deployment environment for the developer to deploy into. Common java deployments have none of these capabilities. The attempts at security and isolation through declarative mechanisms is just not changing anything about what already is happening/possible in the language with keywords. And reflection removes those limits to allow systems to utilize the software APIs in ways that were unknown at the time of packaging. If modules are built with limits on deployment and controls asserted to attempt to keep parts of the “system” inaccessible, why are we releasing software for others to use? > 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. It’s not about benchmarks. It’s about getting access to internal data structures to assert proper locking to use Collections inside your code with the needed locking in new ways that you didn’t imaging. People are decompiling Jars, inspecting the functionality, learning, and then adapting things or fixing things that they need to work or be different. > 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. How is this any different from just changing versions? If you want your software systems to evolve with the users, are you sure you want the burden of changing module declarations and redeploying/releasing new versions continuously as you find out that your users are needing? How will that enable you, or your users to be more productive? They will be waiting for you to change things, and you will be hoping for them to give you that feedback. How often do you want to hear about “packaging needs”? Again, many will decompile your module, change the declarations to do what they need, and await “code changes” instead of just packaging changes I would guess. Gregg > > Now, can we go back to arguing about public vs package private? > > /Claes
