Re: Proposal to add JavaScript platform to jpackage

2021-04-24 Thread Scott Palmer 
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 like more of 
a job for a Maven or Gradle plugin.

Regards,

Scott


> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q...@gmail.com> wrote:
> 
> 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, should sufficient consensus be reached.
> 
> ( To view this proposal as a web page, please visit:
> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
> 
> Thank you!
> 
>  -Andrew Oliver
> 
> Title: Add JavaScript platform to jpackage
> Author: Andrew Oliver
> Created: 2021/04/24
> Type: Feature
> State: Draft
> Exposure: Open
> Component: tools/jpackage
> Scope: JDK
> Discussion: core-libs-dev@openjdk.java.net
> Template: 1.0
> 
> Summary
> ---
> 
> jpackage already allows packaging Java applications for several platforms.
> This proposal adds a new platform: JavaScript.
> 
> This effort will enable jpackage to convert bytecode from the provided
> classes into JavaScript, and generate the required HTML to invoke the
> specified main method when opened in a web browser. These files will be
> bundled into a WAR file for easy deployment.
> 
> Goals
> -
> 
> *   Enabling JVM languages to build client-side web applications
> *   Allow easy generation of JavaScript from JVM bytecode
> *   Allow easy deployment and execution of generated JavaScript in web
> browsers
> *   Allow easy deployment of the generated JavaScript in all web server
> environments
>*   Java web application container (like Tomcat)
>*   Static file web servers
>*   Static file web hosting services
> 
> Non-Goals
> -
> 
> *   Allowing execution of JavaScript server-side. (Java already has
> numerous options for executing bytecode server-side.)
> 
> Motivation
> --
> 
> Java was once used to create client-side web applications via applets that
> could be launched by visiting a web page. Applets could draw on an area of
> the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic
> front-end applications (like JS single-page apps).
> 
> However, as evident in JEP 398 ([
> https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
> applets are no longer feasible due to the actions of browser vendors. While
> browsers have lost the ability to execute Java bytecode or invoke methods
> from the Java class libraries, they do have mature engines for executing a
> different sort of code (JavaScript) and an extensive list of useful APIs.
> By converting class files to JavaScript, and providing mechanisms to invoke
> browser APIs, Java can again be used to create in-browser applications.
> [TeaVM](https://teavm.org) has demonstrated that this is feasible and has
> numerous benefits:
> 
> *   Provides a strongly-typed language for client-side web development
> *   Provides a wealth of IDEs, build tools, and testing tools for
> client-side web development
> *   Allows teams with Java experience to produce apps with familiar
> technology
> *   Allows sharing of POJO and business logic classes, simplifying
> development
> *   Allows options for porting applet- and JNLP-based systems to
> present-day browsers
> 
> Details
> ---
> 
> An additional jpackage option for type will be added: `js`
> 
> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> code to JavaScript, with the main class compiled to a JavaScript method
> called 'main()'.
> 
> jpackage bundles application code, runtime, and resources into a
> platform-specific format. For this new JavaScript type, the layout will be
> either a ZIP file or a standard WAR file. The ZIP format will contain the
> files ready to be extracted to a static file webserver or HTML hosting
> service. Generated WARs will have the required structure to be deployable
> in a Java web application container.
> 
> ### WAR layout
> 
> *   HelloApp.war
>*   index.html (Main application page, loads classes.js and invokes
> main())
>*   teavm
>*   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>*   css
>*   (CSS files from application)
>*   META-INF
>*   MANIFEST.MF
>*   WEB-INF
>*   web.xml
> 
> ### ZIP Layout
> 
> *   HelloApp.zip
>*   index.html (Main application page, loads classes.js and invokes
> main())
>*   teavm
>*   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>*   css
>*   (CSS files from application)
> 
> Basic usage: Non-modular applications
>

Proposal to add JavaScript platform to jpackage

2021-04-24 Thread Andrew Oliver 
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, should sufficient consensus be reached.

( To view this proposal as a web page, please visit:
https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )

Thank you!

  -Andrew Oliver

Title: Add JavaScript platform to jpackage
Author: Andrew Oliver
Created: 2021/04/24
Type: Feature
State: Draft
Exposure: Open
Component: tools/jpackage
Scope: JDK
Discussion: core-libs-dev@openjdk.java.net
Template: 1.0

Summary
---

jpackage already allows packaging Java applications for several platforms.
This proposal adds a new platform: JavaScript.

This effort will enable jpackage to convert bytecode from the provided
classes into JavaScript, and generate the required HTML to invoke the
specified main method when opened in a web browser. These files will be
bundled into a WAR file for easy deployment.

Goals
-

*   Enabling JVM languages to build client-side web applications
*   Allow easy generation of JavaScript from JVM bytecode
*   Allow easy deployment and execution of generated JavaScript in web
browsers
*   Allow easy deployment of the generated JavaScript in all web server
environments
*   Java web application container (like Tomcat)
*   Static file web servers
*   Static file web hosting services

Non-Goals
-

*   Allowing execution of JavaScript server-side. (Java already has
numerous options for executing bytecode server-side.)

Motivation
--

Java was once used to create client-side web applications via applets that
could be launched by visiting a web page. Applets could draw on an area of
the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic
front-end applications (like JS single-page apps).

However, as evident in JEP 398 ([
https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
applets are no longer feasible due to the actions of browser vendors. While
browsers have lost the ability to execute Java bytecode or invoke methods
from the Java class libraries, they do have mature engines for executing a
different sort of code (JavaScript) and an extensive list of useful APIs.
By converting class files to JavaScript, and providing mechanisms to invoke
browser APIs, Java can again be used to create in-browser applications.
[TeaVM](https://teavm.org) has demonstrated that this is feasible and has
numerous benefits:

*   Provides a strongly-typed language for client-side web development
*   Provides a wealth of IDEs, build tools, and testing tools for
client-side web development
*   Allows teams with Java experience to produce apps with familiar
technology
*   Allows sharing of POJO and business logic classes, simplifying
development
*   Allows options for porting applet- and JNLP-based systems to
present-day browsers

Details
---

An additional jpackage option for type will be added: `js`

jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
code to JavaScript, with the main class compiled to a JavaScript method
called 'main()'.

jpackage bundles application code, runtime, and resources into a
platform-specific format. For this new JavaScript type, the layout will be
either a ZIP file or a standard WAR file. The ZIP format will contain the
files ready to be extracted to a static file webserver or HTML hosting
service. Generated WARs will have the required structure to be deployable
in a Java web application container.

### WAR layout

*   HelloApp.war
*   index.html (Main application page, loads classes.js and invokes
main())
*   teavm
*   classes.js (Class files, templates, and resources compiled to
JavaScript)
*   css
*   (CSS files from application)
*   META-INF
*   MANIFEST.MF
*   WEB-INF
*   web.xml

### ZIP Layout

*   HelloApp.zip
*   index.html (Main application page, loads classes.js and invokes
main())
*   teavm
*   classes.js (Class files, templates, and resources compiled to
JavaScript)
*   css
*   (CSS files from application)

Basic usage: Non-modular applications
-

Command-line usage is similar to jpackage today, except you use the `--type
js`. For example, if you have your application JARs in a folder called
`lib` and the JAR with the declared `main()` method is `main.jar`, you
could use this command:

```
$ jpackage --type js --name myapp --input lib --main-jar main.jar
```

This will produce `myapp.war` in the current directory. This is a standard
WAR file ready for deployment in any web application container (like
Tomcat). When myapp/index.html is opened in a browser, the code in main()
will be executed, in-browser. A typical Hello World main() method like

```
public static void main(Str

RFR: 8254598: StringDedupTable should use OopStorage

2021-04-24 Thread Kim Barrett 
Please review this change to the String Deduplication facility.  It is being
changed to use OopStorage to hold weak references to relevant objects,
rather than bespoke data structures requiring dedicated processing phases by
supporting GCs.

(The Shenandoah update was contributed by Zhengyu Gu.)

This change significantly simplifies the interface between a given GC and
the String Deduplication facility, which should make it much easier for
other GCs to opt in.  However, this change does not alter the set of GCs
providing support; currently only G1 and Shenandoah support string
deduplication.  Adding support by other GCs will be in followup RFEs.

Reviewing via the diffs might not be all that useful for some parts, as
several files have been essentially completely replaced, and a number of
files have been added or eliminated.  The full webrev might be a better
place to look.

The major changes are in gc/shared/stringdedup/* and in the supporting
collectors, but there are also some smaller changes in other places, most
notably classfile/{stringTable,javaClasses}.

This change is additionally labeled for review by core-libs, although there
are no source changes there.  This change injects a byte field of bits into
java.lang.String, using one of the previously unused padding bytes in that
class.  (There were two unused bytes, now only one.)

Testing:
mach5 tier1-2 with and without -XX:+UseStringDeduplication

Locally (linux-x64) ran all of the existing tests that use string
deduplication with both G1 and Shenandoah.  Note that
TestStringDeduplicationInterned.java is disabled for shenandoah, as it
currently fails, for reasons I haven't figured out but suspect are test
related.

- gc/stringdedup/   -- these used to be in gc/g1
- runtime/cds/SharedStringsDedup.java
- runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
- runtime/cds/appcds/sharedStrings/*

shenandoah-only:
- gc/shenandoah/jvmti/TestHeapDump.java
- gc/shenandoah/TestStringDedup.java
- gc/shenandoah/TestStringDedupStress.java

Performance tested baseline, baseline + stringdedup, new with stringdedup,
finding no significant differences.

-

Commit messages:
 - New string deduplication

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254598
  Stats: 6185 lines in 105 files changed: 2361 ins; 3202 del; 622 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662