On 26/09/2016 04:50, GREGG WONDERLY wrote:
I still, like others seem to, find it amazingly odd, that the security manager,
existing basis for access control is not still what would count. I understand
that the JDK itself is not deployed with a security manager impl in most cases,
and thus there would be no access context for the security manager to be used
against. What’s odd, is that you are still trying to block access to
reflective access to the “open JDK”. If it’s really open and it’s really
something that the community contributes to, why do we need to block access,
hide details and otherwise obfuscate access details? Modularization should
just be about separating pieces not needed should it not? Why has this
degenerated into such a huge bit of access restriction too?
When you see "access control" in mails on this list then think the
access control specified by the Java Language Specification and Java
Virtual Machine Specification. It's nothing to do with the legacy
security manager mechanism.
As regards core reflection then keep in mind that it has always been
specified to do the same access checks as the Java Language and VM. It
should not be a surprise if you get IllegalAccessException when
attempting to access something when the equivalent Java code does not
compile or where the equivalent bytecode would fail with IllegalAccessError.
:
For a long time, I have had conversations with a lot of different Sun, and now
Oracle employees. I think that they all want to enable great things to happen
with the Java platform. But the attempts at perfection and control involved in
many of the JSRs (NIO2’s failure to provide a working, dependable filesystem
observer for all platforms for example)
I can't tell what you mean here but if you are looking to interpose on
file system operations then that support has been there since Java SE 7.
If you mean the Watcher API then there is a platform independent
implementation in OpenJDK. In any case, the nio-dev list is the place
for to being gripes in this area.
which have resulted in only partial improvements and in many cases reduced
penetration (java.util.logging still doesn’t get improvements to align it’s
apis better with varargs and more brief API designs)
It's not clear to me that it's worth doing a lot of the j.u.logging API
but keep in mind that there were updates to modernize it a bit in Java
SE 8 (Logger has methods that take a message Supplier for example). Also
with JEP 264 then you have a way to plugin in your preferred logging
framework to consume logging from the platform. The core-libs-dev list
is the place to bring gripes or issues on logging.
-Alan
