Dot Neverland

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.

First iPhone application: iBoredom

noreply@blogger.com (julian_za) — Thu, 28 May 2009 18:33:00 +0000

Yes this is a shameless punt...

But hey, if you like it, buy it

It's and iPhone app called iBoredom, the perfect companion for when you are bored...

It aggregates sites with a random content feature like Stumbleupon and wikipedia and allows you to randomly browse content, almost like a remote control.

A Groovy DSL for working with the filesystem.

noreply@blogger.com (julian_za) — Wed, 06 May 2009 16:50:00 +0000

I've recently come back to the idea of using Java as a shell scripting tool. There are a couple of reasons for this; firstly Java is familiar with all my developers, secondly Java's startup time has seriously improved with the 6u1x series of the Hotspot VM, finally Java has a brilliant dynamic language which slips over core Java in the form of Groovy.

However there are still some problems; the most immediately obvious is the fact the shell scripting often involves a lot file manipulation and calling of external processes, tasks which involve a lot of navigation around the file system.

Unfortunately Java has never had a chdir() function, so that means you have to work with everything as an absolute file path, often resulting in some nasty string based code.

Fortunately Groovy can overcome this with it's ability to create Domain Specific Languages. We can use these features to map to standard file system concepts.

Lets take the following bash script. This script creates a directory in the home folder, downloads and unzips a contrived application called myapp into the directory and then creates a shortcut link on the desktop:


# create directory in home
mkdir ~/myapp
# change to directory
cd ~/myapp
# download myapp.zip with wget
wget http://www.myapp.com/download/myapp.zip
# extract myapp.zip using unp
unp myapp.zip
# delete myapp.zip
rm myapp.zip
# change Desktop in home
cd ~/Desktop
# create shortcut and append an entry to the executable to myapp
> myapp.desktop
echo "Exec=${HOME}/myapp/myappExecutable" >> myapp.desktop

While we couldn't map this exactly in Groovy we could at least do something similar, this is what I came up with:


//create the my app directory in home
myAppPath = (~Path + "myapp")
//download and extract
myAppPath.exec "wget -q http://www.myapp.com/download/myapp.zip" .exec "unp myapp.zip"
//delete myapp.zip
myAppPath - "myapp.zip"
//create a pointer to myApp executable
myAppPath/"myAppExecutable"
//create shortcut in Desktop folder
~Path/"Desktop"/"myapp.desktop" >> "EXEC=${myAppPath}"

How would we accomplish this in Groovy.

First we define a class called Path with the ability to ability to build up a path via an append method and a toString method to create a string representation of the path:


public class Path {

Stack pathStack;

Path {
  pathStack = new Stack();
}

public append(String element) {
   pathStack.push "element"
   return this
}

public String toString() {
  //code to build up the path from the stack
  .....
}

}

Now we use Groovy's operator overloading feature to be able to add write pathInstance / "aPathelement", to do this we simply implement the method div on the Path class:


public div(String element) {
return append element;
}

Next we want to be able to quickly get an instance of Path which points to the home directory quickly. I wanted to map this to Bash's '~' home folder expansion. Fortunately we can implement this by overloading the bitwise operator on a static method on the path object:


public static Path bitwiseNegate() {
return new Path()/System.getProperty("user.home")
}

This allows us to write ~Path to create a Path instance to point to the home folder.

Next we want to be able to easily add a new folder to the existing Path instance and then point the Path instance to the new directory by overloading the + operator by implementing the add method:


public Path plus(String element) {
this / element
f = new File(toString())
if !(f.exists()) {
 f.mkdirs()
}
return this;
}

Now we need to implement an exec method to execute processes in the directory specified by the Path instance:


public exec(String command) {
//test that the path is a directory
...
command.execute(new File(this.toString(),null)
return this
}

We also need to be able to delete the file by overloading the '-' operator by creating a minus method:


public Path minus(String element) {
this / element
f = new File(toString())
f.delete();
return this;
}

Finally we want to be able to easily write to a file, we can map to to the unix ">>" shell command which is normally used to route a processes std.out to an existing file (kinda what we are trying to do). We can do this by overloading the right shift operator by implementing the rightShift method:


public Path rightShift(String valueToAppend) {
f = new File(toString())
if (!f.exists()) {
 f.createNewFile()
}
f.append valueToAppend
return this
}

And there we have enough to implement the script example. It is however worth noting that the Path class is far from complete. For example another common task would be to list the contents of a directory and filter via a regular expression, so we can add a method each which takes a regex and a closure to handle each file as a Path instance:


public each(Pattern p, Closure c) {
new File(toString()).each {
  if (p.matcher(it).matches()) {
       //..clone current path
       Path newPath = ...
       newPath / it
       c.call(newPath)
  }
}
}

now you can write:


~Path.each /foo/ {
//do stuff with it
}

However Groovy allows you to call a method as a string literal for example to call x.toString() you could use x.'toString'(), furthermore we can intercept method calls to methods that don't exist, and enhance this a little and rewrite the former as:


~Path.'/foo/' {
//do stuff with it
}

To do this we implement the invokeMethod to handle the non existent method:


public invokeMethod(String name, args) {
if (name.startsWith("/") && name.endsWith("/") {
//strip out regular expession and create Pattern object and assign to 'createPattern' variable
each(createPattern, args[0]);
} else { //blow up

}
}

So there we have it. Of course this class is not complete, we can add additional methods to do additional operations such as iterating through the elements in the Path instance. Furthermore we might be able to further enhance the class by utilising Groovy's Meta Object Protocol.

A full Listing of the Path class can be found here.

Java and Oracle, the real question.

noreply@blogger.com (julian_za) — Sat, 02 May 2009 04:50:00 +0000

So unless you've been living under a rock, you know that Oracle is buying Sun. And of course one of Larry Ellison's motivators to do so is to gain control of Java.

Feelings on how this will affect Java run the gamut from "Blissfully happy" to "The end is nigh".

The press seems to look at Java aspect of the acquisition regarding the product overlap and how little money Sun made off Java. They also seem to view Java as purely an enterprise play, This is an incredibly narrow view as makers of everything cell phone apps to desktop apps to Blu-ray applications will happily attest to.

Java is not a product in the traditional sense of the word, Java is more a community marketplace centered around the Java technology as opposed to a shrink wrapped product.

Java's real value IMHO is then in it's vast reach both in the general development landscape and the vast community of programmers, not so much in the IP or the source code that makes up the JVM.

My question is then if Oracle realizes this.

Community is something that Oracle has not traditionally had to deal with.

Oracle has always been a product company focused on generating healthy margins of all of it's products from a set of clients with deep pockets.

It is now in a position where it will need to support and grow a community of Java users which provide little or no tangible benefit to Oracle's bottom line.

There are many examples of this.

One such example is Glassfish which overlaps with Weblogic and seemingly has no place, however Oracle is now in charge of the JCP and as such has to provide reference implementations for the specifications somehow. Glassfish currently fulfills this role. They could maybe use Geronimo or even JBoss but in a space that will eventually commodotize, it might a bad idea to promote a competitor. Oracle may decide to cripple Glassfish purely to be used for reference but then the fact remains that they have to expend resources on a piece code which makes them no money in order to support the Java community.

Another is the fact that the Java community also consists of companies that compete directly with Oracle. Oracle as the Java shepard must now support these competitors: most notably IBM; the 800 pound Gorilla of the Java community. Strategically it's better for Oracle and IBM to jointly run Java even as competitors lest they both cede a great deal of the Enterprise market to Microsoft. Oracle must therefore keep IBM happy, potentially even spend money to keep them happy in order to preserve the status quo. It must also do the same for it's smaller competitors to expand the reach of Java as far as possible.

Finally Oracle now enters into strange new markets through Sun's acquisition. Oracle's never had any presence in places like the embedded market and now must do work for people who make such strange things as cell phone applications and software for set top boxes, many of whom will never even see an Oracle database or an Oracle App server. Oracle must now keep them happy potentially at margins which don't quite resemble what they make on 11g CALs together with the reality that there is little chance to sell other Oracle products.

No doubt Oracle's shareholders will want Larry Ellison to make good on Sun's purchase but to fit Java into the way Oracle traditionally does things is probably not going to work and might very well end up killing Java.

It's recession time and Sun has the best recession kool aid.

noreply@blogger.com (julian_za) — Sat, 20 Dec 2008 16:47:00 +0000

So you're a CIO and you have several projects to deliver. The only problem is that you've had your budgets slashed.

What is a CIO to do....

Well I don't know if anyone has noticed but one of the coolest recession friendly enterprise software stacks around is being offered by that company we all love to hate: Sun Microsystems.

Consider this:

Sun has a really cool application server which is fully buzzword compliant in the form of Glassfish. Besides the fact that its pretty scalable with old Grizzly, it comes with a rock solid ESB and messaging system, A decent compatible web service stack, and on top of that it is dead simple to administer. And then of course lets not forget the awesomeness that is Glassfish 3.0.

Now Java and JEE can be a little heavyweight, but that's no problem, Sun supports Ruby and Ruby on Rails and has a Ruby interpreter that really rocks in the form of JRuby, and the best part is that you can run it on said application server. And If Ruby is not too your taste, don't forget Groovy and Grails, and soon Python with Django, and if you really want to go exotic there is Scala and Lift. All using it's battle tested core runtime environment otherwise known as Hotpsot.

Of course now you need to save your precious data in a database. Databases of course tend to be notoriously recession unfriendly. Once again Sun provides a proven lightweight solution in the form of MySQL.

Finally no system is complete without a little bit of User interface. Sun provides a good web stack with Glassfish, however you wanna got fat. No problem, JavaFX now provides a good fat solution.

So now you have all the libraries and runtimes, what about an IDE. Once again we have Netbeans, an increasingly one stop shop for doing development, besides doing Java and C++ it does Ruby, Groovy, Scala, JavaScript, PHP and it's newest addition: JavaFX, all with a simple easy interface and allows you to get up and running very quickly.

It's also worth mentioning that Sun also offers a slew of other tools, everything from a continuous integration server in Hudson to an identify management system in the form of OpenSSO, and countless other products.

Once you have all that together, you need an OS to run it all on. Once again you have the increasingly interesting looking OpenSolaris, or it's commercial brother Solaris, which once it's all said and done, is still one of the best OSes on the planet.

Now what is really cool about this whole stack is that everthing I've mentioned here is either open source or free, with support contracts available. If you wanted you could download all individual components and not cost to you, that's right no cost. How recession friendly is that.

But wait there's more, since you've saved all this money on software, why not look at some of Sun's hardware, which includes everything from fast Opteron servers to those Sparc boxes with like a gazillion CPU cores. Then of course there are those Jaw dropping ZFS based Open Storage systems.

So there you have it: If you need to get some bang for your buck, have a look at Sun: your one stop shop for all things EIS.

There is unfortunately one small little caveat...

Sun either isn't interested in dishing out it's kool aid, or is trying too, but no one seems to understand where to get some.

My employer recently bought a whole stack of stuff, and based on what they where looking for a stack like the one I presented here would have appealed to them. All Sun would have had to do, is bundle it up under the banner of a product suite and do some old fashioned selling.

The worst part is that I don't think the Sun people understand what they have. When you watch a Sun presentation you get bombarded with Sun's entire portfolio of products, the only problem is that they present them as a mass jumble of vaguely related products which simply overloads the presentee with information. There's no common theme to say: this is the value proposition we are giving to you.

Now I don't represent Sun in any capacity, but I would find it incredibly sad to see a company that does so much cool stuff fold, and see all this cool stuff potentially disappear.

A simple MP3 Player in JavaFX

noreply@blogger.com (julian_za) — Sun, 10 Aug 2008 09:43:00 +0000

This is pretty much my first attempt at JavaFX and after looking around I wasn't able to find much about using the media player capabilities of JavaFX so I decided to create a simple MP3 player to basically get up and running with JavaFX.

So, for a start what does JavaFX give us in terms of media APIs.

Well the JavaFX SDK contains the javafx.scene.media package which contains the classes for using media within your application.

This package consists of the following classes:

Media : This class wraps a media source, i.e: in this case the location of the MP3 file.

MediaPlayer : This class provides functionality to drive the playback of a Media instance.

MediaError: This class represents an error that occurs during media playback.

MediaTimer: This class allows you to execute actions at an interval during the playback of media.

MediaView: This class is a visual component for displaying your media in the case of video.

For the purposes of this blog I'm only going to focus on the Media class, MediaPlayer class and MediaError class since these are enough to create a very basic MP3 player.

Media Playback using the MediaPlayer class.
So the first thing to do is create a most basic MediaPlayer instance:


 var player =
     MediaPlayer {
       repeatCount:MediaPlayer.REPEAT_FOREVER
       onError: function(e:MediaError) {
                  display = e.message;
                }
     };

You can see here that I've set two attributes: repeatCount and onError.

The repeatCount attribute indicates if the media should loop or play once and then stop. The values for repeatCount are defined as constants on the MediaPlayer class, I've selected MediaPlayer.REPEAT_FOREVER in order to loop playback.

Note: if you leave out repeatCount, playback will not occur (and no error is thrown either if you don't set it, which led to a rather annoying few hours for me).

The onError attribute sets a closure (anonymous function) which gets executed when an error occurs. The closure is passed an instance of MediaError to indicate what happened. In my example I simply set a variable called display, which I bound to a Text node in the UI.

Controlling the MediaPlayer class.
The next thing we need to do define a method to control your player. MediaPlayer has two methods on it which allow you to control it: play() which starts or resumes playback and pause() which allows you to stop (but not reset) the current media playback in the player. For my example I wrote a very simple Button which stops and starts my MediaPlayer instance based on the button's state and the player's state:


Button {
   enabled : bind enabled
   text: bind text
   action: function() {
              if (text == "Stop") {
                 player.pause();
                 text = "Play"
              } else if (player.media != null and text == "Play") {
                 player.play();
                 text = "Stop";
              }
           }
}

Nothing very fancy here, when the Button is clicked in Playing state I call player.pause(), if it's in Stopped state I check firstly that there is media available for the player and then that the button is in a state for me to start playing.

Creating a Media instance for the MediaPlayer class
The last thing really left to do is select some media for playback. Now the JavaFX SDK doesn't wrap all of the Swing API, only a select set of components which you can find in the javafx.ext.swing package. Most notably it's doesn't wrap any of the standard Swing dialogs including javax.swing.JFileChooser. The good news is that's it's easy to call JFileChooser from within JavaFX code. Once again I used a javafx.ext.swing.Button to call my code to select media and set it in my media player instance:


var fileBtn: Button
component:
    fileBtn = Button {
                text: "File"
                action: function() {
                          var fc = new JFileChooser();
                          var mp3Filter = new ExtensionFileFilter();
                          mp3Filter.addExtension("mp3", "MP3");
                          fc.addChoosableFileFilter(mp3Filter);
                          var result = fc.showOpenDialog(fileBtn.getJButton());
                          if (result == JFileChooser.APPROVE_OPTION) {
                             var fFile = fc.getSelectedFile();
                             display = fFile.getName();
                             var file = fFile.toURL().toExternalForm();
                             file = file.replaceAll(" ","%20");
                             if (file != player.media.source) {
                                player.pause();
                                player.media = Media {source:file};
                                text = "Play";
                                enabled = true;
                             }
                           }
                         }
                                     
              }

This code basically calls a JFileChooser which selects .mp3 files from the file system using a simple javax.swing.filechooser.FileFilter instance FileExtensionFilter - which I wrote for my purposes - to get all the .mp3 files in the file system.

Note that when you call showOpenDialog() on the FileChooser you have to pass in a java.awt.Component instance. The Button class does not implement this even though it's wraps a Swing JButton component. However Button does give you a method getJButton() which returns the underlying JButton instance, which you can use to pass to the FileChooser.

Finally once you have the select .mp3 file, the last thing you need to do is create Media object and pass it to the MediaPlayer instance. The Media class has an attribute: source which is a string URL pointing to the location of the media. the Media object will also only accept escaped URLs, which java.io.File.toURL() does not do. This means you have manually escape the URL string before you pass it to the Media object.

And that's it really, the full source code for my player is available here.

Java 7.0 or Java.next?

noreply@blogger.com (julian_za) — Wed, 06 Aug 2008 20:10:00 +0000

A while back I was in a WCF master class hosted by Juval Lowy the MS software legend.

At the time Visual Studio 2008 was a pending release so most of the people were not yet familiar with the language changes in C#.

Juval took a little time to demonstrate the closures in C# to an impressed bunch of hardcore .Net programmers.

At the time I had been regularly writing ruby scripts and all I could think of when I saw the C# closures syntax is: "Man that looks terrible".

Ever since then, I can't help but get the feeling that if MS keeps chucking new features into C# it's not going to look pretty in a few releases.

But regardless of the impact of those features to the core C# language. MS has managed to - with the help of frameworks to make use of the features - create a whole lot of excitement around C# and .Net.

And in the IT industry, excitement around products is important unless you want to leak market share.

It unfortunately also been a couple of years since there's been any excitement around Java.

So what is a direction-less Java developer to do?

One of the options is the Java.next option: keep the JVM but use another language to run on top of it.

This has got quite a few advantages:

You can maintain the investment in Java while moving onto a new language.

You have an nice way to re-skill developers quickly.

You have a clean slate to start from when you design the language.

You can generate excitement while placating your very corporate customers.

As a developer you have a nice new toy to play with.

But before you can do this there are some requirements for corporate IT to accept this:

It must have vendor support, and by vendor support I mean the big guys; IBM, Oracle, Sun etc. etc.

It has to be very easy to to move from Java to Java.next. In fact ideally it should be a superset of Java but that might be pushing it :-).

It has to seamlessly interoperate with all the existing Java frameworks and libraries.

IDE support needs to be on par with Java.

JCP certification wouldn't hurt.

Another option is the Java 7.0 option: simply add new language features to Java to at least maintain parity with other languages. And that of course comes with the risk of messing up the language. Furthermore the changes need to added within a certain time line in order to not create the perception that the language is behind the times.

And then if that fails there is always the COBOL option: leave the language be and then for us developers; when the Java well runs dry we become COBOL style system maintainers or we simply dump the platform all together and start from scratch.

Running your physical Windows XP partition as a VM using Virtualbox on Ubuntu.

noreply@blogger.com (julian_za) — Tue, 05 Aug 2008 19:45:00 +0000

Ok, so you've just installed your shiny new Hardy Heron OS but you still have all those pesky Windows apps you need to run.

Currently you're dual booting, but that sucks.

No worries, the latest version of Virtualbox allows to wrap an existing physical partition as a virtual machine.

Here's how to do it.

1. Install Virtualbox
Firstly; do not install the Virtual box which comes standard in the Ubuntu repositories. In order to support this functionality you have to download the closed source version from Sun. BTW I give Kudos to Sun for being .deb friendly.

2. Setup your permissions.
After you've installed virtualbox you will need to assign your user to certain groups in order to access the physical partition and virtualbox for that matter.

The commands are as follows:
- "sudo usermod -a -G disk "
- "sudo usermod -a -G vboxusers "

You will need to log out of your terminal and then log back in for the changes to take effect.

3. Prep your Windows installation.
Since Virtualbox imposes a Virtual hardware environment to the guest operating system, Windows is going to try install all the new drivers for Virtualbox's virtual hardware environment. This is a problem if you wish to boot back into that Windows partition. For this reason you have to create two separate hardware profiles in Windows; one to run physically and one to run as a guest operating system. This can be done under System Properties > Hardware > Hardware profiles.

Next you have to run a utility called MergeIDE which you can get here. As it turns out Windows writes some registry information about your physical IDE controller into the registry. MergeIDE does some funky rewiring of the registry in order to get around this so that you can "move" your Windows installation onto another hardware environment.

4. Create a virtual hard disk for Virtualbox (VMDK file).
The first thing you need to do is determine which partition your MBR (master boot record) lives on. You can determine this using fdisk or checking your Grub settings.

Finally when you have all this information you create the VMDK file using the command:

VBoxManage internalcommands createrawvmdk -filename [Absolute_Path_to_output_File] -rawdisk /dev/sda -register

You then start Virtualbox, create a new Virtual machine and select this created VMDK file as the hard disk for this VM.

5. Modifying your VM settings for Windows.
In the settings for your virtual machine, under "general" you need to enable the IO APIC and VT-x/AMD-V options in the "advanced" tab.

6. Fixing the licensing issues.
The Windows XP volume license registers your license key against the BIOS for that machine. When Virtualbox loads your guest operating system it presents virtual BIOS information to that OS, which obviously invalidates the license you currently have installed for XP since from it's point of view it's now on a different machine.

In order to fix this you have to modify the settings of your VM config file in order to report your physical BIOS information.

First you have to get the information using the dmidecode command. To get the DMI bios information and the the DMI system information run: dmidecode -t0 and dmidecode -t1 respectively.

You then have to append this information as a set of key-value pairs to your virtual machine settings. A list of all the variables can be found in section 9.13 of the VirtualBox user guide.

The user guide explains how to do this using the "VboxManage" command I found it easier to add the variables myself to the config file of your VM which can be found at ~/.VirtualBox/Machines/My_Windows_Machine/My_Windows_Machine.xml and can be added under the <ExtraDataItems> element.

And that should be it, now you can fire it up!

Some final information.

When you start the virtual machine it will effectively start the same boot loader you normally use for the dual boot system. Under no circumstances boot into the same OS you are currently running. If you do this I can guarantee you a world of pain.

Performance is not fantastic. This seems to mostly stem from lack of decent graphics acceleration. I upped the Video memory and turned off all visual effects in Windows which helped however if you know a way to improve graphics performance, let me know.

Java and the closures hall of shame

noreply@blogger.com (julian_za) — Sun, 03 Aug 2008 18:08:00 +0000

So, to see how far the closures rabbit hole goes I decided to make a list of all the languages in the top ten on the Tiobe index which have no closures support or no confirmed closures support in an upcoming version.

The initial list consists of these languages:
- Java.
- C.
- C++.
- PHP.

Oops I forgot about C++0x and it looks like it has closures support, remember I said confirmed closures support in an upcoming version.

Oh and lets not forget PHP 5.3 and the closures rfc that's already in HEAD.

Therefore the refined list looks as follows:
- Java.
- C.

Now what about C. It's true that ANSI C forbids nested functions but as it turns out GCC has a few extensions which allow you to do closures. It's also worth considering if C belongs here since it's modern use case and characteristics tends to place it in a different category to the rest of the languages on the index. On those grounds I'm going to apply Occam's razor and remove C from the list.

The final list looks as follows:
- Java.

This means that after the next iteration of language versions, Java will lack in capabilities compared to competing languages. Now I can carry on coding without closures - albeit somewhat unhappily. But bear in mind that Java increasingly has to compete with other languages. And if Java is perceived to be obsolete it's going to be a harder sell in the enterprise.

Now I know that time is running out for finalizing Java 7.0 but for goodness sakes Sun you really need to do something.

Now purely from my point of view I wouldn't be upset with either of the following:
- Pushing out the Java 7.0 time line in order to add these language features.
- Make another language such as Groovy a required part of the Java 7.0 spec.

(Yet another) Benchmark of the CLR vs the JVM

noreply@blogger.com (julian_za) — Mon, 28 Jul 2008 19:56:00 +0000

I read this blog entry today on "This Code Goes to Eleven" regarding a JVM vs CLR benchmark.

I decided to redo the benchmark. The first thing I did is slightly tweak the Java version (found here) to use System.currentTimeMillis() as opposed to creating a new Date object which IMHO is fairer test with the C# .Net version. The C# version was unchanged.

I then ran the program in both the JVM's client profile and server profile ("java -client BubbleSort" and "java -server BubbleSort respectively").

To provide some background. Sun's JVMs run in two profiles: the server profile which is optimised for environments which have loads of memory and CPU time and doesn't really have UI interaction, whereas the client is designed to work with more constrained UI centric environments.

My machine specs were as follows:
- Windows XP SP2 32-bit
- Intel(R) Core(TM)2 Duo CPU 2.33GHz
- 4096MB of memory

This was the outcome (click to enlarge):

The results are noteworthy; for one thing the client profile for the JVM is considerably slower than either the CLR or the JVM server profile. Furthermore the JVM running in server profile is markedly faster than the CLR version.

But what have I actually proved?

Absolutely nothing really.

To illustrate, lets take this another step: I took the same test and I ran it on my Ubuntu 8.04 partition on the same machine (once again click to enlarge):

As it turns out the Linux version of the JVM running the same program in server mode is slightly faster overall than it's Windows counterpart and the client mode is on average slower than it's Windows counterpart:

And that's the problem with this whole benchmark.

You can never simply make a blanket statement and say Java is faster than .Net. There are several reasons for this.

A JVM is only as fast as it's implementation allows it to be. IBM's JVMs will perform differently to Sun's JVMs to Oracle's JVMs to Apple's JVMs since the guts of the JVM are implemented quite differently for each vendor. Each company's has engineers who will approach the JVM design differently and have a different set of priorities which may get dictated by the market segment within which they compete.

Secondly a JVM is also constrained by it's platform. If you have a JVM which makes a system call which is slow, or has to generate native code which is slow it's going make your program slow. This means that a Java program performs differently across different operating systems.

Thirdly .Net is supposed to be Microsoft's pre-eminent development tool for the Windows platform. It's fair to say that MS can tweak their stuff for Windows like no one else can (In fact many people have complained that they purposefully do this). The fact that Java does beat .Net on Windows is quite surprising

Finally the usage of Java and .Net in the industry has taken the development of the CLR and JVM down different directions. Java - at least from Sun's point of view - took the high road and thus has had a lot of work done for big iron type environments, meaning that their JVM performs better in server environments than client environments. MS on the other hands needs to keep both environments as happy as possible without rocking the boat too much.

If JavaFX is a flop will you...

noreply@blogger.com (julian_za) — Mon, 21 Jul 2008 19:24:00 +0000

Disclaimer: This poll is utterly unscientific, represents no ones opinion really and is just pretty much a time filler for when you know you should be writing code, but the wild wild web is just more interesting...

Java 7 "quick wins" some ideas

noreply@blogger.com (julian_za) — Wed, 09 Jul 2008 17:17:00 +0000

I while back I was listening to Danny Coward's Java 7.0 interview on Java Posse. He made a comment about the fact that the typical new language features they were looking for are small language changes which don't impact the language too much.

The example he used was a the "foreach" loop which was a relatively small change but had a huge impact with developers, since it actually did make life a little easier as a Java developer.

So I decided to compile a list of some - hopefully - small ideas to reduce genuine sticking points I encounter daily doing meat and potatoes Java programmer.

Now firstly the disclaimer: I'm no language designer nor do I claim originality for these ideas. They are simply ideas that will make my life easier in my Job, they could introduce a whole set of complexities I couldn't even fathom, but anyway here goes...

Remove the final requirement for outer scoped variables which are accessed inside anonymous inner classes. This would allow me to do most of the things I want closures for.

How about a shorthand notation for getters and setters ala Ruby style, for example you would be able to declare something along the lines of:

int myProperty {read;write}

The compiler could simply insert appropriate get and set methods using standard JavaBeans naming conventions. Now generating these haven't been an issue since even the early Java IDEs, but the getter and setter code can still add several hundred lines of clutter to a class and 99% of the time they don't add any real value. If you need to do something specific in the method you can still manually define the getter or setter. Ideally of course, this might be a better option

Finish Autoboxing, I want to be able to do 1.toString().

Shorthand notation for creating maps and lists, something along the lines of...

List myList = {"1","2","3"};

and

Map = {"key1"="value1","key2"="value2"};

While we are at it, what about some basic fixed operator overloading for collections, this has already been suggested and IMHO is a no brainer

Is there absolutely nothing that can be done about anonymous inner class syntax, especially since about 80% of the time my anonymous inner class comprises of precisely one method, couldn't we somehow inline single method classes maybe something along the lines of...

myComponent.addListener(new ActionListener.actionPerformed(ActionEvent e)() {
...do stuff here
});

Although admittedly this just a manifestation of my desire for closures :-(.

Make one of the "buzz" languages a standard part of JSE. By buzz I mean something like JRuby or Groovy. This would make it easier to embrace these languages in a corporate and give some flexibility to platform. A good option might be Groovy since it's the most "Java-ish" language and it is also the only other language which is a Java standard. This has the advantage of requiring no core language changes and could showcase the new invokedynamic bytecode.

Why Windows has become so secure

noreply@blogger.com (julian_za) — Thu, 03 Jul 2008 18:04:00 +0000

It's amazing how secure Windows has become.

The following screen shot illustrates just to what lengths Microsoft goes to, to protect you the user from any "viruses" that might destroy your data..

New buzzwords to reflect reality

noreply@blogger.com (julian_za) — Sat, 21 Jun 2008 14:21:00 +0000

Recently I've been exposed to the process of the aquisition of a large suite of software for the development of a large system. Needless to say the company is a large vendor, the client is a large organisation and the volumes of money involved were, well, volumous.

As usual the decision makers of the large organisation were bombared by a dizzying array of buzzwords designed to exploit the lack of technical knowledge of said decision makers by the vendors.

I thought it's time we start creating a set of buzzwords which are a closer reflection on reality.

These buzzwords are designed to express your feelings in front of managers in a non career limiting manner

Here are a couple that come to mind...

VDD - Vendor driven development: this is when a vendor sells you a set of tools which force you to adapt your working processes to be able to use their technology, since the software is normally too bad to use any other way and you paid a fortune for it, so you have to use it.

COA - Consultant orientated architecture (pronounced "kowa"): this is when you have to buy additional services via expensive consultants in order to make the software you bought for your VDD work.

SaaPG - Software as a Porsche Generator: What software means to the sales people selling you tools.

B-CIEPS - Bean Counter Ignorance Exploitation Procurement strategy (pronounced "beeseeps") : this is the strategy sales people use to enable SaaPG. This strategy works well with large companies.

ROP - Resume orientated programming: 'Nuff said really, just a reminder that we developers aren't exactly blameless either.

BCVLI - Buzzword compliant vendor lock in: This is when a vendor sells you "compliancy" with standards even though the standard is bent or broken or the standardisation process is so bad that only their tools work with the "compliant" product. Anyone who has ever worked with web services can atest to this.

The "Gates-Palminsano-Ellison process": The process whereby you make Bill Gates, Sam Palmisano and Larry Ellison richer men by buying their products, this is actually more an indictment on the company buying the software rather then the vendors, Many decision makers often lean towards large vendors and neglect smaller but equally capable companies because their butts are one the line.

6-zero compliancy: This is the rule that states that in order for a product to be perceived to be useful it's price must have at least 6 zeroes behind the most significant digit, hence; 6-zero compliancy.

UFL - Usefulness follows licensing: This is a rule normally applicable in VDDs, whereby only the basic functionality you could have got downloading an open source product is available and the additional features you actually bought the product for are only available after you purchase additional licenses.

So when you start having project issues because of the load of junk the CIO bought, and your manager asks you why, you can safely look him in the eye and tell him straight: "Well you see this product is very strictly VDD so we have to change the way we work and that takes time, The other product didn't have this problem but it wasn't 6-zero compliant and the "Gates-Palmnisano-Ellison process" eliminated which normally happens when B-CIEPS is employed. It should get better when we start applying UFL, the developers are also quite stoked to start doing ROP.

This list is only the tip of the iceberg, so if you have more let me know, a follow up post should be fun.

The Asus eeePC. What does it's success mean for developers?

noreply@blogger.com (julian_za) — Mon, 16 Jun 2008 12:55:00 +0000

It's been a while since I last blogged, mostly because I've had quite a lot of - shock horror - work to do and just haven't had the time to do any blogging.

However things are quieting down and I'm back to see how many people I can annoy :-)

Anyway, I bought an Asus eeePC for my wife this weekend.

Her needs are very simple; she has a corporate application she needs to run (written in a 4GL called Magic) and she needs to be very mobile.

The Asus eeePC is pretty much perfect for her. The one caveat however is that her corporate application needs Windows. So after much googling I created a stripped down version of Windows XP using a utility called NtLite and managed to cram both Windows XP and her required application into the eeePC's little 2GB flash drive, with a decent amount of space to spare.

The eeePC really is a sweet little machine, besides the fact you can't but help smile when you see this little machine you realise quickly that it could so easily fulfill so many applications.

As I was trying to overcome some of the of the shortcomings of the machine it made me think about about some of the implications for me as a developer if the UMPC market segment takes off and I have to ensure that apps run on this class of computer.

There are a couple things I suddenly need to think about:

My company has standardised on 1024 x 768 as the standard screen size for all applications, this is going to cause a stir when somebody important tries to use the system via their UMPC.

Desktop apps suddenly need to be a little leaner than they have been in the last couple of years, on the 2GB machine, 100MB is a lot, this of course includes data. Gigs and Gigs of hard disk space are suddenly a luxury.

Referring to the previous point, it's also important to make the data more portable, embedded databases are useful but having to make the user perform some complex mount operation in order to run their database off a USB disk is no good.

If Linux ends up dominating this segment, then you can no longer say that the target OS on the desktop is going to be Windows (Not that, that ever bothered a Javaphile like me).

UMPCs are aimed primarily for Web access, this means the browser, JavaScript: say hello to your new, um, "female dog".

I actually question the value of RIA platforms here, if JavaScript/HTML is sufficient for 95% of my applications, and is the lowest common denominator anyway, do I really want the extra overhead of a RIA runtime?

Is Java the new C?

noreply@blogger.com (julian_za) — Sat, 24 May 2008 10:11:00 +0000

I've been watching the language changes being proposed by the community for Java 7.0 like a hawk.

Alex Miller's Pure danger tech blog has become one of my favourite reads as a result.

However I'm pretty sure I'm not the only one who seems to be rather disappointed about what came out of JavaOne this year regarding the proposed Java language features.

It seems that many of the changes will probably be postponed until Java 8.0.

Maybe this is not such a bad thing though.

If I look at the message coming out from JavaOne I could summarise it as being: "Please use Java as a platform but you don't need to use the Java language at all".

In fact I have have a vast array of excellent choices:

If I want a highly productive platform for doing web development, use JRuby.

If I want a highly productive platform for my existing Java Developers use Groovy.

If I want a concise type safe platform with high productivity use Scala.

If I want a mainstream language with Java benefits and high producivity (when it matures) use Jython.

Of these languages, Jython (Python in Java) and JRuby (Ruby in Java) are the most "mainstream" being in the top ten on the Tiobe index with Python and Ruby respectively sandwiching C# - which in itself is quite amazing considering that neither have had C#'s marketing.

Groovy and Scala are a little less mainstream but both have broken into the top 50 with Groovy at number 33 behind Smalltalk and Haskell and Scala finally breaking into the top 50.

Would I still need to write stuff in Java? sure, but only for those bits and pieces which need some low level stuff where speed becomes important especially considering that Java is the only language in the list which still supports primitives, In this scenario the Java language takes on roll much like C.

In fact I'd even go so far to say that Java needs to stay the way that it is in in order to keep it viable for this very important role.

After all we wouldn't want to turn it into the new C++.

Maybe then we should stop regarding Java as the new Cobol but rather look at it as the new C.

JavaFX is a good thing! Really it is!

noreply@blogger.com (julian_za) — Sat, 10 May 2008 06:09:00 +0000

I feel like I must be the only person who thinks that JavaFX is a good thing.

As a Java developer who wrote his first Applet some ten years ago, I kind of find it hard to swallow when IT journalists say things like "Sun has discovered RIA's four years late".

I've got news for you pal, Sun discovered RIA's back in 1995.

What about Adobe Air? huh! don't make me laugh, I've been using Webstart for many, many years now.

Now Applets are not cool, their is no way to get around that, but they were RIA technology version 1.0 or maybe even version 0.9 and it's true that Flash and Silverlight are definitely version 2.0.

It's also true that JavaFX in terms of features doesn't bring too many new things to the table.

But is that a bad thing? There are so many reasons why JavaFX is a good thing. consider the following:

Somebody seems to forget to mention that JavaFX has the only runtime that has first class support for every major operating system. And that's not planned support, that's support that is available today. I'd like to see a Silverlight application running on AIX or even on my PS3.

JavaFX has the same runtime technology that powers many of the world's mission critical systems today. That full power is made available to you on the desktop. It might not be important for a Gmail interface but it is important for a corporate developer like me.

If Sun makes good on it's promises, JavaFX will be the only fully open source RIA with a fully open source runtime. It will even have open source development tools.

It means that companies can re-use their existing Java skills - aka, you and me - for the creation of RIAs.

If it does nothing else, maybe JavaFX might give some credibility back to Java as a GUI development tool. And maybe, just maybe it means that companies might start reconsidering deploying Swing based applications to the desktop. Especially considering that Swing has never been better than it is right now with beans binding and JSR-296, together with the vast array of Swing improvements under the hood.

If Java regains credibility on the desktop, it gives an opening to all languages running on the JVM on the desktop. Maybe it might allow Ruby to break the rails mould.

JavaFX is a very interesting language, I am personally looking forward to seeing where I can push it outside of the RIA space.

Having worked with XAML, the prospect of defining GUIs in horrid XML is very unappealing, give me flash and indeed JavaFX any day of the week