Entries Tagged: Java
The Trials of OpenOffice.Org
I’ve been a user of OpenOffice.Org pretty much since OOO first came out. Even when I was still occasionally using Windows, I was looking for alternatives to using Microsoft products. OpenOffice, to me, offered that alternative. It provided me with the basic functionality that I needed from a word processor, spreadsheet program, and presentation creator. I’m not a power user of the basic office products, so the lack of features that Microsoft Office provides has never been an issue for me.
Fast forward to a couple of days ago. I’ve been working on some articles that I’ve finally decided are good enough to publish to the interweb. I typically write them in OOO. I was looking into an easy way to convert them into HTML and noticed that OOO contains a feature to export a document in XHTML format. I thought that this feature could be pretty handy so I tried to use it. Bzzt! Try again. How foolish was I to attempt such a thing without first telling OOO what Java VM to use. Ouch! OOO depends upon Java for some of its functionality. So I went to the settings to tell it what VM to use. Surprisingly, after I navigated to my /opt directory, it figured out that I had 3 different JVMs installed: 1.4, 1.5, and 1.6. I figured that I might as well use the most recent one I’ve got, so I pointed it to 1.6. OOO gave me a message box that indicated that I’d need to shut down OOO and restart it in order for the setting to take effect. OK. No problem.
It shut down fine, but when I attempted to run it again I got a whole lot of nothing. Nothing? What? It just wouldn’t run. No error messages of any kind. That seemed a bit odd. So, I embarked on a journey to try and figure out how to unset the JVM setting. All I could find was a file that was autogenerated each time OOO was started. So, I asked Gentoo to uninstall OOO. Then I made sure that any OOO related directory was removed. Then I re-installed OOO. I typed in “oowriter” at a command prompt and was greeted with nothing but another prompt. No error, no messages, no OOO starting up. After another fruitless hour of searching and trying everything I could think of, I just gave up. This was going to cause a serious issue. I have Windows installed in a VMWare virtual machine if I absolutely have to use Windows, but I’d rather not deal with it.
I went with Plan B. Plan B was to let my computer spend the time to compile OOO from scratch. Fortunately, I was a bit smarter with my disk partitions on my laptop and actually put enough space in the /tmp partition to be able to perform large compilations. OOO notoriously uses up about 4GB of disk space and on my Core Duo 2 machine took about 3.5 hours to compile. I crossed my fingers and typed “oowriter” into a prompt after it finally finished compiling. Much to my surprise, OOO started right up! Back in business! But, I’ve learned my lesson. I won’t be telling OOO where my JVMs are. I can live without this hassle.
Filed in: Team Member Blog java, linux, openoffice
Shards
I was checking out the Hibernate website (http://www.hibernate.org) and saw something called Hibernate Shards. I thought it sounded interesting so I investigated further.
It seems that some engineers at Google started a project in their 20% time to add functionality to Hibernate to deal with sharding.
It’s an interesting idea. Shards is just Google-speak for horizontal data partitioning. Typical vertical data partitioning will group data rows together in the same table based on some kind of criteria. The theory being that by grouping the data together based upon what you’re searching for, the database will be more efficient when performing the search and returning the data.
Horizontal partitioning is similar except that the data is spread across multiple tables with the same layout.
Hibernate Shards is great in that it abstracts out behind the scenes the strategies for which tables to search when performing a query and which table to insert new data into based upon the strategy you’ve chosen. It will automatically union all the returned rows together if it needs to retrieve data from multiple shards (tables).
It’s an interesting concept. I wonder if we’ll see it in use more and more as a data partitioning scheme.
Filed in: Team Member Blog java
Code Analysis with JavaNCSS
One of the things that I’ve been getting into lately is the usage of various code analysis tools as part of a standard build. There are numerous tools that can be very helpful when used as part of a continuous integration process.
One of the most common static analysis tools is JavaNCSS. It’s a simple tool and it doesn’t do all that much, but I think that it can be beneficial to use.
You point JavaNCSS to your source files and it will output the number of NCSS (Non-Commenting Source Statements) per package, class, and function. Just for kicks, it also calculates the CCN (Cyclomatic Complexity Number) for each function and displays the number of Javadoc comments per package, class, and function. Some of this may seem a bit useless and even pointless, but I think that there’s value to all the information that it calculates.
Most people would look at the number of lines of code and say “whoop-dee-doo!”. Yeah, it is kind of hokey. “Look! I coded 1000 lines today! Bonus time!” Seriously, though. The number of lines of code probably makes more sense to track at the function and class level. If the number of lines of code for a function is large or has been increasing over time, there might be an opportunity to take another look at that code to determine if extra functionality is creeping into the function that shouldn’t be there. If the number of lines of code in a class seems large, then perhaps the class has functionality inside of it that would be better in a different class.
The CCN can be used similarly. The CCN (aka, the McCabe Metric, http://en.wikipedia.org/wiki/Cyclomatic_complexity) is a number that describes the complexity of the code. There’s a whole complex discussion about it on the Wikipedia entry, but basically it’s a measure of how much branching there is in the code. If the number is low, then the code is very straightforward and does not have many decision points. If the number is high, then there are a lot of decision points (if/then/else statements, loops, switch statements, etc.). Generally, if the number is high for a method it could possibly be a candidate for refactoring. Take a look at the method to see if the decision points can be compressed together, or if some of the branching is unnecessary, or if the method could be logically split up into other reusable methods. Many times, however, despite a large CCN there is a reason the method is written how it’s written and that’s ok.
Lastly, I actually like the Javadoc counter. Looking at the counts per function makes it really easy to spot which functions are lacking documentation.
JavaNCSS is a nice little tool to help out with some basic static code analysis. It can be found here: http://www.kclee.de/clemens/java/javancss/
Filed in: Team Member Blog java
Open Source Java
Sun announced earlier this week [announcement] that they would be open sourcing Java. Millions of Java programmers rejoiced.
What does Sun’s decision actually mean for the typical programmer? Probably not much.
Sun decided to release the JDK along with the Java compiler and the virtual machine under the GPL v2 license [GPL website]. What this means is that Sun grants a royalty free license to anybody to redistribute the pieces of the JDK along with the source code. Developers can also create new pieces of work based off the original code as long as they indicate the changes and the original license. This does not stop anyone from charging money, however. It is legitimate to charge for media distribution or warranty support.
What this may really do is kickstart more innovation with regards to the internals of the language implementation itself.
While in the past new JVMs have been created by third parties, Sun would expect those third parties to license the Java technology. Now, since all aspects of the JDK will be under the GPL, anyone will be able to create a new JVM implementation, a new compiler implementation, or even a brand new implementation of the language itself.
I expect the real benefit will come in the form of JVMs for operating systems other than the standard UNIX/Linux, Windows and MacOS. Hobbyists will be able to tweak things and redistribute them to others. Academia could use the source code as a teaching tool.
This announcement is also nice for various Linux distributions and individuals who don’t like to use products that are not licensed with one of the open source licenses like the GPL.
So, at the end of the day this doesn’t really mean much for a regular user, or a non-interested developer. For those who like royalty-free software and the ability to peek under the covers, this is a wonderful opportunity to have some fun.
Filed in: Team Member Blog java