Support for jrt-fs.jar in JDK 7 would be very helpful in allowing FindBugs to run under Java 9

[Remi Forax]

On 11/27/2014 05:56 AM, mark.reinhold at oracle.com wrote:
> 2014/11/26 3:17 -0800, forax at univ-mlv.fr:
>> On 11/26/2014 10:46 PM, mark.reinhold at oracle.com wrote:
>>> ...
>>>
>>> Exposing the package-to-module map via the NIO filesystem API is clean
>>> and relatively simple.  It might be a little less efficient than using
>>> a separate properties file, but I don't think utmost efficiency is the
>>> ultimate goal here.
>> I understand that a plain old file is not something very flexible
>> so ok to not having it.
>>
>> and I think it's not a good idea to pollute the image API with
>> something from the past.  I prefer that each tools that need the whole
>> mapping between a package and a module to create their own index (not
>> necessarily on disk) instead of choosing now to use symlinks to
>> represent such index, something I'm sure we will regret in the future.
> Why do you think we'd regret that in the future?
>
> We're just talking about symbolic links in a virtual filesystem that's
> being used to surface the data baked into a jimage file.  They're not
> actual symbolic links in an OS-level filesystem.
>
> Computing the package-to-module map at build time and storing it in the
> jimage file is almost trivial.  It doesn't take up much space, and it
> helps existing tools migrate to JDK 9.
>
> In what sort of future scenario would we regret this?  It might become
> less used over time, or even not used at all, but I'm hard pressed to
> think of a situation where we'd consider it actively harmful.
>
> - Mark

The problem is that when you expose such API you encode assumptions with it.
Things like the fact that a package can be found in one module (or 
multiple modules)
or the fact that a .so file has to be associated with a package, etc
All these rules are not needed in a modules world so each time we will want
to upgrade the module world we will have to check if these assumptions are
still valid. Basically, we handicap the future of modules with 
assumptions from
the past.

If we want to help tools migration and I think we all want that,
we can provide a compatibility jar that maintain side information like
package mapping corresponding to a jimage. That way, for Java 13
when we (or others) will want to upgrade the Java module,
we will not have our hands tied by something that was decided 10 years 
before.

Rémi