Java

« Home Theater | Main | Linux »

Switching to Linux

Wednesday, August 11, 2010

I switched to Linux from Windows on my laptop about eight months ago and I thought it might me interesting to write a blog post about my experiences. As an Enterprise Java and Android architect and developer, most of the work I do can be done equally well on Linux as on Windows. Many of the applications I work on end up in a Linux or Unix type environment but I don't typically have much to do with the Linux servers on a day to day basis since they are managed by operational staff. While I was comfortable with a Unix command line I really wanted to increase my general Linux skills and using it on a daily basis provided an excellent opportunity to do so.

The first, and best, decision I made was to overwrite Windows when installing Linux and jump in all the way. My reasoning is that with a dual boot system I would be too tempted to go back to the familiar than pushing forward and learning something new. So after backing up all my documents to a portable hard drive I went ahead and installed openSUSE 11.2 on my Dell e6400. I have to say the install experience was significantly better then the last time I played with Linux a few years ago and the process went quite smoothly. The only exception was I had to install a proprietary Broadcom wireless driver manually but other than that it was all good.

After using it now for eight months I have to say that I have been really happy to make the switch. In general I find my development tools run much faster then they did under Windows. Java development tools such as Eclipse, BEA Workshop and JDeveloper tend to be quite heavyweight but feel much more performant under Linux then they do under Windows. I imagine most of this is likely due to the fact that Linux tends to be a lighter weight operating system and you generally run less cruft, not having to run an anti-virus scanner for example probably helps quite a bit.

One big thing I like about Linux is the fast boot time and that once the system is booted it is fully ready for use. Under Windows the boot time was longer plus once it booted to the desktop the system still wasn't really useable until all of the background boot processes finished, starting a program right after boot often entailed a painful wait.

I have not been able to completely ween myself off of Windows though and have Windows XP available in a VirtualBox Virtual Machine (VM) for the times when I need it. VirtualBox is a great application that is free, since it can suspend a guest OS starting and stopping the WinXP VM only takes a few seconds. The performance of XP in the VM is very good with the only noticeable slowdown having to do with disk access. I primarily use XP for the following programs:

  • Microsoft Office. While OpenOffice is a great program it doesn't have 100% fidelity when modifying documents in the MS Office format. Since I work in a client facing position I can't afford to have problems in documents I pass around. I tend to use OpenOffice for reading documents but if something needs editing I'll use MS Office.
  • Microsoft Visio. I use Visio all the time for diagramming various things such as network topologies, class diagrams, sequence diagrams, etc and I've have not found a good equivalent in Linux. There is a program called Dia but the user interface is just awful and it won't read and modify Visio files.
  • Netmeeting. Many clients will use Netmeeting for ad-hoc screen sharing and I'll need to connect to a host machine to view their screen. For hosting meetings I put together a Netmeeting equivalent using VNC and Flashlight VNC Viewer which I blogged about previously.
  • Internet Explorer. Sometimes I need to deal with corporate or client web applications that only work with IE. Fortunately these instances are quite rare and I expect the need for IE to diminish even more over time.

Having to use Windows in a VM highlights one of the weaknesses of Linux in a corporate environment, for better or worse the world around you is Windows based and you have to be able to inter-operate in that environment. Having said that, the Linux applications are getting better at this and knowing the complexity of the Office file formats I was really impressed with how well OpenOffice handled them. I'm optimistic that things will continue to get better with the noteable exception of Visio, there doesn't seem to be anything happening on that front in the Linux community.

As an aside I am fortunate that in my workplace there is support for Linux and we do not use Outlook or Exchange which could add another wrinkle to using an alternative operating system.

So in summary I have been very happy with switching to Linux and would have a hard time switching back to Windows. I feel I am much more productive in a Linux environment and generally prefer the way things work in Linux versus Windows. Overall for Java developers I would strongly recommend considering Linux.

Posted by Gerald Nunn at 12:21 PM | Categories: Java, Linux | Permalink |


Rules for Working with Exceptions

Monday, August 04, 2008

Since I work on the consulting side of Oracle I tend to see a lot of code from clients and it surprises me how often I still see developers making basic mistakes when working with exceptions, both when throwing them and when consuming them. At the risk of beating a dead horse, since this topic has been covered to death, here are some basic rules I try to live by when working with exceptions.

Rule #1. If you catch an exception and wrap it in a new thrown exception, make sure to chain the exception by including it in the constructor of the newly thrown exception. For example:

try {
blah..blah..blah
} catch (IOException e) {
   throw new MyApplicationRuntimeException(e);
}

Rule #2. Include meaningful information in the exception, specifically include whatever information is necessary in order to track down the issue if someone needs to look into it further. Nobody likes dealing with exceptions that have something stupid like "Unexpected error" set as the message. As a positive example, if you're writing code for a financial application and an account creation operation fails, include the account number along with other relevant information in the exception that would enable support or operations staff to diagnose the issue. This additional information can be wrapped in fields of a custom exception class or simply included in the exception message.

Rule #3. Log exceptions where they are handled not where they are thrown. I'm sure we have all seen examples of applications where the developers log the same exception over and over again as it traverses up the stack. Applications should only log an exception once and the easiest and most practical way to enforce this is to only log the exception where it is handled. In other words, if your code simply catches the exception and rethrows it as a wrapped exception then do not log it, rely on the code above you to log the exception properly.

Rule #4. In general, prefer unchecked exceptions except in cases where there is a reasonable chance the receiver of the exception can do something meaningful in response, in these cases use checked exceptions. There has been a lot of debate over the usage of checked vesus unchecked exceptions over the years, I tend to fall somewhat in the middle of the debate in that I feel both types are useful. When throwing an exception, the key to knowing which type to throw is to ask youself "Can someone do something useful in response to this exception?". If the answer is yes, then use a checked exception. If the answer is no or you are in doubt then use an unchecked exception. In general the vast majority of thrown exceptions in an application should be unchecked.

Ruke #5. Always document the use of unchecked exceptions in javadoc through the use of the @throws clause.

Posted by Gerald Nunn at 7:29 PM | Categories: Java | Permalink |


What Happened to Gel?

Tuesday, June 24, 2008

A question that comes up from time to time is why I do not keep working on Gel or open source it. For those not familiar with Gel, it is a free Java IDE that I wrote a few years back. Unlike Eclipse or NetBeans, Gel was a native Windows application written in Delphi and thus had a low memory footprint and very good performance. You can find more information about Gel on the product pages.

Gel had a decent set of features for a Java IDE at the time including support for code completion and javadoc popups. As a result it gained a small but loyal following and it is from them that I usually get this question. Like most things in life the answer is somewhat complex and in fact there is not a single answer, here are some points addressing why I decided to stop work on Gel:

  • The competition got better. Not only were Eclipse and NetBeans constantly adding new features, the performance of the Java based IDEs increased greatly due to better performing JVMs and increasing hardware capabilities. As a result Gel was ending up with less features and not much better performance then other available IDE environments.
  • The Eclipse platform became the de-facto standard. When I started working on Gel the Java IDE market was highly fragmented and I felt that carving out a small niche in that market was quite feasible. Unfortunately as time progressed it became quite clear the Eclipse was dominating the market reducing the niche I was in and thus the merit of continuing to work on Gel. While Gel was free and I was not deriving an income from it, I had no interest in working on something that was only being used by a small group of people. As most readers probably know, I’m not the only one that was affected by the domination of Eclipse, witness the cratering of Borland’s JBuilder product.
  • I took a job in 2003 with a company (BEA) that already had an IDE (Workshop) and my day to day job involved using that IDE. Prior to working for BEA my day to day development tasks used Gel, however with BEA I had to use the Workshop IDE in order to perform my job. Frankly I lost a lot of my motivation to devote my personal time to working on Gel because of this, one of the things that drove me to improve Gel was that it improved my own productivity when building Java products. Additionally I was also concerned about the optics of working on something that might be viewed as competitive to Workshop.
  • Finally I had some personal reasons as well. I have a young son and I am finding as he gets older he puts more demand on my personal time. When he was three he would be in bed by 6:30 or 7 pm at the latest. Now that he is eight he doesn’t go to sleep until 9pm or so which really puts a damper on the time I have available for personal projects. In addition to the family issues, I have some health issues as well with diabetes and while I’m not keeling over or anything it does mean I don’t have the same energy level I used to have in terms of working late nights. It also means more of my personal time is being spent on working out and with other health related activities then doing development.

So those are the reasons for why Gel is not being actively developed anymore. The next question is why not open source it or publish the source code so someone else can carry on with it. Unfortunately Gel uses a number of commercial components that would need to be replaced before it could be open sourced. Additionally commercial icons, from Glyfx, are being used so I cannot even publish the source code without removing those first.

I have offered to work with interested individuals to make Gel open source and have sent the source code to about ten folks over the years since I stopped development. Unfortunately none of those individuals carried on with the project after that. With the fact that the usage of Delphi is dwindling I suspect the odds of finding someone with both Delphi and Java experience who wants to carry things forward is slim to none.

Gel was a fun project while it lasted but as the expression goes “All good things must end” and Gel is no exception. I will continue to leave the product pages up for those interested in checking out what was but there will be no further development on Gel.

Posted by Gerald Nunn at 10:17 AM | Categories: Java | Permalink |


Using Maven and CVS on Windows

Monday, March 17, 2008

I am currently using Maven with CVS on a Microsoft Windows environment and had a minor issue with the Maven changlog plugin. This plugin builds a report from your CVS, or other SCM, repository that displays a list of changes made in the repository.

The issue I had was that this plugin ran fine on the Unix build box but not on my local development station that was running Windows. While not a pressing issue, it was annoying because I could not run the mvn site command locally to test any site changes out. Every time I ran the command I would get an exception about no credential being found. I had run the cvs login command previously but the plugin stubbornly refused to work even though using CVS directly at the command line worked fine. Unfortunately the client does not allow an anonymous user so the only way to get this working is to authenticate successfully.

Turns out the issue is that on Windows I was using the cvsnt binaries and there is one significant difference between CVSNT and CVS with respect to cvs login. Under CVS, when you run the cvs login command, it generates a .cvspass file that is placed in your user directory. The CVSNT binaries though place the credential in the registry. The Maven SCM plugins work with CVS directly and do not use binaries so it expects the standard CVS behavior of using the .cvspass file.

The Maven 1.x changelog plugin did have a way to generate this .cvspass file but this goal does not exist in 2.x. Therefore to generate this file I simply created a quick and dirty ANT build.xml that runs the cvspass task. Here is the build file I created:

<project name="cvspass" default="cvspass">
  <target name="cvspass">
    <cvspass cvsroot=":pserver:${username}@x.x.x.x/apps/cvs/cvsroot"
      password="${password}"
    />
  </target>
</project>

The username and password are picked up from the command line when this task is run. Being lazy, I simply run a setDomainEnv.cmd in a WebLogic domain I have lying around to initialize ANT. Afterwards, to run the ANT task simply execute the following at a command line:

ant cvspass -Dusername=xxxxx -Dpassword=xxxxx

With the .cvspass in place the mvn site command now works fine in all locations.

Posted by Gerald Nunn at 4:01 PM | Categories: Java | Permalink |


Maven 2 and Checkstyle

Wednesday, May 23, 2007

I recently wrote an article about integrating Maven 2 with WebLogic Portal and I found working with Maven an interesting experience. One excellent feature of Maven 2 that I am extensively using is the ability to generate a web site for the project automatically. This web site can include a variety of generated reports including project information and documentation, the results of your unit tests, javadoc and more.

One of the available reports in Maven is a Checkstyle report, I wanted to leverage it in order to ensure compliance with the organization's coding standards. If you are not familiar with Checkstyle, it parses your source code and provides a report with regards to how compliant the code is with a given convention. Additional information on Checkstyle can be found at http://checkstyle.sourceforge.net.

Checkstyle ships with a few default conventions including the Sun coding standards, however most organizations customize this and create their own configuration. The question arises though as to how to centralize this configuration so that it does not need to be manually configured when a project build is done.

Fortunately, this issue is easily addressed using the built-in dependency mechanism in Maven. Essentially we simply bundle the Checkstyle xml configuration file into a JAR and then install this into a Maven repository, typically this will be an organization's internal intranet repository. When the project site is built, this configuration is automatically fetched from the repository and applied when needed.

Configuring this is straightforward, first in the project pom.xml we define the dependency on the checkstyle configuration JAR as an extension dependency, this can be done as follows:


<build>
    <extensions>
        <extension>
            <groupId>com.bea.ps</groupId>
            <artifactId>checkstyle-config</artifactId>
            <version>1.0.0</version>
        </extension>
    </extensions>
</build>

Next we reference the configuration file in the Checkstyle plug-in configuration in the reporting section. Note that the Checkstyle plugin will search the URL classpath for the resource before trying the file system, this is why storing the configuration file in a JAR works. The configLocation referenced below is where checks.xml is located on the classpath in the checkstyle-config.jar referenced above.


<reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <configuration>
              <configLocation>config/checks.xml</configLocation>
            </configuration>
        </plugin>
    </plugins>
</reporting>

That should be it, now the configuration can be centrally managed and controlled and projects can get the latest version simply by updating the version of the artifact in the extension section.

Posted by Gerald Nunn at 4:02 PM | Categories: Java | Permalink |