Monday Aug 13, 2012

Java One 2012 Java SE Embedded Hands On Lab Returns!

After successful runs at Java One 2011 San Francisco and Tokyo, The Java SE Embedded Hands On Lab returns for Java One 2012.  If you're attending the Java One event in San Francisco (Sept 30 - Oct 4), please consider signing up for this session.  As an added incentive, we will be raffling off a couple of the Plug Computer devices that you'll gain experience with during this lab.  Seating is limited to 100 students, so register early.

Here's an overview:

This hands-on lab aims to show that developers already familiar with the Java develop/debug/deploy lifecycle can apply those same skills to develop Java applications, using Java SE Embedded, on embedded devices. The participants in the lab will:

    • Have their own individual embedded device so they can gain valuable hands-on experience
    • Turn their embedded device into a web container, using off-the-shelf software
    • Learn how to deploy embedded Java applications, developed with an IDE, onto their device
    • Learn how embedded Java applications can be remotely debugged from their desktop IDE
    • Learn how to remotely monitor and manage embedded Java applications from their desktop

The course description can be found here:
HOL 7889: Java SE Embedded Development Made Easy

In addition, 2012 marks the first year that we will have a venue specifically tailored for the Java embedded community.  Entitled Java Embedded @ Java One,  this event takes place during the JavaOne/OpenWorld week in San Francisco on October 3-4.  To Quote from the Java Embedded @ Java One URL:

The conference will feature dedicated business-focused content from Oracle discussing how Java Embedded delivers a secure, optimized environment ideal for multiple network-based devices, as well as meaningful industry-focused sessions from peers who are already successfully utilizing Java Embedded.

So if you want to participate in what many consider to be the next big trend in computing -- the internet of things -- come join us 10/3-4 in San Francisco.

Tuesday Jan 03, 2012

Tomcat Micro Cluster

The term Micro Server has been bandied about recently as a means to provide a certain class of server functionality. As embedded systems continue their inexorable drive towards better performance, and standard hardware/software architectures become ubiquitous, the notion of using low-cost, low-power, small-footprint devices as servers becomes quite realistic.  Just as data center managers have utilized multitudes of affordable rack mount servers to provide scalability, why not duplicate that effort with these off-the-shelf devices?

The video that follows takes the Micro Server to its next logical evolution: The Micro Cluster.  Built from commodity hardware (and by commodity I mean The Home Depot), the cluster board has a rack mount form factor that can house 12 Plug Computers.  As the Java SE HotSpot Virtual Machine is available for the Plug Computer (ArmV5/Linux), we'll utilize Apache Tomcat to demonstrate a Tomcat Micro Cluster.  Over time, as the individual compute nodes increase in performance and capacity, this should become even more compelling.

Wednesday Jun 01, 2011

Java SE Embedded Development Made Easy

