Archive for the ‘Java’ Category

3 small steps for non-OSGI developers that want to stay OSGi compatible

May 21, 2010

Here is some advice if you do not know OSGI, but you would like your Java code to at least not be hostile towards OSGI environments (so that other OSGI developers can use your code and you might easier “upgrade” your code to OSGI later):

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.

Posted in Java, OSGI | Leave a Comment »

Portable Eclipse projects & goodbye to unbound classpath container (JRE) errors

April 25, 2010

It is nice to have Eclipse projects under source control but unless you setup your project correctly you will have a high risk of getting JRE errors like “unbound classpath container” when you share your project with other developers.

  • 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

Posted in Eclipse, Java | Leave a Comment »

Generating ANT build numbers using subversion

May 8, 2009

I have been working on a Java project recently where we are using ANT as a build tool and Subversion for version control. Managing software build-versions manually is bothersome and the ANT’s build-in buildnumber task has many problems/pitfalls.

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.

Posted in Java | Leave a Comment »

Shooting yourself in the leg with a bazooka

July 13, 2007

The colorful title reflects that this posting is about common mistakes done by good but relatively inexperienced software developers. Big mistakes that a developer actually need quite some skills to make. Mistakes that we unfortunately see all too often and we would rather not see much of again (hopefully this blog entry can aid a bit towards that goal):

  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.

Posted in .Net, Design & Architecture, Java, Ruby | 1 Comment »