Archive for the ‘Jan's Blog’ Category

Spring MVC on the iPhone

Thursday, March 25th, 2010

…and, as we discovered at the Open Source User Group meeting on 24th March, also on the iPod Touch!
If you’d like to explore in detail the application I used yesterday, download it from GitHub. The webapp uses, as the headline suggests, Spring MVC (with particular focus on ViewResolvers), and alongside the bog-standard JSP code, exploits jQTouch to make the iPhone/iPod Touch interface look very native app-like.
Alternatively, if you don’t want to get messy with the source code, you can just download the Spring MVC iPhone Slides.

Memory management module updated

Wednesday, March 17th, 2010

I have made significant updates to our memory management and garbage collection training module. Previously, I left out the details of the memory manager in the OS and some of the hardware details of the UMA platforms. I also skipped the low-level details of the JVM and covered just strong, weak, soft and phantom references.

With the new version of the module, the first attendees are going to explore how deep the rabbit hole really goes! I talk about the various types of memory in a computer, then show how the operating system presents this memory to user processes (see Figure 1).
Low-level memory overview
I then take a plunge into memory management in user processes. I start with the simplest memory management strategy: reference counting. Even though it is not applicable to Java and [safe] .NET code, it is still widely used strategy.
Once the reference counting is out of the way, I look at true managed environments. I explore the operation as well as management of the managed heap. The example slide in Figure 2 shows what the JVM does to allocate an object on the heap.
Managed heap
Next, I show what happens when the JVM frees some objects and I don’t skim on the details. You will learn about the defragmentation strategies and you will understand exactly why generational heaps are an excellent idea (see Figure 3).
Heap compacting
But that’s not all. Lifecycle of Java objects is not simply active -> freed; Java objects can be finalizable, in which case, the garbage objects fester around until the finalizer thread deals with them. (Does ‘festering’ sufficiently convey the fact that finalizers are generally not a good idea? Yes? Good!)

Obviously, I did not remove the content on the reference types and their operation and typical usage. So, after taking this module, you will have a good understanding of what the OS and the JVM does to manage memory. You will also be able to use this knowledge to make your Java programs perform much better by configuring the garbage collector and using the appropriate references in your code.

A word of warning, though: this module is complex and you may be wishing that you did not sleep through those hardware architecture and discrete mathematics lectures!

Training offer–not for the faint-hearted

Tuesday, March 16th, 2010

We have exciting new addition to our training programme. Our best trainers, Jan or Aleksa, can deliver a workshop, where the trainers and the attendees will analyse, design and implement a problem you are currently facing in your development. Our trainers will be able to combine their extensive experience in domain-driven design, Java EE (particularly the light part of Java EE: the Spring Framework, Hibernate, JMS, JMX) with a bit more abstruse AOP, logic and expert system programming. The trainers will also call on their deep understanding of the fundamentals of the UNIX and Windows operating systems, principles of relational databases (we wish today’s RDBMSs actually used the relational algebra). Even though we understand the operation of the Java VM, know the theory and practice of concurrency, garbage collection and can can [endlessly] discuss the merits of dynamic vs. static, strong vs. weak typing, we will never use Java when there are much better languages for a particular problem. We regularly use Ruby, Groovy, ObjectPascal and Erlang; we have dipped our toes in kernel-mode C programming and microcontroller assembly.
Languages alone are not the complete solution, to get the best results, we combine the right language with the most appropriate runtime environment–”we know the lot”, from console applications, through servlet containers such as Tomcat, to OSGi environments such as Eclipse Virgo.

If you take up our offer of workshop, all our trainers will need is a keen team of developers and a room with whiteboards or flipcharts. It will be up to your team to pick any problem you are currently facing. Our trainers will then discuss the problem with your team to understand it fully. We will then coach your team through the best possible solution. Our trainers will help your team discover the best design and the most appropriate implementation strategy. We will not stop there, our trainers will then work with your team to implement the solution entirely, or, to implement the most difficult portions of the solution.
The workshop is by far the most demanding session on your team as well as on our trainers. We ask that the team members that attend the workshop are not afraid to try new things, that they are prepared to tackle, understand and learn completely new concepts.

The workshop events are the best way to discover the unknown unknowns; our trainers may be able to show you approaches that you had never considered and that will bring immense productivity boost to your project.

Oh, and one more thing: depending on the trainer, we will need a steady supply of coffee and biscuits for Aleksa or tea and vegetables (preferably iceberg lettuce, carrots and celery) for Jan.

Spring and iPhone

Monday, March 15th, 2010

The talk for next week’s open source user group is ready. I will give brief overview of Spring 3 MVC and explain how to create native-looking iPhone web application using as little code as possible.
It would not be a proper user group talk without a live demo, so bring your good selves with your iPhones and we’ll create a Spring MVC application that looks just amazing on the iPhone, all within about 25 minutes!
Figure 1 shows what we will achieve: the iPhone will send a request through the Internet to our Tomcat, where our Spring-driven MVC application is going to process it.
smvci
Figure 1. Spring MVC & iPhone

