java.mini? was: Dependency leaks and embedded Java

[Jaroslav Tulach]

I am also trying to play with Java in a very small environment (but probably 
with more memory than 72kb) and it would help me if the smallest profile would 
not be as bloated as currently proposed java.base.

> Most other embedded Java environments seek to get around the
> monolithic JDK problem by developing their own JDKs. 

Right. That is sort of what I am doing. But I don't consider forking good from 
a long term point of view.

> ....the dependency extent is reasonable, but for Java 7 the
> same classes leak a lot more, and classes that we could previously
> handle can no longer be part of our embedded programs :-(

This is my observation as well. A Throwable has now a direct dependency on 
ArrayList (as of JDK7)! That really does not make the transitive closure of 
Object smaller.

A modularization has to be driven by a need, I know. So far the only need 
jigsaw team tried to achieve was to fit Hotspot on mobile devices and for that 
java.base is enough (as demonstrated @ J1).

However for certain environments it is clearly to big. Can't jigsaw also define 
the smallest possible profile (e.g. with classes that are directly needed 
during compilation by Javac like String, StringBuilder, Enum, Throwable)?

Having such "java.mini" profile would help porting Java to unusual small 
environments. It would ultimately lead to smaller fragmentation of Java - as 
it is better if the smallest profile is standardized than created by 
independent individuals.

Just my 2 Kč to provide something to think about during sleepless nights.
-jt


Dne Po 22. října 2012 15:37:54, Stephan Erbs Korsholm napsal(a):
> To jigsaw-dev,
> 
> Just want to let you know about our research project called the HVM,
> which is an effort to (re)enable the Java SE Platform for low-end
> embedded devices. The targets we have in mind are micro-controllers
> with approx. 8kB (or more) RAM and approx 64 kB (or more) ROM (see
> http://icelab.dk).
> 
> On such devices the monolithic nature of most Java execution platforms
> is obviously a challenge. Using some tricks we are able to execute
> code like e.g the following on low-end embedded devices:
> 
> ArrayList<String> list = new ArrayList<String>();
> list.add("foo");
> list.add("horse");
> list.add("fish");
> list.add("London");
> list.add("Jack");
> Object[] array = list.toArray();
> Arrays.sort(array);
> 
> Most other embedded Java environments seek to get around the
> monolithic JDK problem by developing their own JDKs. The goal of the
> HVM is to actually allow developers to use e.g. Java 6 or 7 to run
> code like above on low-end embedded devices.
> 
> We use static program analysis to calculate a conservative
> approximation to the set of classes and methods that may be required
> to execute the code above. This set we call the 'dependency extent' of
> the program. The method applied to do program specialization (the act
> of shrinking a given application to contain only actual dependencies)
> is an instance of the k-CFA algorithm and also known as variable-type
> analysis (VTA).
> 
> Code like above can be analyzed and results in a manageable dependency
> extent, but code like e.g. System.out.println("Hello") cannot. For
> 'HelloWorld' the dependency extent becomes impractical for low-end
> embedded devices. For the 'HelloWorld' scenario we say that a
> 'dependency leak' has been introduced.
> 
> An interesting observation that we have made is that for Java 6, many
> of the collection classes and other utility class like e.g. String and
> StringBuffer, the dependency extent is reasonable, but for Java 7 the
> same classes leak a lot more, and classes that we could previously
> handle can no longer be part of our embedded programs :-(
> 
> I find the jigsaw project very interesting in relation to our efforts, and
> look forward to eventually explore the dependency extents of our programs
> based on a modularized JDK.
> 
> To ease the use of Java for embedded devices a modularized JDK (and
> VM) would definitely be attractive.
> 
> Since we base the HVM program specialization on static program
> analysis we have to preclude the use of dynamic class-loading. Other
> similar efforts exists e.g. ProGuard.
> 
> Kind regards,
> 
> - Stephan Korsholm, VIAUC, DK