Difference between revisions of "Shared JVM Infrastructure"
(New page: Additional ideas: JRuby/Jython share a startup script. Can we generalize this? Opportunities for a shared IR and compiler backend? What we don't want to do: (From Tom) Shared AST this...)
Revision as of 15:14, 18 September 2009
JRuby/Jython share a startup script. Can we generalize this?
Opportunities for a shared IR and compiler backend?
What we don't want to do:
(From Tom) Shared AST this wouldn't work for Jython, our AST is mapped against what CPython does
Original Proposal for JVM Summit Workshop - Shared Infrastructure for JVM Languages
Just as the Java platform simplifies the development of language implementations, collaborating on a shared infrastructure can further reduce development efforts and meet expectations about compatibility, ease of use, and various costs like startup latency. For Jython, perhaps 10% of the open bugs are in areas that could be addressed by such infrastructure. This proposed workshop will bring together implementers to discuss such topics as the following:
Jar scanning and package cache. Jython implements the same jar scanning that an IDE needs - or a developer might whip up the essence of with the jar tool and grep. How might other languages benefit from our robust implementation? And what can we do to make it better?
Extending native OS support. Native functionality support was not considered a high priority in the past. However, enabling it has enabled Jython, for example, to use standard Python package distribution and build tools. In this example, such support enables Jython to manage the full lifecycle, not just in an app container (where native OS support is likely not applicable and may be restricted by the security policy in effect). Jython and JRuby have collaborated on Posix support, and it's possible other implementers may wish to share work on this as well. Other functionality to consider include fork, additional signal support, pseudo ttys, syslog, and the like.
Reducing effective startup time. Nailgun has become popular, but as an open execution server, it provides no security whatsoever (beyond what a firewall can do). In this workshop, we can consider the design goals of a possible replacement that retains Nailgun's effective model of using a lightweight C client wrapper to communicate requests back to a JVM, while providing appropriate security. This can make many implementations competitive for tools for the command line, and not just in testing (this is how Nailgun is typically used now).
Depending on time and interest, we may be able to open the discussion on other issues like these:
JLine. Console support of readline functionality remains relevant as ever. Jython and JRuby have both adopted JLine, in part because of its BSD license. Besides maintaining it (including fixing a bunch of bugs), what else needs to be done?
Daemonization wrappers and lightweight containers. Containers supporting servlets and OSGI certainly address common use cases. Are there applications that could have more exotic needs? What do we need beyond Apache commons-daemon for them?
Retrotranslator. This is probably not as necessary as it was 2 years ago, but it might be interesting to share experiences on effective use of Retrotranslator.
NestedVM. Except for SQLite3 (already done) and numeric codes in Fortran, do we need to convert other interesting infrastructure to Java through the use of tools like NestedVM?
Android and other mobile platforms. As of Cupcake (Android 1.5), reflection looks usable, including dynamic proxy support. Android Scripting Environment and App Inventor (currently targeting Kawa) also provides useful support. In addition, are other mobile platforms functionality for
FFI. Working with C-based systems is a common theme here, because in the end, Java infrastructure already integrates quite readily. Further enhancing the FFI support used by JRuby and being considered by Jython is an obvious win.