[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel)
From:       bob.vandette () oracle ! com (Bob Vandette)
Date:       2012-11-29 15:42:38
Message-ID: 5B5CEAA3-258F-49F2-A030-2B5304337585 () oracle ! com
[Download RAW message or body]

Sorry for the delay in responding.  Thanksgiving got in the way.

On Nov 18, 2012, at 7:05 PM, Florian Brunner wrote:

> 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.

We are trying to avoid splitting packages at all costs.

> 
>> 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

This dependency is being resolved in JDK8.

> 
> 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.
> 

We have not yet made a decision on these beans classes.  I'll try to dig into these use cases.

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

In general, we decided to keep Desktop, JAXWS and Corba out of the compact profiles.
We don't want to do anything in JDK8 that will make it difficult to support Jigsaw/modules
in JDK9.  These groups are too difficult to split up and even in JDK9, there are no plans to do so.  
The packages you mention are either implemented in these broader categories or are only used 
by them so we decided to keep them together.

javax.accessibility, print and sound are all planned for the Jigsaw desktop module (in full JRE).

javax.activation is implemented in jaxws and javax.annotations is only used by jaxws in the jre
javax.activity is implemented in the corba collection

We have included javax.annotation.processing in compact3.  This is required to support the
javac compiler.  


Bob.


> 
> 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.


[prev in list] [next in list] [prev in thread] [next in thread]