Dot Neverland

Documentation that is useful

noreply@blogger.com (julian_za) — Sat, 14 Jan 2012 15:06:00 +0000

I was reading this article by Neil Mcallister on his Fatal Exception blog entitled "How to get developers to document their code".

Now it begs the question: What documentation is actually useful?

Well, like all things in general I don't think it's a simple answer, best I could say is; what works well in your context.

In my personal context as a developer of information systems for commercial entities I personally find the following useful when it comes to documentation:

A decent setup and getting started guide: where to get the code, what tools and frameworks I need, how to build and configure it, and how to get it up and running.
Environmental information regarding the various environments: How the development, testing, QA and production environments are accessed, configured and managed.
A High level guide to how the components of the software fit together, with a one liner about what each component does.
An High level ERD or any other high level domain model is also quite useful.

Most of this documentation is really there to give context about the code, the rest I can figure out from the code itself.

I also have a list of documentation that I think is a waste of time and effort:

The above compiled into a document and then sent to die in something like Sharepoint: Useful documentation is easily searchable, easily accessible and easy to update referencing the actual models being used by architects and developers.
Low level code documentation: It always out of date and rarely ever reflects the truth of the implementation to begin with (It's also annoying to read, Sequence diagrams come to mind). The only time documentation like this is useful is when the documentation effectively becomes the code (using MDA for example).
Documentation done for the sake of process: No one will ever read this documentation except for the person who has to check that process is being followed. This seems to happen a lot in Waterfall environments where the process becomes so slow that organizations end up short circuiting pieces of the process in order to speed up development times.

What do you consider useful in your context?

Java 8.0 Wishlist (Take 2)

noreply@blogger.com (julian_za) — Sun, 17 Jul 2011 18:16:00 +0000

Ok so it's it been a while since my last article on this topic...

The comments of course have been first rate, with opinions on the wish-list have ranged from outright agreement to threats of violence for even having such boneheaded ideas.

It's all good of course, the thing that I love about the Java community is that we take the ideas and actually question them. Something I felt the .Net world could do more with.

But anyway It's worth going through the list and giving a little rationale and meat on the wish-list, specifically on those that seemed to generate a lot of comments, so here goes...

Properties.
Now I'm going to debate the OO nature of properties. Fact is that - for better or for worse - JavaBean style properties have become baked into Java and it's frameworks. So why not at the bare minimum tell the compiler you want to generate getter and setter methods with syntax sugar. And yes IDE's generate this for you, but I'd still prefer for the sake of brevity get rid of code that does stuff all.

Operator Overloading.
Easily the most contentious point. However let me give you my background: I recently did a lot of work doing monetary calculations. which defined in an Excel spreadsheet by an Actuary. The only way I could get Java code to match the excel spreadsheet was to use ye olde BigDecimal. The code that came out is painful to say the least, mostly due to the lack of operators. Now BigDecimal is on the operator overloading todo list for Oracle, however it's painful having to wait, and the fact is that it's hard to build very expressive arithmetic types in Java.

Alternative deployment formats besides the JVM and a classpath.
Ok this one seemed poorly presented. Basically I want to be able to compile a set of Java classes down into a native executable and deploy that. Even if all the executable does is wrap the classes together with a JVM. You ask why; that's easy I want to run Java apps on iOS.

Parameter names in method calls.
Ok so lets assume I have a method as follows:

public void crappyGFXtask(int startx, int starty, int secondx, int secondy, int lastx, int lasty)

I dare you write the code to call it, leave it for a few days and then go back to it, and see if you can make sense of the parameters. Named parameters simply give you ability to map the parameter names to values ala Objective-C so your call to the method would look something along the lines of:

crappyGFXtask(startx:10, starty:11, secondx:25, secondy:40, lastx:myVariable, lasty:myVariable)

Proxies on Abstract classes.
Yes Spring does this already, but guess what: I don't use Spring in every Java project I do (yes pigs are flying). It's a generally useful feature and JDK support would be sweet.

Ok hope that clarifies things.

Java 8.0 Wishlist

noreply@blogger.com (julian_za) — Tue, 26 Apr 2011 20:43:00 +0000

With Java 7 almost out the door talk has now shifted to Java 8 and of course it's the perfect time for me to add my own $0.02 on my own wishlist.

Properties.
Dunno what you can do here without annoying a few people. However I'd happily settle for some type of shorthand notation for getters and setters.

Operator overloading.
This one pops up at just about every Java release. Now it seems that there are plans in the works to add indexers to collections and such like. Quite frankly if you're gonna do that, why not add a full complement of fixed operator overloadings, maybe taking some ideas from how Groovy does it

Alternative deployment formats besides the JVM and a class path.
When you have to do one of those client Java applications that everyone claims nobody does, the Java deployment model really bites: Basically I want to create a fully contained application for a target platform. Now if all this contained application does at the end of the day is bootstrap a JVM together with a classpath who cares. It's also worth pointing out that this would allow Java applications to run quite easily on iOS, that is; if someone takes the time to do the port.

Parameter names in method calls.
Nice to have, but it would make DSLs in java nicer.

Finish Autoboxing.
I still can't do 1.toString().

Proxies on Abstract Classes.
Not sure about the technical constraints on this, but it would be great if you could also create proxies on abstract classes and not just on interfaces.

Make JavaFX useful.
Ok so JavaFX is not actually part of the JDK. Whatever the case, it's Oracle's chance to make client side Java really slick.

Well that's my list for now...

Using Google Contracts for Java with IntelliJ IDEA.

noreply@blogger.com (julian_za) — Fri, 18 Feb 2011 16:54:00 +0000

The first step after obtaining the Google Contracts for Java Jar and adding it to your project, is to enable Annotation processing support in IDEA.

To do this go to open the Settings window (IntelliJ IDEA > preferences on Mac) and go to Compiler > Annotation Processors.

Now do the following steps:

Check the Enable Annotation processing option.
Select the Obtain processors from project classpath option.
In the Processed Modules table click the Add button and select the Module for which you want to enable Contracts for.
Hit Apply and you are ready to rock.

To test this you can add a basic contract annotation to a method in a class, here is one that I created using the @Requires annotation to ensure that the integer method parameter "c" has a value greater than zero:

import com.google.java.contract.Requires;

public class TestSomeContracts {

@Requires({"c > 0"})
public void testContract(int c) {

}

}

Now when you compile you wont get much feedback as to wether the annotation was processed or not, as the contract syntax is correct, so lets modify it a bit to generate a compile splat by changing the variable name of the precondition:

@Requires({"cs > 0"})
public void testContract(int c) {

}

When you build the module, you will now get a compilation failure which kinda integrates into IDEA, in that you can click on the error in the messages window and it will take you to the line that failed. Unfortunately IDEA wont highlight the line in your Editor or anything fancy like what you get in Eclipse, but it's good enough to work with.

Using a class with contracts.

After reverting and compiling the class I created a simple test case to test the contract by passing in data that violates the contract (ie. an integer less than 1):


import org.junit.Test;

public class TestSomeContractsTest {


@Test
public void testContract() {
  new TestSomeContracts().testContract(-1);
}

}

I run the test… and... it passes!

In order to actually work, Google Contracts needs to do some bytecode shenanigans in order to actually enforce the contract definitions during runtime. Currently they have two modes of operation, an offline instrumenter which is a post compilation processor which weaves in the contracts into a compiled class, and a java agent.

For development the most convenient method to use is the java agent.

To use the agent in IDEA, click the Select Run/Debug Settings drop down and select the Edit configurations option. Expand the defaults entry and select the JUnit option (or TestNG or just plain Application) and add the following to the VM parameters field:

-javaagent:[path to the Google Contracts for Java jar file]

I Also remove an existing configuration so that it picks up the new option when I run the test again.

Now I run the test again and - voila - nice big splat when I run the test and pass invalid data to the method:

com.google.java.contract.PreconditionError: c > 0
at TestSomeContracts.com$google$java$contract$PH$TestSomeContracts$testContract(TestSomeContracts.java:9)
at TestSomeContracts.testContract(TestSomeContracts.java)
at TestSomeContractsTest.testContract(TestSomeContractsTest.java:9)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:65)

