I attended several of the sessions in the Domain Driven Design (DDD) track on Øredev 2008 today, and to the end of the panel debate, I kind of got to thinking: “Why actually bother ourselves with DDD?”

Now, don’t get me wrong here. I actually like the idea of extra emphasis on domain modelling in our profession. Indeed, I wrote “DDD Wanna-Be” as the tagline on my conference pass. I really wanna do DDD. By I also got to thinking: “Why, actually?”

Being the Devils Advocate

It is old knowledge in the computer science industry, that no new tool or language are going to make us orders of magnitude more productive than yesterday. When going from imperative procedural to object-oriented programming, we get to express models in another way, said to be more like the real world. But it really does not make us any more productive than we were in the imperative thinking.

Likewise with DDD. I cannot see it making us orders of magnitude more productive, than when not doing DDD. I really do not. Sure, distilling the core domain seems a good idea, and protecting it with an anti-corruption layer might also be a good idea. And so on. But overall, the development of an application will not go way faster as a consequence of applying DDD. Actually, I think applying DDD to your application development can have the effect of slowing you down. At least while you learn. This is okay, if there is a bonus in the end. But is there?

And do the computing industry actually need saving? It is repeated again and again, how too little focus on domain modelling will create messy, unmaintainable systems. Maybe so. Maybe not. In close co-operation with colleagues and clients I have helped build lots of systems, that both meet the users needs by supporting the business domain while at the same time being maintainable. And we were not practising DDD.

Back to Being Myself Again

So why do I still like the idea of striving for more domain modelling?

Maybe because I find it an interesting academic exercise. Maybe because I see emerging DDD-supporting, interesting technology in stuff like spring load-time-weaving to inject into all of the domain, that I will get to play with then. Maybe because it is something new. Maybe to not be bored by always doing what I did yesterday, even though it worked for me just fine yesterday. Maybe to bring the fun back.

Do you do DDD? And if so, why? Honestly

I had not had the chance yet, to sit down and take a look at D, so I thought it would be a nice idea for me to attend the session named “What Makes a Programming Language Productive?” by Walter Bright, one of the people behind D. So I had completely no knowledge of D before I entered the session.

Now, the conference material did not mention anything about D being a systems programming language, something I kind of found out half-way through the session. And now I also understand why the language designers thought they had done some great things with stuff like automatic memory management and garbage collection, no pre-processor, automatic documentation generation from comments in the source, type inference, etc…

But, being an application developer myself, working with languages like Java and C# in addition to easy access to dynamic languages on the VM, not many of the constructs seem new or that special to me. But I guess they will be for C and C++ programmers doing systems programming.

But this is not the only thing that I find not to be for me.

The D language is said to support multi-paradigm programming. What this means is, that you can write imperative code in the old C-style, object-oriented code, inline assembler, template meta-programming and soon also functional programming in the same language - namely D.

Walter said this to be an advange. If for example, you wanted to express a part of your program in another paradigm, you would not have to learn a new language and interface with that from your D program. True, I guess, to some extent, at least about the integration part. But these are completely different paradigms. Learning to program in a functional language aint that much about syntax, but very much about understanding problem solving in the functional paradigm. Likewise in an imperative or object-oriented paradigm.

But D tries to express multiple paradigms in D alone. That way you won’t have to switch programming language, to express something in another paradigm. I would really think that another design goal of D: “Have a short learning curve for programmers comfortable with programming in C or C++” would go against its goal of being multi-paradigm.

How can one syntax support all those paradigms in a nice and concise manner?

How can the semantics of interoperating code between several paradigms be done simple enough, for it to be understandable and usable?

JetBrains is releasing their ruby and rails support in IDEA as a specially targetted product called RubyMine. I just took a download of the preview and tried it out. To a long term IDEA user, it looks an awful lot like, … IDEA I guess it is “just” a slimmed down version of IntelliJ IDEA, with “only” the ruby and rails support, together with various VCS plugins.

This is actually what Sun have been doing with Netbeans for some time now. Providing a slimmed down download of Netbeans, that only includes their support for ruby and rails.

What URL Input Encoding Is

When a HTTP GET or POST request arrive at a servlet-container, the container implementation must interpret the incoming characters using some character set. In the case of a POST request, the web application developer has a chance to submit this information explicitly, by including this element in the FORM:

<input type="application/x-www-form-urlencoded; charset=charsetNameHere">

In the case of a GET request, there is no way to set this information, so the container use a default. I do not think, that the servlet specification mandates a specific default. In all cases, I think it is wise to uncover what it is set to for your container, and set it explicitly if it does not match your clients.

