Happily, the OpenJdk project does have Java 7 for Mac OSX under development with an official build from Oracle available here.

In related news, Eclipse Indigo SR1 (v3.7.1) has just been released with full JDK1.7 support for Mac OS X. It is available here.

To get Eclipse 3.7.1 to work with Java 1.7 (EA) on Mac OS X do the following.

1) Install Java 7 but leave the more complete+stable Java 6 as the default Java on Mac OS X.

2) Install Eclipse and let it run under Java 6.

3) Start Eclipse, select Preferences,  Installed JREs, Execution Environments and click on “add”.

4) Select standard VM.

5) In the field JRE home, do not attempt to browse for the Java 7 directory as this will not work. Instead just paste the installation dir of the installed Java 7 package +/Content/Home (fx. “/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home”) into the JRE home text field and press return.

6) Fix the JRE name in the field below to something suitable like “JDK1.7″ and click finish.

Now you should be able to create your Java 7 project in eclipse on your Mac OS X and you should be able to run/debug without problems…. Yes!

1) Do not use (or set/unset/inspect) the context class loader returned by Thread.getContextClassLoader(). The context class loader is only applicable to JEE applications. For OSGI in particular, any code that relies to the context class loader will generally fail (or more correctly might by accident work in a few OSGI implementation but will fail in most cases)…. Even if the context loader is non-null do not try to use the context class loader to load any classes as this might interferer with how OSGI resolves classes/versions. To put bluntly, the context class loader should be completely ignored for anything but JEE-only applications, where the context class loader is well defined.

2) Do not use Class.forname(“name”) which will not use the class loader setup by OSGI and cause of kinds of failures incl. ClassNotFound exceptions. You can use the classloader returned by any of the existing classes of your module to dynamically load your classes. F.x. you may use Myclass.class.getClassLoader().loadClass(“name”) instead.

3) Do not split your packages across multiple jars (i.e. where multiple jars have the same exact package and java has to combine the files from each jar to get the whole package content). While it works in OSGI, it is complicated and highly undesired.

P.S. Also, do not use the default package (no package) for your code as this will break OSGI. But seriously, who would do that anyway ?

That’s it, while your code might still not be full OSGI’fied it will at least be OSGI friendly.

• For new projects make sure to select “Execution Environment JRE” when you create your projects – do not select project specific JRE or default JRE!
• For existing projects select package view, right click on JRE system library, select “Execution Environment” and the appropriate environment.  F.x. JavaSE-1.6

Modern Exception Handling (EH) in C++, JAVA, Ruby, Modular-3, C# and other modern programming languages is a great tool for handling errors but unfortunately it is sometimes abused by software developers that do not quite get what exceptions are really for or are just ignorant of possible implementations.

The handling of exceptions must be done at runtime by your compiler/os/virtual machine, since it is generally not possible to predict in advance which handler to transfer control to, identify which exception has been raised, where to perform object cleanup during the propagation of an exception and how much memory to pre-allocate for exception storage. Sometimes the EH runtime mechanism is compiler-specific and a part of compiler’s runtime library. In other cases, support for EH is provided through the operating system or virtual machine.

Common abuses of EH that affect performance include using exceptions as an alternative flow control mechanism (think sophisticated “goto’s” and you got the basic idea of this antipattern”)……. Don’t do that. It will only make the code harder to read. It will also make your code slower to execute since throwing exceptions are generally very expensive operations.

Another less apparent misuse of EH is usage of try-catch(-finally), or similar constructions your language may offer, inside the control flow of hotspots (such as inside time critical loops). Don’t do that, as a the try-catch-finally construction may have overhead even when you won’t expect it.

So why are throwing exceptions expensive and why may the try-catch-finally constructions (or similar) have overhead ? Well, it all depends on the language, the implementation of your VM or compiler (and sometimes on whether you use native code or not if your language allows it). Depending on your environment, just raising one exception can be from 10-100.000 times as slow as alternatively returning a simple return code from the method (in particular depending on if a dynamic registration approach or  a static table approach is used to support control flow transfer). And even if you don’t raise any exception, just having a try-catch-finally in your control flow can also be moderately expensive (but usually only enough to be a real problem inside hotspots).

Specifically, the case of overhead of try-catch-finally constructions when no exceptions occur is difficult to get rid of by compiler & virtual-machine implementers. Few implementations on selected virtual machine and chip architecture got it right and have 100% overhead-free implementations but many impose a overhead just for placing try/catch/finally constructions in your control flow. Basically this is because something like a “linked list” may have to be maintained internally by the compiler or VM each time the control flow enters or exits a try-catch-finally (unless you are luck to run om a fully static table driven implementation of EH).

For much more details about various possible implementations of exception handling and the impact on performance refer to this old thesis of mine here (not up-to-date for virtual machines though).

In conclusion, the morale of the story is:
* Do use exception handling for error handling only (not for control flow).
* Don’t use try-catch-finally constructs inside hot-spots (i.e. loops and such) if it can be avoided. Do the try-catch at a higher level that is called less often.
* If your particular java, c++, ruby, clr … implementation of exception handling on one chip architecture yields excellent performance even when you break the above rules you are just plain lucky. Change the version, vendor or chip architecture and you luck may desert you. Therefore don’t do it

P.S. This post is not about good use EH in general…. But of cause, don’t forget to use exception handling when it is necessary and in particular do NOT ignore exceptions. I have also seen quite a few mistakes in code where exceptions are catched and then ignored. I have even seen senior developers do this in difficult places like event-handlers where one have to go the extra mile to actually handle the error (one way to do this is to create have the main thread manage errors and transfer exceptions to that thread in the event handlers ; but that is long story so I will reserve that for another blog posting)

Notice:

This post is slightly updated version of a posting originally from my old blog at “http://www.mortench.net/blog” which I will shortly retire for good.

This free meet up is sponsered by Miracle and 41concepts. We meet at GeekHouse from 5. May. 2010  kl. 15-17 , Rosensgade 22, 2. sal, 8000 Århus C.

Agenda is still open, but we will try to ensure that subjects like Scala 1.7/1.8, Lift, development tools and Java integration will be covered. If you are experienced in Scala and want to contribute with a talk or demo, you are very welcome !

P.S. It is the plan to arrange a similar meet up in Copenhagen at a later time, so don’t worry if you can’t travel on the 5th.

In a consulting job I recently ran into an interesting case involving a webservice with several different service methods f1, f2, fn (sample names, not actual names) all taking the same string argument and all returning a string. The user would select an operation name after which my code had to call the named operation on a web service using a standard parameter. Trivial really, if one would do accept bad code like this below, but I don’t:

 String operationName = …
 String arg = …
 Webserviceproxy webserviceproxy = …
 // Warning: Badly coupled code begins here (need to update each time we  add/rename/delete operations).
 switch (operationName) {
 case “f1″: return webserviceproxy.f1(arg); break;
 case “f2″: return webserviceproxy.f2(arg); break;
 }

What is really needed is a method to invoke a webservice method by name, while still using the generated .NET proxy to do the hard soap/http stuff (no time to reinvent a better wheel here). Reflection is one way to do this, but let’s try another type-safe method for this posting, because the technique shown here is quite powerful for all sorts of related problems:

Let’s look at an extract of the generated proxy:

public partial class Webserviceproxy :  System.Web.Services.Protocols.SoapHttpClientProtocol
 {
  …
  public string f1(string arg) {
   object[] results = this.Invoke(”f1″, new object[] {arg});
   return ((string)(results[0]));
  }
  …
 }

and at the inherited SoapHttpClientProtocol:

 public  class SoapHttpClientProtocol : HttpWebClientProtocol {
  …
  protected object[]  Invoke(string methodName, object[] parameters) {
  …
  }
  …

  }

It seems the method “invoke” would fulfil our needs if it was only public (which it isn’t). So what do we do? Certainly we do not want to modify the generated file (and lose our changes each time it is regenerated).

The good news is that Generatedwebserviceproxy is a partial class so we can extend it with the following code. We will place the code in a file safely outside the generated proxy class file:

public partial class Webserviceproxy :  System.Web.Services.Protocols.SoapHttpClientProtocol
 {
  ///
  /// Dynamic operation that allows us to call an operation by name.
  ///
  public string InvokeAny(String operationName, string arg)
  {
   object[] results = this.Invoke(operationName, new object[] {arg});
   return ((string)(results[0]));
  }
 }

The compiler will merge the two class definitions effectively adding a new public InvokeAny method to the generated class. And now we can call our web service calls dynamicly from using InvokeAny:

 String operationName = …
 String arg = …
 Webserviceproxy webserviceproxy = …
 return webserviceproxy.InvokeAny(operationName, arg);

Clearly, easy to do and with better overall code than a “switch” – even though it is not without drawbacks as it breaks encapsulation of the generated proxy.

Post scriptum:
Used the same partial classes trick today to add a common custom interface to two differently generated proxies. I now officially miss this feature in Java (yes, AspectJ can do the thing but it is not a official part of the language).

Recent update and notice:

This post an almost identical copy from my old blog at “http://www.mortench.net/blog” which I will shortly retire for good.

RoR does not provide any direct means to monitoring the progress of the boot-process, so a little work is necessary. Changing the ruby source files involved in the boot process is not ideal from a maintenance standpoint and even if one does so, the progress report turns out to be very uneven. The best approach I could come up with was a Kernel hook which keeps track of when files are require‘d. Both easy to do and works surprisingly well for fine-tuned progress reporting.

# Hook into require so that we can track startup progress
module Kernel
 alias org_untracked_require_myAppName require
 def require(file, *extras)
 v=org_untracked_require_myAppName(file, *extras)
 $progress_coordinator.addWorkDelta(1,'Rails required '+file.to_s)
  unless progress_coordinator.nil? || file.nil? || !v
 v
 end
end

activerecord:
  models:
    user: Dude
  attributes:
    user:
      login: "Handle"

Well that didn’t work for me. My only difference was that my model name consisted of two words, so in my yml file I had the following:

activerecord:
  models:
    email_template: Email template
  attributes:
    email_template:
      name: Name
      subject: Subject
      body: Body

But this did not work in the “error_messages_for”. Well the attribute names did, but not the model name that remained untranslated.

After an hour of Googling I didn’t have any answers until I tried to ad a space instead of the “underscore” in the model name. THAT WORKED. So now my yaml file looks like the following. Notice the inconsistencies in the model name!

activerecord:
  models:
    email template: Email template
  attributes:
    email_template:
    name: Name
    subject: Subject
    body: Body

Looking at the source code for the helper method “error_messages_for” we find the thing bothering me here:

          I18n.with_options :locale => options[:locale], :scope => [:activerecord, :errors, :template] do |locale|
            header_message = if options.include?(:header_message)
              options[:header_message]
            else
              object_name = options[:object_name].to_s.gsub('_', ' ')
              object_name = I18n.t(options[:object_name].to_s, :default => object_name, :scope => [:activerecord, :models], :count => 1)
              locale.t :header, :count => count, :model => object_name
            end

(line 199 of active_record_helper.rb)

object_name = options[:object_name].to_s.gsub('_', ' ')

?!?! They are replacing the underscores instead of doing something like:

eval(resource_name.classify).human_name

Has someone else noticed this?! And what are your fixes?
Currently I have to write the model name twice in my yaml files. This is not DRY. My file ended up looking like:

  activerecord:
    models:
      # used by EmailTemplate.human_name
      email_template: "Email template"
      # used by error_messages_for (go figure?!?)
      email template: "Email template"
    attributes:
      email_template:
        name: Name
        subject: Subject
        body: Body

https://sites.google.com/site/gcalweeknumbers/googlecalendarweeknumbers

Using subversion and it’s reversion history is really the way to go for easily generating consistent, ’build’ numbers across team member machines. Furthermore, if your application has multiple modules (in multiple directories) subversion can easily provide individual version numbers for each module.

Unfortunately, subversion is poorly supported by ANT. There are many optional add-on tasks that can be downloaded, but all the ones that I looked at either did not work, was not portable or the license was unacceptable.

The best solution I could find was to invoke the subversion command line command “svnversion” directly from ANT and with a little help from here and here, I wrote a nice little macro that can be used from ANT 1.6+.

<macrodef name="svnversion" description="Get last subversion commit version.">
 <attribute name="dir"/>
 <attribute name="outputproperty"/>
 <attribute name="unversionedDefault"/>
 <sequential>
  <echo message="svnversion -n -c '@{dir}' => '@{outputproperty}'"/>
  <exec outputproperty="@{outputproperty}" executable="svnversion" failonerror="true">
  <arg line="-n -c @{dir}" />
  <redirector>
   <outputfilterchain>
   <tokenfilter>
    <replaceregex pattern="^[0-9]*:" replace="" flags="g"/>
    <replaceregex pattern="exported" replace="@{unversionedDefault}" flags="g"/>
   </tokenfilter>
   </outputfilterchain>
  </redirector>
  </exec>
  <echo message="svnversion returned '${@{outputproperty}}'"/>
 </sequential>
</macrodef>

Usage example

<!--
Sets the ant propery 'src_revision' the the subversion revision of the 'src' directory.
-->
<svnversion unversionedDefault="" dir="src" outputproperty="src_revision"/>

P.S. The last echo statement in the ANT macro also demonstrates a useful ANT trick: How to get the indirect value of a property using another property’s value as the name of the property that we are retriving the value from? This is something that is only possible in ANT 1.6 using macros.