On 30/09/16 15:11, Sanne Grinovero wrote: > Hi all, > I think what Peter raises is a very interesting quandary. > > Without going in the syntax details of this proposal, the point is > that implementations of "javax.persistence" (and similar APIs) need to > advertise themselves as eligible to getting certain additional > privileges - such as reflective access - which the platform is > attempting to limit (why?). > > The problem I see is that it should be fairly easy for any library to > fool the platform to obtain the same privileges; I could certainly > extend Hibernate and make a new JPA provider in just minutes, and do > something else with those additional privileges as well. > This might be a clumsy trick, but sufficiently motivated people - such > as those having malicious intents - could certainly entertain such > plans. > While well intentioned developers who have a legitimate reason to need > reflective access - like plans to make some better framework ? - would > need to write odd looking, time wasting code to get their work done.
This assumes that malicious code can get into the classpath in the first place. Of course, if you don't (cannot?) control what gets into your classpath you are fairly much skewered already. Also, although this solution leaves a window ajar it doesn't leave every opening in the fabric of the building wide open. I think the main concern here is therefore how much this provides room for accidental transgression, rather than any question of protection from malicious larceny -- the latter being more an academic question of how game over exactly over is "game over". > Wouldn't it be far easier to just allow reflective access to everyone > without restrictions, at least on weak modules? I'm not seeing the > benefits of preventing this - especially to people using the > Reflection API. One benefit of limiting reflection is the ability to decide precisely what can or cannot be be accessed and in the former case where it can or cannot happen. That's certainly important for analyses which may help performance optimization. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander