Web Frameworks

I found this free e-book which describes some web development frameworks for Java developers. These frameworks are like those of event driven GUI applications. However they sometimes have steep learning curves. Java provides some web technology. But it does not provide a web application framework. So these third party frameworks have come about to help you with the low level tasks.

Struts is the most well known framework. It is well documented and has a large following. A drawback of using struts are the big configuration files. You need to use a lot of XML markup files for forms and rendering. I hear that developers are moving away from this framework in general.

Java Server Faces (JSF) is another framework. It runs on an application server like WebSphere. It strives to decouple the components and the view. The most frequently used implementation of JSF is Apache's MyFaces. JSF uses a managed bean to store user info. The bean classes contains the logic. This technology is backed by big companies like the former Sun Microsystems. A few years back I did hear that JSF might not be appropriate for mission critical applications. Not sure whether this opinion has since changed yet.

Game Programming

I just started reading The Black Art of Java Game Programming. And I tell you what. I already have a good feeling about this book. Sure it was written in 1996 when Java 1 just came out. However by chapter 2 we are already learning about animation. Damn.

One thing that struck me as odd was that the authors of the book are young. Or more precisely they are still in school. One of these is an undergrad, and the other a grad. That does not mean they are junior. They seemed to be on the cutting edge of Java right when it came out.

This book does specialize in teaching you how to code network games. The authors believe that object oriented programming is the way to go for creating games. They are going to teach me a lot about AWT (since Swing has not been invented I guess).

Chapter 1 already got me into a lot of Java syntax. It also highly recommends you use arrays instead of lists for speed. Back in 1996, Java ran a lot slower than compiled C or C++. I also learned some basic stuff I was never taught in my Java college class. The import statement allows you to reference classes in packages. However you can still access those classes without an import by using the classes fully qualified name. I did not know that. I am excited about getting into the meat of this book. Who knows? I might be turning out some cool games in no time.

Java Enterprise Edition 6

I read an article on the good things coming in Java EE version 6. There is a new API for REST. There is a web profile, meaning you can use a scaled down version of the previously bloated enterprise edition. In the tools department, there is a new version of NetBeans being released.

Enterprise Java Beans has been updated. Things have gotten much simpler with it. The beans are "light". Complexities such as requirements for frameworks are gone. This is in line with the scaled down profile version of the Java EE.

Right now I am still concentrating on learning Java Standard Edition. Some Java friends keep asking me whether I am up to speed on Java EE. It might be time to start learning it. Looks like I will have access to a new updated version, which is actually simpler than previous ones.

Java Game Programming

I read a blog post about hiring for startups (or something like that). It was written very well. So I checked out the author's bio. Turns out he was one of the authors of an old book called The Black Art of Java Game Programming. When I say old, I mean it was published in the 1990's for Java 1.0.

Normally books like these get obsolete immediately. And this book seems to have code that became obsolete with Java 1.1. However a number of comments on Amazon indicate the book still has a lot of merits. Well it warrants a read by me even though the book might be 25 years old. I placed an order with Amazon today.

I will let you know what I learn. Things are looking good for my Java development. I took a college class last year. This year I plan to take a week off from work and complete the remaining chapter in my college class textbook. I had though I might learn some more HTML programming (including JavaScript) later this year. However I might change direction and get deeper into Java. If so you will be hearing about it with some more frequent posts on this blog. Stay tuned.

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.