Dot Neverland

Swift for the Java Guy: Part 2 - The basics.

noreply@blogger.com (julian_za) — Mon, 06 Jun 2016 06:01:00 +0000

In Part 1 of this series we looked at how to get Swift up and running. In this part we will look the Differences between Java and Swift at a language level by creating the Swift classes and comparing them to Java. For this article we will go over the basic of class construction.

Firstly; Whats the same.

Both languages are fundamentally statically typed class based OO languages with single inheritance and interfaces. Furthermore Swift includes the normal set of features that Java has including:

Try-Catch style Exception handling
C-Style syntax
Generics
First class and high order functions

Whats different

Swift is very different in a key set of areas including

Reference based memory management using Automated Reference counting as opposed to a garbage collector.
Swift classes don't inherit from a base object class.
Swift classes do not need to be declared in a file that follows the Namespace and Class name pattern.
All methods in Swift are functions, Void in Swift is essential a type alias for an empty Tuple.
Swift only has three access modifiers, private and public which behave similarly to the Java equivalents. It also has internal which is Swifts equivalent of default access, Swift however has no protected modifier.
Swift interface (or protocols as they are called in Swift parlance) cannot have default implementations (although you can achieve the same effect with extensions).
Enums in Swift are "different". The best way I can describe is that Swift Enums are basically a set named Tuples which are grouped together in a Enum declaration, each one can declare it's own structure.

What Swift has that Java does not.

Swift has a range of features that Java does not have

Value Types (Structs)
Tuples
Extension types
Operator overloading
Type inference
Language level optional monads and strict null checking
Properties
Destructors
Values and variables as opposed to just variables ala Scala
Nested functions (AKA functions inside functions)
Pattern matching

Declaring your first Class in Swift

For this example I create simple class called "Animal" with a single void method makeSound

