The Java SE 8 release is planned for mid 2013 by Oracle.

Project Lambda as well as the JSR-335 wants to provide means for modelling of code as data in Java – in non-exact, colloquial words one could say it aims for functions as first-class objects in Java. To do so, Project lambda wants to provide the following four extensions to the Java language:

1. Lambda Expressions or Closures which allow the programmer to specify a piece of executable code  in an idomatic way. They can be stored in a variable, passed to a method as argument or used as return value of a method.
2. Expandend Target Typing to bind the Lambda Expressions to objects of a specific type (type inference). These types can be so-called Function Interfaces – Java interfaces with exactly one method.
3. Method and Constructor References to allow the programmer to use existing methods on objects to be bound to a a Function Interface.
4. Default or Virtual Extension Methods to add more methods to existing interfaces without breaking existing implementations  (especially in the collection library).

List students = // ...
students.filter(new FilerFunction(){
    @Override
    public boolean filter(Student s){
      return s.getEntryYear() == 2011;
    }
    })
  .map(new MapFunction<Student,Integer>(){
    @Override
    public Integer map(Student s){
      return s.getGrade();
    }
  })
  .reduce(new ReduceFunction<Integer>(){
    @Override
    public Integer reduce(Integer value1, Integer value2){
      Math.max(value1, value2);
    }
  });

In contrast the following code using the features on their way with Project Lambda:

List students = // ...
students.paralell()
  .filter(s -> s.getEntryYear() == 2011)
  .map(s -> s.getGrade())
  .reduce(Math::max);

The information about the current state from Specification Lead and OpenJDK Project Lead Brian Goetz can be found at State of the Lambda.

In Project Jigsaw, the OpenJDK community lead by Oracle tries to introduce modularity into Java the language. The approach will be different from e.g. OSGi, because they want to establish it on the language level – with static compile time checking. The Oracle people always say they strive for compatibility of Jigsaw with OSGi.

Marc Reinhold, Oracles Chief Platform Architect and OpenJDK Project Lead, describes three principles of the modularity approach:

• Modularity is a language construct – The best way to support modular programming in a standard way in the Java platform is to extend the language itself to support modules. Developers already think about standard kinds of program components such as classes and interfaces in terms of the language; modules should be just another kind of program component.
• Module boundaries should be strongly enforced –  A class that is private to a module should be private in exactly the same way that a private field is private to a class. In other words, module boundaries should determine not just the visibility of classes and interfaces but also their accessibility. Without this guarantee it is impossible to construct modular systems capable of running untrusted code securely.
• Static, single-version module resolution is usually sufficient – Most applications do not need to add or remove modules dynamically at run time, nor do they need to use multiple versions of the same module simultaneously. The module system should be optimized for common scenarios but also support narrowly-scoped forms of dynamic multi-version resolution motivated by actual use cases such as, e.g., application servers, IDEs, and test harnesses.

For the programmer using Jigsaw, it will be especially noticable because the language will now have three phases (instead of two):

• Compile Time: The classes of a module are compiled. The compiled classes together with the resources (configuration files, metadata files etc.) are packed together in an archive in the format of JMOD (for java module):
• Install Time: On any computer having the JRE installed, there will be a module library. Here the user can install java modules.
• Run Time: A module defining a main class (Invokable Module) can be executed. The JVM will load this module and any module it requires from the module library and then execute the code.

Information about the the current state of Project Jigsaw from Marc Reinhold can be found at Project Jigsaw: The Big Picture — DRAFT 1.

The “Golden Eggs” have been written down from Joe’s slides – I hope without big mistakes. The comments are my summaries from his talk.

The full version of Joe’s talk will be available at Parleys soon.

This is a topic Joe has been talking about in a few Java Posse episodes already. And it is simple: By looking at the UI, you should not be able to see already the data structure. The UI should be solely tailored to be easy to perceive and understand by the user. Users don’t think in data structures typically – don’t make them.

With the former rule at hand, some of us engineers tend to go out, design a view and make the data structure look exactly the same. This it not how it is supposed to be. We have layers in all of our applications to abstract away the data structure, for example in the database, from the user interface. So we should do it. Design the data structure to be efficient and elegant for storing. Not like in the user interface.

You never ever should user HTML 5 because it is HTML 5. You should not use anything for the sake of technology.

Think about the user, think about their expectations. What user experience do you want to give them? This should lead your technology decisions.

When starting to design a UI, use a real use case. Not an abstract one, a generalized one. Use something the user will really do with the application. Use example interactions and data which are realistic.

Identify which kind of persons will use your apps. Split them into categories and give them a real name like ‘Ben’ or ‘Anna’. Give them a personality – this is called personas in a design process. Attach one persona to each use case you want to discuss.

As a side note: If you have two very different personas, think about the trade-off for creating two UIs compared to making one configurable. It is sometimes cheaper to create two UIs.

For the user experience it is important to think in application flows. Meaning the process of clicking through an “Login Process” with all state changes and transitions. Don’t think about a login screen.

Similar – if you design a design prototype, make it functional. The steps going through the design is as important as the look on the screen.

UI design is developed in prototypes. Create a prototype of your apps UI – and then throw it away. If you do not throw it away, it is not a prototype!

When you are inside a dialog of your application, the next step the user wants to do should always be very obvious. Make it never hard to find the login button, the next button or the create new user button if this is, what the user wants to do.

To understand this, you have to understand how our brain works, when it perceives a user interface. There are always three phases:

1. In the emotional phase, the brain recognizes colors, layouts and images on the screen. It sets the tone of the interaction with the UI.
2. In the parsing phase, the brain figures out the purpose of every element on the screen. It prepares the user for the task.
3. In the execute phase, the user starts to interact with the first element of the UI.

Our brain is a muscle. It can be trained. It reacts to common patterns. So make your UI consistent to use. Same things should always look the same. And they should align with the behavior the user expects from his operating system.

If you are inside the web, avoid complete page loads. Use the techniques offered by AJAX to load new elements or information in place. So the user does not have to re-parse all the elements because they are gone temporarily.

If your application changes the state, use simple transitions to make clear what is happening. For example, if you hide someting, fade it out so the user knows where to look if he wants to have it back.

The process of designing a UI is iterative. You have to make a lot of proposals and be ready to change your mind. Extend them. Add new designs. Combine them. Throw some ideas away and use others to iterate further.

I had – again – the luck to attend and it was an awesome experience. I’m really thankful that Stephan and his team is doing this works. We love you guys!

So – let me try to give you a very brief overview on what I found most interesting at Devoxx 2011.

As you might know, Java 7 has shipped this summer. I don’t describe the features in depth – but here are the most important ones:

• Project Coin  (JSR-334) which does some small changes to the language to make developers life easier (I wrote about this here and here already).
• The DaVinci Virtual Machine project aims to introduce some features for dynamic languages to the JVM. In Java 7 they introduced invokedynamic (JSR-292), which allows more performant dynamic method invocation.
• The Fork-Join framework (JSR-166) allows a command-and-conquer style execution of big tasks on multiple CPU cores.

Java 8 will be a revolutional release. On contrary, Java 7 was considered evolutional.

The are two revolutional features in Java 8:

• Project Lambda (JSR-335)
• Project Jigsaw (Marc Reinhold (@mreinhold) want to file a JSR soon)

Lambda will allow lambda expressions on the JVM. You can think of a lambda as a function, which stands on its own. A method without an explicit class context. These lambdas can be mapped to SAM-Types (Single-Abstract-Method) types and therefore be very useful for a lot of purposes.

Here is a syntax grap, which is subject to change (as always):

List<Students> students = // ...
students.paralell()
  .filter(s -> s.getEntryYear() == 2011)
  .map(s -> s.getGrade())
  .reduce(Math#max);

The feature will be coupled with virtual extension methods. A virtual extension method is a default implementations of interface methods. This default implementation will be used, if the implementing class does not provide one.

Project Jigsaw will introduce a modularity system for the core Java platform. I haven’t been to a Jigsaw talk this year, so I have no new knowlegde. Nevertheless, Jigsaw will allow you to group your classes into modules and make those modules depend on each other – just like the dependencies section in a maven POM. However, it will be checked by the compiler.

There will be a new file format jmod as well to replace jar files. This will allow you to use modules already installed on your systems, instead of having to package them everywhere.

Other features of Java 8 will be:

• Convergance of the Hotspot VM (former Sun’s VM) and the JRockit VM (Oracle’s own one)
• Type Annotation (JSR-308) to allow annotations in more places.
• A new Date/Time API (JSR-310) base on the joda-time efforts.

Java 8 will be release summer 2013. I bet it will at least have some release at 2013/08/08 . Oracle wants to stay with the two years release cycle. We’ll have to find out, if they can.

The features planned for Java SE are numerous – and still more in a planning phase. Nevertheless, they give you an idea what might come:

• Convergance of the Java SE and the Java ME platform
• Supporting to handle Big Data
• Reification of Generics to make generics more accesible via the reflection APIs
• Unification of primitives and objects in Java
• Having a common Meta-Data Object Protocol for all languages on the JVM.
• Tails Calls & Continuations
• Support for Multi-Tenancy
• Self-tuning VM which is able to inspect and improve its own parameters.

There have been two talks which I shamelessly will handle together, because in my opinion they had the same overall statement. The first one was “Courage in Software Development” by Dick Wall (@dickwall). The other one was “The Diablic Developer” by Martijn Verburg (@karianna). The latter one was acutally over-exagerated and ironic, so  beware I might have misinterpreted it.

Both were actually making the point, that you should not over-estimate the power of best practices. You should always strive for better coding – but this does not mean reading best practices from a book. Most important, you need to try out the things yourself. Try out new things, improve your practice.

Dick was talking a lot about taking risk in software development (and mountain biking). He thinks, that risks as well as failure are part of life, part of learning and part of getting better. So we should do it. Well, I agree on this.

Both stessed the need, to think yourself. “Don’t trust the giant” – said Martijn. This means, don’t unreflectively repeat the heros of our industry. Think about what they say. Think about why they say it. Think about what is there agenda.

Actually I think both talks were pretty good.

This was a Talk from Joe Nuxoll (@joeracer) – trying to teach engineers like us how designers thinks. According to him, the most important thing is to communicate. And for this communcation, designs and engineers have to understand each others language. So …

One common misunderstanding is, that design is about “make things pretty”. But this is acutally the last step. Design is a process. It starts with the idea of a product and it continues through several stages very closely analysing what the different user types (personas) need. The bullet points for this are:

1. Concept
2. Information Architecture & Interaction Design
3. Visual Desing / Interaction Polish
4. Production Plan

You have to understand, that this process is highly iterative and comparative. Designer iterate a lot and make a lot of different drafts and prototypes for there design work. They are also highly interested to critique each others work.

One of the most importants skills of a designer is to listen to the potential users – especially listen between the lines.

After this introduction Joe gave a few golden eggs for UI design. Maybe I’ll blog about them some time later (if asked ).

It was announced in the wednesday keynote, that the Devoxx will be branching out. April, 18th till 20th 2012 a second Devoxx will take place in France, Paris (see http://devoxx.fr/display/FR12/Accueil). The talks will be 25 percent in English, the rest will be in French.

The original Devoxx will of course stay as it is: In Antwerp Belgium and in November.

Other things shortly noted

• The whole Devoxx talks as well as some talks from JavaOne this year will be on Parleys http://www.parleys.com/
• Oracle stopped funding the work in Swing. So Swing is effectively dead.
• There we loads of talk about HTML5 – and they were very well attended. Feels like it is on top of the Hype now.
• There is a “Adopt a JSR” Programm from the London Java User Group to envolve the community in the Java Community Process: http://java.net/projects/ljc-london-jug/pages/AdoptAJSRProgram
• The Technial Discussion Panel with Emmanuel Bernard, Brian H. Prince, Mark Reinhold, Brian Goetz, Joshua Bloch and Ben Evans has been great. You should watch it on parleys.

Especially GIT, which has been developed by the linux kernel developers has some momentum. Furthermore it has a very nice integration into SVN, so that you can use GIT as an interface to a remote subversion repository. In this post, I will show a little bit how I currently use GIT to interface with different branches of the blueprint and training project.

Subversion is a central source control management systems. This means, that there is only one repository where you commit your changesets to. In contrast, on your local machine, you just have a working copy of that repository. Meaning you have the files from a particular branch in a particular revision on your local machine.

In a distributed version control system, everyone has a complete repository. So you have all the code, in all branches and all revisions on your local computer. To share code, you can now syncronize with other repositories over the internet/intranet, but as well locally or via a usb drive.

You can find a more extensive explaination with really nice graphics here.

This sounds very nice. But why should I use it? I will give you some reasons why I use it currently.

To give you some background: I currently work in a department, which supports other developers working with an company internal framework. So we have a project, which is called PetClinic. This PetClinic is used, in different states, as QA project, as training project, as experiment project and as blueprint project.

In the PetClinic we are trying out the latest features from our framework. As we try those on the development versions of the framework, we naturally run into bugs and might therefore break somethings – which would hinder my collegues work, if I check it into subversion, before the bugs I report get fixed.

For this, GIT enables me to create a private branch. This branch and all the commits to it only lives on my machine. When the bugs are fixed, I can check in everything – but still have a nice history.

Merging in SVN is a pain. Especially when you look at our situation. We have a branch for the current snapshot blueprint, a branch ‘exercises’ where we have the final solutions of all exercises  and finally a branch ‘starter’ which is the base project for our training where the training starts from.

These branches require to be synchronized often, with a very fine grained, selective level. It is very often the case, that I want to merge a few revisions from ‘exercises’ back to ‘starter’. This happens as well, when in training I discover something I want to have in ‘exercise’ and/or in ‘starter’ for the next training. Or if some new feature from the blueprint branch needs to be ported to one of the training branches.

GIT helps me here with a sophisticated merging mechanism. Furthermore I can use git cherry-pick to select one specific changeset I want to have in a branch.

Especially for Training, I want, that all my commits are complete and make sense. So someone who looks into my history, should have a step by step description what I did.

Unfortunatly I don’t get everything right the first time. So I often discover after one or two commits, that one line has been missing in a commit or one particular change should belong to another commit.

GIT gives me the opportunity to do so using git rebase.

When working with SVN, you always need a network connection to your SVN server to commit your changes. So typically when in the airplane above the atlantic, you code and make a monster commit.

Furthermore, when you have a network connection, on every commit you wait a few seconds (or more) before the commit is through with the central server. This takes alot of time, I you are not in the company and maybe on a slow VPN connection.

In GIT you commit locally. Against your machine. No network connection required. Only if you synchronize with the external repository – calling push and pull in GIT terminology – you need a connection to this repository. But in this step, you could synchronize hundred nice, small changesets. And you can do it, after your done – while watching TV or brushing your teeth.

GIT has been done by the linux kernel developers. So it has been made for linux. And it has been made for the command-line. On linux, you can easily install the git-core package via the package manager.

On windows, I would recommend using cygwin and install GIT via its package manager – I use it every day and it just works fine. I have installed the packages git, git-svn, gitk and git-gui.

You can install GIT on Windows. There is a TortoiseGit on the internet. I have no idea how the quality is now, but one or two years ago I had some problems using it.

For this blog, I’ll show you the stuff on the command line, as real developers use the command-line ;-)

So, first lets setup a petclinic project connected to our trunk blueprint:

$ mkdir petclinic # create an empty directory
$ cd petclinic # switch to the new directory
$ git svn init http://someserver/svnrepos/common \
    -Ttrunk/blueprints/petclinic \
    -bbranches/QA/*/petclinic \
    -ttags/blueprints/petclinic

This will lead to the following message

Initialized empty git repository in /tmp/petclinic/.git/

This initializes the repository with telling the GIT-SVN tool, where it can find trunk (which is essentially just a branch for GIT), where it can find the other branches and where it can find the tags.

The star * in the branches tells GIT, that at this place it should take the folder name as name of the branch. So the folder name branches/QA/2.11.1.x/petclinic will be the branch 2.11.1.x for GIT. For the tags it automatically assumes the name at the end, because I didn’t specify anything different.

The GIT repository has now been created. It is located in the .git folder. Your working copy is in the normal file system once you selected a current branch.

Ok, now we can fetch the data:

$ git svn fetch

This will now fetch the whole history of all the branches in the PetClinic. So take some time. On larger histories it can take a whole night or more. So be aware – but it has only to be done once.

In SVN you have properties svn:ignore on folders, to tell the version control system which files it should not consider when commiting to the repository. In GIT there are configuration files called .gitignore in the root of your repository which define which files to be ignored.

For example this .gitignore file excludes .project files and the target folder:

.project
target/*

But I do not want to check this file into want to check in this file into version control – it might confuse the SVN users. There is another option: .git/info/exclude. This file works just the same – but is local to your repository.

I can generate the .git/info/exclude file from the svn:ignore information with the following command:

$ git svn show-ignore >> .git/info/exclude

So first of all, I want to see how the different tags and branches behave. A nice point to check this is GITK:

$ gitk --all

This will show something like this:

Ok. After I know, what I have in my repository I want do do some work. I want to try out the some new featuer in a local branch. So I create a new branch based on the current trunk:

$ git checkout -b new_experiment svn/trunk

So, what does this mean?

• git checkout means, that git should “open” the a branch
• -b mean, it should create the branch first.
• view_compiler_experiment is the name of this new branch
• svn/trunk means the new branch should be based on the trunk branch, from the remote repository called trunk

So now, I’m in this branch – and I made some changes to some files. Now I want to commit them.

In GIT I have a very fine-grained control over what I want to commit. First I need to stage the changes I want to commit. I can do this by using git add path/to/file. In contrast to SVN, I need to do this on all changes – not only on the files which are actually new.

Then commit my changes locally by doing:

$ git commit

I could as well do

$ git commit -a

This would automatically stage all changes in files under version control (so this is like the SVN behaviour).

So now I have a bunch of commits and want to push them up to SVN. But first I want to get any changesets from SVN. This is done by

git svn rebase

This will fetch the changesets one by one from the SVN an try to merge them with your branch. In my experience, this does not raise so many merge conflicts as usual – and if it does, they are smaller.

Then I am ready to push my changes into the SVN

$ git svn dcommit

GIT and GIT-SVN have a ton of features. I only use a fraction of them – and from those I only showed a even smaller fractions. There is a Cheatsheet on the GIT page only for GIT-SVN. An the internet is full of other tutorials.

I would really encourage you to use it. Just use the comments, if you need any help with it. I might write a sequel in future.

So, let’s dive into the topic:

Sometimes in Java, you face the problem that a certain set of method calls may throw more than one checked exceptions. This is especially true, if you are working with reflections.

You often want to do the same thing with those exceptions. You might, for example, box them into a RuntimeException because you and your caller methods will not be able to do anything, if the method toString() on the String class is suddenly missing.

The problem might be, that the only common parent of all those checked exceptions is java.lang.Exception. But you cannot really use java.lang.Exception in a catch block, because you are garanteed to catch exceptions you don’t want to catch as well. One of those examples might be the famous java.lang.NullPointerException.

So you have to dublicate your code. This might look like this:

try {
  callWithReflection(arg);
} catch (NoSuchMethodException e) {
  throw new RuntimeException(e);
} catch (IllegalAccessException e) {
  throw new RuntimeException(e);
} catch (InvocationTargetException e) {
  throw new RuntimeException(e);
} catch (ClassNotFoundException e) {
  throw new RuntimeException(e);
} catch (IOException e) {
  throw new RuntimeException(e);
}

JDK 7 will improve the situation for the specific case of reflections, by offering a common parent for all reflection related operations: ReflectiveOperationException. So the following code looks a little better – but we still have two catch blocks, so we are dublicating our code still:

try {
  callWithReflection(arg);
} catch (ReflectiveOperationException e) {
  throw new RuntimeException(e);
} catch (IOException e) {
  throw new RuntimeException(e);
}

This is were multi-catch comes to help. You will be allowed to catch any type of exception – you just have to declare the parameter in the catch block final and seperate the types by a pipe |.

try {
  callWithReflection(arg);
} catch (final ReflectiveOperationException | IOException e) {
  throw new RuntimeException(e);
}

In the exception logic, you can still use only methods on which are available on the first common parent of all the exception types you specified. But if you need more specific methods, you better want to use different catch blocks anyway.

The next features is related. Because you declare the method parameter final, the compiler knows, which checked exceptions might occur in a catch block. So if you are catching IOException and ReflectiveOperationException with a final parameter and rethrow them, you only need to declare those two on the method. So it can look like this:

public void call() throws ReflectiveOperationException, IOException {
    try {
      callWithReflection(arg);
    } catch (final Exception e) {
      logger.trace("Exception in reflection", e);
      throw e;
    }
}

You can – and should – of course combine multi-catch and final rethrow.

There is a second place were exception handling can be nasty: If you have a resource, which needs to be closed. It becomes especially unhealthy if you have more than one resource to close.

Here I want to read the data from a database. The example is the same I used in the first post as an example for the diamond operator. We  have a table, were we have a patient, a medication date and a medication description.

For this we need the following resources: a database connection, a jdbc statement and a jdbc result set. So let’s try the code with JDBC 4.1 (which is new in JDK 7 as well, by the way):

public void readData() {
  Connection conn = null;
  Statement statement = null;
  ResultSet resultSet = null;
  try {
    conn = DriverManager.getConnection(CONNECTION_STRING);
    statement = conn.createStatement();
    resultSet = statement.executeQuery("SELECT patient, medication_day, medication_desc FROM medications");
    while (resultSet.next()) {
      String patient = resultSet.getString("patient");
      LocalDate medication_day = LocalDate.fromDateFields(resultSet.getDate("medication_day"));
      String medication_desc = resultSet.getString("medication_desc");</p>
      System.out.println(String.format("'%s','%s','%s'", patient, medication_day, medication_desc));
    }
  } catch (SQLException ex) {
    logger.error("Error in Database", ex);
  } finally {
    try {
      resultSet.close();
      statement.close();
      conn.close();
    } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    }
  }
}

The problem is, that this code does not account for all possible error which might occur. Here are some of those:

• connection could not be opened (NullPointerException line 22)
• statement could not be opened (NullPointerException line 22)
• sql exception when creating the result set (NullPointer Exception in line 22)
• exception in one of the close statements (unclosed exceptions)

So I did an – probably not perfectly correct – attempt to do a more sophisticated error handling:

finally {
  try {
    if (resultSet != null) {
      resultSet.close();
    }
  } catch (SQLException ex) {
    logger.error("Error in Database", ex);
  } finally {
    try {
      if (statement != null) {
        statement.close();
      }</p>
    } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    } finally {
      try {
       if (conn != null) {
         conn.close();
       }
     } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    }
  }
}

This is a lot of code. And the problem with it is: It might even be still wrong. You can do exceptions handling with resources correct, but  you cannot do innovation. It is a stultifying work.

And stultifying work can be done by compilers! So – with Project Coin – the compiler can do the work for you.

You have to allocate you resources inside of parentheses after the try statement. Then the compiler will care for the resources.

This made my example so easy that I could add another resource (using NIO.2 which is also new with JDK 7) to write the data into a CSV file.

try (Connection conn = DriverManager.getConnection(CONNECTION_STRING);
        Statement statement = conn.createStatement();
        ResultSet resultSet = statement.executeQuery("SELECT patient, medication_day, medication_desc FROM medications");
        BufferedWriter output = Files.newBufferedWriter(target, Charset.forName("utf-8"))) {
  while (resultSet.next()) {
    String patient = resultSet.getString("patient");
    LocalDate medication_day = LocalDate.fromDateFields(resultSet.getDate("medication_day"));
    String medication_desc = resultSet.getString("medication_desc");</p>
    output.write(String.format("'%s','%s','%s'\n", patient, medication_day, medication_desc));</p>
  }
} catch (SQLException ex) {
  logger.error("Error in Database", ex);
} catch (IOException ex) {
  logger.error("Error in File Writing", ex);
}

You still need to handle the exception with the try-with-resources concept. You can either rethrow or catch them – but the system will care to close the resources you have.

One thing, which requires mentioning, is that in a try-with-resources statement it might happen, that more than one exception occur in the handling of closes. You can find those exceptions as “supressed” in the new method on Throwable getSuppressed().

Project Coin is a project about “small language changes”. Those are changes, mostly inside the compiler, that do improve the productivity of the developers but are small of scope.

The changes by Coin are very easy to grasp if you see them in code, so I’ll demonstrate them to you here.

You can test all the Coin features (as you can test all JDK 7 features) with the developer preview build available from OpenJDK. For Coin you need to use Netbeans 7 Beta, because Coin brings a few syntax changes. Netbeans even shows you, where you could use the new Coin features instead of old style and helps you with the conversion:

With Java you could always specify integer values (int or long) using the decimal notation, the octal notation (starting with 0) or the hexadecimal notation (starting 0x). For binaries you could use the Integer.parseInt(…) method. In JDK7 you will be able to specify such values in binary notation as well, if you start your declaration with an 0b. The definition of the decimal number 153 in all four representation can be found below:

int dec = 153;
int hex = 0x99;
int oct = 0231;
int bin = 0b10011001;

Assert.assertEquals(dec, hex);
Assert.assertEquals(hex, oct);
Assert.assertEquals(oct, bin);
Assert.assertEquals(bin, dec);

Besides this, you can now insert an underscore _ into an inger literal. You can use this, to make the literal more readable. The compiler will just ignore it. It  will look like this:

private long salary = 15_500_000_000L;
private int bitmask = 0b1010_1011;

In Java you have a switch satement available to check for the value of a variable and do several different thing in consequence. One of the thing you might do is, to perform an action for “yes”, “no”, “cancel” or “yes to all” according to the input of a user. You can determine what to do, by giving the user the possibilty to enter a char Y,N,C or A according to their wishes. This char can be used in a switch-case statement like this:

public void perfom(char userInput) {
  userInput = Character.toUpperCase(userInput);
  switch (userInput) {
    case 'Y':
      performYes();
      break;
    case 'N':
      performNo();
      break;
    case 'C':
      performCancel();
      break;
    case 'A':
      performYesToAll();
      break;
    default:
       throw new IllegalArgumentException();
  }
}

If you now want to add a new method “no to all”, you have a problem because there is no obivous char mapping. So you might want to use strings as user input instead. Unfortunalty, if you are using Java 6 or below, you cannot use switch-case with strings. So you have to use if-else statements, which some people consider to be a bit boilerplate:

public void perfom(String userInput) {
  userInput = userInput.toLowerCase(Locale.US);
  if (userInput.equals("YES")) {
    performYes();
  } else if (userInput.equals("NO")) {
    performNo();
  } else if (userInput.equals("CANCEL")) {
    performCancel();
  } else if (userInput.equals("YES TO ALL")) {
    performYesToAll();
  } else if (userInput.equals("NO TO ALL")) {
    performNoToAll();
  } else {
    throw new IllegalArgumentException();
  }
}

With Java 7 you can use switch for strings as well. So the code now can look like this:

public void perfom(String userInput) {
  userInput = userInput.toLowerCase(Locale.US);
  switch (userInput) {
    case "YES":
      performYes();
      break;
    case "NO":
      performNo();
      break;
    case "CANCEL":
       performCancel();
       break;
    case "YES TO ALL":
       performYesToAll();
       break;
    case "NO TO ALL":
      performNoToAll();
      break;
    default:
      throw new IllegalArgumentException();
  }
}

I studied medical informatics – so I give you an example from the medical domain. You want to have a data structure, were you can find the medications of the patients groupped by the date they received their medication. For this you could come up with something like this:

Map>> medications = new HashMap>>();

What you can see is, that there is a very lengthy generic type declaration. But what is more: you have to repeat it. You have to write it inside the Map<…> of the type declation and inside the HashMap<…> of the intialization. You should not specify anything different in the initialization, because it breaks you program.

So why writing it? The good new is: You don’t neet to anymore. You can use the diamond syntax.

Map>> medications = new HashMap<>();

These  two angle brackes <> look like a diamond – that’s why it is called diamond syntax. They tell the compiler to copy the generic type from the declaration to the initialization. That’s all

To know, what this warning really is about, you have to understand what heap pollution means. As did not know this before, so I’ll explain it. If you already know, you can skip all the text and code until the last two code blocks. In Java, Arrays and generic types do not go well together. If you want to create an Array of objects which can be typed generically, you can define the generic type on declaration. But you cannot use it in initiazation:

List[] matrix = new List[23];

This can lead to something called Heap Pollution, when you assign an object with an “illegal” generic type to that array. If you try to access the object from the array as the type-signature tells you, you can face a ClassCastException, where you never though you would cast anything.

List[] matrix = new List[23];
List[] nonGenericMatrix = matrix;
// No exception
nonGenericMatrix[0] = Arrays.asList("String1", "String1");
// java.lang.Integer cannot be cast to java.lang.String
List vectorList = matrix[0];

This behaviour is contradictory to the behaviour of a array, without generic types. Here you would receive an ArrayStoreException, when you try to assign an illegally typed object to the array.

Integer[] vector = new Integer[3];
Object[] vectorObjects = vector;
// java.lang.ArrayStoreException
vectorObjects[0] = "String";

Heap Pollution becomes really tricky, when it comes to var-args were you pass an object with a generic type. Var-args will be treated by the virtual machine as arrays, so the problem is essentially the same.

What makes it more difficult, is that you might not have implemented the method you call yourself. You call the method and maybe store the result. And then, 10 years later you are using values from the array you once stored and …

public static  L[] createHeapPollution(L... args) {
  Object[] elements = args;
  elements[0] = Arrays.asList(12, 12);

 return args;
}

public static void main(String... args) {
  List[] polluted = createHeapPollution(Arrays.asList("a", "b", "c"));
  // java.lang.Integer cannot be cast to java.lang.String
  String element = polluted[0].get(0);
}

This was the reason, that in Java 6 you got the compiler warning “[unchecked] unchecked generic array creation of type java.util.ArrayList<java.lang.String>[] for varargs parameter” on the method call which used generic typed objects and var-args. This warning confused users of APIs, while the authors of those APIs got no warnings. To avoid this, a new compiler warning “[unchecked] Possible heap pollution from parameterized vararg type L” has been introduced, so the author of the library will get notified about the problem. He also can use the @SafeVars annotation, to promise that his method will not generate heap pollution. In this case the warning will dissapear on the side of the implementer and the caller of the method.

@SafeVarags
public static  L[] createHeapPollution(L... args) {
  return args;
}

public static void main(String... args) {
  List[] unpolluted = createNoHeapPollution(Arrays.asList("a", "b", "c"));
  String element = unpolluted[0].get(0);
}

There are two addtitional features Project Coin introduces. They will be described in the next post on the JDK 7 subject. Stay tuned …

def insertionSort(unsortedList : List[String]) = {
    val F = unsortedList.toArray
    for(i <- (2 until F.length)){
      val m = F(i)
      var j = i;
      while(j > 1 && !sorted){
        if (F(j-1) >= m) {
          F(j) = F(j-1)
          j -= 1
        }
      }
      F(j) = m
    }
    F.toList
 }

// Note:
// This algorithm has been transcribed from:
// Saake and Sattler. "Algorithmen und Datenstrukturen. Eine Einführung in Java".
// dpunkt.verlag Heidelberg, 2004. page 123f

So, the program iterates over the indexes of the elements from 2 to unsortedList.lenght (line 3). Then it grabs the element of the current index (line 4) and and checks that all elements bigger than the current one get moved one index higher (line 6-11). The it assigns the current element to the place the last element from has been moved from – and everything is sorted.
What I left out from the original algorithm from my source, is a break. This is not critical as the break is a green-cut, to save some performance. This is because scala doesn’t offer a break. This does not really look like scala code. It uses an Array, which is a mutable class – and it uses index based access to a large extend. So I thought about the algorithm and came up (after some trying) with this alternative implementation:

def insertionSort(source : List[String]) = {
  var sorted = List(source.head)
  var unsorted = source.tail
  while(unsorted.tail != Nil){
    val index = sorted.indexWhere( _ > unsorted.head)

    if(index < 0){
      sorted = sorted ::: List(unsorted.head)
    }
    else {
      sorted = sorted.take(index) ::: unsorted.head :: sorted.drop(index)
    }

    unsorted = unsorted.tail
  }
  sorted
}

So first of all, we now have two lists. One with the unsorted and one with the sorted elements. At first the program puts the head of the source list into the sorted list, the tail ends up in the unsorted list (lines 2 and 3). Then it does a while loop until the unsorted list is empty (Nil is an empty list in scala, line 4)- always putting its head into the sorted list and putting its tail in the unsorted list itself, so the unsorted list gets smaller every while-iteration.

The sorting happens based on index (as I understand it, this cannot be avoided in insertion sort, or do you have a solution?). First it finds the index of the first element smaller than the current one (line 5). Then the program creates a new sorted list (the lists are immutable, so we have to create one and assign it to the variable) – with the elements before at the top, the current element in the middle and the elements after at the end (line 11). If the current element is the biggest one (which would mean the index is -1), the element is put at the end (line 8).

So this is my approach. Do you have a better one? Or at least a different one?

The ruby script basically automates the upgrade instructions from the DokuWiki main page. So the following actions are performed when executing the script:

1. Making a backup into /tmp/dokuwiki_backup_#{timestamp} of every installation.
2. Downloading the dokuwiki release (passed in as a parameter).
3. Extracting the files and copying everything to the installations (execept for the content of the /data directory).
4. Creating missing folders in the /data directory, making the owner www-data:www-data and chmodding them to 664.
5. Deleting files from a list of file from older revisions.

Within the script you need to specifiy this snipped for setting your DokuWiki installations:

# Definition of existing installation
INSTALLATIONS = [
  '/path/to/docu/wiki/installation1',
  '/path/to/docu/wiki/installation2'
].freeze

Then you can call for a new release as follows:

/path/to/script/upgrade_dokuwiki.rb http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2009-12-25c.tgz

If you want to improve the script, feel free to fork me on Gist.

Nun trug es sich aber zu (;-)), dass heise.de sein Design geändert hat. Mich hat deren Design schon vorhher immer genervt, wenn ich aus meinem RSS-Reader auf die einzelnen Artikel bin. Aber jetzt war definitiv die Schmerzensgrenze überschritten. Um nicht alle Elemente nachstylen zu müssen (was ja auch sehr fragil ist, da die ids und classes ja jederzeit geändert werden können), habe ich mir überlegt, das ich erstmal die Styles der Printversion nehme. Das ging erstaunlich einfach:

// Erstmal JQuery ins Dokument einführen
// Der Code zum einbinden von JQuer ist ist von:
// http://www.joanpiedra.com/jquery/greasemonkey/ und ist unter MIT-Lizenz gestellt
// Kommentare sind angepasst.
var GM_JQ = document.createElement('script');
GM_JQ.src = 'http://jquery.com/src/jquery-latest.js';
GM_JQ.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(GM_JQ);

// Warten bis JQuery nachgeladen ist
function GM_wait() {
if(typeof unsafeWindow.jQuery == 'undefined') { window.setTimeout(GM_wait,100); }
else { $ = unsafeWindow.jQuery; letsJQuery(); }
}
GM_wait();

// Das normale Greasemonkey Skript, nur jetzt mit JQuery
function letsJQuery() {
// Lösche alle Stylesheets die nicht media=print sind
$('link[rel=stylesheet]').not('[media=print]').remove();
// Ändere das media von print auf screen
$('link[rel=stylesheet]').filter('[media=print]').attr('media', 'screen');
}

Ich habe das Skript speziell für heise.de noch etwas erweitert … wen das interessiert, der möge mich ansprechen.

Ruby 1.9

Matz und Koichi Sasada haben das neue Ruby 1.9 vorgestellt. Und einen Überblick darüber gegeben, was war, was ist und was noch kommen wird. Neben den technischen Details (die man übrigens sehr gut auch aus dem Google TechTalk Vortrag von Matz entnehmen kann) hat Matz vorallem herausgehoben, dass für ihn die Innovation der Sprache Ruby sehr wichtig ist. Er möchte nicht mit dem zufrieden sein was ist, sondern möchte weiter gehen und Ruby weiter entwickeln.
Weiterhin ist natürlich zu erwähnen: Ruby programming is fun …

JRuby

Für mich war JRuby die absolute Überraschung. Bisher hat man sich immer gefragt, was eigentlich JRuby soll – nun im Prinzip ist JRuby dazu da, Ruby Code zu schreiben und gleichzeitig Java-Klassen zu verwenden. Whant so see some?
(Nach Installation via apt-get install jruby1.0 und interaktiv, also jirb1.0)

require 'java'
include_class 'javax.swing.JFrame'
include_class 'javax.swing.JLabel'
include_class 'java.awt.event.ActionListener'
include_class 'javax.swing.JOptionPane'

frame = JFrame.new "Das JRuby Fenster"
frame.setSize 400,200
# Überlagerter Setter von
# frame.set_default_close_operation(JFrame::EXIT_ON_CLOSE)
frame.default_close_operation=JFrame::EXIT_ON_CLOSE
label = JLabel.new "Hello World"
frame.add label

frame.visible= true

Dinge wie obejct.method etc gehen natürlich auch, sodass man super neuer Java-Bibliotheken über jruby ausprobieren kann, selbst wenn man sie ‘nur’ für Java selbst verwenden will.
Übrigens wurde die 1.1 Release während der Konferenz bekannt gegeben.

Weitere Vorträge

Wurden auch gehalten. Alle waren sehr interessant und haben vorallem eines gezeigt: Mit Ruby kann man verdammt viel mehr machen, als bloß Rails. Und dass heißt ja nun wirklich etwas … Ich fands jedenfalls sehr cool (schon alleine wegen der T-Shirts )

Die Folien sollten in Kürze http://www.euruko2008.org zu finden sein.

In klinischen Studien – also Studien in denen neue Therapien im Gesundheitswesen am Menschen getestet werden – ist es Standard, Patienten zu randomisieren. Das bedeutet, dass man Patienten auf zwei, manchmal auch mehrere, sog. Arme aufteilt und das, wie der Name schon vermuten lässt, zufällig. Patienten bzw. Probanden die zu einem Arm randomisiert wurden, erhalten dann eine Behandlung gemäß ihrem Arm. Das sieht so aus, dass zum einen die neue Therapie und zum anderen die Standarttherapie bzw. Placebo zu der Zielerkrankung angewendet wird. Diese beiden Arme können nachher verglichen werden, sodass festgestellt werden kann, ob das neue Medikament besser ist als das andere oder eben nicht.

Randi 2 ist eine webbasierte J2EE Anwendung, die es ermöglicht, eben jene Randomisation durchzuführen. Dabei kann sich – wenn eine Klinische Studie angelegt ist – der Arzt einloggen und die von ihm rekrutierten Probanden sofort randomisieren lassen.

Randi 2 ist im Studiengang Medizinische Informatik an der Universität Heidelberg/Hochschule Heilbronn in einem Softwarepraktikum entstanden. Ich war damals auch Mitglied des ca. 18-köpfigen Teams, dass die jetzige Version von Randi2 in zwei Semestern entwickelt hat. Jetzt soll das Projekt als Open Source unter GNU GPL 3.0 weiterentwickelt werden.

Seit gut einer Woche gibt es die Seite http://randi2.hs-heilbronn.de und ab heute sind wir auch unter http://sourceforge.net/projects/randi2 zu finden. Auf der ersten Seite findet man die wichtigsten News rund um Randi 2 und seine Entwicklung. Die zweite ist unsere Kommunikationsplattform die auch gerne genutzt werden darf, um Wünsche zu äußern.

Bis die Software für die erste klinische Studie produktiv eingesetzt wird, wird es vermutlich noch etwas arbeit bedürfen. Daher ist jeder willkommen, der das Open Source Projekt unterstützen will. Dazu einfach Mail an randi2@hs-heilbronn.de. Ich freue mich auf euch!

Die Seite bietet neben dem Suchen (natürlich mit Aut-Expansion), was ja bei der traditionellen Java-API immernoch fehlt, in einer API, auch das Suchen in mehreren sowie das Merken von den gewünschten Favoriten. Außerdem können die Suchwidgets einzelner APIs auch in andere Seiten integriert werden – müsste theoretisch sogar mit iGoogle gehen. Heißt: Lieblings-API auf der Browser-Startseite serviert?
Der Inhalt der APIs wird nicht von gotAPI gepflegt, sondern es werden die Seiten angezeigt, die in der Ursprünglichen API benutzt werden. So ist man auch bei Änderungen – etwa durch SUN – immernoch auf dem neuesten Stand. Wenngleich hier anzumerken wäre, dass die Java 1.6.0 API noch nicht zur Verfügung steht. Lediglich 1.5.0.
Was mich als Rails Entwickler natürlich freut ist, dass Ruby und Rails in einer API aufgeführt werden. Das macht das Suchen nach Funktionen einfacher bzw. spart mir einfach die Überlegung, ob das eine Ruby oder eine Rails frage ist.

Fazit: Unbedingt ansehen!