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

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.

1. Overly complicated design – Instead of a simple design for a simple project some developers insist on using a impracticable mix of all the newest, fanciest abstractions, design patterns, techniques and advanced language constructs that can possibly be combined in one software solution. All design elements have benefits and drawbacks. Great (experienced) developers know when a particular benefit of an abstraction, pattern, technique or feature outweighs the drawbacks. There is no silver bullet. No design element works well in all situations (just as no rules that you learned in “programming school” are in fact absolute). Developers that get way too eager ends up with one big unmaintainable design mess with the combined drawbacks of all decisions but few if any real benefits remaining…. Remember, a simple design is a beautiful design!
2. Writing too much code – Writing lengthily code with a high maintenance cost by hand when writing such code can be avoided. Much code can be avoided by choosing a more suitable design/architecture, using standard framework/library features (xml serialization is a common example), using techniques such as dynamic reflection or specialized code generation and aspect oriented tools (be careful though).
3. Reinventing the wheel – Some developers think they can write their own code much faster than learning to understand the underlying framework and available libraries. This might in some cases even be true, but when considering overall quality and maintainability (which developers seldom do) reinventing the wheel is almost always a bad idea.
4. Incorrect use of advanced concepts such as multithreading – Some developers use multithreading without the discipline and deep understanding that writing correct, safe multi-threaded code requires. Multithreading can improve the user experience immensely. It is also the answer to scalability nowadays. However, before even considering to use multithreading in your design, make sure to know the theory and features in your environment well. A vague recollection of mutexes and semaphores from school is not good enough. You should also realize that by deciding to use multithreading, you generally need to upgrade on testing, documentation, reviews and quality insurance.