Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel)

[Florian Brunner]

Hi Bob,

Thanks for your response.

> We have analyzed two different OSGi implementations and they don't appear to
> have any dependencies on these classes.

I was more refering to the fact, that OSGi sometimes has issues when packages 
are split/ incomplete.

> Can you provide us with a list of some concrete applications that you
> believe require Java Beans?  We could investigate the feasibility of
> pushing this package down to compact3 if there's enough demand and if it
> doesn't have any dependencies that we can't untangle.


According to:
http://docs.oracle.com/javase/7/docs/api/java/beans/package-use.html
JavaBeans are used even by supported Compact1 profile packages such as:
- java.util.jar
- java.util.logging

Often JavaBeans classes such as PropertyChangeListener, Introspector, 
BeanInfo, PropertyDescriptor etc. are used somewhere in the implementation and 
not necessarily in the API, so it's a bit hard find the dependencies, but a 
quick search showed at least:

- Eclipse Link
- Spring
- Several Apache Projects
- GlassFish Projects
- robokind.org

I'm sure the list can go on.

Also my own framework, which I'm about to release, uses 
PropertyChangeListeners under the hood in the JavaFX-independent parts.


And what about the other packages I've mentioned:
> >     javax.accessibility
> >     javax.activation
> >     javax.activity
> >     javax.annotation
> >     javax.print.*
> >     javax.sound.*

Especially javax.annotation is also quite popular.

Regards,
Florian

Am Freitag, 9. November 2012, 18.34:20 schrieb Bob Vandette:
> On Nov 9, 2012, at 5:55 PM, Florian Brunner wrote:
> > Hi Bob,
> > 
> > As I understand the profiles/ project Jigsaw in the context of JavaFX is
> > it to makte it easier to port Java + JavaFX to other platforms especially
> > by omitting AWT. So I understand that the following packages are omitted:
> > 
> > javax.awt.*
> > javax.swing.* (dependencies to AWT)
> > javax.imagio.* (dependencies to AWT)
> > 
> > But neither are any of the following packages mentioned:
> >     java.beans.*
> >     javax.accessibility
> >     javax.activation
> >     javax.activity
> >     javax.annotation
> >     javax.jws.*
> >     javax.print.*
> >     javax.sound.*
> >     org.omg.*
> > 
> > Now, I understand that the java.beans.PropertyEditor related classes cause
> > an issue because of the dependency to AWT, but the JEP 161 states that
> > some packages have to be split up anyway (which will probably cause
> > issues with OSGi based library, though). And Java Beans patterns (and
> > e.g. PropertyChangeListener) are used at many places in applications and
> > frameworks.
> We really want to avoid splitting packages because this will make it
> difficult to transition to Jigsaw in JDK9.
> 
> The PropertyChangeListener classes are problematic.  We currently have a
> small set of beans classes in compact1 that we'd like to remove.  I've
> requested the fx team remove any dependency on these class in preparation
> for their possible removal.  They have a few JIRA's filed to track this
> change.
> 
> We have analyzed two different OSGi implementations and they don't appear to
> have any dependencies on these classes.
> 
> Can you provide us with a list of some concrete applications that you
> believe require Java Beans?  We could investigate the feasibility of
> pushing this package down to compact3 if there's enough demand and if it
> doesn't have any dependencies that we can't untangle.
> 
> > I think there should be a profile (maybe Compact3?), which includes
> > everything except AWT related classes to allow maximum reuse and
> > portability of existing 3rd party libraries, which make the Java
> > ecosystem so rich, so they can be used in JavaFX applications.
> The compact3 profile is a very rich set of APIs.  The only large group of SE
> APIs that are not found in this profile are:  Desktop (AWT/SWING/Java2D),
> JAX-WS, and Corba.
> 
> For embedded we felt that JAX-WS was too heavy weight and difficult to split
> up or subset.  We've been working under the assumption that embedded
> devices will probably continue to use the smaller kSoap or move to JAX-RS
> for lighter weight RestFul web services.
> > And another question:
> > 
> > The JEP 161 states:
> > "If a package listed in a lower Profile in this table has subpackages then
> > those subpackages are included in that Profile unless they are identified
> > as members of some higher Profile. Thus the java.lang.reflect package,
> > e.g., is in the Compact1 Profile, but java.lang.management is in the
> > Compact3 Profile."
> > 
> > But the profile Compact1 states explicitly both java.util and
> > java.util.logging.
> > 
> > What about the following packages?
> > 
> >     java.util.concurrent
> >     java.util.concurrent.atomic
> >     java.util.concurrent.locks
> >     java.util.jar
> >     java.util.regex
> >     java.util.spi
> >     java.util.zip
> 
> We were attempting to keep the contents of the JEP to the minimum.
> 
> These packages are covered by this statement "If a package listed in a lower
> Profile in this table has subpackages then those subpackages are included
> in that Profile ".  Since they aren't explicitly mentioned in higher
> profiles, they are in compact1.
> 
> Feel free to build your own set of linux 86 profiles where you can see
> exactly what we've proposed for each profile.
> 
> You could also grab a copy of this repo and look at the
> jdk/make/profile-rtjar-includes.txt file that lists the packages included
> in each compact profile level.
> 
> http://hg.openjdk.java.net/jdk8/profiles/jdk
> 
> Thanks for the input,
> Bob.
> 
> > I think it would be clearer if all subpackages were listed explicitly.
> > 
> > - Florian
> > 
> > Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette:
> > > There have been some questions on this list about Jigsaw, compact
> > > profiles,
> > > embedded, minimal VMs and the JRE customization tool called jrecreate.
> > > Richard asked me to jump in to try to clear up any confusion.
> > > 
> > > Here goes ....
> > > 
> > > The Java Modularity Project (project Jigsaw) that was originally planned
> > > for JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead)
> > > was expecting to use Jigsaw in order to provide smaller customizable
> > > Java runtimes for embedded devices.  Lacking this new functionality, we
> > > decided to propose a simpler alternate plan that would enhance the JDK8
> > > specification to allow the distribution of a small set of profiles that
> > > are
> > > subsets of the full Java runtime.   These are called Compact Profiles.
> > > We
> > > have proposed three compact profiles.  A talk and presentation that I
> > > gave
> > > at JavaOne describes these profiles.
> > > 
> > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAE
> > > AD8A BE54064406AC304AD59/CON4538_Vandette.pdf
> > > 
> > > The Java Enhancement Proposal (JEP) for this work is here:
> > > 
> > > http://openjdk.java.net/jeps/161
> > > 
> > > The openjdk repository that implements our current prototype is located
> > > here:
> > > 
> > > http://hg.openjdk.java.net/jdk8/profiles
> > > 
> > > The mailing list that discusses the profiles is
> > > build-infra-dev at openjdk.java.net since the creation of the new profiles
> > > is
> > > done using the new configure based JDK build system.
> > > 
> > > This repository allows you to do a build that generates the full JRE,
> > > JDK
> > > but in addition produces three additional image targets (compact1,
> > > compact2, and compact3).
> > > 
> > > In order to achieve the smallest Java runtime for embedded (our goal is
> > > around 10MB), we have applied changes to Hotspot that allow us to build
> > > a
> > > small VM (2-3MB) with reduced functionality.  The small VM (minimal) +
> > > compact1 profile goal we've set is around 10MB.  We're at 11MB today.
> > > 
> > > In addition to the profile bundles and the small VM, we have a reduced
> > > Embedded FX stack that we'll run on embedded devices such as the
> > > RaspberryPi.  This FX Embedded stack is a compatible FX implementation
> > > without media and webkit support.   The goal for this added stack is
> > > 6MB.
> > > 
> > > The jrecreate tool that some of you have asked about is not a java
> > > stripping tool.  It's main purpose is to assist the embedded developer
> > > in customizing Java runtimes.  It allows the developer to select which
> > > profile, VM, debugging options, compression, security and FX options. 
> > > It does not strip the full JRE to produce the compact profile. The
> > > jrecreate will be packaged with the three compact profile binaries.  It
> > > simply copies these profiles and applies some additional massaging
> > > based on the selected options.
> > > 
> > > We have already pushed the minimal VM changes to JDK8 hotspot and will
> > > be
> > > open sourcing the compact profile changes since they will be a standard
> > > feature of JDK8 (independent of embedded).  The current profile changes
> > > in
> > > our project repository are only functional for Linux x86.
> > > 
> > > We certainly recognize the value that small Java runtimes + reduced FX
> > > could have on Java applications published on Web App stores, but the
> > > current immediate plan is that the jrecreate tool is only going to be
> > > available with our embedded binary downloads since that's where it's
> > > needed most. I've had some discussions with our Netbeans team to see
> > > what it will take to make Netbeans profile aware.  This might be a good
> > > way of taking advantage of profiles, reduced FX for producing smaller
> > > applications for distribution.
> > > 
> > > I hope this help,
> > > Bob.