ERIC BRUNO'S BLOG

Java: The Daily Grind.

May 2007

Sun is building a JRE of minimal size that downloads classes as needed over the network.

The problem today is that most of Java’s runtime classes are bundled into one monolithic JAR file (rt.jar). Even if you need only a small percentage of the classes contained within it, your application requires the entire JAR file. This isn’t a problem if the JAR file is on the filesystem with your application. It becomes an issue when components run in a distributed environment, where classes need to be downloaded over a network. Today, instead of loading only the portions you need, the entire JAR would have to be downloaded. This is precisely the problem that has prevented Java Applets from being used more widespread than they are today.

Enter the Java Kernel, which requires only the class files needed to run a “Hello, world!” application. If an application executes code that requires more classes, only those classes are downloaded, saving both time and resources. To be clear, classes are grouped into what are called “bundles,” of which there are about one hundred currently defined. A compromise was made to balance the overhead of requesting classes one by one (many network round-trips) versus downloading classes as bundles, even if an application doesn’t need all the classes in a bundle. Given that there are about one hundred or so bundles, the tradeoff between bundle size and download requests seems reasonable. You can also build a custom bundle containing just the classes required for your particular application.

The goal has been to get the JRE below 2MB in size. To do this, Sun has omitted many optional features from the JVM such as the various garbage collectors that come with it (instead it uses just one). The result is that the Java Kernel JRE, which contains the JVM, the Java plug-in, Web Start, java.exe, javaw.exe, javaws.exe, support libraries, and various other files, is at 1.9MB in size.

Posted by Eric Bruno at 09:39 AM  Permalink |

Spring, the open-source Java application framework, has grown with Interface21’s support. Look for new software, and new releases.

Inteface21 is the company behind the Spring Framework, and offers consulting and training to companies building enterprise Java applications. Their goals are to maintain a strong relationship with the development community, and to be the commercial entity behind the popular open-source framework.

Spring includes many sub-projects in addition to the Spring Framework, such as Spring Web Flow, Spring Web Services, and so on (see the list here). On May 8, Interface21 added Spring Batch to this list.

Spring Batch, which itself is based on the Spring Framework, represents collaboration between Accenture and Interface21 to address the need for a Java-based framework for batch-oriented processing. Spring Batch’s features and capabilities include:
• High-volume, bulk processing of business transactions and data without the intervention of end-users
• Java-based business logic to improve the efficiency of software development and application processing, including support for important processing concepts such as job restart and parallel processing essential for high-volume transactional throughput environments
• Developers can focus on business logic, instead of the technical approach and details required for processing large volumes of information
• Leveraging highly effective Spring development framework concepts
• A common batch architecture framework
• Different interaction styles – ranging from scheduled-based program executions to message-based processing
• Minimized local framework development and support through software that is licensed under the Apache 2.0 open source software style license

The soon-to-be-released Spring Framework version 2.1 includes many enhancements including the extended use of annotations (JSR-260) to aid in component configuration. Existing XML-based configuration files can be combined with attribute-based configuration data to help developers migrate to an all-attribute approach over time.

Other enhancements includes support for JDBC v4; JSR-223 (scripting language integration including Rhino, Groovy, JRuby, and JavaScript); new JCA features for enhanced integration; and more. Version 2.1 remains backward compatible with previous versions.

Happy Coding!
-EJB

Posted by Eric Bruno at 10:52 AM  Permalink |

Did you see the Rich Green’s keynote address at JavaOne? If not, watch the webcast replay here.

There was an interesting (albeit quick) segment on real-time Java; specifically regarding Sun’s Java Real-Time System (Java RTS). Anna Ewing, the CIO at Nasdaq, spoke about Nasdaq’s key trading system, and how it’s implemented in Java. They handle hundreds of thousands of transactions per second during peak load, and they do it with Java. That alone is cool.

However, do you understand why Java RTS is important to Nasdaq? Before you answer, let’s brush up on what, exactly, real-time is. A real-time system is one that is subject to an operational deadline. For example, the time from when a real-world event occurs, to the moment the system completes its processing of that event must occur within a strict deadline. Such a system demands predictable overall system behavior, with bounded latencies.

Often, real-time is confused with “real fast,” but that’s not accurate. A web server is required to send back HTTP responses as quickly as possible, but that doesn’t make it real-time. Conversely, financial settlements (the transfer of money from one bank to another) for foreign exchange trades are required to occur within two days of a trade, or they become invalid and stiff penalties apply. That two-day deadline is a hard real-time requirement, but it doesn’t demand a “fast” response. Nasdaq most certainly has tighter deadlines than two-days. In fact, Anna alluded to a sub-millisecond deadline requirement in her talk at JavaOne.

That requirement applies to each task, not the average response time of that task. For instance, if a system has a real-time requirement to process a request within 1 millisecond, and the average response time for 10,000 requests is 600 microseconds, it might appear that the system has met its real-time constraints. However, that may not be the case. This measurement, unfortunately, is for throughput, which is also confused as real-time.

Even if the large majority of responses over time are delivered by their deadline, the existence of even a few responses that occur outside that deadline represent what is known as “outliers.” Since the number of, and the degree of, these outliers is unknown and therefore unpredictable, this high-throughput system is not a real-time system. Real-time means you must complete a task before a deadline, all the time, or the result is an error.

Now you understand the differences between high-performance systems (really only a relative term), high-throughput systems, and real-time systems. It should also now be clear why Nasdaq requires Java RTS. Having high-throughput with standard Java today is good, but because throughput is a measure of average response time, it means that some customers get their orders fulfilled outside of the agreed deadline. This could cost the customer (and Nasdaq) money, as the markets continue to move during that delay. Java RTS assures customers like Nasdaq that their Java code will perform its tasks within a predictable amount of time, all the time.

For Java RTS to do this, it requires a different form of garbage collection, as GC in standard Java can occur at any time and interrupt your code from executing. This can cause you to miss a deadline. The real-time garbage collector (RTGC) that comes with Java RTS solves this problem.

And if the RTGC, with its minimized, bounded, latencies still fall outside of your tight deadlines, Java RTS (which adheres to the Real-Time for Java Specification) provides a means to work outside of the heap and without the need for GC at all.

This is an exciting achievement for Java (and Greg Bollella, Sun's Distiguished Engineer behind its success) as it opens the door for it to be used in applications it couldn’t be used before, such as critical flight control systems, manufacturing systems, military applications, embedded systems, and so on.

For more in-depth information on the internal real-time scheduling within Java RTS, read this DDJ article by Dr. Greg Bollella.

Posted by Eric Bruno at 05:32 PM  Permalink |