On 11/27/2014 05:56 AM, mark.reinh...@oracle.com wrote:
2014/11/26 3:17 -0800, fo...@univ-mlv.fr:
On 11/26/2014 10:46 PM, mark.reinh...@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
