Regardless of whether you integrate into jpackage or provide a new
"jspackage" tool, this presupposes the capability of running a set of
Java class files on top of a JavaScript engine. Pointing to a
third-party library that happens to implement this isn't sufficient to
define this new
Much of the feedback (public and private) from this proposal has focused on
integration with jpackage. There is concern that jpackage is strictly for
platforms where the OpenJDK runtime is bundled with the class files in an
installer for distribution on that platform. I have a couple of
Without commenting on the value proposition of what you propose to do, I
am fairly certain that jpackage is not the way to do it. The job of
jpackage is to take an application, bundle it with a Java Runtime, and
create a native package / installer from it. What you are describing
goes far
While I agree it is a somewhat different platform than Linux, Mac, or
Windows, I do think the web is a platform worth targeting. And when seen
through just a slightly different lens, it is more like the others than it
might first seem:
On the platform:
* It is difficult for users to run Java
This doesn’t seem like something that should be the job of jpackage. The
jpackage tool is currently used for producing platform-specific packages or
installers targeted at end-users that include native launchers and a JRE.
Web-based applications are an entirely different beast. This seems
Below is a Java Enhancement Proposal for your consideration to add
JavaScript to jpackage as a new target platform. I would appreciate
feedback on the proposal contents. I am also interested in learning about
the process, specifically what approvals are required prior to start of
implementation,