Setting Input Encoding on Tomcat

On tomcat, it is in the Connector element in server.xml, that you specify this setting. Here is an example of a Connector element that includes the setting:

<Connector
port="8080"
maxThreads="150"
minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
redirectPort="8443"
acceptCount="100"
debug="0"
connectionTimeout="20000"
disableUploadTimeout="true"
URIEncoding="UTF-8" />


If not set, tomcat defaults to ISO-8859-1.

Setting Input Encoding on Weblogic

On Weblogic, the setting is done in the weblogic.xml deployment descriptor, using the input-charset element. Here is a small example:

<input-charset>
<resource-path>/some/url/resource</resource-path>
<java-charset-name>UTF-8</java-charset-name>
</input-charset>


It appears that weblogic supports setting this more fine-grained than tomcat, as you can set a resource url for the setting to apply to.

Actually, it took me a while to discover where the module settings had been moved to. Not that they were hard to find when I actually started looking for them, but simply because I thought JetBrains were in the middle of reworking them into the new settings dialog.

It turns out, that the module settings have moved to another place altogether.

The Old Module Settings at its New Place

In IDEA 8, you can enter the (old style) module settings by hitting Ctrl-Alt-Shift-S, which will take you to a dialog like the one you entered through the old settings plus hitting 1 (one). You can also enter them by clicking the little icon in the top bar next to the old settings icon or by right-clicking a module in the project navigator and choose “Module Settings” near the bottom of the popup menu.

The New Settings Dialog

The old hot-key “Ctrl-Alt-S” now leads to a IDEA/Project settings only dialog, in which things like JDK, libraries, facets and modules cannot be edited anymore. Instead, you can edit IDE-wide settings like fonts, colors, plugins, … or project-wide settings like VCS settings, maven integration, … In fact, if you hit Ctrl-Alt-S without a project open, you can edit “new project default” settings too.

The navigation of the reworked settings dialog somehow reminds me of how Eclipse works in its settings. Hmm… I am not sure what to think of that, but lets see how it works over time.

After using puremvc for real for some time now, I have collected a list of things, where I find puremvc getting in the way.

Here it goes…

1. Use of Service Locator instead of Dependency Injection

Two patterns for letting a software components resolve its dependencies on other components are Service Locator and Dependency Injection. Of the two, puremvc use the Service Locator pattern, which I like the least. As an example, let us take a simple command:

public class ExampleCommand extends SimpleCommand {
  override public function execute(note : INotification) : void {
    var clientDataProxy : ClientDataProxy = facade.retrieveProxy(ClientDataProxy.NAME) as ClientDataProxy;
    clientDataProxy.getExampleData();
  }
}

What this command class does, is to ask a service locator (the facade.retrieveProxy call), through a direct dependency on the puremvc api, to get an implementation of a ClientDataProxy service. Next thing is to call actual services on that proxy.

Here is how I would like it to have been:

public class ExampleCommand extends SimpleCommand {
  [Inject] private var clientDataProxy : ClientDataProxy;

  override public function execute(note : INotification) : void {
    clientDataProxy.getExampleData();
  }
}

There is no code here, that looks up the service. There is only the usage of the service. For one thing, the service lookup code only clutters up the code, as it has nothing to do with what the application is doing. Another thing is the direct dependency in the puremvc api to lookup the service. Both are things not welcome in the code.

2. Casting, Casting, Casting

Again, taking a line from the example above:

    var clientDataProxy : ClientDataProxy = facade.retrieveProxy(ClientDataProxy.NAME) as ClientDataProxy;

Wow! I am writing the type again, and again, and again. All the retrieve calls in puremvc have rather wide return types, hence the need for all the casting.

And it is not only the retrieval of proxies and mediators, that needs casting to specific types. It is also when extracting data from the notifications. Like this:

   var user : User = notification.getBody() as User

This is partly because AS3 has no generics/templating system, partly because of puremvc design (notifications are not application specific classes) and partly due to the use of service locator and not dependency injection.

Anyway, it is damned irritating.

3. Forced Inheritance Everywhere

Anywhere I go, I need to inherit a puremvc base class. This is hard to cope with, in an OO programming world which have long gone to favour composition over inheritance. Especially in a single inheritance only language. To me, it seems like puremvc was designed for the inheritance to provide two things:

1. Having mediators, commands and proxies hook properly into puremvc, but overriding methods like, listNotificationInterests(), execute() and call super constructors.
2. To provide access for the appliction into puremvc glue, primarily by letting sub-classes access the facade everywhere, hereby giving access to the service locators to obtain mediators and proxies.

Now, both of these can be accomplished in other ways, if the framework had been designed in other ways.

4. Avoids Platform Dependencies

At first glance, avoiding platform dependencies for a framework might look like a positive thing, but it is not. At least not from the perspective of the user.

So, what do I mean by platform dependencies? Well, puremvc is written purely in ActionScript, and then ported to other languages like C#, Java, haXe, PHP, .. you name it. To be able to port the framework nice and easily, there can be no direct dependencies on flex and flash APIs.

Think about that for a while…

This means the framework cannot tell about what it is doing using the flash trace() method. I suspect this to be the reason that there is no debug option to turn on in puremvc. It also cannot utilize flex or flash event classes. I suspect this to be why notifications, a completely new abstraction found in puremvc, was conceived, instead of just using the event framework.

Each and every time there is a very platform specific feature, the core framework is unable to utilize it, as that part would then be impossible (or damned hard) to port to another platform.

But for me, the application developer, I have no need to port the puremvc framework. I have chosen flex. I am writing an application for flex. I am using the flex APIs/components, hereby binding my application to the flex platform. There is then no gain, only pain, in using a framework, which completely abstracts out that chosen platform.

Then What?

Is puremvc bad then? Hell no! Let me reiterate: Tt gets the job done. It solves the problem. Which problem? The problem of keeping an architecture on your code! You get a split-up of view, model and application logic. Shelves to place you code on.

I just think it could be done better.

Back when I started using puremvc, it was “the best” around, as I saw it. But others have come to. Most notably, Mate has had some great press lately. I think it is great, but also think it has drawbacks.

Okay, that was a bit harsh, it just seems to me, that there isn’t a day, without a new issue to be reported in the JetBrains Jira with respect to flex support.

Here are some of my current complains, and the list is far from complete:

• It doesn’t have proper, working refactoring, for even simple things like rename method or class or move, except for the vanilla cases, where all is private
• There seem to be problems with what I would expect as basic stuff, like warnings on completely correct expressions
• Auto-importing classes has never really worked satisfying yet, there is currently no support for completion in import statements and organize imports organizes nothing
• Import from maven poms is lacking just about all functionality
• The debugger does not work

And I am not talking about the current 7.x release of IDEA, which only have the slightest hint of something called flex in it. No, I am talking about the latest and greatest EAP releases of the upcoming v8 of IDEA.

Even though I battle with this stuff every day, I just so much want IDEA to succeed on this one, because I love the IDE, and I am sure, that if they put enough focus into it, they could do a way better job than Adobe on FlexBuilder. That said, I am not sure they will succeed on this one. Why? Because I am seriously doubting, that we are thar many users out there, of the flex support in IDEA.

When I look at issues reported in their Jira related to flex support, there seems to be a core of very few people, who actively give feedback on this. And more than that, nearly all, if not all, the issues are assigned to the same JetBrains developer. Now, he is working on it, because I get some of my issues fixed and closed from time to time, which is nice. There just seems to be so long a road, until even the basic stuff is there.

Sorry to be such a bitch, but it is starting to get on my nerves. So, how many are we, using or wanting to use the flex support in IDEA?

The other day, I noticed that the flash.events.ErrorEvent actually inherits from flash.events.TextEvent. What the f*** happened there? I guess this is an prime example of using inheritance as a means to reuse, instead of as a means to express some static, is-a relationship in a model.

To see what I mean, read the documentation for the TextEvent class:

An object dispatches a TextEvent object when a user enters text in a text field or clicks a hyperlink in an HTML-enabled text field. There are two types of text events: TextEvent.LINK and TextEvent.TEXT_INPUT.

Okay then, a TextEvent is something about a user, that has done something in a UI, that has produced some text, which the application shall know about. Now, let us take a look at the documentation for the ErrorEvent class:

An object dispatches an ErrorEvent object when an error causes a network operation to fail. There is only one type of error event: ErrorEvent.ERROR.

That is a completely different thing than a TextEvent. There is no chance, that saying “An ErrorEvent is also a TextEvent” could be true.

Given this AS3 code:

var foo : Number = null;
trace("foo="+foo);

The compiler outputs a warning saying “null used where a Number value was expected“, but it does compile. The trace outputs “foo=0“. Hmm, okay then, foo must be an instance of a Number class. If I change the code to have no initializer for foo, like this:

var foo : Number;
trace("foo="+foo);

The output of the trace will read “foo=NaN“, which is as expected, as this is the default value of Number variables.

But wait, this AS3 code:

if (foo == null) {
trace("oops, does not compile");
}

Actually fails compilation. The compiler complains about “Comparison between a value with static type Number and a possibly unrelated type Null“. So, I can assign null to Number, albeit with a warning, but I cannot compare with null. Okay then, foo must then not be a real reference to an object.

But wait again, the documentation says that Number is a “public final class Number“, which extends Object. But I cannot compare instances of it with null. Hugh!?

I think I am actually supposed to use the global function isNaN(), to determine stuff like this. You might be alarmed to hear then, that isNaN() applied on a Number typed variable, which have previously been assigned null, will return false.

In my opinion, there are downsides to Mate, and I think one needs to consider these too, before blundering out in a new flex framework.

So, on with “Il buono, il brutto, il cattivo”.

The Good

Here are the main benefits I see in Mate.

1. Acknowledges Its Flex Heritage

Mate is a flex framework, meaning it does not try to hide or abstract access to flex apis. It uses normal flex events as communication mechanism, and depends heavily on the flex apis in general. This is something it shares with Cairngorm, but stand in clear contrast to PureMVC. PureMVC has gone to great lengths, to abstract out any access to the flex apis, in the process inventing its own event-like system in the form of “notifications”. This makes the PureMVC framework itself portable to other platforms, but only puts extra burden on the developer, which have chosen flex as the platform.

2. Builds Upon Dependency Injection

Mate utilize dependency injection (DI), which is a programming pattern I have come to like, and use day in and day out, when doing Java development. Using DI promotes louse coupling between classes and subsystems and makes for a more flexible codebase. What DI in Mate should give me, is mxml and application logic, which does not depend directly on the Mate apis. I like that.

3. Simple, Uncluttered View

Using Mate, the mxml view definitions become really simple an uncluttered with anything but the view code. This is partly due to the above description on dependency injection, as Mate is able to inject into the view, when it needs data. This is something Mate shares with PureMVC, but not with Cairngorm. PureMVC also makes for pretty simple mxml view definitions, but at a higher cost, using Mediators and extra levels of abstraction.

The Bad

That was some of the main benefits, I have seen with Mate. Now on to what I do not like about Mate.

1. Too Much Magic

In short: There seems to be too much magic happening behind the scenes. Now, I should be a little careful here, because this might be due to me not knowing the intricate details of the framework yet. On the other hand, I recal previous experiences with Tapestry v3+4, where in-depth knowledge of how the server-side playback of a request works inside Tapestry, was needed to understand how to use stuff like ActionLinks. Maybe some of it can be taken care of with better documentation, maybe not. My main point is, that you should be able to use the framework, without knowing intricate details about how it works beneath.

So, where is the magic? It is in the EventMap, where one wires up the whole application with various xml tags. And we shall get to that right now in the next section.

2. Programming in XML

Mate has something called an EventMap, a place where one wires up the application. You can think of it, as the place where flex events from the UI is mapped to application logic, but also where processing code and remote calls execute and return results and data back to the view.

The EventMap is all done in XML, and is where the dependency injection is defined, as in which UI components get which things injected as a result of what. What I do not like about the EventMap is how it looks like application code, … just in XML. Take a look at this example:

<EventHandlers type="{FlexEvent.APPLICATION_COMPLETE}">
   <HTTPServiceInvoker instance="{employeesService}">
      <resultHandlers>
         <MethodInvoker generator="{EmployeeParser}" method="loadEmployeesFromXML" arguments="{resultObject}" />
         <MethodInvoker generator="{EmployeeManager}" method="saveEmpoyeeList" arguments="{lastReturn}" />
      </resultHandlers>
   </HTTPServiceInvoker>
</EventHandlers>

Which is something like when a FlexEvent.APPLICATION_COMPLETE event is fired, the application shall call some remote service (the HTTPServiceInvoker part), and the result of that shall be parsed by an instance of EmployeeParser through its method loadEmployeesFromXML,….

Shit, I thought I would never have to see something like Jelly again. Programming in XML quickly leaves you up shit creek without a paddle. I hate that!

3. Nullifies The Power of AS3 Compile-Time Type Checking

Okay, granted, I do not think it completely nullifies all type-checking. But the xml EventMap is not understood by the compiler, as the mxml code is, hence no type-checking will be done by the compiler on that part.

As an example, when data-binding a property of a component to some other property or variable using an expression like fooProperty={bar}, the mxml-compiler will generate as3 code which does the binding, and the generated code includes type-information, that will make the compilation fail, if the types do not match.

Not so with all the “code” in the EventMaps.

The Ugly

And on to the ugly part. This is mostly for fun, as I happened to peak into the code of Mate and saw this:

public function createInstance(template:Class, p:Array):Object
{
   var newInstantce:Object;
   if(!p || p.length == 0)
   {
      newInstantce = new template();
   }
   else
   {
      // ugly way to call a constructor.
      // if someone knows a better way please let me know (nahuel at asfusion dot com).
      switch(p.length)
      {
         case 1:newInstantce = new template(p[0]); break;
         case 2:newInstantce = new template(p[0], p[1]); break;
         case 3:newInstantce = new template(p[0], p[1], p[2]); break;
         case 4:newInstantce = new template(p[0], p[1], p[2], p[3]); break;
         case 5:newInstantce = new template(p[0], p[1], p[2], p[3], p[4]); break;
         case 6:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5]); break;
         case 7:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6]); break;
         case 8:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]); break;
         case 9:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8]); break;
         case 10:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9]); break;
         case 11:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10]); break;
         case 12:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11]); break;
         case 13:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11], p[12]); break;
         case 14:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11], p[12], p[13]); break;
         case 15:newInstantce = new template(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11], p[12], p[13], p[14]); break;
      }
   }
   return newInstantce;
}

Anyway, I do not know a better way in as3 myself. Just thought it was funny code.

But It Is Great

… to see something new and innovating in the flex MVC space, and Mate is it. I just think, that it still can be done better.

If you want to learn more about Mate, you should go to asfusions site about Mate. In addition to some Mate documentation, they have forums about Mate, and it looks like they are good at providing answers to peoples problems.

The Problem

If this webapp is hit on an URL that does not exist, the webservice servlet does not even get hit, and the container produces a 404 html page. If some internal server error happen before the webservice servlet is hit, the container generates a 500 html page. If the client calling the webservice does not produce proper authentication tokens, the container generates a 401 html page, again before the webservice servlet is reached.

In all these cases, the webservice engine, Axis, CXF or their cousins, won’t be able to produce a proper SOAP fault message. If the client program that calls the webservice, trigger any of the above described situations, the response cannot be parsed properly as a SOAP response. Because the response is html (or nothing/empty).

This is not very SOAP like. Luckily, the solution is simple.

The Solution

In web.xml, you can both map server response codes to specific response pages and map certain extensions to HTTP response content-type setting. Let’s solve the problem for the 401 situation, where authentication failed:

Step 1: Create a static SOAP response

For the 401 problem, we will create a file named 401.soap and place it inside the webapp in the /soap-error-responses directory. The file shall contain this static xml:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
	<env:Body>
		<env:Fault>
			<faultcode>env:Server</faultcode>
			<faultstring>401:Unauthorized</faultstring>
		</env:Fault>
	</env:Body>
</env:Envelope>

Step 2: Map the error-code to the static file

Inside web.xml, you add this mapping:

<error-page>
  <error-code>401</error-code>
  <location>/soap-error-responses/401.soap</location>
</error-page>

This will make the container return your static response in the case of a 401 response code.

Step 3: Map the .soap extension to a content-type

A SOAP response should be sent with HTTP content-type text/xml. To ensure this for the .soap files, you put the below mime-mapping element into your web.xml file:

<mime-mapping>
  <extension>soap</extension>
  <mime-type>text/xml</mime-type>
</mime-mapping>

And you are done.

One thing about this solution, as also mentioned in the beginning, is that it will be okay for a webapp which contains nothing but a webservice service. On the other hand, if the webapp also contains a regular web application with html and jsp files, it will be a problem that 401, 404, 500,… are mapped to SOAP fault codes. The browser will be disappointed

Another thing to note is, that there is nothing stopping you from using dynamically generated response files, like jsp files. One caveat though, the source of a response like 500 (internal server error), could be things like out-of-memory, out-of-disk-space or out-of-file-handles, all errors that most likely will prevent the container from processing a dynamic jsp files too. So, maybe better stay with the static ones.

I think it started for real with libraries like prototype and script.aculo.us, and then just accellerated from there on into Dojo, MooTools and jQuery. And last, Google published the AJAX Libraries API, to ease loading of JavaScript libraries into your application.

All the cool web applications on the net seems to use javascript heavily. Mashups depend on javascript heavily. Browsers are getting good at javascript.

And it is spreading. Through Rhino, JavaScript became one of the supported scripting languages that can be called from Java using the Java6 script engine. And there is ActionScript3, which I like writing UI logic in when doing the flex dance.

Up until lately, I had a grudge against JavaScript. Mostly because my initial experiments with JavaScript was in browsers to manipulate the DOM, validate html input etc. All done in now old and gone browsers, with lousy JavaScript support. After fighting with it back then on several occations, I built up that grudge. But I cannot go on like that.

I need to embrace JavaScript. I have started work on it with ActionScript3, but I need to do more than that. Or I will miss the boat.

Back in the days of Java1, two cool parts of this new platform was the threading apis and the JDBC apis. These APIs have both had immense success. But I think we, as application developers, should forget about them. I know I mostly have.

There are good reasons, that these apis were cool and became popular and much used.

The JDBC apis were a giant leap in how easy, it suddenly was to connect to and query a relational database. And with the common JDBC api, you could just swap the driver and connect to another database. With the threading apis this was even more true. Coming from C, parallel programming was done with multiple processes and various IPC techniques like sockets or shared memory. Suddenly, there was an easy to use api, with Thread as abstraction level.

Before the success of application servers like Weblogic and Tomcat, back in the days where Weblogic was named Tengah, we all wrote our own server applications, using stuff like Thread pools and dispatching work into threads by ourselves.

But this is no more. When reading Effective Java (again), I came across all the advice on how to do parallel programming. And I came to think of, that it has been a really long time, since I used the threading apis myself directly. And the same is true for the JDBC apis. I know intimately how they work, and I am glad for that, but I don’t like working with them anymore. They are a way too low abstraction level.

Doing applications on the web, the container shall be the one using those apis. Not the application developer. Doing application development, we should use higher abstractions like JPA, to enable better modelling and talking in the language of the model when coding.

What do you think? Is there any need for application developers to use these libraries anymore, except for rarely written software?

When I ordered the book, I was unsure if it would be a waste of time. Was there really so much new to say about the Java platform, since then? After all, this book is all about best practices and common idioms for programming on the Java platform. How many new such could there be?

Well, quite a few it turned out.

There are completely new chapters, like the 37 pages on generics and the 33 pages on enums and annotations, as these are language features added in Java5.

In addition to this, a great deal of the old items have been heavily revised, to accomodate the new features, as there are now better ways to do things. One example is the advice to use enums for singletons. Another is the advice to prefer Executors over working with threads and to prefer concurrency utilities like CountDownLatch, CyclicBarrier, etc. over wait and notify. All new stuff from the java.util.concurrent package.

I can only say, that second edition is a must-read too.

Next up for me is Java Puzzlers, which I never got around to reading.

What you need to do, is clear the cache through the Java Control Panel, which can be hard to locate on Linux (on Windows it is placed in Control Panel->Java). Depending on your distro and how Java was installed, you might be lucky and find a link to the Control Panel inside the menues somewhere (like in System->Preferences or something like that).

When installing Java manually with a tar.gz, and the Sun Java Plugin manually by this method, where you yourself symbolic link from the the plugins directory to the JRE Java Plugin .so file, finding the Control Panel can be harder.

Luckily, if you know what to look for, it ain’t hard at all.

Inside either the SDK bin directory or inside the JRE bin directory, you will find a binary named ControlPanel (actually, it is a shell script, but whatever). Executing this yields this:

And clicking the “Delete files” button will let you delete applets (and Java Web Start applications installed/cached).

In addition, clicking “Settings” will show you where the cache is placed ($HOME/.java/…), which makes it easy for you to clear the cache later with a simple remove.

As a little side-note. When developing or debugging applets, it can be nice to have the Java Plugin console window open when the plugin loads. This can be enabled in the Control Panel, on the “Advanced” tab, like this:

This is why we created this little find+perl one-liner on my current project, to enable a quick and easy pom.xml version element upgrade. Here is the one-liner:

find . -name "pom.xml" -type f -exec \
  perl -0777 -pi -e \
    's#(<project.*?<version>)1.9-SNAPSHOT</version>#${1}1.9.0</version>#s' {} \;

The above line upgrades from version 1.9-SNAPSHOT to a final 1.9.0, which is what we do when preparing a release where SNAPSHOT was used on trunk and a real final version number is to be used for the release.

Here is a bit of explanation of the one-liner:

