Re: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers
On 02/01/2019 10:43, Claes Redestad wrote: : While we're in the area then it would be nice to eliminate the use of Class::newInstance too - if each of the built-in protocol handlers is public with a public no-arg constructor then getConstructor().newInstance() should do it. To be perfectly compatible I think .getDeclaredConstructor().newInstance() should be used: http://cr.openjdk.java.net/~redestad/8215990/jdk.01 This looks okay. Using getConstructor should work here too because this is the built-in protocol handlers. I think the only compatibility concern with getConstructor in this code path would be if someone deploys a custom protocol handler in the sun.net.* tree via -Xbootclasspath/p or by patches a java.* or jdk.* module that is mapped to the boot loader and the protocol handler doesn't have a public no-arg constructor. If they set java.protocol.handlers.pkgs property then it uses lookupViaProperty and Class::newInstance as before. -Alan
Re: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers
Hi, On 2019-01-02 11:04, Alan Bateman wrote: On 02/01/2019 09:02, Claes Redestad wrote: Hi, during bootstrap we load and use at least two of the jrt, file and jar URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to instantiate these slightly speed up bootstrap by reducing number of classes loaded and doing fewer relatively expensive reflective operations: http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ This looks okay to me and will continue to work when the protocol is not in lower case (URL protocols/schemes are compared with regard to case). thanks! (The protocol input string should already be lower-case at this point) While we're in the area then it would be nice to eliminate the use of Class::newInstance too - if each of the built-in protocol handlers is public with a public no-arg constructor then getConstructor().newInstance() should do it. To be perfectly compatible I think .getDeclaredConstructor().newInstance() should be used: http://cr.openjdk.java.net/~redestad/8215990/jdk.01 A bigger job of work in this area is to replace the use of Hashtable (handlers field). That's something for a bigger overhaul of course. We shy-ed away from doing this in JDK 9 due to OSGi implementations hacking the field directly. I'm in favor of any effort to get rid of Hashtable usage, anywhere. :-) /Claes
Re: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers
On 02/01/2019 09:02, Claes Redestad wrote: Hi, during bootstrap we load and use at least two of the jrt, file and jar URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to instantiate these slightly speed up bootstrap by reducing number of classes loaded and doing fewer relatively expensive reflective operations: http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ This looks okay to me and will continue to work when the protocol is not in lower case (URL protocols/schemes are compared with regard to case). While we're in the area then it would be nice to eliminate the use of Class::newInstance too - if each of the built-in protocol handlers is public with a public no-arg constructor then getConstructor().newInstance() should do it. A bigger job of work in this area is to replace the use of Hashtable (handlers field). That's something for a bigger overhaul of course. We shy-ed away from doing this in JDK 9 due to OSGi implementations hacking the field directly. -Alan
RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers
Hi, during bootstrap we load and use at least two of the jrt, file and jar URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to instantiate these slightly speed up bootstrap by reducing number of classes loaded and doing fewer relatively expensive reflective operations: http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ Thanks! /Claes
