Wednesday, August 18, 2010

A long shadow over Java's future

Martin Paulo and Ben Hutchison are closing the VJUG mailing list.

Hi All

Ben and I feel that Oracle choosing to sue Google has cast a very long shadow over Java's future, potentially affecting all of us who use Java in our day to day work. We thus no longer have any desire to direct our energies toward VJUG activities going forward.

Unless anyone has strong feelings to the contrary, we propose that the VJUG formally be closed at the end of this week - that the newsgroup and web site be shuttered, and finally, the jug place marker be removed.

Any thoughts or screams to the contrary before we start the process? We will take silence as a vote for closure!


While the Victorian Java community has never been strong, and I can fully understand the reasons for closing the group, I haz a sad.

Despite the considered opinions of others a lot smarter than me concluding that it's far from being the end of Java, Oracle has delivered a great big kick in the slats to a thriving community of Java developers. In my opinion, the biggest effect of this law suit is to bring down the collective morale of Java developers everywhere; it feels like a show of contempt rather than a shroud business move.

It is certainly a sore strain on my good will towards to the new care-taker of Java - the technology my professional career is built on. I cannot understand what positive effects Oracle hopes will come from this suit - either for them as company or the Java community. Does Android hurt Java or Oracle? Will Java or Oracle grow stronger if Google moves away from Java?

This story is far from over, but it is not a good beginning.

Thursday, August 12, 2010

A better way to handle debug logging in IE

When it comes to debugging Javascript in Internet Explorer, the Internet Explorer Developer Toolbar and Firebug Lite are both very useful tools. For a long time, Firebug Lite offered functionality not otherwise available to Internet Explorer developers. Recently, the Developer Toolbar has began incorporating some of the functionality found in Firebug Lite, such as console debugging, They both allow you to execute arbitrary Javascript code to inspect and manipulate elements and state on your page (in IE).

Firebug Lite is installed by dragging a bookmarklet to your Favourites bar. The bookmarklet contains Javascript that opens up a Firebug instance for whatever page you are on. Open the Developer Tools via Tools menu > Developer Tools or F12. Once you have either open, you can run arbitrary Javascript statements and see console logging displayed nicely.

The problem is that often I have Javascript console logging that executes while the document is loading (such as during onLoad). This means IE will always show an error when the page loads because the console object doesn't exist until you open the Developer Tools or Firebug Lite. Usually I will develop in Firefox or Chrome (which both have a console object by default), use a lot of console logging to debug etc and get a nasty surprise when I eventually switch to IE and find a bunch of console is not defined errors. Worse, what happens if you forget to remove those logging statements and the code hits production with those errors?

I have attempted to deal with the development phase of this issue before by opening a text area and dumping console logging to it, but that solution was ugly, didn't play nicely in frame documents and needed to be tied into onLoad. Since those days, I have been playing around with jQuery and Firebug and found a better way to do it.

The code below checks for the existence of the console object. If it is not present, make one up with all the expected log methods: log, debug, info, warn, error. Instead of outputting the messages, it will store them in an array that can be referenced later. When Firebug Lite or the Developer Tools are opened, they override the console object with their own. The old messages can still be accessed though - through the console using the jQuery syntax $(oldConsole.history). That code is below.

 * Catch logging to console in browsers that don't have the console
 * object e.g. IE. Even though you have Firebug Lite, you can only turn
 * that on after the page has loaded - too late for console logging
 * made before you load Firebug Lite.
 * NOTE: This code needs to be loaded before any logging statements.
if (!window.console) {
   window.console = {
      logHistory: function () {
         // Store logs to an array for reference. Thanks to
         console.history = console.history || [];
      log: function() {
      debug: function() {
      info: function() {
      warn: function() {
      error: function() {

   // Once Firebug is opened up, can still access old messages here.
   // E.g. jQuery syntax: $(oldConsole.history).
   window.oldConsole = window.console;

This code needs to be placed before any logging statements happen.

Here is a nice way to re-print those old statements after Firebug has loaded (using jQuery syntax).

$(oldConsole.history).each(function(index) {

Additionally, I have found the following two snippets to be very useful. The first provides a shortcut (log) instead of console.log. The second allows you to use use log as part of a jQuery builder chain.

 * Allows logging to console.log shortcut "log" object. E.g.:
 *    log('inside coolFunc',this,arguments);
window.log = function(){
    console.log( );

// Allow inline jQuery logging following builder pattern: E.g.
//    $("p.someClass").log("inline logging").css("background-color", "red");
jQuery.fn.log = function (msg) {
   console.log("%s: %o", msg, this);
   return this;

Pages that helped me with this code.

Wednesday, August 04, 2010

Check your DOCTYPE

Hit this issue again: some CSS works fine in Chrome and Firefox, but *gasp* doesn't in Internet Explorer. The fix: make sure you have a correct DOCTYPE to ensure IE renders in a "standards compliant" mode. Read more about DOCTYPEs in this informative A List Apart page: Fix Your Site With the Right DOCTYPE! by JEFFREY ZELDMAN.

Monday, August 02, 2010

Autohotkey mapping for a find with "Highlight All Items Found" option in UltraEdit

One of the relatively new features I like in UltraEdit is the "Highlight All Items Found" option in the Find dialog - it will yellow highlight all instances of the thing you want to find in the current document. Unfortunately, this is not quite as good as the same thing in Notepad++ and Eclipse. In Notepad++ and Eclipse, you activate this just by double clicking on a token i.e. double click on a word and all instances of it in the same document will be highlighted.

Worse, Ultraedit doesn't have any way to make a keyboard shortcut for a find with the "Highlight All Items Found" option, nor can it be recorded/used in a macro. So, I have created a rough work-around using Autohotkey. The script below binds control+h to do a find against whatever text you currently have selected and uses the "Highlight All Items Found" option to do so. Also note that the control+h only does this when you are actually in UltraEdit i.e. doesn't affect control+h in any other programs.

; - UltraEdit macros
#IfWinActive, UltraEdit ; Mappings defined here work only for UltraEdit
   ; - Ultraedit: Find using "Highlight All Items Found" option.
      WinWait, Find,
      IfWinNotActive, Find, , WinActivate, Find,
      WinWaitActive, Find,
      Send, {ALTDOWN}i{ALTUP}{ENTER}
#IfWinActive ; Subsequent mappings now affect all windows.

This is just one AutoHokey function I have defined in a single Autohotkey utilities script that gets loaded through my Windows Startup directory so that it is always available. For others, check out this SuperUser post: Most useful AutoHotkey scripts.