Example code in JDK8 requiring change for modular function

[Paul Sandoz]

On May 6, 2012, at 4:17 PM, Alan Bateman wrote:

> On 06/05/2012 13:36, David Holmes wrote:
>> :
>>> 
>>> When running in "modular mode" the system class loader is the class loader of the entry module, where as what we really want to use is the class loader of the callee (the class loader used to load Files).
>> 
>> 
>> The system class loader needed not be the classloader of the callee. So if we expect this to use the loader of the callee then the code is broken regardless of module-mode.
> This code works as specified, if you have a custom file type detector then you put it on the system class path and it will be located.
> 
> To work with modules it requires changes, including specification changes. This goes for many other areas of the JDK, I assume Paul just picked this one out to start a discussion on the changes that will need to happen across the board.

Yes.

Where possible it is convenient to make changes in JDK8 and pull into Jigsaw (makes the merge back easier), as has been the case for other changes. But, for such areas it is gonna be a multi-stage process given the required (but as of yet unspecified) javadoc changes.


> In this case the specification will need to make it clear how it works when running with modules.


> Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules.

FWIW i verified that is the case today in Jigsaw. Do the generated module-info.java files contain all known providers, or is there still some work to do here? 

The main concern i have with this example is the caching of the service provider implementations. It is something we will have to revisit.

Paul.