ES6 Java modules API

[vmutafov]

Currently, in order to access Java classes from JavaScript, users should use the syntax provided by GraalVM - either using:

const ArrayList = Java.type('java.util.ArrayList');
const arrayList = new ArrayList();

or:

const arrayList = new java.util.ArrayList()

Although these syntaxes work (the former being the recommended way by GraalVM due to performance reasons), there is another possible way of importing Java classes:

import { ArrayList } from "@dirigible-native/java.util"

This syntax would probably be more aligned to the way that JS modules are imported. Also, such syntax can possibly be supported on Graal NodeJS and in the NativeScript framework. This would bring the benefit of having the same Java API access on several platforms which is currently not available or at least I haven't found something with a better API.

A really important thing to discuss is if we provide this syntax, what would be the scope name? Would it be @dirigible-native or something else? Some other names may be @java, @polyglot, @interop but we should be cautious about possible trademarked names.

This discussion is only about the API proposal. If we decide to implement this API, there would be a new discussion about the implementation details as there are several ways to make it all work.

[Fluctuationqt]

if we use the default import syntax import * as javaUtils from "@dirigible-native/java.util",
what would we expect to be contained in javaUtils from java.utils
Classes are straightforward, but what about enums and interfaces on graal and other possible target platforms?

[vmutafov]

We would default export all the classes/interfaces/enums and if you have the above mentioned import, you could access like

const arrayList = new javaUtils.ArrayList();

As for exporting interfaces and enums, we would pretty much do the same thing. There would be a difference in what would be possible to do with them based on the platform on which the code is running. For example, in Dirigible and on the Graal NodeJS you could implement an interface using the Java.extend() Graal function. This however could not be achieved right now in NativeScript. The syntax for extending/implementing classes/interfaces is quite different and also includes generating some stuff at build time. I'm not saying we can't make Java.extend() work on NativeScript but it would probably be better to have a more JS-like way. An interesting issue regarding extending/implementing is this one :)

[delchev]

We may need to avoid the use of Java term in general for such cases.
Proposal from my side: @classpath e.g. @classpath/java.util

[vmutafov]

Yep, this sounds nice as well. The question then would be if we want, at some point in time, to be able to import not only from Java but from other languages as well, how should we name the imports from them? For example, let's say we want to expose some Python modules, would we import from @pythonpath/some-module? The same goes if we would like to contribute support for importing ObjC/Swift files in NativeScript. I'm not saying we should implement all these things now but it may be better if we think of a name that would also fit these cases in the future.

[delchev]

Agree. My personal preference would be somehow to distinguish between the languages and technologies, because the actual processing would be different in general. Hence, I would like to be aware whether a given "artefact" which I'm going to use in my JavaScript module comes from Java or from Python. Maybe as usual, it is better to start simple with the first one and then if necessary can put everything under @polyglot like namespace.