June 2007

Hello (Again and Again)

Friday 6 p.m. local time.

There have been other computers before the Macintosh ...

There have been other MP3 players before the iPod ...

There have been other mobile phones before the iPhone ...

The secret is software.

Hello iPhone, and good luck in changing the way we are used to using technical devices again!

But: Despite the hype that surrounds this new product, over here in good old Europe we're given the chance to wait for General Availability. That is, a second generation iPhone with UMTS support (3G) and - most important - the freedom of choice for the carrier I want. However cool the iPhone might be, I'm definitely not going to switch my carrier just because a phone manufacturer wants me to. That would be like having to use a certain internet provider with my iMac: Not acceptable.

iCards Gone? Not Yet.

Of course there are thousands of e-mail postcard services around the web. But I only used one or two of them, actually. And now my favourite e-card service seems to be gone... (Here's a link to the other one.)

Well, not quite, luckily. Apple obviously removed all iCards links from its homepage, but the free service still exists. Just click here and send your iCards :-)

iCab 3.0.3 Beta 452

Yesterday, on June 17, a new iCab beta was released to registered users. There are some fixes and improvements, among them my long-standing wish for the option to not automatically select the first suggestion in the URL autocompletion popup:

• When loading plugin data by simulating the Windows Active-X API on web sites which do use the proprietary windows technology, iCab will now initiatesome additional checks to make sure that a wrong base URL setting could lead to the wrong URL for the pugin data.
• In the Classic version of iCab the build-in RSS-Reader could not be replaced by an external one by placing the external one (RSSReader.html) into the folder /System/Application Support/iCab/ when running natively in MacOS 8.x or 9.x. Running in the "Classic" environment of MacOSX everything worked fine.
• Added a new option in the "URL autocomplete" settings of the preferences dialog. It is now possible to configure iCab to either automatically select the first suggestion of the autocomplete list which opens just below the location field (which also was the standard behaviour before) or to select nothing automatically, so the user has to explicitly use the arrow-up/down keys to select one of the autocomplete suggestions (the latter is the standard behaviour of Firefox).
• Fixed an error when checking certificates. iCab could display a message about an invalid certificate even if the certificate was valid.
• Saving and fillong out forms automatically (using the menu items in the "View" menu) now uses slightly relaxed rules. Before a "session ID" in the URL for the form submission could be the reason that iCab won't be able to fill out the form with saved form data, because the different URL tiggered the "security" handler which then refuses to fill out form data in "foreign" forms. Now iCab tries to find out if a different URL is different only because of a session ID and so allows to fill out the form data when it failed before.

Java String Concatenation

Recently I found another blog posting about how Java concatenates strings. While the author is absolutely right that you should use java.util.StringBuffer or StringBuilder in loops, the very first example is not quite correct.

If you use a line like

String str = "foo" + "bar" + "Oh my, there must be a more efficient way...";
 

i.e. if you concatenate only String literals and constant expressions (and no variables) the Java compiler uses no StringBuffer/StringBuilder at all, but compiles the String values into a single string. Here's proof. Consider this simple class:

public class StringTest {
    public static final String STR = "ABC" + "DEF";

    public static void main(String[] args) {
        final String str = "abc" + "def";
        System.out.println( STR );
        System.out.println( str );
    }
}

Compile it into bytecode and disassemble it with javap -c StringTest:

public class StringTest extends java.lang.Object{
public static final java.lang.String STR;

public StringTest();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:   ldc     #3; //String ABCDEF
   5:   invokevirtual   #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   8:   getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;
   11:  ldc     #5; //String abcdef
   13:  invokevirtual   #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   16:  return
}

As you can see, at runtime there's no String concatenation any more, but only pre-concatenated String constants (bold lines). So, it's definitely absolutely ok to break down long String values into smaller, concatenated chunks without any runtime performance penalty at all.

Setting JAVA_HOME on Mac OS X

Once in a while the question arises how to set environment variables on Mac OS X in a way that GUI processes can access them, too. In particular, some Java applications require a properly configured JAVA_HOME value.

Answer, part one: Download the preference pane RCEnvironment, install it with a double click and set your variables (they're available after your next login). Yes, it's that easy:

Answer, part two: Use a correct value for JAVA_HOME, which is usually

/Library/Java/Home

This alias (link) defaults to the Java version Apple wants most users to use (currently Java 5.0). Only if you have good reason to do so (for example, if you are a developer), you can set this variable to point at a specific version, e.g.

• /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
  (latest Java 6 release) or
• /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
  (only Java 6.0, no later 6.x release)

iCab 3.0.3 Beta 451 - Atomic

iCab beta 451 fixes several bugs and adds the possibility to display Atom feeds with the built-in RSS reader. Here is Alexander's complete list of changes in the new version:

• Workaround for a bug in classic MacOS if not using the Unicode TextEdit fields in web forms. In certain circumstances the non-Unicode text fields could cause a crash if the text field was empty when trying to insert some text.
• Added a workaround for the buggy Javascript code of the yahoo image search feature when using the Firefox identity setting. Yahoo uses the most complicated way one can think of to open the back/forward links. It first deactivates the links to do the whole processing via JavaScript. The JS code then will first load a small image file that is never used at all. But only after this image was downloaded, the javascript code will open the original link now. But unfortunately it initializes some variables after they are needed when processing some of the JavaScript events. So iCab will now delay som of the events to give the yahoo script more time for initializing these variables.
• Bugfix for the CSS rule "html { font-family: inherit; }, which could cause a crash. The HTML element is the root element (it has no parents) and therefore can't inherit anything from its parent elements. iCab did nevertheless try to inherit from its non-existing parents.
• Checking the validity of SSL certificates could fail because of a buffer that was too small. So iCab could have reported an invalid certificate which was valid.
• Added an optimization for the new ebay layout and the new pull down menus of the ebay site. These menus are very badly programmed. The menu code uses a special exception handling for Safari and IE browsers. And this special code is programmed in a way so that it does all the "expensive" calculations which are needed for Safari or IE before(!) testing if these calculations are necessary, and so in iCab these calculations are done multiple times and afterwards the result is ignored because iCab is neither Safari or IE. Also these calculations are don is way which is most ineffective and even "dangerous" because it can lead to many problems. The optimization for ebay is to cache requests to the HTML code that can be retreived by "innerHTML" in JavaScript.
• The optimization for activating/deactivating StyleSheets from within JavaScript didn't work correctly if only a single StyleSheet was deactivated in a JavaScript call.
• The build in RSS reader does now also support "Atom" feeds. Also if the RSS feed does not provide any links to the articles (which is usually the case when the articles ar already part of the RSS feed) the article list will get much more room and the content area where the article links would be opened otherwise gets less space.
• The enhanced RSS reader is now also available in the classic version of iCab.

Informix and Hibernate

While working on a Java web application that uses Hibernate as the persistence layer and Informix 10 as the database backend we discovered that Hibernate's built-in Informix dialect does not support BLOB and CLOB types.

Since Informix 10 supports these LOB types, it was easy to derive a new dialect from the existing one by simply adding the missing mappings:

  public class Informix10Dialect extends InformixDialect {
     public Informix10Dialect() {
        super();
        registerColumnType( Types.BLOB, "blob" );
        registerColumnType( Types.CLOB, "clob" );
     }
  }

This extended dialect works fine for us, and if you don't want to write it yourself, you can download a small archive here (provided "as is" without any warranties, use it at your own risk). Put the included JAR on your application's classpath and set the dialect in hibernate.properties as follows:

hibernate.dialect=de.snailshell.hibernate.Informix10Dialect

I've also posted a bug report for this issue, and once this is fixed, you won't need the extra dialect JAR any more.