• The find finds files only (-type f) with the name pom.xml recursively and executes the perl command-line on each
• The perl option -0777 sets the input record delimiter character ($/) to a non-existing character, to slurp all of the file into one long string, which enables us to match and replace into a single long line
• The -p option loops all files
• The -i does inplace editing of files (aka: The replace on the match is done directly into the file matched in)
• And finally, the /s modifier on the end of the pattern makes it a single match and in combination with -0777 also substitution

So, why do this, when we have the maven release plugin? Because the maven release plugin scares me! Have you seen all it does with your repo and all? Take a look at the actions done by the release:prepare goal. These actions includes changing poms, committing changes, tagging, changing poms again, … I want to be more in control than that

Now that Sun has released a preview SDK of JavaFX over at javafx.com, they must be thinking that it is soon ready for the world. I have previously talked about javafx as being forever unfinished, and this was my opinion of it still.

But today, I set out to try the preview SDK, and it kind off changed my mind.

Starting out, I had to both install a latest and greatest Java6Update10 release candidate and the dreaded Netbeans IDE (which by far was the worst hurdle to overcome). But from there on, things just worked. I followed a couple of tutorials, and built my own Clock JavaFX application stone by stone. And I most say, that even Netbeans did a good job in helping me.

What stunned me a bit, was the feeling of quality and readiness of the JavaFX technology. It just worked.

Here is a bit of what I noted down, when working with it. I might compare a bit with flex/air on the way too.

The Language

• The syntax for defining UI declaratively looks like crap. To me, it is not even the slightest bit intuitive and easy to read. Only positive thing is, that it is easier than gluing up a Swing application in plain Java code. Why on earth have they dreamt up a new syntax, when xml is here for such things? Flex wins here.
• The language for scripting looks much nicer. It seems to be close to actionscript and javascript syntax and it supports stuff like attributes and data binding in the language. Nice!
• Dead cool feature is of course the ability to mix and match real Java code right into the application. JavaFX wins bigtime over Flex/AIR here.
• JavaFX supports multiple inheritance - why on earth that? It gives the compiler extra work, as it compiles into Java bytecode, which does not support this.

Tooling

• I guess this must be Netbeans for now. Not the coolest thing on the planet. Them having dreamt up a completely new syntax, instead of going with xml for declarative UI, will require more work for competing IDEs to catch up.

Components

• At first, JavaFX seems to be centered around the rich media part (Frame, Stage, Animations, Shapes, Transformations, …)
• But of course, Java has the complete Swing apis, with a lot of components to support forms (Buttons, Tables, Checkbox, …). These are components in the Flex world, an integral part of Flex/AIR framework. In JavaFX, they are just there already, because of the complete integration with the rest of the Java platform.
• One can turn the above argument on its head though. Cause flash has had stuff like scenes, stages, animations and transformations for a lot of years. This is new stuff on the Java platform, brought about by JavaFX.

Platform

• Well, fx source compiles to JVM bytecode, of course
• From here on, “everything” is possible
• Target execution platforms includes: Desktop application using JRE, applets in the browser, mobile platforms (cell phones and tvs in the common profile only)

• Notification of new versions, patches, and updates
• Special offers on Sun developer products, services and training
• Access to early releases and documentation
• Ability to track and manage your registered products and systems on the Sun Inventory site

Let’s take a closer look at these 4 “nice”, extra things, Sun will give me, if I register:

Notifications I already get, really annoying, from the popup balloons on the windows task bar about a new new JDK ready for me. Cannot even say no to them.

Then there are the “Special offers on Sun developer products, services and training”, which to me is other words for .. SPAM.

Of course, I would like “Access to early releases and documentation”, … which can be accessed anyway, without the registration, right.

And last, the “Ability to track and manage your registered products and systems on the Sun Inventory site“. So I can go and login at Sun, to see what I have installed on my own laptop?

What the f…

How about calling it what it is. Sun wants some information about JDK installations. Please ask nicely and honest for it then!

Brent Boyer explains that Windows XP has a granularity of 15 ms, while Linux with a 2.6 kernel have a much finer grained precision of 1 ms. For many purposes, I guess this is no problem. I know I have not had a problem with it before.

What I did not know is, that the System.nanoTime call (available from Java5 and on) should be the one used for timing intervals. In addition to being nano-based, this call does not work as a “wall clock” as System.currentTimeMillis() do, in that it only measures elapsed time in an interval. The System.currentTimeMillis() call tries to reflect a “wall clock” time, as milliseconds since January 1, 1970. If the clock is drifting or being set by tools like NTP daemons, this will skew the results of System.currentTimeMillis().

