Created attachment 102303 [details]
Proposed patch to code.startup module for release691 branch

I would be interested in an use case for this.
I have had an example with native libraries (JNI), but that use case got solved on the class loader level and without any need for separate module for each architecture.

We are distributing using NBMs updates an executable to be launched by our RCP application. We have 4 different modules (linux32, linux64, win32, win64) containing the executable for each arch/os combination we have to support.

FYI currently we have this solution: we are storing the executable in a resources package of each module (so 4 modules) and we copy only the correct executable in the <cluster>/modules/ext folder, checking os.name and os.arch at runtime in a ModuleInstaller class.

Ideally we do not want the user to download all executables when he really needs only one. More than that we also want that only the needed NBM is visible in the update center so the user can just install it and we do not need that "copy exe" code anymore.

The same argument can be stated for installation of libraries (like JOGL), users do not need to download all .so/.dll libraries when they really need one for their particular OS/arch combination.

An other example are the SWT Libraries. SWT runs only in exactly matching OS<->VM. You need a SWT Library for "Win32/Java VM 32Bit" and a library for "Win64/Java VM 64Bit". (used by DJ Native Swing)

Without an arch-token it's hard to load only one JAR with the standard module loader system. 

br, josh.

Good, I can accept the API change. I need patch with test and description of changes in openide.modules/src/org/openide/modules/doc-files/api.html, changes to module versioning.

When ready, reopen.

(In reply to comment #3)
> currently we have this solution: we are storing the executable in a
> resources package of each module (so 4 modules) and we copy only the correct
> executable in the <cluster>/modules/ext folder, checking os.name and os.arch at
> runtime in a ModuleInstaller class.

If by "executable" you mean "native library", much better is to statically bundle all the arch variants for a given OS under modules/lib, but using different basenames. Then call System.loadLibrary using a basename corresponding to the current arch.

That assumes that it is your own code which is calling loadLibrary, not some third-party Java library. If you do not control the call to loadLibrary, the enhancement in bug #186000 is less flexible but can be used to address the most common requirement of loading a different SO/DLL according to arch token - you just need to arrange the files in a particular hierarchy.

Of course, this enhancement is still desirable so that the user can avoid even downloading irrelevant libraries, which may be a concern when each library is in the megabyte range. Currently the best you can do is have the user download libraries for all possible architectures on a given OS.

If by "executable" you really mean "standalone executable to be launched via ProcessBuilder", then of course you would just determine the desired executable at runtime before launching it, finding the actual File path using InstalledFileLocator. No copying or ModuleInstall needed. ('modules/ext' is not the conventional cluster-relative path for such files; use 'bin'.) Again there is the potential issue of download size if several architectures must be packaged in one OS-dependent module.

(In reply to comment #6)
> (In reply to comment #3)
> > currently we have this solution: we are storing the executable in a
> > resources package of each module (so 4 modules) and we copy only the correct
> > executable in the <cluster>/modules/ext folder, checking os.name and os.arch at
> > runtime in a ModuleInstaller class.
> 
> If by "executable" you mean "native library", much better is to statically
> bundle all the arch variants for a given OS under modules/lib, but using
> different basenames. Then call System.loadLibrary using a basename
> corresponding to the current arch.
> 
> That assumes that it is your own code which is calling loadLibrary, not some
> third-party Java library. If you do not control the call to loadLibrary, the
> enhancement in bug #186000 is less flexible but can be used to address the most
> common requirement of loading a different SO/DLL according to arch token - you
> just need to arrange the files in a particular hierarchy.
> 
> Of course, this enhancement is still desirable so that the user can avoid even
> downloading irrelevant libraries, which may be a concern when each library is
> in the megabyte range. Currently the best you can do is have the user download
> libraries for all possible architectures on a given OS.
> 
> If by "executable" you really mean "standalone executable to be launched via
> ProcessBuilder", then of course you would just determine the desired executable
> at runtime before launching it, finding the actual File path using
> InstalledFileLocator. No copying or ModuleInstall needed. ('modules/ext' is not
> the conventional cluster-relative path for such files; use 'bin'.) Again there
> is the potential issue of download size if several architectures must be
> packaged in one OS-dependent module.


Yes, I was meaning "standalone executable to be launched via ProcessBuilder" and the main reason for this enhancement of arch tokens was about the download size since we have executables for each arch/os combination, we would like to avoid irrelevant downloads.

Thanks for the comments, I will provide a patch with test and api.html changes.