On a final note. Google contracts is still pretty fresh, so here's hoping IDE support will improve if the project takes off. I must also say that I'm not too fond of the current mechanisms for enforcing the contract. Hopefully Google might take a page from Lombok and do to weaving at compile time.

Does Java need a "Linux moment"?

noreply@blogger.com (julian_za) — Tue, 26 Oct 2010 08:17:00 +0000

Does anyone remember that one of the reasons Linux or GNU/Linux (sorry Richard Stallman) was created, was to create a Unix like environment which was free and open to use and not encumbered by the licensing restrictions of the AT&T's original Unix.

With all the stuff happening with Java right now, being a Java developer has become a depressing experience, and it's getting really hard to see a positives for the platform.

Perhaps Java needs it's own "Linux moment".

A Java (but not Java) platform that is free and open and built on the same principles that made Linux a success, with the potential for the same type of success that Linux has enjoyed.

I don't know if it's even feasible, but it's certainly becoming an appealing thought.

Solving the software patent issue: The Software patent clearing house

noreply@blogger.com (julian_za) — Thu, 07 Oct 2010 06:55:00 +0000

Motorola is suing Apple for infringing 18 of it's patents in it's phones and computers.

Apple is suing HTC for infringing it's patents.

Microsoft is suing Motorola for infringing its patents.

Nokia is also suing Apple, to which Apple countersued Nokia, all of course for patent infringements.

Lets not forget Oracle who is suing Google for infringing Java patents.

Now Microsoft is about to release it's Windows phone 7, and they've had to do quite a bit of catchup so it's quite possible they might have "infringed" on some vague and obscure software patent. So it wouldn't surprise me if - in order to complete the circle of litigation - either an Apple or a Google type company sues Microsoft on or about the release date of Windows 7.

It strikes me that all this circular ligation is forcing companies to spend an awful lot of money on lawyers who seem to be the only ones benefitting.

To remedy this situation I recommend that it's time for a Software patent clearing house.

Now what exactly would a Software patent clearing house do?

Basically it would be an organisation which has a central repository of all software patents. Whenever a company launches a software patent infringement suite against another company they would submit this suite to this organisation.

Since it's most likely that the company being sued would probably countersue with it's own patent infringement suite, The Software patent clearing house would be responsible for vetting and offsetting the patents of the first suite with the patents of the counter suite, and the only the company with a positive amount of patents left would be able to continue litigation.

To illustrate: Let say company A sues company B for infringement of six of it's software patents. Company B could then countersue company A for infringement of four of it's patents. The clearing house would then subtract company B's claims from company A's claims, leaving Company A with two patent infringements it can litigate for.

The clearing house could also provide a key additional service:

You could do data mining on the patent information and create a litigation index for companies which is basically a numerical value calculated to the perceived market value of the underlying patent. Companies with a low litigation index would have few patents while a company with many patents would have a high litigation index. Companies can then trade their litigation index points much like you could trade shares.

For example company A might have a high index but have a few bad quarters. They could then sell off index points (and consequently the patents backing the index points) which other companies could then buy bringing in cash for Company A. Company B who bought some index points can then use this index points to offset any patent litigation they might encounter, so if Company B get's sued by Company C they can use the index points to reduce the scale of the litigation, for example if they are being sued for infringement on six patents, they could trade off index points to the suing company to reduce the suite to a mere one or two patents. Company B could then even use it's own patent set to nullify the suite completely.

The price of the index points would be determined by the availability of index points on the market against the volume of litigation. No doubt this price would become one the standard indicators that you normally get from financial news services.

Furthermore Venture Capitalists could even buy index points up front, which would become a regular part of the the capital that they provide new startups.

Some companies might even have so many index points they could get out of the software altogether and start simply start trading these index points as a means of making money.

Of course the clearing house itself would need to charge fees in order to fund the operation, but think of what companies could save on legal fees, together with the allure of actually being able to earn cash of patents as opposed to getting into a major legal wrangling.

The Next Big Java Language; my $0.02

noreply@blogger.com (julian_za) — Mon, 27 Sep 2010 06:19:00 +0000

Time to to add my $0.02....

What is the Next Big JVM Language going to be?

I've been watching the whole evolution of alternative languages on the JVM for a few years now. Long enough to start tracing the hype around the different languages.

Yet none of these languages are really mainstream, despite their apparent advantages.

I think the reason for this has absolutely nothing to do with the technical features (or lack thereof) of any of these languages.

I think the NBJL will be the one that large organisation or group of organisations with enough clout and deep enough pockets is actually willing to go out and effectively market both to decision makers and developers.

No doubt Java did strike a chord with mainstream developers, but quite honestly was that more to do with Sun's aggressive marketing campaign or because it of it's many technical merits?

Quote of the Day

noreply@blogger.com (julian_za) — Mon, 23 Aug 2010 08:29:00 +0000

Quote of the Day:

"In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."

- Simon Peyton-Jones; Co-creator of the Haskell programming language.

Why Java is more open than .Net

noreply@blogger.com (julian_za) — Sun, 15 Aug 2010 04:46:00 +0000

First of all, lets clarify a few things: Open does not necessarily mean free, and indeed Open Source, secondly in saying that Java is open, I also don't mean that it couldn't be more open than it already is and that the current processes don't have some painful problems regarding openness.

With that out of the way, why is Java more open than .Net?

Lets start with a Simple question: Can anyone show me a .Net 3.5 (Never mind .Net 4.0) certified implementation, that also has certified implementations of all the important .Net technologies that actually make .Net useful like WCF, WPF, WWF, WIF etc, etc. so that I can take my .Net 3.5 App written on Microsoft's .Net implementation and dump it unchanged onto this implementation onto - say Solaris - and it will run no problem regardless of what frameworks and features of those framework I used?

While you are looking it up, here are some more questions:

How do go about (or can I even) license .Net from Microsoft?

How do I get a say in the specifications for new or existing .Net technologies?

Can I actually get my .Net implementation and appropriate frameworks rubber stamped by some certification authority?

Does .Net have some type of philosophy regarding platform neutrality?

Here are the answers to those questions from a Java perspective:

I go to Oracle apply for a Java License, pony up some cash, agree to some terms, then I get a nice kit from Oracle and go forth an implement.

I join the Java Community Process and give input to the various Java Specification Requests, I can even submit new Java Specification Requests.

I run my implementation of a Java Specification Request against the Technology compatibility kit for that Java Specification Request and not I can say my implementation is certified.

Java has had the concept of Write Once Run Anywhere from the beginning and it's backed into Java and the JCP.

So what does this mean, and why does it make Java more open?

It means; that as an end user of Java I can pick and choose the best Java implementations around, and if I decide that I want to change the underlying platform or even the implementation I can do so with relatively little fuss.

I have in the past run the same Java program happily on OSX, Windows, AIX on Solaris running on Intel, PowerPC and Sparc respectively.

I have also developed on JBoss and deployed on Glassfish.

In other words; I as an end user am not locked into any specific Java provider.

But what about Mono and Ecma?.

Yes the CLR (and I think C# as well) is an Ecma standard which Java is not.

But the CLR and C# alone maketh not a development platform and the stuff that makes .Net useful is not very open at all, and as much a The Mono community likes to play it down a cloud still hangs over Mono regarding patents. (BTW: If any Mono guys ever read this, it's fair to say that Mono hasn't cost Microsoft a lot so far, if Android where to run Mono, the cost to Microsoft might be in the billions, can you guarantee Microsoft's behavior when it's losing market share and money?)

Things may of course change, Microsoft may actually put forward a formal licensing program, and together with the ECMA standardization, and then when I can run all of .Net anywhere on any implementation, then I can say .Net is more open than Java.

Steve Jobs vs Steve Ballmer.

noreply@blogger.com (julian_za) — Fri, 30 Jul 2010 06:12:00 +0000

Ok, this time I really promise that this is the last I write about Apple for a while...

This time however I'm going to compare Steve Jobs and Steve Ballmer via the magic of Youtube.

Firstly lets compare the two men think about the nature of what a computer should be:

Here's Jobs, now here's Ballmer.

Now before I continue, it would be easy to write Steve Ballmer off, however during his tenure, Microsoft has become the most powerful technology company in the Enterprise. I daresay Ballmer's stoic approach to computing has allowed to see things in the black and white manner that Business customers understand.

However is this a good thing. Does anyone remember how Microsoft got to the top? Bill Gates understood consumers, and that's how he drove Microsoft to the top. The question is does Ballmer understand them.

Now Steve Jobs is a character of note, and certainly not everbody's cup of tea. He's made some nasty comments about Microsoft and actually seems rather unfair if you ask me. But consider these interviews with Ballmer regarding Apple's iPhone, AppStore and iPad, just as they launched and then read this.

Android and the iPad makes Steve Ballmer quiver in his boots.

noreply@blogger.com (julian_za) — Wed, 21 Jul 2010 18:27:00 +0000

I wonder if Android and the iPad keeps Steve Ballmer awake at night.

Why so?

The iPad is successful, not only as a consumer device but also as an enterprise device. If the results of the iPad are anything to go by, the Tablet is poised to be a very popular form factor.

But the iPad is effectively just one device (albeit the first one) in this new emerging Tablet space. It seems the majority of these devices will be running Android, and none seem to be running Windows.

Now consider this. Windows has risen to be the dominant enterprise operating system, despite of the fact that for most of it's existence the Windows platform has been inferior to the Unix/Linux/Mainframe platforms.

Consider how first DOS then Windows started out purely on - what was then - the low end of the computing market; the Desktop, and gradually started moving into more and more sophisticated applications, with each version getting incrementally better until Windows Server 2008, which can be used quite safely for high end computing tasks.

It was able to do this, partly thanks to Moore's law but more importantly by capitalizing on the familiarity of Windows by the people making the decisions, not to mention the shallow learning curve offered to people who had practically grown up with the OS.

Windows is an example of a disruptive technology, clearly illustrating the fact that's it's often easier to drive a low end product into the high end, than a high end product into the low end thanks to mass appeal.

Unfortunately Windows is no longer a low end product.

Windows 7 is optimized for desktops, it's not really designed for Tablets and touch screens, and so far it hasn't really featured much on any of the upcoming Tablets.

Now iPad aside basically every new Tablet is running Android, a low end operating system and based on the iPad's success; the Tablet is the new disruptive technology.

So lets suppose for a minute that Android becomes the dominant Tablet OS, and that the Tablet becomes popular enough that at least most knowledge workers and decision makers have one.

It's not inconceivable that those same knowledge workers and decision makers may easily decide to start using Android for other tasks, initially maybe for things like cheap Android powered terminals (even terminals calling Windows Apps via Citrix or Terminal services) for call center agents and then later for full desktop replacements.

Now you may be thinking "Huh! Android is a mobile OS" but consider that if it made the jump from a phone to a tablet, why couldn't it jump to a full desktop? I don't think many people envisaged Windows getting onto the server either.

Of course this is just speculation, the only successful tablet so far is the iPad, and it's too early to say if any of the multitude of Android Tablets (most of which haven't even been released yet) will be as successful. Furthermore it's still early enough for Microsoft to develop a compelling product for the Tablet space.

Microsoft - despite it's wide market range - Is dependent on it's desktop dominance. Steve Ballmer must be a very concerned man.

The power of simplicity.

noreply@blogger.com (julian_za) — Wed, 21 Jul 2010 18:06:00 +0000

Never underestimate the power of simplicity...

I've been running my Windows environment for work purposes on a Virtual Machine.

I started off on Virtual Box and decided after a little while that I wanted to see what more sophisticated virtualisation would be like.

My first attempt was Parallels 5. Now Parallels offers fantastic Integration, for example it wraps all the running Windows processes and presents them as processes running in your environment, so you can switch to VM applications as if they were running inside your host OS.

The only problem was that Parallels is dead slow. It managed to grind my quad core i5 Macbook Pro to a halt, not to mention all the daemons it runs messes around with the startup and shutdown of the Macbook itself.

My next attempt was VMWare Fusion. Now VMWare is the Mercedes Benz of virtualisation products, and although it wasn't as fancy as Parallels, it worked very well, easily reading and importing my existing virtual disks, and running the VM with little fuss and overhead with all the integration I really needed, without dragging down the performance of my Macbook.

Unfortunately, on day three of my VMWare experiment I tried to restart a paused VM and it crashed and would not let me restart the OS inside the VM, I tried to reimport the original VirtualBox VM but it would not let me.

So now I'm back on VirtualBox. It's fast, simple and so far the only Virtualisation product I've been able to use with any success.

Bottom line: Simple is best.

Android vs Apple.

noreply@blogger.com (julian_za) — Tue, 13 Jul 2010 06:04:00 +0000

I don't think anyone who reads this blog will doubt the fact that I love Apple products. I write this blog entry on a Macbook Pro, I have an iPhone 3GS and before that I had the 3G which my wife is now very happy with.

I also like Android.

For me Android is best poised to become the commodity mobile platform for Phones and possibly for Tablets. It's going to become the DOS/Windows of the Mobile world.

I also like Android because of it's Open Source underpinnings and the Java roots of it's SDK.

On top of that, I'm also a Google fan, I use Chrome and I'm watching the whole Google Wave thing with a lot of interest.

Furthermore besides the iPhone, I've looked at developing some Android apps (An activity that is unfortunately limited because Google doesn't offer paid for apps in my country)

I even attempted to try buy an Android phone earlier this year. And I honestly couldn't find one that I liked (although that is mostly due to the rather poor selection we have in our Country)

The thing about Apple is that they build a device for which the software and hardware is in unison from the ground up, coupled with arguably the worlds best user experience.

For example, take OSX. OSX is a great product on it's own, and technically you could run it on a standard beige Intel box. The question is would I want to.

OSX is the best part of my Macbook, but the sheer niceness of my Macbook hardware is enough to not make me want to run OSX on anything else. I would miss things like the integrated light sensors, the useable track pad, the lighted keyboard, the magnetic charger. Not to mention the eye soothing looks of the Unibody design.

There is however a problem with Apple's approach.

Apple provides the only way to use it's own products. In other words it's a pure product as opposed to being a platform like Android or Windows.

You can't build an "ecosystem" with Apple with new devices being used in new contexts, like embedding iOS into a robot or an industrial device like you could with Android.

More importantly you will never be able to use Apple in a corporate for anything more than a niche group of users. The reason is quite simply that you can't run OSX on anything but Apple, and corporates don't like having thousands of desktops so tightly coupled to a single supplier.

As a result Apple is never going to be a monopoly in anything. A fact that is unfortunately baked into the way it does things.

I fully expect Android to product a market vastly larger and much more diverse than anything Apple could ever hope for.

I will even go so far as too say that Apple knows this and accepts it.

So why am I writing this. Maybe because I don't like the fact that there is this belief in IT that for one platform to win the other has too lose.

It's the type of belief that allows monopolies to form and prosper.

Oracle and the Sun exodus

noreply@blogger.com (julian_za) — Fri, 25 Jun 2010 18:11:00 +0000

So Oracle has had quite a good quarter, with profit jumping 24%.

What makes this interesting, is that Oracle claimed that $400 million worth of profit came from the sale of Sun gear, which is quite interesting especially that before the sale Sun hadn't really been making money even in the good times.

At the same time James Gosling is comforting the hordes of former Sun employees leaving Oracle.

Quite honestly though, I think the whole exodus of Sun employees leaving is being overblown by the media.

When you buy a company that is floundering like Sun was, you generally have to take drastic measures in order to bring that company back from brink, and drastic measures in the corporate world normally means doing lots of nasty things.

Oracle has a reputation for being to integrate companies it purchases quite well, so it's therefore fair to say that they are pretty good at doing said nasty things.

Now to take it a step further, Sun was not in a fantastic place when Oracle bought it, no doubt it needed some rather drastic measures to get things going again, so I can imagine Oracle had to do some really nasty things.

As a result you are going to get many people who leave, many of whom are good people who you don't want to lose, but it's unfortunately par for the course.

To be totally honest It didn't even bother me when James Gosling left Oracle.

Consider that he has pretty much had no publicly visible direct influence on core Java since it got handed over to the JCP which was 12 years ago.

Now don't get me wrong, He's left a big hole in Java for Oracle, and I'm hoping that he stays involved in Java, heck, maybe now he can contribute more directly to Java and the community than he could while he was working for Sun.

A question for Oracle and the Apache Software Foundation

noreply@blogger.com (julian_za) — Fri, 11 Jun 2010 05:15:00 +0000

Time for a Rant.

It's been roughly six months since Oracle bought Sun. And while I know very little about these things I doubt that it's been enough time to absorb a company like Sun whose product portfolio was extensive to say the least.

For that reason I've been pretty lenient on Oracle on the lack of information on Java that we developers have been getting.

After reading this however, my mercy is exhausted. Basically Oracle and the Apache Software Foundation still haven't come to an agreement.

In the mean time it sucks to be a Java developer right now. It's been three and half years since we had a new version of Java, and no new official version on horizon.

I've had more debates about "what comes after Java" in the past few months than in last 5 years.

My question now to both Oracle and the ASF is this: What do you think the long term effect of this impasse is going to be if you don't sort it, what value in Java are you destroying?

Steve Jobs and the future of Apple.

noreply@blogger.com (julian_za) — Fri, 30 Apr 2010 06:39:00 +0000

Ok I promise this is the last blog on Apple for a while...

Steve Jobs recently published an article on Apples's web site detailing his reasons for why Flash is not allowed on the iPhone.

The article has obviously taken quite a bit a bit of flak.

Here's the thing though, much as everyone decries Apple, they tend to forget that Apple is not a monopoly in any market that it operates, and they can't force anyone to buy their products.

This is important because if Apple manages to annoy enough developers and users, there are sufficient alternatives in the market to Apple products to allow said users and developers to leave.

If this happens then it's fair to say that the only entity that is going to suffer in this mess is Apple itself.

A few thoughts on the iPad

noreply@blogger.com (julian_za) — Fri, 29 Jan 2010 17:47:00 +0000

Being the resident Mac fan I thought I might add my $0.02 on the iPad.

Firstly the name is aweful, I can't believe that someone didn't start giggling the moment the suggestion was made. I have two theories about how this one got through; 1) The obvious : Steve Jobs made the suggestion therefore it was so. Or 2) The marketing guys were stereotypically stoned so that means a) no one thought much about the giggling and b) they were - well - stoned.

Secondly, yes, it is a large iPhone. Rumor has it that the iPad design has gone back and forth between the drawing board and prototype stage a couple of times, in fact it's technologies became the basis of the iPhone, Now the leaked sources pretty much confirmed that the iPad was going to be using the iPhone OSX as a basis so the way the OS looks and works was not at all surprising, but I'm rather dissapointed that Apple chose to so blatantly follow the physical look of the iPhone, after all, it is a design which - while being very pretty - is getting on in the years. Now it was probably too late by then, but I hope Steve is going "Oh crap why didn't we think of that" when he watched Avatar.

Thirdly it's not an iPhone at all. If you drill down into this logic you can quite easily make that argument that my laptop shares many of the characteristics of my iPhone by virtue of the fact that both can perform many of the same functions.

So what is the iPad then, it's not a laptop, it's not a netbook, it's not a phone, it's also nothing at all like Bill Gate's vision for the tablet PC way back in 2001.

The fact is that the iPad simply doesn't fall into any of the current categories, Apple has the rather daunting task of trying to create a completely new class of mobile device.

This is both a blessing and a curse.

If the iPad takes off, it will be great for Apple of course, being the pioneers in a new category, the problem of course is that in order for this new category to take off you need to have customers who have a reason to buy one.

In other words you need a killer application.

Now with that in mind here are a few things to ponder:

The starting price is $499, which will translate into about +- R5500 after import duties (unless the importers decide to milk us dry). This makes it cheaper than many smartphones including HTC's Android phones. It also falls in the same pricing bracket as many Netbooks.

It has quite an awesome battery life, You could use this device for most of the day, no boot up time and no hibernating.

The type of functionality being offered by the iPad is basically 100% of what most mobile office workers need from a computing device, my boss for example spends his entire work day in meetings and uses his PC for nothing but e-mail and documents.

I think therefore that there is potential for this device, however Apple is going to have to work harder to make that obvious.

Now in closing it's worth noting that the device simple had no way to live up to the hype surrounding it. It's a version 1.0 device, it has many flaws and omissions which Apple will need to address (although at the price you DO get quite a bit), So quite honestly It mightn't be bad idea to wait for version 2.0.

No Next Big Language... Dunno, I suspect we may be stuck with one.

noreply@blogger.com (julian_za) — Wed, 16 Dec 2009 11:54:00 +0000

I've just read Alex Miller's blog entry regarding the NBL (Next Big Language) or rather the fact that there will not be a NBL and that the age of multiple programming languages has arrived.

I like the idea and I'm all for it to take off...

It's just that in my experience companies, especially those who's core industry is not IT related tend to minimize risk as much as possible, and therefore try to stay as mainstream as possible.

Java after all, quickly got pushed into the mainstream by companies like IBM and Oracle throwing their weight behind it, And consequently companies adopted it - I daresay - because it presented a much lower risk than many of it's competitors at the time such as Smalltalk.

Furthermore companies seem to like to standardize on a programming language since it makes things like hiring and training and administration a lot easier.

Its also these companies which keep the bulk of the programming community employed.

Therefore as much the acceptance of multiple programming languages is growing among us programmers I see very little acceptance of it with these companies who fork out the majority of the cash to get systems built.

Consider that Microsoft talked much about multiple programming languages when it released .Net and after almost 8 years you will be hard pressed to find a lot of work being done on .Net which isn't written in C# or VB.Net.

Consequently then it's normal that one of the language will get used the most and therefore employ the most people and become the NBL.

Now having said that I think Sun-Acle may actually be in a good position to take the multi-language concept mainstream, more so than Microsoft in 2002. For one thing the JVM is still the most portable runtime around, furthermore it's battle tested and smokin' fast. It's also widely adopted, supported and well understood.

The JVM could allow a company to standardize on the infrastructure but pick the tool which will be the most productive for the development task at hand.

Of course if this idea takes of, then we our next debate will be on the NBR (Next Big Runtime).

Regarding Sun and Java 7 Closures

noreply@blogger.com (julian_za) — Fri, 20 Nov 2009 05:23:00 +0000

Here in South Africa we have a colloquial term: "oke". Pronounced "oak" it is basically a casual friendly reference for another male, kinda like "dude".

The word itself is actually from the Afrikaans language and has transferred into daily use by English speaking South Africans males. How it originated in Afrikaans I don't really know, It might simply be the Afrikaans translation of the English "bloke".

Typical usage is normally within a group of friends, for example you might tell your wife: "I'm off to have a beer with the okes" or as a more general reference: "Geez! did you see that try by Brian Habanna! That oke must be on speed or something".

Now regarding Java 7 and closures, I have this to ask of Java's venerable leaders: "Dear Sun, what the [expletive] are you okes doing?!"

Apple and it's nefarious ways.

noreply@blogger.com (julian_za) — Wed, 23 Sep 2009 06:53:00 +0000

I hope this whole Google Voice App scandal completely blows up in Apple's face.

A nice hefty fine consisting of least 9 digits would be perfect.

Why you ask, because like other iPhone developers I'm rather fed up with the whole process.

Furthermore Apple seems to forget that it's not a monopoly, I have plans to write software for the Android platform (when commercial apps come to my region), and quite honestly if the experience is better what reason could I possibly have to do iPhone work.

A nice scandal like this might have the ability to force Apple to be a little more transparent with developers.

The naked fan boy

noreply@blogger.com (julian_za) — Tue, 22 Sep 2009 18:41:00 +0000

I'm an Apple fan, and I am the proud owner of both a Mac book pro and an iPhone 3G. I've always been quite happy to admit that I am a "fanboy" of Apple products.

It turns out though that I didn't actually know what a "fanboy" is.

My understanding of what a fanboy is, is rather mundane: It's simply a person who is a fan of a product or brand or even a personality.

My friend however has a different view, his view of what a fanboy is seems rather more suited to someone who is a member of Al-Qaeda.

Now much as I like Apple I'm not blowing myself up because someone happens to criticise the new iPod.

So in order to reduce my ignorance I consulted that completely reliable source of truth: Wikipedia to find out more about what a fanboy is. This is what I found:

"Fanboy is a term originating in the United States[citation needed], used to describe a male who is highly devoted and biased in opinion towards a single subject or hobby within a given field. The earliest known recorded use is dated 1919.[5]"

The key phrases here are "highly devoted" and "biased".

Kinda strong words for something that should be as black and white as a technology choice.

The fact is though that if you step back and look at the whole IT scene and apply this definition you can't help but feel that us computer geeks are nothing much but a whole bunch of fanboys. Here is a short non exhaustive list of some of the fanboy debates I've been privy to during my time as a computer geek:

AMD vs Intel.
ATI vs NVidia.
3Dfx vs NVidia.
.Net vs Java.
C++ vs Java.
[for brevity's sake: Insert your language of preference here] vs Java.
RISC vs CISC.
Linux vs BSD.
Linux vs Windows.
OS2 Warp vs Windows 95.
Xbox vs Playstation.
Microsoft vs Open Source.
OSX vs Windows.

What really amazes me though is how the same person who can explain to you the nuances of Lisp on the one hand, can then on the other hand scream bloody murder because you bought product X instead of Y and that makes you an idiot because product Y is clearly 5 attoseconds faster than product X and unlike product X, product Y's maker does not sacrifice little children in order to gain market share.

And we're supposed to be that smart guys....

I guess it's perhaps a reflection of our passion, by in large technology people are very passionate about what they do and have a strong belief in the importance of what they do, after all; no other profession has caused as a dramatic a change in the last few decades to the way the world works as we have.

Of course it's perhaps also indicative of the fact that when it's all said and done, Computer geeks are just as driven by emotion as the rest of humanity.

A quick sample of Lists and Tuples in Scala

noreply@blogger.com (julian_za) — Fri, 18 Sep 2009 11:10:00 +0000

So I've been challenged with a simple problem to solve in Scala, that is; to take a List of values and and then sum each corresponding value in the list together into a resultant list.

For example:

[1,2,3,4,5] becomes [3,5,7,9]

You can accomplish this in Scala using the List class and its functions, these include:

zip : this function takes an input list and creates a list of tuples with each mapping pair, discarding jagged values.
tail : this function returns a list minus the first element of the list on which tail is performed.
foldLeft : combines the elements of the list together with a seed value (in my case I use a target List).
reverse : reverses the order of the list.

so here is the code to do this:

object SumPairs extends Application {

val numbers = List(1,2,3,4,5);
val result = numbers.zip(numbers.tail)
             .foldLeft(List[Int]()) (
                (list, y) => {
                   y._1 + y._2 :: list
                }
              )
             .reverse;
println(result);

}

Basically this works as follows:

I create a List of Tuples of each adjacent value in the List by getting the tail of the List.
I get each Tuple in the list, sum it and prepend it to the List returned by "foldLeft".
I reverse the List to fix the order as a result of doing a prepend.

Now this is is designed to be functional but not overly complex (at least I hope not), Since I'm still fairly green in the Scala dark arts I'd like to hear on improvements.

BTW the challenge I'm talking about can be found here.

UPDATE:

Another solution would be to use List.flatMap which basically takes a function which returns an Iterable and appends it to a function, it pretty similar, It's maybe a little more concise, I'll let you decide:

val numbers = List(1,2,3,4,5);
numbers.zip(numbers.tail).flatMap {
     value => {
          List(value._1+value._2);
      }
};

Dynamic Data Access Objects for JPA

noreply@blogger.com (julian_za) — Sat, 01 Aug 2009 06:52:00 +0000

JPA is pretty cool and JPA 2.0 looks even better, in a standardised way JPA has managed to rid us of the pain of CRUD, which; when it's all said and done is still the heart of most enterprise apps.

One thing that isn't very clear is how to implement the Data Access Object pattern in JPA. For one thing EntityManager pretty much takes car of abstracting your data access and that as some notable authors have pointed out you don't necessarily need to create a DAO at all. I agree with this but there are a couple of problems I keep running in to:

How to manage the vast numbers of queries that you get when you start doing anything useful in an Enterprise System.
Testing is made hard in that EntityManager is the pits to test especially when you start writng queries with many parameter, inevitably you end up with a vast brittle network of mocked objects which don't actually add any value and make my life miserable every time you make a change.
Named queries are great but but they really bloat your code for a multitude of "adhoc" queries which just seem overkill for me to put into a NamedQuery.
Queries are still strings and until JPA2.0 rolls out we can't avoid this indirection. One of things that the DAO pattern used to provide is a method for a query which normally named the purpose of the query and named its parameters and typed them, which was a real blessing when you had to work on code several years old.

Of course the other side of the coin is that we don't want to bring back a lot of boilerplate code, and end up writing too much custom stuff which re-implements features that JPA already has.

My suggestion therefore is to shamelessly steal ideas from Ruby on Rails albeit in a Java-fied manner.

The idea in question is the concept of a finder method in Rails. The one where you can simply call a class method on your Entity: EntityClass.findByName(theName) and thanks to the magic of Ruby's MOP; Rail's ActiveRecord pattern ORM framework can dynamically generate a sql query to go hunt for records for the entity where the name column is equal to "theName". All this without you having to write a single line of additional code.

Of course by now most readers will be smiling since they know that Java definitely has no Meta class facilities. This is of course very true, We can't replicate the exact flexibility of ActiveRecord but we can get some features by resorting to the closest thing Java gives; none other than the good old Dynamic Proxy.

Lets take the following interface:


package repo;
import java.util.Collection;

public interface AnEntityRepository extends EntityRepository<AnEntity> {

 AnEntity findByName(String name);

 Collection<AnEntity> findAll();

}

This interface extends an interface called EntityRepository (this is just a little marker interface so that I can hit F4 in Eclipse and I also use the type parameter to link the interface to an Entity) Each method on the interface maps to a specific query we want to run against an Entity class "AnEntity", the first method is a simple findByName which will have JPAQL generated dynamically, the next one is findAll which we map to a Named query.

Here is how we will do it: we will pass this interface to the dynamic proxy framework together with our own code to handle invocations which will do the following: first try map the invoked method name to a named query, if that fails we check if the method name starts with "findBy" we then do some funky string gymnastics on the rest of the method name to attempt to extract properties of the targeted entity and then build some JPAQL from that, then create the query and map the passed method parameters as query parameters to it. If any of the previous steps fail we blow up with a Runtime exception.

First step: The proxy framework requires an invocation handler (java.lang.reflect.InvocationHandler), this class is responsible for handling method dispatches from the proxied interface, mine is called RepoInvocationHandler (Repo being short for Repository):


package repo;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class RepoInvocationHandler implements InvocationHandler {

 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

 }

}

the invoke method will actually handle all the dispatches coming from the proxy, the parameters indicate the proxy instance that called with method, the actual method being called and the parameters that were passed to the method respectively. The first iteration of this invocation handler will be to build a JPAQL from the simple finder method, note that we pass a class in to the invocation handler, this is the entity we wish to query. Here is the implementation of the RepoInvocationHandler to do precisely that:


package repo;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.util.Collections;
import javax.persistence.EntityManager;
import javax.persistence.Query;

public class RepoInvocationHandler implements InvocationHandler {

 Class<?> targetEntity;
 EntityManager entityManager;

 public RepoInvocationHandler(Class<?> targetEntity, EntityManager entityManager) {
    this.targetEntity = targetEntity;
    this.entityManager = entityManager;
 }



 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    String name = method.getName();
    String query = buildQuery(name);
    Query q = entityManager.createQuery(query);
    int parmIndex = 0;
    for (Object arg : args) {
      q.setParameter(parmIndex++, arg);
    }
    //we can add the functionality to return a single result or multiples
    //by checking if the return type is a Collection instance.
    if (Collections.class.isAssignableFrom(method.getReturnType())) {
       return q.getResultList();
    } else {
       return q.getSingleResult();
    }

 }

 String uncapatalise(String property) {
    return property.substring(0,1).toLowerCase()+property.substring(1);
 }

 String buildQuery(String name) {
   if (name.startsWith("findBy")) {
      String property = name.substring("findBy".length());
      //uncapitalise to adhere to conventions
      property = uncapatalise(property);
      return "select x from " + targetEntity.getName() + " x where x." + property + " = ?";
   }
   throw new RuntimeException("oops, looks "+name+" is not a finder method");
 }

}

A note: you can make finder methods as complex as you want, this case just takes a single property and does an equals to query (select x from repo.AnEntity x where x.name = ?). The possibilities -however - are endless, Ive implemented this with AND and OR functionality so I can write "findByNameAndSurname(String name, String surname) or "findByNameOrSurname(String name, String surname) with n levels of predicates. however I want to keep the features of the generated finder method simple, if your query becomes to complex it should become a NamedQuery, which then brings us to the next iteration.

The next iteration of the invocation handler adds the ability to utilise NamedQuery functionality in order to handle complex queries, it also allows us to override the standard finder functionality:

package repo;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.util.Collections;
import javax.persistence.EntityManager;
import javax.persistence.Query;

public class RepoInvocationHandler implements InvocationHandler {

 Class<?> targetEntity;
 EntityManager entityManager;

 public RepoInvocationHandler(Class<?> targetEntity, EntityManager entityManager) {
  this.targetEntity = targetEntity;
  this.entityManager = entityManager;
 }


 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
  String name = method.getName();

  Query q = null;
  //Note that I create a named query in the format EntityClassSimpleName.methodName
  //this is because named queries are global not so by prefixing the entity class name
  //it mostly eliminates duplicate named queries, it also gives a useful convention.
  try {
      String namedQuery = targetEntity.getSimpleName()+"."+method.getName();
      q = entityManager.createNamedQuery(namedQuery);
  } catch (IllegalArgumentException e) {
      //yes there are more efficient ways to do this, however this is easiest
  }
  //no named query so lets build one from the method name
  if (q == null) {
      String query = buildQuery(name);
      q = entityManager.createQuery(query);
  }
  int parmIndex = 0;
  for (Object arg : args) {
      q.setParameter(parmIndex++, arg);
  }
  if (Collections.class.isAssignableFrom(method.getReturnType())) {
      return q.getResultList();
  } else {
      return q.getSingleResult();
  }


}

String uncapatalise(String property) {
  return property.substring(0,1).toLowerCase()+property.substring(1);
}

String buildQuery(String name) {

  if (name.startsWith("findBy")) {
      String property = name.substring("findBy".length());
      //uncapitalise to adhere to conventions
      property = uncapatalise(property);
      return "select x from " + targetEntity.getName() + " x where " + property + " = ?";
  }
  throw new RuntimeException("oops, looks "+name+" is not a finder method");
}

}

For reference purposes I've included what the NamedQuery declaration would look like on AnEntity for the method "findAll":

@NamedQueries( {
 @NamedQuery(name="AnEntity.findAll", query="select x from AnEntity x")
})
public class AnEntity implements Serializable{
...
}

And there we have the basic functionality I want to implement, the last thing we need to do is create the proxy, I have a simple factory which takes in the Interface (I've forced all the interfaces to extend the EntityRepository interface, for documentation and typing purposes) as follows:

package repo;

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Proxy;
import javax.persistence.EntityManager;

public class EntityRepositoryFactory {


public static <T extends EntityRepository<?>> T createEntityRepository(Class<T> homeRepositoryClass, EntityManager entityManager) {
  ParameterizedType type = (ParameterizedType) homeRepositoryClass.getGenericInterfaces()[0];
  Class<?> entityType = (Class<?>) type.getActualTypeArguments()[0];
  return (T) Proxy.newProxyInstance(
                  Thread.currentThread().getContextClassLoader(),
                  new Class[] {homeRepositoryClass},
                  new RepoInvocationHandler(entityType, entityManager));
}

}

Finally using this interface is as simple as creating it via the factory and then calling the methods:

   AnEntityRepository repo = EntityRepositoryFactory
                              .createEntityRepository(AnEntityRepository.class, entityManager);
  AnEntity entity = repo.findByName("Fred");
  Collection<AnEntity> allEntities = repo.findAll();

A few final notes:

For testing purposes you simply mock out the interface, either with a mocking framework or an anonymous classes.
There's nothing stopping you from creating the factory in Spring if you are using Spring.
I wish EJB3.1 had introduced a Factory concept for creating instances of beans much like Spring has this would make life easer in the EJB world.
Sooner or later you will need to create pagination, you can add this functionality by using parameter annotations, I was thinking of something like: "findAll(@Start int start,@Max int max)";.

Is Javaless Java reaching critical mass?

noreply@blogger.com (julian_za) — Mon, 08 Jun 2009 17:27:00 +0000

There is a lot of talk about how this is possibly the last JavaOne, as Oracle is about to buy Sun out.

However if you look at what everybody was at talking about at JavaOne you can't but help get the idea that JavaOne is an anachronism any way, this trend seems to involve:

- JavaFX.
- Groovy.
- Scala.
- JRuby.
- Honourable mentions for Clojure and Jython.

It's hard to miss the lack of Java here...

Ok so people are interested in other languages in the JVM, however interest doesn't necessarily translate into use.

This brings me to my question: have alternative JVM languages gone mainstream? can I go to my client who is still trying to get COBOL out of their system and confidently sell him on one of these alternative languages?

Enterprise Scala Beans

noreply@blogger.com (julian_za) — Mon, 01 Jun 2009 16:09:00 +0000

This is a "hello world" tutorial to show how to get a Scala class configured to run as an EJB 3.0 inside a JEE app server, in this case Glassfish V2.

Why exactly are you doing this?

Well mostly to see if it's possible, one of Scala's benefits is the fact that it runs on a Java Virtual Machine with Java interoperability as a feature, this would allow developers to make use of Scala's additional language features to create a little more concise code and still make use of an enterprise's existing investments in JEE.

First up.

To create EJB3.0 beans, a language will need to support the following:

- A compiler which compiles to standard Java classes (with the actual implementation bean using the standard no-args constructor for instantiation).
- A construct which can map logically and physically to a Java interface in order to support the EJB's local and remote interfaces.
- Annotations (although you could get away with ejb-jar.xml but that sucks) in order to integrate into the EJB container.

Huh?! you need interfaces! Scala doesn't have interfaces!.

Scala does not have interfaces per se, however it has traits (basically interfaces which allow implementation of methods). As it turns out Scala compiles the basic type skeleton specified by the trait into an interface.

Now with that out the way here's the code:

First we define the Trait which will serve as a remote Interface, for our example we are going to define a simple trait called ITest:

package net.jexenberger

trait ITest {

 
  def doStuff(x: String) : String;
 
  def hello() : Unit = {
    System.out.println("hello world");
  }
 
 
}

This trait has one unimplemented method and one implemented method (this is to illustrate that you don't lose the functionality of traits with Scala when you have to work in a pure interface world).

Secondly we define the actual implemention of the trait ITest in a class TestBean as follows:

package net.jexenberger

import javax.ejb._;
import javax.annotation._;

@Stateless { val name="ScalaTestBean", val mappedName="ScalaTestBean" }
@Remote {val value = Array(classOf[ITest])}
class TestBean extends ITest {
 
  @Resource
  var ctx:SessionContext = null
 
  def doStuff(x : String)  : String = {
      "hello "+x+" called with "+this.ctx.toString()
  }
 
  @PostConstruct
  def postConstruct() : Unit = {
    System.out.println("Post Construct called");
  }
 
}

Note the following about the implementation:

Firstly you will see that annotations are defined almost exactly the same as in Java, however the annotations have been "Scalafied" to look more Scala like with the use val and functions and of course Arrays, as illustrated by the @Remote usage above the class declaration. Finally we also inject the java.ejb.SessionContext object as an instance variable ctx and a @PostConstruct method; postConstruct(), this is to test that we can map Scala variables and methods directly to Java methods and variables in order to utilise the EJB container's dependency injection mechanism and to integrate into the EJB lifecycle.

We can now package the bean into a standard java jar (with META-INF/ejb-jar.xml if required), it can then be deployed as part of an EAR or indeed as a standalone EJB application. I built and packaged the project using Maven's standard maven-ejb-plugin and the Maven Scala plugin (org.scala-tools.maven-scala-plugin).

Finally we write a remote client to invoke the Scala EJB:

package net.jexenberger;

import java.util.Properties;
import javax.naming.Context;

public class JavaTest
{

    public static void main(String[] args) throws Exception {
        Properties props = new Properties();
        props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
        props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
        props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

        Context ctx = new javax.naming.InitialContext(props);
        ITest instance = (ITest) ctx.lookup("ScalaTestBean");
        System.out.println(instance.doStuff("world"));
        instance.hello();

    }

}

Note that is a straight Java class, used to illustrate that the EJB could still be consumed by using straight Java code, also note that ITest is recognised as a standard Java interface.

The output produced by by running the client is:

net.jexenberger.personal._ITest_Wrapper@4a1c06a1
hello world called with ScalaTestBean; id: [B@12d9e34

And on the server we get:

[#|2009-06-01T13:13:12.538+0200|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=23;_ThreadName=p: thread-pool-1; w: 9;|
Post Construct called|#]

[#|2009-06-01T13:13:12.541+0200|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=23;_ThreadName=p: thread-pool-1; w: 9;|
hello world|#]

And there we have it. An EJB 3.0 compliant Scala Enterprise Bean!

A final note on packaging and deployment:

Scala obviously requires its supporting runtime and libraries, in order to do this, you will need to package and specify the dependencies in an EAR or copy it into a location in your app Server. In Glassfish the easiest thing to do is copy scala-library.jar to [Glassfish home]/lib/endorsed.