Coincidentally, I was reading a chapter on concurrency in Effective Java (2nd Edition) (The Java Series) by Joshua Bloch, in which he states:

For interval timing, always use System.nanoTime in preference to System.currentTimeMillis

I do still have my thoughts about these two methods. When I read the javadoc for the new System.nanoTime call, I do not really feel at ease using it:

…The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change….

Note the “perhaps in the future” and “values may be negative”. Hmmm!

This just goes to show, that it is really hard, to provide a virtual platform, that is supposed to look and act equal on all platforms.

General Stuff

I read the e-book version (pdf), so I cannot tell you anything about the quality of the book itself. As a little side note, I find e-books harder to read, maybe because I cannot (easily) take it with me to the toilet.

The overall tone in the book is to the point and a bit fun. If you do not like a little joke or a funny way to express something, you might get a little irritated. On the other hand, it is not as if it destroys the meaning, and it is actually funny. At least I liked it!

The book is very much to the point, which I like, as it helps me get faster to the real stuff. There is so much to catch up on in the programming world, so no need to read a lot of unneccessary bullshit. To the point. Nice. The book does not provide much explanation of basic Java stuff. Good, but know your Java and Java5 workings, before going with this book.

When the book describes something that can be done in more than one way, there is always good advice on when to use which and why. This is exactly the kind of information I like to get out of a book. Not just a publication of the API, but in-depth advice on how to use the api and how not to (or what the implications are for doing it the way you do).

There are good spin-offs from reading this book. There are links to people who elaborate on ideas introduced (or mainstreamed) in guice. For instance, this was my first entry into TypeLiterals (or TypeReferences). Also, I got a pointer (again) to ServiceLoader in Java6, which we all need to know about.

Chapter by Chapter

Here, I will give you my opinion on each chapter.

Chapter 1: Setting the Stage

• A good and short introduction to dependency injection
• I was pleased that the intro on DI was nice and short. If you new nothing at all about DI, there could have been a little more info on this, but it gets the point out.

Chapter 2+3

A good introduction and explanation of the core Guice functionality - aka: how all the injection stuff works

• Know your Java(5) beforehand
• You will learn how to bootstrap guice, use guice annotations to inject stuff and how to wire it up with modules or annotations
• All other sorts and stuff like: Injecting properties, static injection, custom scopes, using web scopes, organizing bootstrapping into several modules, …

Chapter 4: AOP

• Guice supports method interception only (80% of the use cases in AOP are using 20% of the AOP features possible in Java)
• Guice uses aopalliance.jar, which makes for a common api to AOP from the framework (aka: You can reuse the spring tx interceptor, if you like)
• Shows how simple AOP can actually be, when packaged correctly
• Of course, this is also due to limiting in functionality provided, just like EJB3 does

Chapter 5: Integration with the Web

• How to bootstrap guice in a web application (the usual context listener stuff)
• How to inject on servlets, plugin for struts2, wicket
• I learned that guice 1.0 is very basic in its support for web integration
• I also learned, that warp provides extra stuff for web integration (amongst others)
• You will have to do some initial digging, to see how well guice integration is supported for your favourite web framework

Chapter 6: Practical Guice

• A practical example of how to configure guice with struts2, warp persist, JPA, and hibernate to build a real world web-stack application with transactions and database access
• Really good, binds all the previous theory together in a practical example

Chapter 7: Guice Recipes

• “..best practices and commonly asked questions”
• Interesting stuff, that you are sure to be interested in, if you plan on using guice for real

Chapter 8: The Future

• A look into what coming versions of guice might bring

Conclusion

Overall, I think the book is good and certainly worth the money. Two questions that I would expect any book on google guice to answer are:

1. Why use guide instead of spring? and
2. What about the services provided by spring - like transactions?

And I got an answer for these questions by reading this book:

1. The last part of chapter 2, “Debunking Myths”, answers this in a good way. There is definitely a room for both Spring and Guice. They are not the same, even though they overlap. Guice is “just” a DI framework. In addition to this there are some other good points on their differences, and why you might chose one over the other.
2. Go warp@wideplay

In addition to this, here is some cool stuff about guice, that I learned from reading the book:

• The way that all things are done in “plain” Java code (some of the config is not that plain, namely TypeLiterals). With a good IDE, this can safe you lots of building/running. Though IDEA has good support for spring, it has excellent support for Java.
• Guice supports circular dependencies (for all bindings, that bind to an interface)