The Ongoing Toplink Saga

Another thing I hate about Toplink. The mapping editor support within JDeveloper is not compatible with the standalone Mapping Workbench. They are built using different offline DB and Java class definitions.

Two tools built by Oracle. Both do the same thing as far as Toplink is concerned. They configure a datasource for Toplink interaction. Yet they use different foundation classes and output configuration files that are incompatible with one another? WTF? Not only that, but they aren’t even smart enough to recognize when this occurs. So when you open a file in one that you created in the other you just get this:

oracle.toplink.workbench.framework.OpenException: java.lang.NullPointerException
	at oracle.toplink.workbench.scplugin.SCPlugin.open(SCPlugin.java:113)
	at oracle.toplink.workbench.framework.internal.FrameworkApplication.open(FrameworkApplication.java:689)
	at oracle.toplink.workbench.framework.internal.FrameworkNodeManager.openCallback(FrameworkNodeManager.java:341)
	at oracle.toplink.workbench.framework.internal.RunnableProjectLoader.run2(RunnableProjectLoader.java:76)
	at oracle.toplink.workbench.framework.internal.RunnableProjectLoader.run(RunnableProjectLoader.java:63)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
	at oracle.toplink.tools.sessionconfiguration.DTD2SessionConfigLoader.load(DTD2SessionConfigLoader.java:70)
	at oracle.toplink.tools.sessionconfiguration.XMLSessionConfigLoader.loadConfigsForMappingWorkbench(XMLSessionConfigLoader.java:146)
	at oracle.toplink.tools.sessionmanagement.SessionManager.getInternalMWConfigObjects(SessionManager.java:149)
	at oracle.toplink.workbench.scplugin.model.adapter.RootSCAdapter.load(RootSCAdapter.java:110)
	at oracle.toplink.workbench.scplugin.model.adapter.RootSCAdapter.(RootSCAdapter.java:69)
	at oracle.toplink.workbench.scplugin.model.adapter.TopLinkSessionsAdapter.(TopLinkSessionsAdapter.java:56)
	at oracle.toplink.workbench.scplugin.SCPlugin.open(SCPlugin.java:110)
	... 5 more

Way to go Oracle. Thanks for making your tools developer friendly.

So I’m off to download and install the 441MB JDeveloper package instead of the 28MB Toplink Workbench. Later.

Disappointed with Toplink+Tomcat Combo

I’m working on migrating an application from Weblogic 8 to Tomcat 6. The strict J2EE portions of the migration were cake. Weblogic has some conventions for storing classes and other resources shared among applications deployed to a server. Reverting these conventions to use something simpler and compatible with Tomcat (i.e. common/lib) was easy. Just about everything else was just a matter of getting my projects set up in Eclipse WebTools. I use MyEclipse for Kuali. So it took me a little bit of digging to figure out how to do everything in WebTools. But, all in all an easy process.

Then it came time to configure Toplink. What a nightmare. The docs are years old. And the docs don’t even cover Tomcat. They only cover OC4J, WebLogic, WebSphere. Not surprised by that, just disappointed given the popularity of Tomcat. The configuration files used by Toplink (sessions.xml and project.xml files) need reconfiguring. And the only (documented) way to reconfigure them is to use Toplink Workbench, which I don’t really feel like installing and using (the last thing I need right now is to add something else to the mix).

I searched the OTN forums for help on this. But the only things really mentioned there refer to JPA implementations, one of which this project doesn’t happen to be.

And my least favorite part about this is the exception messages I get from Toplink. They’re completely unhelpful. Here’s an example:
This exception indicates that there’s an error in the username/password combination:

Exception [TOPLINK-4002] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.DatabaseException
Exception Description: java.sql.SQLException: invalid arguments in call
Internal Exception: java.sql.SQLException: invalid arguments in call
Error Code: 17433

How intuitive is that!? And the best part is that the username/password combination is in both the project.xml and the sessions.xml. So I have to test 4+ combinations to figure out which one is wrong. *sigh*

So, overall I’m not very pleased with Toplink. I’ve used it in the past and thought it was OK. But compared to the relative simplicity of tweaking this sort of thing in Kuali, this is a real pain in the butt.

I’m considering recommending migrating from Toplink to JPA/Hibernate. Kuali’s headed that way. That might be overkill. I’m probably missing something simple. Without a good user community and any kind of helpful documentation it’s going to be a task getting on track.

So how about it Oracle? How about a screencast showing a Tomcat 6+Toplink configuration eh? If/when I figure this out I’ll have to put one together.

String Permutations

The Problem

Write a function to print all of the permutations of a string.

The Solution

See: StringUtil.permute(String)

AtoI

The Problem

Write a function that takes in a string parameter and checks to see whether or not it is an integer, and if it is then return the integer value.

The Solution

See: StringUtil.atoi(String)

Quicksort

The Problem

How would you write quicksort?

The Solution

See: RecursiveQuickSort.java and IterativeQuickSort.java

All Files Recursively

The Problem

Implement an algorithm to print out all files below a given root node.

The Solution

See: FileProcessorRecursive.java

Neck Deep in Performance Analysis

I’ve been embracing my recent assignment to performance test Kuali Financials Release 2.0. It’s been a very interesting exercise to work through such a large system looking for 100 milliseconds here and there that can be shaved off.

I’ve been using the YourKit profiler mostly to inspect call trees and SQL queries. I’ve been very happy with the performance of this release of Kuali. The functionality is vastly improved over Release 1.0. The internals are much more robust, thanks in no small measure to the efforts of the Kuali Rice team. The Spring-based service oriented architecture which is used to weave the everything together is greatly enhanced from version 1.0.

I’m very pleased to be a part of the Kuali organization. And I’m very happy with the work we’ve accomplished. I have very high hopes for the future of Kuali. And I’m very excited about the upcoming 2.0 release.

The Value of Code Clarity

Programming is a “read-mostly” endeavor. Source code should easy to read. Source code should emphasize code that “does stuff”, not “busy work” code or “code noise”.

Get/setters are “busy work”. They’re frequently over-used for the sake of adherence to the Java beans convention.

I recently spoke with Andrew Myers, a Cornell professor whos specialty is programming languages (among other things). I spoke with him about writing a small bit of syntactic sugar for Java to allow getters and setters to be generated automatically at compile time for class attributes for which no getter or setter existed. His response was insightful.

I typically need getters and setters to access private class attributes. Professor Myers basically told me that it sounded like I wasn’t properly designing my classes. Instead of declaring private attributes and allowing access to these attributes via get/set methods, I should be just declaring the attributes with the appropriate scope. This seems like a perfectly obvious answer. So why didn’t I do that in the first place?

I use the Spring Framework a lot. Spring provides aspect-enabled dependency injection. This is a great facility to have. It allows for code that can be simply reconfigured via xml descriptors. The alternative would be to require that the code itself be modified and recompiled to produce a new executable. Overall this isn’t a very flexible option. So Spring provides a great deal of value in this regard.

The downside to the way Spring does dependency injection is that it requires public setter methods for each attribute that can be injected. This is an easy enough thing to do. But, it encourages a very sloppy paradigm of having setters in order to provide the hook that Spring needs.

For Java, Spring does a good job. The Java language, being compiled and statically typed just requires more verbosity than a language like Ruby.

I personally find the Ruby syntax for declaring class attributes to be much less verbose and much more clear.

Writing Code That Isn’t Clever

This is one of the hardest things for me to do. I think it’s probably hard for many, many programmers and is the root of over-engineering.

It’s interesting and engaging to write code that does something interesting. But being able to just simply switch off that jones for all things clever in order to write code that does things which aren’t very clever, but are nonetheless absolutely necessary, is something I find difficult at times. When I’m unable to do it I find I make things more complicated than they should be. I find myself down a rabbit hole, unable to clearly see the next step. This is because there isn’t another step to be taken in the forward direction. It’s time to turn around, rethink the problem I’m trying to solve, and simplify the code in order to solve the problem quickly and with clarity.

I’m not big into writing programmer manifestos, sets of commandments or treatises on how to be a great programmer. But this is one observation that I think can save a lot of programmers a lot of time.

Top Ten Developer No-Nos

10. Not having fun. If you’re not enjoying your work, you’ll never be great at it. You can be mediocre. But why bother.
9. Thinking you’re the first to think of it. Whatever it is, someone thought of it long ago. It’s just as much about timing as it is about having good ideas. Keep your eyes and ears open until the time is right.
8. Thinking that your tools of choice are better than whatever else is out there. Whether it’s what language you prefer, what operating system you like or what editor you use, get down to brass tacks and make the tools work for YOU.
7. Thinking you won’t burn out. There are only so many 12-20 hour days that you can take. You won’t realize it until you’ve experienced it. But that doesn’t make it any less true. Work at a pace you can sustain. The occasional push is OK.
6. Thinking you can do everything alone. Even if you can, you won’t want to forever. Let others share the fun.
5. Thinking you’re going to get it right the first time. You won’t. Plan to throw the first one away.
4. Turning everything into a framework. Frameworks get complicated in the long run and don’t save as much time as you thought they would.
3. Writing something from scratch instead of taking the time to learn how to use the best tool on the market. Even though you think it’s a great idea now to write your own, your idea too will have shortcomings that will be just as much a pain to your client. Save everyone some time and just sit down and rtfm.
2. Thinking you know better than your client. They still sign your checks.
1. Over-engineering. Some problems just aren’t that complicated.