Lucky us–OSJ editorial

Wednesday, March 10th, 2010

A few weeks ago, I had a chance to catch up with a friend from university days. Inevitably, we ended up talking about our jobs. We both had a little moan about the amount of work we have to put in.
I can honestly say that not a week goes by where I start something in the office and simply have to continue working on it at home; not because I must, but because it is so bl**dy interesting that I cannot wait until the next day. We are all very lucky to work in a field where work can be so fascinating that it stops being work and becomes play.
However, this play quickly turns into frustration when you have to use something that you paid for, that the vendor says should work, but doesn’t. Closed source, anyone? If a closed source component doesn’t work, I can report a bug to the vendor, but what next? Sit around and wait for a response? Hack together a workaround in my free time? No thanks, I’d much rather be out in the Peak District.
By all means, go ahead and moan about work with your friends, it is therapeutic. But know that we are lucky to be able to work with open software!

Domain driven design

Tuesday, March 2nd, 2010

Almost every developer will agree that DDD is important. But what is DDD and why exactly is it so important? The best way of looking at this is to consider the conceptual differences between DDD and non-DDD scenarios.
But, you say, aren’t we are doing DDD simply by carefully separating our applications’ tiers into domain, repository, services, web, and et cetera? I can see the domain tier in my application; the only things that live in the domain tier are the domain objects, therefore my application uses DDD. Right?
Well, possibly. It is important to make clear distinction between domain objects as buckets for data and true objects, that is things with data and behaviour. A good indication of buckets of data situation is where your services contain a lot of non-transactional logic that shuffles data in your domain objects. A system implemented in this way is very similar to the old-school procedural programming approach. In procedural systems, there are no objects, there are only data structures and procedures that operate on those data structures. Keep term here is data structure; a data structure can be very rich:

typedef struct __INVOICE_T {
  int id;
  char invoice_number[100];
  supplier_t supplier;
  date_t invoice_date;
  invoice_line_t *invoice_lines;
} invoice_t;

in C is not that different from

public class Invoice {
  int id;
  String invoiceNumber;
  Supplier supplier;
  Date lastLogin;
  List invoiceLines;
}

The similarity is striking. Both structures (the C structure and the Java class) are simply holders for data. Both objects hold enough information to calculate the sum of all net amounts on all invoice lines. This is where the difference between procedural and true DDD code becomes apparent. In procedural approach, you would write a procedure (by all means in a service-tier object, but ultimately a procedure) that takes the Invoice or (invoice_t) and returns the total.
A DDD approach would be to have BigDecimal getTotal() method in the Invoice object. This is the simplest take of the DDD world; the methods in your domain objects could and should do as much work as possible. This is because the functionality of the domain objects is available to all tiers of your application.

Spring MVC and iPhone

Tuesday, February 23rd, 2010

I have exciting new talk ready for the next open source user group meeting. We will implement a very friendly iPhone web application using Spring MVC 3.0 in about 30 minutes’ time while keeping the controllers and models completely intact.
I don’t want to spoil the show; come along and don’t forget to bring your iPhones for testing.

Native-looking iPhone web applications

Monday, February 22nd, 2010

Say you have a [Spring] web application and you want to make it available on the iPhone with as little cost as possible. Naturally, you can just keep the application as is, after all, the iPhone is quite capable of displaying web pages. However, if you take a regular web page and show it on the iPhone, it does not always look its best. Another option is to create an iPhone native application (or use frameworks such as Appcelerator to turn HTML, CSS & JavaScript into a native iPhone application). The native application gives you access to the iPhone hardware, but can take far too long to create.
You can try out a third route. An iPhone web application that looks almost native, but is still a web application. We have taken an existing Spring Framework-based web application and “ported” it to the iPhone. Our objectives were simple: we do not want to change the structure of our controllers (or any other Java code, for that matter); all we were prepared to do is to prepare some iPhone-specific views. Now, because we said we did not want to touch our Java code, we implemented another ViewResolver, which we called UserAgentViewResolver. The UserAgentViewResolver is a view resolver that delegates to other view resolvers depending on the user agent of the request. This means that we can have different views with the same name for each user agent. In our case, we used plain old InternalResourceViewResolvers:

...
<bean class="uk...servlet.view.UserAgentViewResolver">
  <property name="viewResolvers">
    <map>
      <entry key="*iPhone; U*">
        <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"
                      p:prefix="/WEB-INF/views-iphone/en_GB/" p:suffix=".jsp" />
        </entry>
     </map>
  </property>
  <property name="defaultViewResolver">
    <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"
                 p:prefix="/WEB-INF/views/en_GB/" p:suffix=".jsp" />
    </property>
</bean>
...

We used jQTouch in our iPhone views. The view itself is very simple, all we needed to do is to configure the jQTouch library and use standard HTML elements.

