Encapsulation of polyglot/java Dependencies
#7082
Comments
|
Isolation can be achieved by using different |
JaroslavTulach
changed the title
polyglot/java Dependencies
|
The implementation of encapsulation is provided by #10714. It uses Java Platform Module System and defines a |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-07-30): Progress: - #7082: ClassPath & Using
|
|
Jaroslav Tulach reports a new STANDUP for today (2024-07-31): Progress: - Turning libraries into modules by Pavel: 7e865ce#r1697852981
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-01): Progress: - libs as Java Modules
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-02): Progress: - case study
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-03): Progress: -
|
|
@gunnarmorling provided a reference to layrry - A Launcher and API for Modularized Java Applications. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-05): Progress: - Deep review of #10725 (review)
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-06): Progress: - REPL script verified: 78db664
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-07): Progress: - #10736: error&warnings PR cleanup: #10765 (comment)
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-08): Progress: - Reimplemented: #10765 (comment)
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-09): Progress: - review of revert: #10778
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-12): Progress: - review: #10793 (review)
|
|
With the imports/exports discussion we are talking about encapsulation of out private modules.
Many of our libraries rely on Java helpers that are imported using the
polyglot java importstatements. To achieve proper encapsulation of library internals, we should ensure that these internal helper libraries (std-base,std-tableetc.) are private and not accessible from user projects.High level idea
For most cases, we want to ensure that a JAR file that is in a
polyglotdirectory of a given project can only be imported from within that project and not from other places.Re-exporting
We still want some helpers to be visible in other modules. For example, some helpers from
std-table(theTablelibrary companion JAR), are also used in theDatabaselibrary. To do so we can re-export such symbols by wrapping them in Enso wrappers. This will be enough for helper methods, but it may not be enough for types.For the time being this should be enough for our usecases.
Potentially, for longer-term, maybe we should devise a better control over where the JARs are importable from. Maybe we can include some information in the
package.yamlfile or have a sibling directorypublic-polyglot- where such JARs would be visible to the outside world?Implementation
Currently, loading a JAR is achieved by
TruffleLanguage::Env::addToHostClassPath. This does not have the control for imports we need. We would probably need a check at compiler level which verifies if a givenpolyglot java importclause is allowed based on the contents of thepolyglotdirectory associated with the project from which the compiled Enso file comes from.Collisions
This still leaves the question of - what if two libraries contain JARs in their
polyglotdirectories that have clashing classpaths? For example, two versions of the same Java library? Ideally, due to the encapsulation each library should be able to import each own version, but that would require some stricter separation of classpaths.Until we have some 'clever' solution for this, we may want to forbid importing clashing libraries. Ideally we should detect if adding a new library to the classpath will shadow another one and disallow importing such a library.
Alternatives
The Java Module System seems to be solving a similar task. Maybe we can somehow plug into it and exploit it instead of inventing our own wheels? It partially depends on if that is possible to do in how Truffle/Graal handles the modules for the polyglot interface.
Tasks
The text was updated successfully, but these errors were encountered: