• The New School Enterprise IT Day will show how new technologies and business challenges will change the Enterprise IT. I am quite happy that this has been added to the JAX schedule - because I believe there will a huge shift in this area in the next few years.
• The Cloud Computing Day will show the latest and greatest in the Cloud. Several topics - such as the different Java PaaS alternatives but also IaaS will be explained in detail.
• I have done several Code Retreats at adesso AG and always found them to be a great experience for all involved. Therefore I am pleases that I can do a Code Retreat at JAX this year.
• And of course the Advanced Spring Powerworkshop will take place - it is a unique opportunity to dive deeper into the framework.

¶ 11:14 0 comments

• Ever since the invention of Java EE roles like the Application Assember were defined. I never saw a project that followed this workflow. Nowadays there is just an automated process that results in an EAR or even a complete setup including an application server. It is time to face this reality and get rid of these role descriptions. The deployment process is not done that way. Java needs to step away from it.
• Nowadays application server are seldom used to host more than one application. So maybe that offers some possibilities to improve the deployment processes and also the features. If there is just one application on a server anyway the strict isolation between applications Java EE offers does not make that much sense any more.
• It would be good to focus more on deployment during the development process. Applications are much more often deployed into testing or development environments than into production. I am wondering how many CPU and I/O cycles are wasted compressing WARs and JARs and then EARs during a build process - and immediately decompressing them on the web or application server so testing can start. Can't the Java EE standard do something about this? Obviously there are exploded WARs and EARs - but they are not used as often as they should be. Obviously there are tools like JRebel and Play - but what if the complete tool chain including IDEs, build tools, servers etc would support a standard here? What if all of those parties could collaborate to make this work flawlessly? I think we would see quite a boost in developer productivity.
• Often I see applications modularized in several WARs. These modules need to talk to each other. However, there is no easy way to do this. Usually they end up using Web Services or another HTTP based protocol. Compared to a local method call this adds the overhead of HTTP, sockets and marshalling / demarshalling. A possible solution would be OSGi - but that technology is quite complex. The reason to me seems to be the problems around shared class loading. Classes that might represent parameters or return values can be shared between modules. JBoss includes a solution based on JMX that did not support shared classes - so modules need to have the correct classes available. This is the same as for Web Services or the other HTTP protocols. But there is no standard apart from JMX - which is very low level. Can't we have some communication between WARs that in the standard? Maybe based on JMX? Or at least best practices around it?
• Concurrency in languages like Erlang is very different from what we are used to in Java. There are actors that work on a serial list of messages. Concurrency is achieved by multiple actors working in parallel - while the actors themselves are just working serially. This approach is also used by the Scala library Akka on the JVM. In Erlang this approach leads to lots of actors - far more than the number of threads that can be supported on the JVM. If the JVM wants to stay relevant for this model we need proper support for it.
• Actors in Erlang and in Google Dart - they are called Isolates have separated heaps. Those heaps can be independently GC'd - so while one actors spends time doing GC the other can continue to work on messages. By design you end up with less stop-the-world-GC. Maybe we could have a similar concept in Java? This is an extension of the previous suggestion but there might be other options as well. For example each WAR file could have a separate heap.

¶ 14:56 1 comments

• We did an internal Code Retreat
• We are sponsoring the Legacy Code Retreat in Berlin.
• Also adesso Mobile Solutions does internal Katas.

¶ 16:26 1 comments

Nowadays almost all programmers do extensive Unit Tests. And therefore we see problems arising. Instead of thinking about a problem and building a reliable solution developers now just write a test and code away. At one point they get a green bar and consider the job done. But can you build proper software that way? Dijkstra stated in 1972: "If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with." - see Wikiquote. I think the same holds true for testing. So instead of the ever famous code-test-refactor cycle we could use more of the Feynman Way of Solving Problems. If you really think about the solution first you will find you won't need a test. Instead you will actually write correct code from the beginning. You won't need to rely on tests. They cannot show the absence of bugs anyway - as Dijkstra mentioned. In the end you will end up with cleaner code and less code - as there are no tests to be written.

This principle can be applied to other areas as well. I think one reason why there are so many car accidents are the very effective brakes cars have now. If we had less effective brakes people would think about possible problems beforehand, drive more carefully - and we would have less accidents.

¶ 13:04 5 comments

@Stateless
@TransactionManagement(BEAN)
public class MySessionBean implements MySession {

  @Resource
  javax.transaction.UserTransaction ut;
  @Resource
  javax.sql.DataSource database1;
  @Resource
  javax.sql.DataSource database2;

  public void someMethod(...) {
      java.sql.Connection con1;
      java.sql.Connection con2;
      java.sql.Statement stmt1;
      java.sql.Statement stmt2;
      // obtain con1 object and set it up for transactions
      con1 = database1.getConnection();
      stmt1 = con1.createStatement();
      // obtain con2 object and set it up for transactions
      con2 = database2.getConnection();
      stmt2 = con2.createStatement();
      //
      // Now do a transaction that involves con1 and con2.
      //
      // start the transaction
      ut.begin();
      // Do some updates to both con1 and con2. The container
      // automatically enlists con1 and con2 with the transaction. stmt1.executeQuery(...);
      stmt1.executeUpdate(...);
      stmt2.executeQuery(...);
      stmt2.executeUpdate(...);
      stmt1.executeUpdate(...);
      stmt2.executeUpdate(...);
      // commit the transaction
      ut.commit();
      // release connections
      stmt1.close();
      stmt2.close();
      con1.close();
      con2.close();
}
... }

public void someMethod() throws SQLException, NotSupportedException,
  SystemException, SecurityException, IllegalStateException,
  RollbackException, HeuristicMixedException,
  HeuristicRollbackException {

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class MySessionBean {
  @Resource
  javax.transaction.UserTransaction ut;
  @Resource
  javax.sql.DataSource database1;
  @Resource
  javax.sql.DataSource database2;

  public void someMethod() throws SQLException, NotSupportedException,
      SystemException, SecurityException, IllegalStateException,
      RollbackException, HeuristicMixedException,
      HeuristicRollbackException {
    java.sql.Connection con1 = null;
    java.sql.Connection con2 = null;
    java.sql.Statement stmt1 = null;
    java.sql.Statement stmt2 = null;
    try {

      con1 = database1.getConnection();
      stmt1 = con1.createStatement();

      con2 = database2.getConnection();
      stmt2 = con2.createStatement();

      ut.begin();

      stmt1.executeUpdate("");
      stmt2.executeQuery("");
      stmt2.executeUpdate("");
      stmt1.executeUpdate("");
      stmt2.executeUpdate("");

      ut.commit();
    } finally {
      if (stmt2 != null)
        try {
          stmt2.close();
        } catch (SQLException ex) {
        }
      if (con2 != null)
        try {
          con2.close();
        } catch (SQLException ex) {
        }
      if (stmt1 != null)
        try {
          stmt1.close();
        } catch (SQLException ex) {
        }

      if (con1 != null)
        try {
          con1.close();
        } catch (SQLException ex) {
        }

    }
  }
}

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class MySessionBean {
  @Resource
  javax.transaction.UserTransaction ut;
  @Resource
  javax.sql.DataSource database1;
  @Resource
  javax.sql.DataSource database2;

  public void someMethod() throws Exception {
    java.sql.Connection con1 = null;
    java.sql.Connection con2 = null;
    java.sql.Statement stmt1 = null;
    java.sql.Statement stmt2 = null;
    try {

      con1 = database1.getConnection();
      stmt1 = con1.createStatement();

      con2 = database2.getConnection();
      stmt2 = con2.createStatement();

      ut.begin();

      stmt1.executeUpdate("");
      stmt2.executeQuery("");
      stmt2.executeUpdate("");
      stmt1.executeUpdate("");
      stmt2.executeUpdate("");

    } catch (Exception ex) {
      ut.setRollbackOnly();
      throw ex;
    } finally {
      ut.commit();
      if (stmt2 != null)
        try {
          stmt2.close();
        } catch (SQLException ex) {
        }
      if (con2 != null)
        try {
          con2.close();
        } catch (SQLException ex) {
        }
      if (stmt1 != null)
        try {
          stmt1.close();
        } catch (SQLException ex) {
        }

      if (con1 != null)
        try {
          con1.close();
        } catch (SQLException ex) {
        }

    }
  }
}

• The whole point of transactions is to provide safety if something goes wrong. If you do not commit nor roll back the transaction it will be left in an undefined state and all kinds of things might happen. This is compromising the safety of transactions. So the transactions become more or less useless. You might as well just not use them at all.
• Not closing connections and statements will eventually lead to resource leaks e.g. connection pools running out of connections. This will at one point make the system fail.
• These problems are hard to detect - they will only surface if exceptions are thrown. So finding and eliminating the problem is complex. You should rather get it right from the start.

¶ 16:33 11 comments

• Compiling Dart into JavaScript is a good idea. It means Dart is immediately usable on any platform. There is no other way to quickly get it out to so many developers. Users are not quickly to switch to new browser - think about IE6.
• I originally expected that a Plug In and VM for Dart on Chrome would be released quickly. Now I think that would have been a bad idea. Chrome would have had a good support for Dart while the rest of the browsers would have been left in the cold. They would probably not use the Google VM - remember that they also have their own JavaScript VMs. It is also unlikely that they would create their own Dart VM. So the current approach create a level playing field and makes it more likely for Dart to succeed.
• I think the Dart VM might be an option for Android - maybe not in the near term but probably in the long run. Also it might be enough for Google to have an alternative VM. It just means it has a stronger position if a deal with Oracle must be closed.
• Dart is a good fit for Google App Engine (GAE). Isolates have just one thread - that is also what Google App Engine enforces. That has the advantage that GAE can restart isolates. Isolates can be snapshotted and migrated to other VMs - which is great if you want to react to different load by offloading work from a machine. Isolates can only communicate via ports - that allows you to minimize dependencies to the outside. Again that is great if you want to restart or migrate Isolates. It might also be a way around the limitation that GAE won't allow you to open sockets. Java without Multithreading and without the possibility to open sockets is hard and no fun - and that is why I believe Java on GAE ist not that great. This changes dramatically if you use Dart.

Labels: Dart, Google Dart

¶ 09:31 0 comments