There will likely be many more small, unchanging applications than large
constantly changing applications requiring upgraded code to support new
standards. There needs to adequate attempt at accommodation of application
deployment paradigms where having to change API use in the application is a huge
waste of time, and will be nearly impossible for the author to make it possible
for "users" to know how to do that (primarily because Java still has no App
store, but also because more "users" of "software" are often not developers who
know about releases of fixes and updates).
Jar based deployment has always been a very convenient way to ship Java code
that didn't need odd startup control, such as command line parameters for
policy, URL handlers etc. And, even some of those things could be done at run
time quite readily.
If all Oracle and the OpenJDK community wants, is to use Java for "server apps"
where deployment and management have significant administrative overhead, then
that will significantly reduce the buy in to any "new paradigm" for Java deployment.
The desktop environment is still horribly ignored as a place where Java could
really provide great user experiences, if the UI strategy was part of the work
that people invested in getting right.
This strategy for "packaging" Java could allow custom UI work to be done and
substituted into the runtime environment so that more investigation and work
could happen toward fixing all the plethora of problems that have manifested
from there only being a single, closed system for UI "improvement".
Gregg Wonderly
On 11/16/2014 7:47 AM, Remi Forax wrote:
On 11/15/2014 11:18 AM, Alan Bateman wrote:
On 14/11/2014 16:34, Bill Pugh wrote:
Following up on a email thread started by Dalibor Topic…
In short, back porting jrt-fs.jar to work under Java 7 would be very helpful
to the FindBugs project.
At length:
FindBugs needs access to the classifies for the standard Java libraries in
order to analyze code. Right now, we access that through the file system,
but that won’t be possible under jigsaw and JEP 220: Modular Run-Time Images.
The JRL file system is what is recommended and needed to support FindBugs
access to standard library classifies under Java 9. Having to support two
different mechanisms for accessing standard library classifies would be
annoying. We could move entirely over to the JRL file system. However,
FindBugs is committed to running under Java 7 for a long time, at least
several more years, and it would be good if FindBugs support for Java 9 were
available within a year, if not sooner.
So, if jrt-fs.jar ran under Java 7, we could just rewrite that section of
FindBugs to use the JRL file system, and have one version of the code
running for Java 7+.
If the jrt file system provider could run on JDK 7 then it would just mean
that a tool running on JDK 7 could access the class files and resources in a
JDK 9 image. So I think this would mean that FindBugs would need to keep its
existing code so that it can get to class files in JDK 7 and JDK 8 runtime
images.
As to whether it could run on JDK 7 then it could be made to work but would
require dropping the use of newer Java Language and APIs in the
implementation. It would also require a few contortions in the build as JDK 9
uses a JDK 8 for bootstrapping (we always use a JDK N-1 as the boot JDK).
Also just to say that a one-off back-port for JDK 7 wouldn't work as the JDK
9 image format is intended to change and evolve, hence a build of jrt-fs.jar
in JDK 9.0.0 may not work with a JDK 9.0.1. This means that for now at least,
tools have to use the jrt-fs.jar in the JDK 9 image that they want to access.
The only way that I think would be possible to avoid two mechanisms is for
future JDK 7 and JDK 8 updates to include a jrt-fs.jar that works in the same
way but makes it transparent that the classes and resources are coming from
rt.jar, resources.jar, jsse.jar etc. Even then, I would assume that FindBugs
and other important tools wanting to keep the existing mechanism so they can
work on existing JDK 7 and JDK 8 versions.
-Alan.
First, I think we should provide a good answer to that question,
anything that can smoother the integration of jigsaw will increase its
adoption rate.
I think it's not a good idea to try to embed jrt-fs.jar in older releases.
Instead, we can provide
a backport of jrt-fs.jar lets name it jrt-fs-backport.jar, publish it on maven
central
(with the same licence as the OpenJDK) and lets tools that need it to use it.
I have taken a look to the source code of jdk.internal.jimagefs and
jdk.internal.jimage and
i think such backport is possible with an automatic tool if we stick with the
following rules
for the development of the two packages:
- you are allowed to use lambdas and functional interfaces declared inside
java.util.function
so API like j.i.jimage.Archive that use things like Consumer in public
methods is fine.
- you are not allowed to use any default methods introduced in JDK8 (Stream
API, by example)
nor to use ReflectiveOperationException because this requires to patch
existing JDK classes.
Given the current source code, I don't think it's a big deal to refactor it a
little to avoid
the use of the Stream API (BTW, there is a method forEach on Iterable, you
don't have
to create a Stream for it, and instead of Array.asList(foo).stream(), there is
a method
Arrays.stream() for that) and it can write the tool that does the retro-weaving.
cheers,
Rémi