<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%>
<%@ taglib prefix="d" uri="http://uk.co.protomed/tags/display" %>
<%@ taglib prefix="buttons" tagdir="/WEB-INF/tags/buttons/" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <meta name="viewport" content="user-scalable=no, width=device-width" />
  <meta name="apple-mobile-web-app-status-bar-style" content="black" />
  <link type="text/css" rel="stylesheet"
    media="screen" href="/styles/jqtouch.css">
  <link type="text/css" rel="stylesheet"
    media="screen" href="/styles/themes/apple/theme.css">
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
  </script>
  <script src="/js/jqtouch.js" type="text/javascript"></script>
  <script type="text/javascript">
		var jQT = $.jQTouch({
			cacheGetRequests: false,
			statusBar: 'black'
		});
  </script>
</head>
<body>
<div id="home" class="current">
  <div class="toolbar">
    <h1>${patient.title} ${patient.firstName} ${patient.lastName}</h1>
    <a class="button back" href="#">Back</a>
  </div>
  <div class="info">
    <h1>Address</h1>
    <c:set var="address" value="${patient.address}"/>
    ${address.address1} ${address.address2}<br/>${address.address3} ${address.postCode}<br/>
    <a href="callto:${patient.phone}" rel="external">${patient.phone}</a>
  </div>
...

Using the UserAgentViewResolver and jQTouch, we got an iPhone web application with animations and other features that make it feel as if it were real web application, but the server-side of our Java EE application remained unchanged!.
The end result is here:
iPhone application

HqlToken exception in dm Server

Sunday, February 21st, 2010

If you’re using Hibernate in WebLogic, some of you may have come across a class loading problem, because WebLogic includes Antlr 2.7 on its main classpath, and when you start application that requires antlr as well, you will end up with strange class loading and casting exceptions.
OSGi should really solve all this, shouldn’t it? We no longer have monolithic classpaths, we have bundles with isolated classpaths and the OSGi runtime provides the lifecycle management and dependency resolution services. Well, in case of Hibernate, it is not that simple. Let’s say you have a typical web application with the repository tier implemented in Hibernate. The bundlified Hibernate distribution (courtesy of the SpringSource Enterprise Bundle Repository) correctly depends on Antlr 2.7; and so–to satisfy the dependency–you make your repository bundle depend on the appropriate Antlr bundle, and all seems to be working. Until you use more complex HQL query; that is one that does not begin with select, but with delete or update.
You see, Hibernate uses Antlr to translate the HQL into an abstract syntax tree. The root of the problem is that it [Hibernate] passes a name of its internal class to Antlr. Antlr then tries to load the class using the provided name and use this class in the vertices of the AST. Naturally, in OSGi, this is a problem, because the Antlr bundle does not depend on Hibernate. The error message is then quite obvious ClassNotFoundException: HqlToken, but this exception is thrown from Antlr rather than from Hibernate or the rest your application.
The dm Server’s extensions to the OSGi standard allow us to specify PAR-wide resolution context, which solves this problem.
In practice, you have to place both your repository and webapp bundles in a PAR; in your repository’s MANIFEST.MF, you need to specify

...
Import-Bundle: ...,
 com.springsource.org.hibernate;version="[3.3.1.GA,3.3.1.GA]";
 import-scope:=application,
...

and finally, in your webapp, you need to include dependency on Hibernate in its MANIFEST.MF.
In summary, you need to:

  • Mark the Hibernate Import-Bundle entry with import-scope:=application in repository,
  • Include Hibernate in Import-Bundle in webapp

These two simple steps solve the
ClassNotFoundException: org.hibernate.hql.ast.HqlToken web applications that use Hibernate in dm Server 2.0.

What’s cooking

Tuesday, February 16th, 2010

Let me give you my outlook on what Cake Solutions will be focusing over the next year.
I think that Java will continue being very important player. The two main reasons is that the language itself will quite likely go through some significant improvements in JDK 1.7 and, as consequence of the new JDK, we will also see easier adoption of dynamically-typed languages running on top of the JVM. This, in combination with the vast selection of open source libraries and frameworks, still makes Java our primary choice. Spring Frameworks remains important player in the Java server arena and will remain in the same position for the next year or two.
Leaving development and compile-time tools aside, we need to improve our footing in the complex runtime environments. I see OSGi as a major influence in the next two years in the Java world.
Specifically, our focus will be on:

  • Ruby on Rails and Grails to offer rapid application development where Java EE is too much work (and until we become experts in expert systems, viz Roo!)
  • OSGi, which will bring new way of managing Java EE applications’ runtime.
  • REST and dynamically typed systems. We need to be able to use at least one distributed application runtime platform.
  • HTML (5), CSS and jQuery. Most of our web user interface work is criminally out of date. We must use our RIA team’s expertise in modern web design and train all our old-school JEE code monkeys on contemporary web development standards.
  • Expert-system assisted development. Over the last 30 years, we have tried and failed to construct expert systems that can stand in place of human developers. We have failed because the expert systems tried to solve far too generic problems. With the new features in Java’s code, and with support from aspect-oriented programming, and in limited domains, it is now possible to use an expert system to construct a simple non-distributed, non parallelising, single VM Java EE application. I expect to see much more of the declarative programming concepts making their way into imperative programming, thus allowing us to implement more sophisticated expert systems.