class Animal {

func makeSound() -> Void {

print("Roar!!")

}

Animal().makeSound()

A few observations:

Swift methods are explicitly declared with the func keyword and have the return type after the "->" operator which is the opposite order of Java approach in terms of declaration.
The last line creates a new instance of Animal and calls the makeSound method. Note that Animal also has an implicit no-args constructor, also there is no new keyword.

Adding a property

So obviously not all animals roar, to fix this we add a property sound to the class by adding the following

class Animal {

var sound:String = "Croak"

func makeSound() -> Void {

print(sound)

}

let animal = Animal()

animal.sound = "Roar"

animal.makeSound()

By default all variables (denoted by the var keyword) declared as members are properties. What isn't visible here is that when you set the sound property it's actually accessed via accessor methods that are created implicitly. Another point worth mentioning is that the animal variable is not a variable at all but rather a constant as indicated by the let keyword, the let keyword is Swift's equivalent of Scala's val keyword.

Constructors

In the previous example I set roar the default value of "Croak", It would be better if we could pass this information via a constructor and make the sound property immutable, to do this we change the class as follows:

class Animal {

let sound:String

init(sound:String) {

self.sound = sound

}

func makeSound() -> Void {

print(sound)

}

let animal = Animal(sound:"Roar")

animal.makeSound()

Constructors in Swift are slightly different to Java in terms of syntax in that they are defined inside inside a block defined with the keyword init. These blocks can take parameters as you would have in a Java constructor. I also changed the sound property from var to let, this means that the sound property cannot be reassigned once it's been assigned. Its also worth showing here that Swift requires you to use named parameters when you invoke the constructor, this will be familiar to anyone who has ever used Objective-C.

Adding an interface (or Protocol)

Since Animals aren't the only things that make sound, we can pull this functionality up into a Protocol called Audible which can be implemented by the Animal class.

protocol Audible {

func makeSound() -> Void

}

class Animal:Audible {

let sound:String

init(sound:String) {

self.sound = sound

}

func makeSound() -> Void {

print(sound)

}

let audible:Audible = Animal(sound:"Roar")

audible.makeSound()

Here I added a protocol with a makeSound method, aside from the protocol keyword, this should look familiar to most Java developers. The only change to the Animal class is that it implements Audible. The syntax for extension and implementation is the colon syntax which works the same way as C#. I also explicitly typed my audible value to be of type Audible just to force an upcast.

Properties on Protocols

With property properties onto Protocols. For this example I created another Protocol called Named which just has a String property; name

protocol Named {

var name:String {get set}

}

protocol Audible {

func makeSound() -> Void

}

class Animal: Audible, Named {

let sound:String

var name:String

init(sound:String, name:String) {

self.sound = sound

self.name = name

}

func makeSound() -> Void {

print(sound)

}

let animal = Animal(sound:"Roar", name:"Lion")

print(animal.name)

animal.makeSound()

This example also shows mutability of the name property using the get and set keywords. Interestingly I still have to define the actual name variable on the Animal class. Keeping in mind that a Protocol defines behaviour, a property on a Protocol only indicates how the property is structured not how it's stored, that is the responsibility of the implementing class.

Inheritance

For our final addition lets create a class called LivingOrganism which implements Named and make Animal extend that. I also add a default constructor which takes the name property as a parameter

class LivingOrganism:Named {

var name:String

init(name:String) {

self.name = name

}

class Animal: LivingOrganism, Audible {

let sound:String

init(sound:String, name:String) {

self.sound = sound

super.init(name:name)

}

func makeSound() -> Void {

print(sound)

}

Again note the C# style inheritance syntax. Another interesting thing to note is the use of the super keyword which behaves much like super in Java. In this case I invoked the super class init method inside Animal. One difference to Java is that Swift requires the local variables to be initialised first before invoking the super constructor, hence the call being the last line of Animal's constructor. This is the reverse of Java.

So there we have it, a basic overview of class construction in Swift. In the next part we will explore Some of the additional features of Swift such as Tuples and Strict Null checking with optional monads.

Swift for the Java guy: Part 1 - Getting Started

noreply@blogger.com (julian_za) — Sat, 28 May 2016 14:22:00 +0000

It's been a while since I had to look at the Apple development Eco-system.

In fact the last time I did anything serious was back in 2009 when I tried to get in on the boom in apps at the time.

I honestly didn't have a lot of issues with Objective-C as a language per se. In fact if anything I much preferred that than if I had had to whack out code in C or C++.

I think my main objection - if I had one - was that the Xcode environment is nowhere close to the level of something like IntelliJ. Also the SDKs at the time were pretty limited compared to what you had on the full blown version of OSX.

Needless to say; I spent a lot of time doing a lot more boilerplate code than what I would have liked.

When Swift came out (almost two years ago now, can you believe it) I briefly looked at the language which I thought was quite nice but it didn't really interest me much. The biggest reason for this is that my world has been - for the most part - Server side Java running on some type *nix based platform.

Fast forward two years and suddenly Swift is OSS and companies like IBM are trying hard to make Swift feature in my world.

Ok but what can it do that Java cannot?

Well here's a few things to consider:

Docker is changing the landscape in terms of how we deploy software. In a lot of ways Docker is the new Application server and the new virtual machine.
Together with Docker we have the rise of Microservices and the need to create very small deployable units of code.
Swift is a native language, it's fast out the box and incurs very little overhead in terms of memory and startup time.
Swift is also a thoroughly modern and clean language.
The combination of these things potentially makes Swift a great platform to build Dockerised Microservices, perhaps better than a language which historically incurs a large cost with it's VM and dependent libraries.

Installing.

If you are you are using OSX the easiest way to get running is simply to get the latest version of Xcode from the App Store.

If you are running Ubuntu (14.04 or 15.04) I suggest you use the excellent swiftenv utility to install and manage Swift versions.

You can also install swiftenv for OSX via Homebrew. This is useful if you want to easily play around with the Swift 3.0 development builds.

The system I am using for this post is running Ubuntu 14.04 and I using the 2016-05-09-a version which is a Swift 3.0 development snapshot.

Firstly I installed swiftenv as follows:

git clone https://github.com/kylef/swiftenv.git ~/.swiftenv

echo 'export SWIFTENV_ROOT="$HOME/.swiftenv"' >> ~/.bashrc

echo 'export PATH="$SWIFTENV_ROOT/bin:$PATH"' >> ~/.bashrc

echo 'eval "$(swiftenv init -)"' >> ~/.bashrc

Then I can go ahead and install the Swift development package.

swiftenv install DEVELOPMENT-SNAPSHOT-2016-05-09-a

That's it! Swift is now installed.

You can test the installation by running the Swift REPL

Building your first bit of Swift.

My first issue that I encountered on Linux is the complete lack of a decent IDE for the Linux environment. For this example I ended up using good old Vim.

However I'm - somewhat ironically - playing around with Visual Studio Code which also seems to do a decent job.

For this example I will do the obligatory "Hello world"

I simply create a file "HelloWorld.swift" and I put the following code in it.

print("Hello world")

And that's it. Swift will basically run any code which is declared inline alla Ruby, Python, Groovy et-al.

You can now run this as follows:

swift HelloWorld.swift

at which point you see the output:

hello world

Wait a minute didn't I say this is compiled!?

Another really neat feature of Swift is that you can run code both in interpreted and compiled mode.

To compile the code you simply run:

swiftc HelloWorld.swift

This spits out the Executable "HelloWorld" which you can simply execute as:

./HelloWorld

And there you have it! Swift is up and running. In the next post we will explore the language a bit.

Some Notes

swiftc didn't work the first time on my machine. It turns out that Swift relies on a version 3.6 of Clang on Ubuntu 14.04

I fixed this by doing the following:

apt-get install clang-3.6

update-alternatives /usr/bin/clang clang /usr/bin/clang-3.6 100

update-alternatives /usr/bin/clang++ clang++ /usr/bin/clang++-3.6 100

Type safe dependency injection using Java 8.0

noreply@blogger.com (julian_za) — Wed, 25 Jun 2014 21:12:00 +0000

So I sometimes really miss old school Dependency Injection. Back when Spring was still "lightweight" we happily configured all our beans in an application.xml file with the "learn-in-a-day" Spring bean xml configuration. The downsides to this were of course a loss of type safety. I can think of quite a few test cases whose sole purpose was to bootstrap the Spring configuration file and just see if the ApplicationContext starts up without going belly-up due to mis-wiring and correct resolution of included bean xml configuration files.

I may be a minority but I never liked the Spring Schema configuration. To me it feels a bit like configuration for configuration.

Annotations came along and improved things, with the caveat in that you have to import libraries for all those annotations. I like annotations but there is a good case for having all your DI information in a central place so you can actually see how your app hangs together. Finally you sometimes need to create managed objects you can't annotate.

Java Spring configuration makes things better with compile time safety, but I had to rethink the way I did a lot of my wiring, as I had to be careful how I did my wiring as I lost some of the lazy eval that you get in a Spring context as your Java code evaluates immediately when the ApplicationContext starts up.

So, Java based DI is nice but how can we use Java 8.0 to improve it?

Apply that Lambda Hammer

Right so this is the part of the post that starts applying the new hammer in Java 8.0: Lambdas.

Firstly Lambdas give a type safe way of deferring execution till it's needed.

So, lets first create a wrapper object called "ObjectDefinition" who's job it is to define how an object should be created and wired with various values. It works by instantiating the class we want to create and object from (In this case we have a class called "MyObject"). We also give it a list of java.util.function.BiConsumer interfaces which are mapped to a specific value. This list will be used to perform the actual task of setting values on the object.

ObjectDefintion then instantiates the object using normal reflection and then runs though this list of BiConsumer interfaces, passing the the instance of the concrete object and the mapped value.

Assuming we give our ObjectDefinition a fluent DSL we can do the following to define the object by adding the set() method which takes a BiConsumer and the value to set and populates the BiConsumer list as follows:

  MyObject result = new ObjectDefinition()

.type(MyObject.class)
.set((myObject, value)-> myObject.setA(value), "hello world")
.set((myObject, value)-> myObject.setB(value), "hallo welt")
.create();

The create() method simply instantiates a MyObject instance and then runs through the list of BiConsumers and invokes them passing the mapped value.

Method pointers??!! in Java??!! (Well Kinda)

Now, Another interesting feature in Java 8.0 is Method references, which is a feature where the compiler wraps a method in a functional interface provided that that method can map to the signature of that functional interface.

Method references allow you to map to an arbitrary instance of an object provided that the first parameter of that method is that instance value, and the subsequent parameters match it's parameter list.

This allows us to map a BiConsumer to a setter where the first parameter is the target instance and the second parameter is the value passed to the setter:

   MyObject result = new ObjectDefinition()
     .type(MyObject.class)
     .set(MyObject::setA, "hello world")

     .set(MyObject::setB, "hallo welt")
     .create();

Method references provide an interesting feature in that it provides a way of passing a reference to a method in a completely type safe manner. All the examples require the correct types and values to be set and the setter method needs to correspond to that type.

It's Container Time

So now we have a nice little DSL for building objects, but what about sticking it into a container and allowing our ObjectDefinition to inject references to other values.

Well, assuming we have this container, which conveniently provides a build() method which provides a hook to add new ObjectDefinitions.

We now have a container we can use to inject different objects in that container:

     Container container = create((builder) -> {
          builder
              .define(MyObject.class)
              .set(MyObject::setA, "hello world");
     });
     String myString = container.get(MyObject.class);

Our Container object has the define() method which creates an instance of an ObjectDefinition, which is then used to define how the object is created.

But what about dependencies?

Dependency Injection is no fun without being able to inject dependencies, but since we have a container we can now reference other objects in the container.

To this end we add the inject() method to our ObjectDefinition type, this can then be used to reference another object in the container by it's type:

   Container container = create((builder) -> {
      builder.define(String.class)
             .args("hello world");


      builder.define(MyObject.class)
             .inject(MyObject::setA,String.class);
   });
   MyObject myString = container.get(MyObject.class);

In this example we map an additional object of type String (the args() method here is method which can map values to the the constructor of an object). We then inject this String calling the inject() method.

Cycle of Life.

We can use the same approach of Lambdas and Method References to manage the life cycle of an object in the container.

Assuming we want to run an initialisation method after all the values have been set, we simply add a new Functional interface which is invoked after all the values are set.

Here we use the a java.util.function.Consumer interface where the parameter is the instance we want to call the initialisation code on.

    Container container = create((builder) -> {
      builder.define(MyObject.class)
             .set(MyObject::setA,"hello world")
             .initWith(MyObject::start);
    });
    MyObject myString = container.get(MyObject.class);

In this example we added a start() method to our MyObject class. This is then passed to the ObjectDefinition as a Consumer via the initWith() method.

Yet Another Dependency Injection Container

So all these techniques (and more) are included in the YADI Container, which stands for Yet Another Dependancy Injection Container.

The code is available on Github at https://github.com/jexenberger/yadi. And is licensed under an Apache License.

When writing too much code can kill you

noreply@blogger.com (julian_za) — Tue, 27 May 2014 20:34:00 +0000

So now that I lured you in with that provocative title I suppose I need to clarify. Well it's true; too much coding can kill you, the real question is "what is the reason?" and the answer to that is; Chronic Stress.

So why write about this; well it's personal. You see: it happened to me, and I'm hoping to tell other people that it could happen to them to.

"Holy Smokes Batman, do you mean it takes years"
So what is Chronic stress. To quote Wikipedia: Chronic stress is the response to emotional pressure suffered for a prolonged period over which an individual perceives he or she has no control.

A few key observations:

Chronic stress is prolonged stress experienced over a long time, period often years.
There is a distinct physical effect on the body resulting in the continuous release of hormones meant to only be released for a temporary period of time.
When you are in state of prolonged stress, you may not recognise it or if you do, feel that you cannot do anything about it.

"Cortico...what!!??"

The Human body is designed to deal with stress, provided it's temporary. When you are under stress your body releases hormones most notably Adrenalin and Cortisol. Adrenalin boosts your heart rate and energy supplies. Cortisol increases glucose in the bloodstream and increases the bodies ability to produce glucose and ability to repair tissue.

If you were to compare is to a car, Cortisol is like Nitrous, Adrenalin is your Turbo.

Now Nitrous is meant for a short boost, running it permanently is not great for your engine. Adrenalin and Cortisol is pretty much the same. If you run it permanently it's not great for your body.

Here are a few highlights of what you might expect when you suffer from Chronic Stress.

Anxiety
Irritability
Recurring Insomnia
Headaches
Digestive disorders
Depression
Reliance on boosters such as caffeine
Spikes and drops in energy at odd times
Unexplained sudden weight gain
Increase in illness and difficulty in recovering from illness

And (The ones that can kill you):

Hypertension
Cardiovascular disease.

It's also worth noting that many of the symptoms have knock on symptoms.

For me particularly I started suffering from Insomnia almost a year and a half before I was diagnosed with Chronic stress. The effect this had quite a negative effect on my mood and concentration.

Developers are like Soylent green.

So Developers - contrary to popular belief - is people. In other words they are fallible limited creatures who have limitations in what they can do.

The problem is that we often subject ourselves to increased stress, because of crazy timelines, unrealistic expectations (both by our employers and also by ourselves) and no small amount of ambition.

This is complicated if you are a bit of an A-Type personality who has a tendency to take more and more things on.

The sad part is the more you take and the higher your stress levels become, the less productive you become.

The writing is on the wall

First chronic stress is not like a common cold, the symptoms develop after a long period of time and furthermore it's not something that really well understood.

The result is that it's that this type of thing that creeps up on you, and before you know it you are chronically stressed out and now you need treatment.

So here are some early warning signs that you can learn to identify it:

Recurrent episodes of insomnia.
Multiple people repeatedly tell you: "You look tired" or something similar.
Your buttons suddenly start being pushed often and you find yourself getting more easily aggravated at things.
You start becoming very negative and people tell you as much.
You suddenly realise you haven't engaged in a personal hobby or done something you like in quite some time.
You often have a headache and/or heartburn.
You struggle to turn off work and/or you're always anxious about a work.
You often work overtime because it's the only time you can get "flow" due to the multitude of distractions in your environment.

Deal with it!

There is quite a lot help out there with regards to reducing stress, but from a personal view there are a few things worth mentioning:

Ultimately no one actually forces you to be stressed out, If you don't find a way to deal with it no one else will.
Other people won't get it or recognise it unless they have first hand experience, you have to accept and deal with it yourself.
Acknowledge your limits.
Take stress seriously, it can damage your relationships, your career and your health.
Don't be afraid to get professional help.
Take that vacation.
Be careful when you blur work and pleasure, Especially if one of your hobbies is writing code.

So I hope this was informative and here's hoping to no more stress and - off course - staying alive.

Builder pattern using Java 8

noreply@blogger.com (julian_za) — Sat, 11 Jan 2014 15:01:00 +0000

I work in an environment where a great deal of our day to day scripting tasks occur through calling remote services as opposed to working with the database.

For a lot of scripting tasks I've often used Groovy and one of the most useful features of Groovy specifically for that task has been it's built in fluent Builders.

Now Groovy builders exploit a few Groovy language features that are never going to make it into Java.

Most notably Groovy builders make use of Groovy's Meta programming features which isn't coming to Java any time soon.

However a key feature that Groovy builders have is their hierarchical approach to building constructs.

This allows the builders to neatly and safely create nested tree like constructs which can be used to model everything from UX form layouts to XML.

This approach we can at least model quite succinctly using Java 8 lambda expressions.

For my sample I decided to take a reasonably simple Maven pom file and see if I could create a builder to handle that.

All the code for the builder is available on Github here.

The pom.xml file is as follows:

 <?xml version="1.0" encoding="UTF-8"?>  
 <project xmlns="http://maven.apache.org/POM/4.0.0"  
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  
   <modelVersion>4.0.0</modelVersion>  
   <groupId>com.github</groupId>  
   <artifactId>lambda-builder</artifactId>  
   <version>1.0-SNAPSHOT</version>  
   <dependencies>  
     <dependency>  
       <groupId>junit</groupId>  
       <artifactId>junit</artifactId>  
       <version>4.11</version>  
     </dependency>  
     <dependency>  
       <groupId>commons-beanutils</groupId>  
       <artifactId>commons-beanutils</artifactId>  
       <version>1.7.0</version>  
     </dependency>  
   </dependencies>  
   <build>  
     <plugins>  
       <plugin>  
         <groupId>org.apache.maven.plugins</groupId>  
         <artifactId>maven-compiler-plugin</artifactId>  
         <configuration>  
           <source>1.8</source>  
           <target>1.8</target>  
           <fork>true</fork>  
           <compilerArgument>-proc:none</compilerArgument>  
         </configuration>  
       </plugin>  
     </plugins>  
   </build>  
 </project>

Here is the sample code for the builder to build this model:

     MarkupBuilder pom = new XmlMarkupBuilder(true, "pom")  
         .at("xmlns", "http://maven.apache.org/POM/4.0.0")  
         .at("xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance")  
         .at("xsi:schemaLocation", "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd");  
     pom.el("modelVersion", "4.0.0");  
     pom.el("groupId", "com.github");  
     pom.el("artifactId", "lambda-builder");  
     pom.el("version", "1.0-SNAPSHOT");  
     pom.el("dependencies", () -> {  
       pom.el("dependency", () -> {  
         pom.el("groupId", "junit");  
         pom.el("artifactId", "junit");  
         pom.elx("version", version::get);  
       });  
       pom.el("dependency", () -> {  
         pom.el("groupId", "commons-beanutils");  
         pom.el("artifactId", "commons-beanutils");  
         pom.elx("version", version::get);  
       });  
     });  
     pom.el("build", () -> {  
       pom.el("plugins", () -> {  
         pom.el("plugin", () -> {  
           pom.el("groupId", "org.apache.maven.plugins");  
           pom.el("artifactId", "maven-compiler-plugin");  
           pom.el("configuration", () -> {  
             pom.el("source", 1.8);  
             pom.el("target", 1.8);  
             pom.el("fork", true);  
             pom.el("compilerArgument", "-proc:none");  
           });  
         });  
       });  
     });

A few notes on this in general:

I created a special form of some the methods which takes a java.util.function.Supplier as a parameter, and allows you to delay evaluation of a value until you traverse the builder.
I eschewed method chaining (although I catered for it in the builder). Trying both methods I personally felt this was a lot cleaner.
Java doesn't have all syntax sugar that Groovy has, so I used a java.lang.Runnable for the functional interface which reduced the syntax creating a closure, with the downside that you have to have a handle on the initial builder object.

Nowhere as nice as Groovy builders but nevertheless a great step forward. Can't wait for Java 8.

Adding Java 8 Lambda goodness to JDBC

noreply@blogger.com (julian_za) — Thu, 14 Nov 2013 16:04:00 +0000

Data access, specifically SQL access from within Java has never been nice. This is in large part due to the fact that the JDBC api has a lot of ceremony.

Java 7 vastly improved things with ARM blocks by taking away a lot of the ceremony around managing database objects such as Statements and ResultSets but fundamentally the code flow is still the same.

Java 8 Lambdas gives us a very nice tool for improving the flow of JDBC.

Out first attempt at improving things here is very simply to make it easy to work with a java.sql.ResultSet.

Here we simply wrap the ResultSet iteration and then delegate it to Lambda function.

This is very similar in concept to Spring's JDBCTemplate.

NOTE: I've released All the code snippets you see here under an Apache 2.0 license on Github.

First we create a functional interface called ResultSetProcessor as follows:

@FunctionalInterface
public interface ResultSetProcessor {

public void process(ResultSet resultSet,
long currentRow)
throws SQLException;

}

Very straightforward. This interface takes the ResultSet and the current row of the ResultSet as a parameter.

Next we write a simple utility to which executes a query and then calls our ResultSetProcessor each time we iterate over the ResultSet:

public static void select(Connection connection,
String sql,
ResultSetProcessor processor,
Object... params) {
try (PreparedStatement ps = connection.prepareStatement(sql)) {
int cnt = 0;
for (Object param : params) {
ps.setObject(++cnt, param));
}
try (ResultSet rs = ps.executeQuery()) {
long rowCnt = 0;
while (rs.next()) {
processor.process(rs, rowCnt++);
}
} catch (SQLException e) {
throw new DataAccessException(e);
}
} catch (SQLException e) {
throw new DataAccessException(e);
}
}

Note I've wrapped the SQLException in my own unchecked DataAccessException.

Now when we write a query it's as simple as calling the select method with a connection and a query:

select(connection, "select * from MY_TABLE",(rs, cnt)-> { System.out.println(rs.getInt(1)+" "+cnt)
});

So that's great but I think we can do more...

One of the nifty Lambda additions in Java is the new Streams API. This would allow us to add very powerful functionality with which to process a ResultSet.

Using the Streams API over a ResultSet however creates a bit more of a challenge than the simple select with Lambda in the previous example.

The way I decided to go about this is create my own Tuple type which represents a single row from a ResultSet.

My Tuple here is the relational version where a Tuple is a collection of elements where each element is identified by an attribute, basically a collection of key value pairs. In our case the Tuple is ordered in terms of the order of the columns in the ResultSet.

The code for the Tuple ended up being quite a bit so if you want to take a look, see the GitHub project in the resources at the end of the post.

Currently the Java 8 API provides the java.util.stream.StreamSupport object which provides a set of static methods for creating instances of java.util.stream.Stream. We can use this object to create an instance of a Stream.

But in order to create a Stream it needs an instance of java.util.stream.Spliterator. This is a specialised type for iterating and partitioning a sequence of elements, the Stream needs for handling operations in parallel.

Fortunately the Java 8 api also provides the java.util.stream.Spliterators class which can wrap existing Collection and enumeration types. One of those types being a java.util.Iterator.

Now we wrap a query and ResultSet in an Iterator:

public class ResultSetIterator implements Iterator {

private ResultSet rs;
private PreparedStatement ps;
private Connection connection;
private String sql;

public ResultSetIterator(Connection connection, String sql) {
assert connection != null;
assert sql != null;
this.connection = connection;
this.sql = sql;
}

public void init() {
try {
ps = connection.prepareStatement(sql);
rs = ps.executeQuery();

} catch (SQLException e) {
close();
throw new DataAccessException(e);
}
}

@Override
public boolean hasNext() {
if (ps == null) {
init();
}
try {
boolean hasMore = rs.next();
if (!hasMore) {
close();
}
return hasMore;
} catch (SQLException e) {
close();
throw new DataAccessException(e);
}

}

private void close() {
try {
rs.close();
try {
ps.close();
} catch (SQLException e) {
//nothing we can do here
}
} catch (SQLException e) {
//nothing we can do here
}
}

@Override
public Tuple next() {
try {
return SQL.rowAsTuple(sql, rs);
} catch (DataAccessException e) {
close();
throw e;
}
}
}

This class basically delegates the iterator methods to the underlying result set and then on the next() call transforms the current row in the ResultSet into my Tuple type.

And that's the basics done. All that's left is to wire it all together to make a Stream object. Note that due to the nature of a ResultSet it's not a good idea to try process them in parallel, so our stream cannot process in parallel.

public static Stream stream(final Connection connection,
final String sql,
final Object... parms) {
return StreamSupport
.stream(Spliterators.spliteratorUnknownSize(
new ResultSetIterator(connection, sql), 0), false);
}

Now it's straightforward to stream a query. In the usage example below I've got a table TEST_TABLE with an integer column TEST_ID which basically filters out all the non even numbers and then runs a count:

long result = stream(connection, "select TEST_ID from TEST_TABLE")
.filter((t) -> t.asInt("TEST_ID") % 2 == 0)
.limit(100)
.count();

And that's it!, we now have a very powerful way of working with a ResultSet.

So all this code is available under an Apache 2.0 license on GitHub here. I've rather lamely dubbed the project "lambda tuples, and the purpose really is to experiment and see where you can take Java 8 and Relational DB access, so please download or feel free to contribute.

New Years Resolutions for the Java Developer

noreply@blogger.com (julian_za) — Sun, 30 Dec 2012 19:00:00 +0000

So in closing on a rather eventful year for me personally it's always good to reflect and think and thus we apply the cliché of the new years resolutions - with a twist - in that they will be Geeky.

So without further ado here we go.

Use Spring Less.
I plan to use vastly less Spring this year.

Now Spring has pretty much become the de facto component framework in the Java ecosystem. This is not a bad thing; that is until every software nail must be nailed flat with the Spring hammer.

I been on the Spring Bandwagon now since about 2005 when Spring was still the breath of fresh air promising to save us from the evil Darth Ee-jay-bee. From about that time every developer with a glint in their eye and a will to type has tried to shoehorn everything to "integrate" into Spring.

Again this is not necessarily bad, however I work for a company where the perception is that anything prefixed with the word "Spring" is automatically better, sometimes coming at the cost of something that is actually better.

But lets not stop there...

I'm tired of the "For Real?" look I get from my developers when they are debugging Spring configuration and they ask my why Spring is better.
I'm tired of the massive War files I get and often the dependency clashes I have to fix because of the other stuff I need to pull in.

So this new year I plan to use Spring in it's pure simple form.

Stop treating JPA/Hibernate as the one stop shop for Java based persistence.

I want to use something besides JPA/Hibernate to do persistence this year, I want to do this because of the following:

I want to have POJOs that are still POJOs at runtime.
I want to stop having weird hibernate exceptions that happen after we've been in production for a bit, and then have my customer stop screaming at me.
I want to stop having the rich domain model being so tantalisingly close to my grasp only to have it all come crashing down when the realities of ORM kick in.
In reference to the previous point: I hate DAOs; JPA/Hibernate don't make them go away (at least not completely).
I'm tired of the "For Real?" look I get from my developers when they are debugging JPA/Hibernate issues and I'm explaining to them how JPA/Hibernate simplifies things.

Now to fair a lot of the points listed is because JPA/Hibernate does a lot of complex heavy lifting on my behalf, but in many cases the power is just not needed.

Stop using Anonymous Inner classes and just bite the bullet and wait for 8.

I've been excited about the inclusion of closures in Java for a long, long time. I am a self confessed "closurist " and I fully plan to find as I many nails as I can when I get my closure powered hammer.

But I also have to accept that Java 8 especially in full production use is still going to be some ways away.

And before that I resolve to resist the temptation to butcher code with anonymous inner classes in order to recreate that style of coding.

Stop worrying about the procedural code.

Hah! bet you never saw that one coming.

I've been looking at the code that we produce, typically I do a lot of SOAP web services in my job, and what I see a lot of is that while we normally try to stick to SOLID principles, I don't see a lot of value coming out of the abstractions we create.

We have an anaemic domain model and most of the work is done in the Service tier implementation delegating to DAOs for data operations (although I've started introducing newer patterns here).

I can't help feel that had I done this code in pure C it probably wouldn't feel massively different. To this end I sometimes wonder if all we do is procedural code with a bit of OO sauce on top.

I also wonder is this is necessarily a bad thing; the code works, it's simple to follow and read and is not burdensome to maintain, so this coming year I plan to to stop worrying about it :)

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).