I ran into this really strange error the other day while using Eclipse. I had been creating some JUnit tests, and everything was going just fine. Then I tried to create another one, and I saw the dialog below with the error message, Superclass does not implement the ‘junit.framework.Test’ interface.
The JUnit JAR file was in my classpath, so I was befuddled for a minute or two. After searching around I discovered that I had accidentally deleted the JRE System Library from my project Java Build Path. After I restored that, everything worked fine.
Strange, but absurdly true. If it were only one of the two delays, I’d skip it, but both is just too odd to pass up.
I work for a national company. I made a request to change my direct deposit setup a while back. I was told by our local branch that headquarters had received the request and would process it. My next deposit was barely half of my regular paycheck and I had no idea what happened. It turns out that the payroll processing is done in Boston, and my request happened to be processed around the time of the Democratic National Convention, where traffic was so bad that people were either not going to work, or leaving early, or whatever. So the second half of my paycheck was delayed a week because the Democrats had a party. If it weren’t so funny I’d probably be a bit annoyed.
Now, I can understand one political event having outrageously insane odds of actually affecting my work life, but two events is just plain weird. Today I discovered that our current project may be delayed becuase of the upcoming US presidential election. We’re sending a mailing out to our customers, giving them a yearly statement, and the two week window that it’s been planned for probably won’t work for the mailing vendor — they’ll be sending out 6 million political mailings for both candidates, and do we really want our clients’ statements to get lost in that mess? No.
Whatever the outcome, I’m ready for the political hoopla to end. I need to get my work done, something they’re not likely to understand.
I recently wrote about standardizing Eclipse plugins across your team by using a shared Eclipse product extension. We had to do a few things this morning that we hadn’t yet tried since we set this up about a week and a half ago, and it worked out great.
We upgraded our common Subclipse plugin from 0.9.13 to 0.9.16. This turned out to be a really bad idea (not to mention the maintainters are losing my respect), so we backed it out and reverted to 0.9.13. The only thing we had to do was re-enable that plugin on some developers’ Manage Configuration screen (watch out — disabled plugins aren’t shown by default, but you just need to click a button on the toolbar to make them show up again).
We also promoted a plugin from my personal plugin area up to the unstable area. Within 2 or 3 minutes, the move was complete and everyone had the new plugin that wanted to use it. Piece of cake.
We even had a guy move to Eclipse 3.1 M1 last week by simply copying the links folder to his new Eclipse directory as discussed in my other entry. It worked like a charm, and all he was up on 3.1.
So continued experience with this plugin setup seems to be quite favorable. Let me know how you’ve shared or standardized Eclipse plugins in your group.
We’ve got several developers (more than 5) at work using Eclipse, and some are pretty new at it. We gave each a list of the plugins that we’d like them to install, and some that are optional. Some people put them on, and some didn’t have time to read through and understand how to install them all in addition to understanding what they’re for and how to use them. To make that easier, we wanted to install all the plugins at once for them, and also make it a really simple to upgrade the main Eclipse installation.
We took a tip from the MyEclipse folks (no, we don’t use it), and setup a few directories as Externally Linked Features or Product Extension. So we setup a few directories like this on a shared drive:
stable-plugins/
eclipse/
features/
first.feature_1.0.0/
next.feature_1.0.0/
plugins/
first.feature_1.0.0/
next.feature_1.0.0/
first.plugin_1.0.0/
unstable-plugins/
eclipse/
features/
trial.feature_1.0.0/
plugins/
trial.feature_1.0.0/
And then on each developer’s machine, we create a place for them to put their own individual plugins.
user-plugins/
eclipse/
features/
plugins/
user.plugin_1.0.0/
Finally, there’s just a few files and one directory to create in the main Eclipse installation on the developer’s machine.
eclipse/
[...]
links/
stable.link
unstable.link
user.link
[...]
Each .link file contains the path to the directory above. For example, the stable.link file looks like this:
path=C:/path/to/stable-plugins
Notice that it’s the path to the stable-plugins directory, and not to stable/eclipse. Eclipse expects to find the eclipse directory under the path pointed to in each .link file.
When we go to install a new plugin, we just make sure to choose which installation the plugin should go under. Remember that if you’re installing more than one plugin at a time, each one requires you to select the installation directory individually.
Select the plugin location for the first plugin…
…but the second plugin location has to be selected as well.
We can allow developers the freedom to disable any of the provided plugins, or even disable all the plugins for a particular extension location (like unstable-plugins). Simply go to Help > Software Updates > Manage Configuration. Click on the extension location, and then click Disable on the right.
We need to do one more thing before we can have a seamless upgrade of Eclipse from one version to the next: the workspace must not be in the Eclipse directory. We’ve setup our code similar to this:
work\
company-repository\
.metadata\
project1\
project2\
other-code\
.metadata\
oss-project\
We choose a standard place for the workspace to exist. Our source code repository ignores the .metadata directory, and all of our projects are located directly under the chosen workspace (C:\work\company-repository). This makes importing projects into the workspace easy, it keeps all of our code together, and it allows us to have a separate workspace for other code, such as open source software.
Now we’ve got a really great Eclipse configuration. We can share plugins amongst all of our developers in a standard way that ensures everyone has the right versions and such. Developers can choose to ignore unstable plugins, and they can add any plugins of their own. On top of that, there’s only one directory added to the standard Eclipse installation directory — the links directory. That means that it’s easy to upgrade to 3.1 or any milestone build. All you need to do is drop the links directory into the new installation, and you’re ready to go. When you open your new version of Eclipse, you’ll simply choose your existing workspace and all of your projects will appear, and your plugins will be installed (assuming they work with the new version).
Anyone who tried to keep up with the moving milestones of 3.0 can appreciate how easy this configuration is to upgrade frequently, and if you’re looking for a way to standardize the Eclipse plugins used in a corporate environment this just might work for you. If you’ve got improvements to this setup, I’d really love to hear them!
I’m trying out the Spring JMS support in the 1.1 RC2 release. So far I’m pretty impressed, but that’s something I’ll delve into another time. While I was running my tests from the Eclipse JUnit test runner, I got the following exception:
org.springframework.jms.UncategorizedJmsException:
Uncategorized exception occured during JMS processing; nested exception is javax.jms.JMSException: ctor
javax.jms.JMSException: ctor
at com.evermind.server.jms.JMSUtils.makeJMSException(JMSUtils.java:1829)
at com.evermind.server.jms.JMSUtils.toJMSException(JMSUtils.java:1845)
at com.evermind.server.jms.EvermindObjectMessage.(EvermindObjectMessage.java:64)
at com.evermind.server.jms.EvermindSession.makeMessage(EvermindSession.java:1405)
at com.evermind.server.jms.EvermindSession.createObjectMessage(EvermindSession.java:276)
at com.example.myproject.JmsSender$1.createMessage(JmsSender.java:59)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:566)
at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:547)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:512)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:524)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:545)
[...]
The original message (not from Spring) ctor was incredibly vague, so I decided to follow a hunch. I applied the serialization testing advice from one of my recent posts to this new project, et voilà, my error was immediately uncovered. One of the two items in my Message object was not Serializable. A quick update and I was happily sending JMS messages using the Spring template.
I had never seen the Greek spelling of Athens before the Opening Ceremony for the 2004 Summer Olympic Games. I thought it was quite cool. There’s not much that Americans encounter on a daily basis that gives us a sense of the truly international community we live in. Open source projects do that for me. So did living in a few non-English speaking countries in Europe (that’s another reason I like the Olympics — I get to hear French, and not just read it). I think experiences that remind us of the world community are perhaps too undervalued in America. Respecting those moments and pondering their significance could truly change the international “social skills” of an entire nation, and might even help change the world. Thanks Αθήνα. You’ve done well.
Have you ever encounterd a NotSerializableException in staging, or worse, production? Perhaps you’ve run your application for months or years, but then you decided to cluster your web tier and you realize that your container is actually trying to write out your HttpSessions to some place hither or yon. Perhaps you’re testing after adding that last little feature, only to eventually realize that your brilliant new feature inserts something into the session that prevents serialization.
I’ve encountered such unpleasent experience as those in past projects. Today I wanted to make sure that my Message for a JMS queue was serializable. More than that, I wanted to make sure that the attribute that’s a Typesafe Enum class I’ve used (yeah, I know they’ve added enums in 1.5/5.0) properly deserializes — it shouldn’t create a new object. Here’s the test I used on the enum:
public void testSerialize() throws Exception {
ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bout);
out.writeObject(MyEnum.ENUM_CHOICE);
out.flush();
byte[] bytes = bout.toByteArray();
ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bytes));
MyEnum enum = (MyEnum) in.readObject();
assertTrue("Deserialized constant should be exactly the same object as the constant itself.", enum == MyEnum.ENUM_CHOICE);
}
For more nuances of writing Typesafe Enums, why they’re really needed, and how to use them well, you should really checkout Item 21 of Josh’s book. In the meantime, think about testing your serialization assumptions. Got any suggestions for other serialization areas to watch?
I just finished my first real code review cycle using Jupiter, and I’m quite happy, to say the least. It’s quickly becoming something I don’t want to be without on any future project. Let me back up.
Everyone learns in Software Engineering 101 that code reviews are an excellent way to remove defects from your program. Many people are also introduced to the various types of software reviews, ranging from “Hey, can you look at this?” to a formalized code inspection. If you look at either Steve McConnell’s Code Complete or Shari Pfleeger’s Software Engineering, you’ll find plenty of statistics on how many bizillion defects you can remove by doing code reviews and inspections.
The problem is, that the more formal-style inspections tend to have the biggest positive impact upon the code quality. But nobody has a great way of being formal about it. You don’t really want to have Author, Scribe, and Reviewer worprocessing templates that you print out and write on. That’s the technology that the experts suggest. That’s a pretty fair waste of time, and you don’t have that luxury on a faster moving small business project.
Enter Jupiter. It’s an excellent plugin for the Eclipse IDE that provides the more formal-style advantages with a very non-intrusive UI that allows you to conduct reviews that fit your company style. You get all of the record keeping with almost zero hassle.
The tools supports three simple steps, which you can do in any order.
- Review code by yourself
- Review code as a team
- Follow up on identified defects
There’s really not a lot to this. You ask each of your team members to review your code on their own. They note defects and questions using Jupiter. Jupiter creates one XML file per person (per review session), and they commit that to your version control. Then you get together around one computer, pull the latest files from version control, and talk through the issues everyone found. You can double click on each issue to jump to the code where the suspected defect is. As you talk, you simply note down if the group thinks you should address it now, later, or never (among other choices). Once you finish, commit the files again, and return to your own computer. Pull down the files you updated during your team meeting, and then act on only those that the team thought you should change.
The critical elements are recorded. You can verify that issues were followed up on, and Jupiter is so smooth you never actually notice it during the process. During our experience, the group meeting was focused 100% on code and 15 seconds on the tool. It just worked. So well that no one even brought it up after their first experience. They just used it and we talked about the code.
Now that’s a well-written tool.
Update: Jon Udell is talking about many of the same issues I raise here, though at a bit more abstract level, and using other tools. To my knowledge, everything he describes using del.icio.us is possible using Furl as well.
Have you ever found an interesting article on the Internet, only to forget where it was when you want to go back to it three days later? Ever gone digging for a quote from an article about Struts or Tapestry to show a friend, but can’t where it is amongst all the stuff that you’ve read? I’m sure you scan over tons of stuff on the Internet, and I’ve found a great way to keep track of it without cluttering up your desktop, email, or browser bookmarks.
Check out furl.net? It’s way more than an online bookmarks site. From the About Furl page:
The web’s usefulness grows each day. More great content is available each week. More transactions are executed as users buy more goods online. Unfortunately the web is also very large and dynamic. How many times have you gone back trying to find an article you read only days before but not finding it? How many times have you tried in vain to recall something you read months ago?
Furl is dedicated to making it easy for users to archive, recall, share, and discover useful information on the Web. With a couple clicks, Furl will archive any page. You can easily find it by browsing your personal directory of web pages or by using the full text search that only searches pages you’ve archived. It’s like having your own Google.
Not just limited to archiving pages, Furl also gives you the best ways to share content. Furl makes it easy for your friends to decide which categories of links they are interested in and receive a daily “newsletter” of links. Furl also generates RSS feeds for your links and makes it simple for you to integrate this content into an existing website.
The searching feature is just awesome. Not only can you search any keywords you typed in when you clicked Furl It!, but it actually searches the full text contents of the page you bookmarked! But what if that page disappears? You have your own private copy at Furl (you can view it, but others can’t).
I never thought I’d use the Share freature of Furl, but I’ve got a friend’s Furl RSS feed in my aggregator. I watch what he bookmarks since we work together, and have a similar direction we’re looking on Java and some of the other tools. I find most of what he links to interesting, and some of it surprising. It’s hard to describe until you experience it yourself. Watch a friend’s links, or follow mine if you’d like.
So sign up, put the Furl It! scriptlet on the links bar of your favorite browser, and Furl It! whenever you find a page that’s kinda cool. You’ll find stuff more often, and you can rest easy knowing that your internet research time won’t need to be repeated from scratch 3 weeks from now. Get your friends to Furl It!, and you’ll find half your research is already done before it’s needed! Leave a comment with a link to your Furl site and RSS feed (check out Sharing Your Archive once you’ve registered) so others can watch your links. Maybe we’ll eliminate the need to do any research. 
Furl It!
I mentioned in one of my latest entries that I’ve done a bunch of fixed point stuff in Java lately. I work for a company that does many financial calculations, and much of the legacy code is in other languages. There’s always been a problem with rounding and consistency in these calculations. They’ve all been addressed, but there’s always pain to get it through testing when a change to calculation code arises.
Martin Fowler has discussed in several venues the idea of having a class that represents Money. This ensures semantic consistency, rounding precision, and especially it provides an allocate method to distribute Money among various individuals or accounts without losing any fractions. Everything is accounted for correctly.
We not only deal with Money, but other values which we must treat as always having exactly n number of decimals. Martin Fowler’s examples have often included code, and this guy wrote a Money class in the same spirit. But I didn’t want to rely on my own fixed point caculations to do the job right (you know, losing precision, increasing scale based on the arithmetic function performed, and all that stuff that’s real easy to ignore — even though you know it’s gonna come back and bite). I poked around and found out that IBM has done a great job of it already. They submitted a JSR long ago, and you can see that their work has been incorporated into J2SE 1.5 (or 5.0 — silly Sun marketing droids).
If you need to do reliable fixed point or decimal floating point calculations in Java, and you aren’t moving to J2SE 5.0 immediately, check out the small decimal.jar in this ZIP file (there’s even decimal1.jar for the 0.004% of Java users stuck on JDK 1.1) from IBM. It just may save the day.
My open source work over the next little while is going to involve providing better integration between Hackystat and Maven. I’m excited, since the two tools seem to naturally fit together. Hackystat collects and analyzes data over time. Maven provides an extensible build framework and really good HTML reports of certain build metrics. Bringing the best of the two worlds together will be quite interesting to watch.
My wife has been doing some work for a friend, which has involved some mailing lists and merging. This friend isn’t very computer savvy, and has obtained these lists from other people lacking in computer knowledge. We have received files in various formats, all with poor field design for this type of work, but tonight was the one that topped them all.
We received a disk with a file named something like mailing_list.dat. All attempts to open the file failed. Opening the file in Notepad showed that the file began with this information, including non-printable chars not listed here.
xŸ>"
ä è
€ IPM.Microsoft Mail.Note
When I got back from work I did some Google digging, and came up with a few potential sites, including one where Eudora claimed:
This TNEF information [winmail.dat] is unopenable and irrelevant outside of Outlook.
But I persisted, annoyed again at Microsoft’s snub of standards, this time causing my wife’s confused friend to be unable to open her list file.
Then I hit the jackpot. A post at Google Answers pointed out that while the file was an annoying side effect of the MS Outlook, it could be decoded using a shareware time-limited program available for free download.
I ran the program and out popped a Microsoft Excel spreadsheet, which I happily opened with OpenOffice.
Google really does have all the answers to the messes Microsoft creates.