Slowly but surely this old dog (who can learn new tricks, but at a snail's pace) came to the realization that although still quite relevant, a whole generation of people prefer not to read lengthy writings, but would rather digest information in small pieces using new media formats.  Thus the rationale for the following blog...

Certainly no thespian when it comes to public speaking, I will say this:  based upon my experience demonstrating Java SE on embedded devices, people have definitely expressed genuine interest.  Maybe it was the cool device (i.e. Plug Computer) which was used, or maybe this combination of hardware and software inspired the audience to think of the possibilities presented by this new platform.  Either way, I thought it might make sense to capture a shortened presentation/demonstration session.  Following is a 30 minute session broken down into two 15 minute videos (because YouTube only allows videos of 15 minutes or less for mere mortals). They aim to demonstrate how developers already familiar with the Java SE development paradigm can leverage that knowledge to seamlessly develop on very capable embedded processors.  Happy viewing!


Wednesday Mar 26, 2008

Reduced Footprint Java SE: Bringing Java Standard Edition Down to Size

A previous blog post demonstrated how you can, with minimal effort, lessen the disk footprint of a typical Java SE 5.0 runtime environment by about a third without violating the Java Standard Edition Licensing agreement. That post focused primarily on removing optional files and compressing class library jar files.  It turns out that with a little more engineering,  there is significant opportunity for further space optimization.

These additional savings involve more intimate knowledge of the inner workings of Java SE.  Sun performs this engineering work and provides a series of reduced footprint versions of Java SE, in binary form, for some of the most common embedded platforms.  They include some of these enhancements:1

  • Headless configuration - The inclusion of graphics subsystems like AWT and Swing comprise a large chunk of the Java SE footprint.  If your device has no graphics capability (i.e. is headless) why would you need to include this functionality?  Headless configurations:
  1. Do not support keyboard or mouse input
  2. Cannot create windows or display graphics
  3. Throw a HeadlessException when a graphics API is called
  4. Still support a functional Java 2D API for printing and off-screen rendering
  5. Are still 100% Java SE compatible
  • Eliminate client or server compiler - Sun's Java SE implementations include two HotSpot compilers, tuned and designed for specific environments.  The client compiler focuses on things like fast user interactivity and quick startup, while the server compiler's priority is on optimizing large, long-lived server applications.  The Java SE VM can only use one of these compilers at a time, so removing the unused one can save considerable space.
  • Minimizes memory consumption - Standard Java SE allocates RAM to house things like the JIT code cache and the object heap.  By default, each one of these areas (and others) can be assigned 64 MB.  In an embedded platform where the total amount of RAM might only be 64MB, Java SE will simply not have enough memory to run.  Java SE Embedded on the other hand, will automatically adapt memory usage to the amount of available RAM.  Consequently, 64MB is a reasonable amount of RAM for a large set of embedded Java applications.
  • Space vs. speed tradeoffs - (1) Java SE implements a thread lookup table, which in layman's terms, helps save a few instructions when switching between Java threads.  By eliminating this table, a couple of MBs of RAM can be spared from your application's working set. (2) Java SE also sets aside an area (mmap'ed) for loading jar files into random access memory, which as was explained to me, may help performance, but may also result in duplicate copies of jar files in memory.  Removal of this area further reduces the Resident Set Size.

An Example

Following through with the exmaple in the last post., let's start with an unmodified version of Java SE 5.0 Update 13 for Linux/x86.  By default, the static footprint is approximately 88MB.

   jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
88185   ./jre1.5.0_13/

After following the directions in the previous post, we can pare it down to roughly 60MB.
   jimc@jalopy:/tmp> du -sk /tmp/jre1.5.0_13/
59358 /tmp/jre1.5.0_13/

Downloading Sun's reduced footprint version of Java SE for x86/Linux yields:

   jimc@jalopy:/tmp> du -sk /tmp/jre1.5.0_10/
31003 /tmp/jre1.5.0_10/

This version of the JRE is about one-third it's original size, and furthermore has been modified to use significantly less memory than the standard Java SE offerings.  Note: we are comparing slightly different updates of Java SE 1.5 (update 13 vs. update 10).  They are indeed not identical but their differences should be considered, for the sake of argument, negligible. 

[1] Many thanks to Bob Vandette, who though presentation and conversation, supplied this information.  One of many sources comes from Bob's Java ONE 2007 session called, Deploying Java Platform Standard Edition (Java SE Platform) in Today's Embedded Devices (TS-2602)


Thursday Feb 14, 2008

Reducing Your Java SE Runtime Environment Footprint (Legally)

Because the resource requirements for Java Standard Edition are by no means insignificant, developers interested in utilizing Java on smaller platforms have traditionally opted for one of the Java Micro Edition configurations.   It should therefore come as no surprise that some of the Standard Edition functionality has to be sacrificed in these constrained Java ME environments.  However, as the trend towards more capable devices continues, it becomes reasonable to once again consider the advantages of utilizing Java SE.  Unfortunately, with a static footprint that could easily exceed 100MB, Java SE may still be too large to swallow for a lot of applications.

It is duly noted that the criticism leveled at Sun for exacting too much control over the Java platform has been widespread.  Like it or not though, one benefit of Sun's initial stewardship has been that Java SE has remained a standard platform, and threats to splinter it have thus far been reasonably thwarted.  Accordingly, in order to avoid incompatibilities, there are restrictions spelled out in the Java SE Licensing Agreement which prohibit modification of the Java SE binary distribution.

That  being said, there are a list of optional files, specified by the Java Runtime Environment's README file which can be removed, without ramification, to lessen the footprint.  They include:

  • Deployment tools (e.g. Java Web Start, Java plugin)
  • IDL and RMI tools (e.g. rmid, tnameserv)
  • Security tools (e.g. policytool, keytool)
  • orbd
  • Localization (charsets.jar)

In addition, further space optimization can be achieved by compressing the class library files contained in the rt.jar file.  By default, Java SE ships this jar file uncompressed.  The tradeoff here is space vs. performance, i.e. the classloader must expend cycles to uncompress the Java classes as they are being loaded.

An Example

So let's download a sample JRE from java.sun.com and see how it's footprint can be minimized.   For this example, we'll use Java SE 1.5.0 Update 13 for Linux x86.

After installation, the JRE is approximately 88MB

   jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
88185   ./jre1.5.0_13/

Here's what it looks like after removal of the optional files

   jimc@jalopy:/tmp> cd jre1.5.0_13/

jimc@jalopy:/tmp/jre1.5.0_13> /bin/rm -rf lib/charsets.jar lib/ext/sunjce_provider.jar \\
lib/ext/localedata.jar lib/ext/ldapsec.jar lib/ext/dnsns.jar bin/rmid \\
bin/rmiregistry bin/tnameserv bin/keytool bin/kinit bin/klist bin/ktab \\
bin/policytool bin/orbd bin/servertool bin/javaws, lib/javaws/ and lib/javaws.jar

jimc@jalopy:/tmp/jre1.5.0_13> cd ..
jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
77227 ./jre1.5.0_13/

And after rt.jar has been compressed

   jimc@jalopy:/tmp> mkdir rtjar
jimc@jalopy:/tmp> cd rtjar/

jimc@jalopy:/tmp/rtjar> jar -xf /tmp/jre1.5.0_13/lib/rt.jar
jimc@jalopy:/tmp/rtjar> zip -q -r /tmp/rt .
jimc@jalopy:/tmp/rtjar> mv /tmp/rt.zip /tmp/jre1.5.0_13/lib/rt.jar

jimc@jalopy:/tmp/rtjar> du -sk /tmp/jre1.5.0_13/
59358 /tmp/jre1.5.0_13/

Conclusion

In many cases, you can lop off about a third of the Java Runtime Environment footprint with no ill effects.  In a future post, we'll discuss how Sun has further reduced Java SE significantly, not only from the point of view of static footprint, but also from a RAM usage perspective too.  For a preview you can check out Sun's Java SE Embedded technology.

About

Jim Connors-Oracle

Search

Categories
Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today