Java Running on Apple II c

I just heard that a subset of Java can now run on the Apple IIc computer. Bamm. Of course there are some limitations. You need a real Apple II c with the 65C02 microprocessor. That means Apple II e computers don't work with this port.

The good news is that some of Swing is available. No AWT or JDBC is supported yet. The eventual goal is to port all of Java to the Apple. Right now there is also a JDistro available. This is a desktop which is written in Java Swing. JDistro is a limited version too that can only run 1 app at a time.

The whole thing fits on 3 floppies. Source code will be made public. This seems pretty hard core as the Apple II is some hardware from yesteryear. Now we just need Java ported to the Tandy Coco III, and I will be complete.

Making the JVM Fast

Java was a very slow performer when it first came out. Then it started becoming a contender for other compiled languages like C and C++. In fact, Java is faster than C++ in some cases. But in general it is a little slower.

All code is interpreted by the Java Virtual Machine. However for methods that are used very frequently, the JVM compiles the code and then you get really good performance. The trick is that the JVM can see how the code is used many times. Then it has the knowledge needed to optimize the compilation.


With the default options, code written in smaller sized methods runs faster. The reason for this is the the JVM will not compile methods that are too large. You can modify this behavior with some options. In fact you can even force the JVM to compile everything. While this might seem to be best, it is not. You should let the JVM interpret the code first. Only after interpreting a method many times can it make the best optimizations for compilation.

J2EE to Tomcat Port

There is a movement in the enterprise to port J2EE applications to lightweight Java containers such as Tomcat. This is part of the Agile development movement. There are many ways to tackle this port. You can just code some services up in lightweight Java. Or you could just write the new stuff in lightweight Java.

Techniques such as SOA are complex. Java frameworks now offer a lot, but have a small code footprint. There are multiple lightweight Java containers. Tomcat from Apache happens to be a free and popular one. This may be the way of the future. Developers are tired of running under app servers like WebSphere.

Servoy Library

Servoy Corporation is releasing its libraries under a GPL license. They provide access to Java function within JavaScript. The solution uses native Java code. You can think of this as JavaScript wrapping Java objects.

This solution is aimed at web developers. Servoy will release the source code on their own hosted Subversion servers. The GPL license requires that users of their libraries in turn make their source code available to the public free of charge.

Mission Critical Java Apps

Department of Defense standard DO-178C defines methods to verify object oriented systems for critical uses. In the past, Java has not been normally used for mission critical applications. All that may be changing now.

Java now has JSR-302 which addressed safety critical Java. Safety critical apps are mostly the domain of large scale DoD sponsored programs with big money backing them. This is a good move for the Java world.

Java on the Cloud

A bunch of companies are working on a Java based solution to cloud computing. It will be using the Spring framework. It will run on vSphere from VMware. And it will be hosted on the Salesforce.com servers. This beat will be called VMforce. I guess that means that VMware is the main company behind it.

This solution will be able to host any Java application in the cloud. There are around 6 million Java developers out there. Cloud computing is supposed to boost their productivity. So if this works, this may have a big impact on their productivity. Look for VMforce to be available later this year.

Java Performance

In the old days, there was much concern that Java programs were slow and could not complete with C or C++ programs. It seems that this is not as true any more. I just read a huge discussion on the topic. Here are some interesting points I came out with.

C has a small footprint. So if that is required, choose C. Java has a long startup time. This is the time it takes for the JVM to load and initialize. We are talking on the order of seconds here.

Direct machine access can be done with Java using JNI. However it is clunky. In C, direct machine access is natural. However garbage collection in Java is easier than C's malloc/free. Java also make parallel programming easier.

Be careful when you are comparing speed between Java and C programs. You must ensure both programs are using the same algorithm. You also need accurate stats to make a good comparison. As an aside, C# will normally be a little bit slower than Java.

Java 7

Java 7 is big. The Java Virtual Machine will support dynamic languages. Strings can be used in a switch statement. The JVM performance has been improved. A new garbage collector called the G1 is the source of the speed up.

There are other niche additions to Java in Java 7. For example, in the security world, there will be support for curve cryptography. Personally I care little about JVM support for dynamic languages. Java with its static typing is fine for me.

Gosling is Gone

James Gosling, creator of Java, has quit from Oracle. He announced this on his blog. Strangely enough, his blog has disappeared. I guess they chop your blog at Oracle when you leave.

Gosling did not provide a reason for leaving. Hello? Can you say Oracle acquisition? He is going to take some time off.

Word on the street is that the Java faithful were taken by surprise. Does this mean that Gosling will not be present at JavaOne? You got to go and find out.