Options for platform specific classes and native code

[Roger Riggs]

Hi Alan,

It would be desirable if a module with native code or sections within the
module with native code unambiguously identified the target os and 
architecture.

It would allow a direct check on installation that the contents of the 
module
would be appropriate for the target system.  It would also allow a 
provisioning
server to contain modules for different architectures and be able to select
the proper module without having to decipher it from a file name or 
module name.
Modules that are self describing can be managed without the need for 
external
metadata that can get out of sync or need to be manually maintained.

The virtual modules approach works but it is not indicated how the resolver
would select between two modules that both 'implements foo-natives'
or if the module was absent it might query a provisioning server for
an appropriate module that 'implements foo-natives'.

The final point about modules that rely on native libraries should be 
supported.
If such dependencies were explicit then during module installation, checks
could be made for the native modules and automate their installation if 
desired
or fail if not present.

Roger




On 04/11/2011 11:57 AM, Alan Bateman wrote:
>
> Mandy and I recently went through (at a high level) the pros and cons 
> of how modules containing platform specific classes or native code 
> could be supported. I've put the notes from that discussion here:
>
> http://openjdk.java.net/projects/jigsaw/doc/topics/nativecode.html
>
> -Alan