Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support overrides (additions) to known JVM bootstrap & extension modules #132

Open
jvasileff opened this issue Nov 2, 2015 · 1 comment
Labels

Comments

@jvasileff
Copy link
Member

In practice, libraries such as JavaFX and Nashorn APIs are be available at runtime on JDK 8, even if not officially supported.

Therefore, it would be nice to have a mechanism to "assert" that certain packages are available, even if omitted (intentionally or otherwise) from package-list.oracle.jdk8 and package-list.jdk8.

Ideally this would be available through module.ceylon, such that a Ceylon utility module would be able to make (and document) an assertion that JavaFX is available, and importing modules (of the utility module) would inherit this assertion without the need for additional "sidecar" override configuration files or command line arguments.

Whatever the mechanism, the following would be required:

  • shared imports of the introduced module
  • native annotation on the import (would always be jvm, if present)
  • A one-to-may mapping of module name (e.g. oracle.jdk.nashorn) to packages (e.g. jdk.nashorn.api.scripting, jdk.nashorn.internal.ir, etc).

This approach certainly isn't perfect (What if two modules disagree on the makeup of oracle.jdk.nashorn? What if jdk.nashorn.api.scripting really isn't available?) But the feature request is to find something practical, because, as it stands, these packages are not available at all.

@quintesse
Copy link
Member

I've always thought we need a much more generic approach to this. Why only consider things that are part of the JDK? Those might be the most "obvious" cases but certainly not the only ones. For example in a server container there would be other packages that exist as part of "the environment".
And in general a way to assert the existence of certain packages on the classpath while not being able to point to the actual JAR that they come from would be advantageous IMO.

So a way to do this for example would be to allow JAR-less modules. Modules that would only consist of a module.xml with a bunch of export entries for packages perhaps?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants