Archive for the 'java' Category

Ruby for Java Programmers, Part IV

Published by ugo on February 8, 2006 in java and ruby-rails. 0 Comments

In the previous installments of this series, I did some experiments trying to make Java and Ruby coexist by using two bridges: rjb and YAJB. This time, I’m going to try to solve the same problem using JRuby.

JRuby is not simply a bridge, it is a “1.8.2 compatible Ruby interpreter written in 100% pure Java”. As it is written in Java and consequently runs on the JVM, it should provide a much better integration. At the very least, it allows you to use some typical Ruby idioms when traversing Java collection classes, or accessing bean properties by name:

require 'java'

include_class 'Fetcher'

feed = Fetcher.fetch(ARGV[0])

feed.entries.each do | entry |
  p "#{entry.publishedDate} #{entry.title}"
end

Compare that to the sample I posted here.

You should be aware of a couple of limitations, though:

  • JRuby is not a complete implementation of Ruby. Some things are missing that, for instance, won’t allow you to run Rails on JRuby just yet. However, the development team seems to be progressing nicely along this road and supporting Rails is one of their foremost objectives.
  • Ruby extensions written in C will not be loaded. This is probably never going to change. If you need a particular C extension, you should try to find an alternative in pure Ruby or Java.

Ruby for Java Programmers, Part III

Published by ugo on January 26, 2006 in java and ruby-rails. 0 Comments

Just tried to perform the same test I did in Part II using YAJB instead of rjb. Unfortunately, I wasn’t able to obtain any result, since even a simple program like:

require 'yajb/jbridge'
include JavaBridge
jimport "java.io.*"

fails with a java.lang.OutOfMemoryError. This is on OS X 10.4, YMMV.

Ruby for Java Programmers, Part II

Published by ugo on January 25, 2006 in java and ruby-rails. 6 Comments

Part I is here.

As promised, I will now try to invoke some more complex Java classes from Ruby code. Since I might need this for a real project and one of the things I find missing in Ruby is an RSS/Atom parser that offers the same features as Rome, I figured I might just try fetch and parse an RSS feed using Rome via Ruby.

Even something simple as fetching a single feed using Rome involves a handful of classes and methods. If all you need is getting at feed entries from your Ruby code, you’d be much better of if you encapsulate API calls in some higher-level class that is intended to be called from Ruby. This will avoid you the hassle of importing more than one class and calling overridden methods for which you’ll have to supply signatures and such trivia. This is just what I did in Fetcher.java:

import java.net.URL;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.fetcher.FeedFetcher;
import com.sun.syndication.fetcher.impl.FeedFetcherCache;
import com.sun.syndication.fetcher.impl.HashMapFeedInfoCache;
import com.sun.syndication.fetcher.impl.HttpURLFeedFetcher;

public class Fetcher {
	public static SyndFeed fetch(String url) throws Exception {
		URL feedUrl = new URL(url);
		FeedFetcherCache feedInfoCache = HashMapFeedInfoCache.getInstance();
		FeedFetcher fetcher = new HttpURLFeedFetcher(feedInfoCache);
		SyndFeed feed = fetcher.retrieveFeed(feedUrl);
		return feed;
	}
}

Calling this class from Ruby is straightforward enough:

require 'rjb'

Rjb::load('.:rome-0.7.jar:rome-fetcher-0.7.jar:jdom.jar:jdom.jar', [])

fetcher = Rjb::import('Fetcher')
feed = fetcher.fetch(ARGV[0])
p feed.getTitle
entries = feed.getEntries.iterator
while entries.hasNext do
    entry = entries.next
    p "#{entry.getPublishedDate.toString} #{entry.getTitle}"
end

Two things to note here. First, it would be great if the Ruby-Java bridge would pick up JavaBeans conventions and allow you to simply write entry.title instead of entry.getTitle.

Second, I will probably need to convert Java dates to Ruby Time objects by formatting as a string and then parsing it back. It would also be useful if the Ruby-Java bridge could provide more automatic type conversions, where such convertions are possible, besides simple strings.

Ruby for Java programmers, Part I

Published by ugo on January 23, 2006 in java and ruby-rails. 6 Comments

This is the first article in a series that I plan to write in order to describe my experiments with combining together Ruby and Java. The reason I’m doing this is that, as much as I find Ruby on Rails to be fun and agile and all-around great, still I haven’t grasped much of Ruby the language yet, so I sometimes find myself wanting to reuse some Java code (and there’s a helluva lot of it around, free for grabs) instead of thinking about a rewrite.

One of the things I’d really want to be able to do is call Java code from Ruby. There are some projects intended to provide a Ruby-to-Java bridge, even though none of them seems to be really mature. The ones I found mentioned more often seem to be RubyJavaBridge and YAJB.

Let’s start with the former. After downloading and unzipping the file, you should read the provided readme.txt file, as there don’t seem to be instructions on the website for actually performing the build. If you’re under OS X, make sure the JAVA_HOME environment variable is set (should be something like /Library/Java/Home, unless your setup is peculiar). Also, ignore everything about the LD_LIBRARY_PATH variable, again if you’re on OS X.

Then you can try configuring and compiling the sources with:

    ruby setup.rb config
    ruby setup.rb setup

On OS X, this will fail, as the off_t type is used but never declared. I assume it gets defined in one of the included C header files in Linux and Windows, but under OS X it’s to be found in <sys/types.h>, which is not included. You can fix it by adding the following statement:

#include <sys/types.h>

to file ext/rjb.h, around line 25 should be fine. After this, everything should compile and install fine just by following the instructions.

Next I did a series of tests with simple Java types to confirm that the JVM was loaded and that the basic functionality of the bridge was fine. In the coming days I plan to invoke some more complex library and report my findings in further installments of this series.

Amsterdam Java Meetup - 24 February

Published by ugo on January 18, 2006 in java. 1 Comment

Alef: “After the first successful Java Meetup in Amsterdam, held last November 11th, I’d like to promote all this to a quarterly event. That’s why you’ll have to block February 24th in your agenda coz’ from 6 o’clock on, there will be beers again in a place yet to be announced.”

As I am in Amsterdam now, and will probably be here most of the time between now and the end of February, it would be interesting to join. However, I’m wondering whether the official language of the meetup will be Dutch or English and, if the former is the case, whether my knowledge of Dutch can be brought up to the level required to follow a conversation about Java in slightly more than a month ;).

Update: I just noticed that the 24 is a Friday. Too bad, as even if I’ll probably be in Amsterdam that week, I’ll be taking a plane back home by Friday afternoon.

On Rails

Published by ugo on December 14, 2005 in java and ruby-rails. 1 Comment

On the trainNo, this post is not about Ruby on Rails (they just released version 1.0, by the way), but it’s half about rails, as in “railways”, and half about Ruby the language.

With respect to the former, I was finally able to book my railway trip to Rome, despite my previously reported problems. I enjoyed traveling by train much more than traveling by plane. It’s true that it takes more time, but when you compare having to wait in line at the check-in counter, at the security control, at the gate, at the plane door, then traveling for one hour in a crammed space and finally having to wait for your luggage, to sitting quite comfortably for four hours, at half the price, the choice is clear.

Ruby die-hards might comment that the experience of traveling by plane is akin to programming in Java, which brings us to the second half of this post. While traveling, I did a bit of Ruby programming, just for fun. One thing that struck me negatively about Ruby is learning that Ruby strings are made up of 8-bit bytes. Uh-oh, I smell trouble ahead. Indeed, I hit trouble as soon as I tried to parse (using Lucas Carlson’s SimpleRSS library) some RSS feeds that used different encodings (UTF-8 vs. ISO-8859-1, for example). If I were using Java and a Java XML parser, I’m pretty sure that the strings containing the text values extracted from the feed would have all been Unicode string and I would have had no problems mixing them or storing them in a UTF-8 encoded database.

I’m pretty sure this problem is mostly due to my ignorance of Ruby, but still I wonder whether using 8-bit characters in the era of globalization was a wise decision. I’d rather have Java’s 16-bit characters, if possible.

Update: Got it to work by determining the original encoding using open-uri’s charset method and iconv to convert between it and UTF-8. Suboptimal, but it works.

Say “Hello!” to the TSS crowd

Published by ugo on December 13, 2005 in java. 2 Comments

Spring FrameworkMy recent post on Spring 2.0 was featured on the front page of TheServerSide. This brought some nice traffic, but most people left immediately and nobody bothered to leave even a short comment. Probably those who felt like commenting did so on TheServerSide’s own forum.

Reading those comments, I’m amazed at the amount of ignorance that is on display there. Comparing Spring to Struts and turning the former down because it’s not “standard” doesn’t reflect to well on the poster’s knowledge or intelligence.

Anyway, what I want to tell the TSS crowd is that you should take my extreme assertion (”I seriously wonder why anyone would want to develop anything substantial in Java nowadays without using Spring.”) with a grain of salt. Can you say “hyperbole”?

What prompted me to write that sentence was not much my fondness of Spring’s features and architectural beauty, which is certainly there. I just wanted to express my admiration for Spring’s core team dedication to its users and to the quality of its product. Doing a major release that is 100% backward-compatible, to the point of being able to simply drop the new library in place of the old one and have everything still work perfectly, is not something that happens frequently, particularly in the Open Source world.

So, if you want to find a way to architect your J2EE applications in a simple, lightweight, flexible and testable way, have a look at Spring. You won’t probably use everything of it, but that’s just fine. And you’ll certainly find that the parts you end up using will make your life easier.

Hani bileblogs Basecamp

Published by ugo on December 12, 2005 in java and ruby-rails. 1 Comment

I’m surprised to see that David Heinemeier Hansson took offense at
the latest BileBlog:

This is awesome. In the sense of awesome meaning funny in a sad, tragic way where you feel sorry for the person.

It’s surprising that David fell for Hani’s prank, just like an ordinary Andy C. Oliver. Know what, David? Hani’s biles are the self-inflicted punishment that we Java-types deserve for our sins, like XML configuration files, EJB and all the JCP madness. We enjoy them just like Xians enjoy being punished for their sins. It’s all guilt.

Note for the humor-impaired: the above was largely ironic. However, there’s also some serious debate material in this thread, buried under all the mudslinging. We can start from the following Hani quote:

There’s no doubt that ajax, tagging, semantic fappery and all that other gibberish have some potential. Ultimately though, there is no revolution, nor even an evolution. It’s simply the ability to toss in a few more tools in the toolbox. Specialised tools, that can be effective when used against the right obstacle.”

Spring 2.0: What breaks?

Published by ugo on December 12, 2005 in java. 15 Comments

Matt Raible: “Spring 2.0: What breaks?

Nothing.

Of course, some things might break - but Rod can’t think of anything significant will. It should be a drop-in replacement for 1.x JARs. This really goes to show the value of a non-invasive POJO programming model. There will be some changes in best practices, but you are not forced to change anything.

This should be the norm, but hasn’t been so in enterprise Java.

Alef just did a demo of migrating JPetstore from 1.2.6 to 2.0. He copied the 2.0 JAR over the old one and redeployed to Geronimo 1.0 M5. After proving everything worked (in a browser), he changed some of the XML syntax and redeployed. Again, everything worked as expected. “

When I read things like this, I seriously wonder why anyone would want to develop anything substantial in Java nowadays without using Spring.

Another migration to Rails

Published by ugo on November 28, 2005 in java and ruby-rails. 1 Comment

headshot.jpgAfter Graham Glass, here comes another old Java hand diving into Ruby on Rails.

Elliotte Rusty Harold: “I tried writing some PHP pages, but that was more difficult than I expected so I thought I’d take a day and see if Ruby on Rails was all it was cracked up to be. I’d looked at it initially, but decided against it because IBiblio doesn’t yet support Ruby. But I’m prototyping this on my desktop Mac, and if Ruby makes my job a lot easier, I could find a different host.”

I will follow this development with lots of attention, but already the following snippet raised my alarm sensors:

It’s trying to set a cookie for no reason whatsoever, even for a page that doesn’t exist! What’s worse, it’s a session ID! This is completely contrary to the web architecture, and a very common mistake made by developers who are mired in 1980s style of applications and have never understood the Web, and probably never will. My PHP version and the existing site I’m replacing are completely cookie-free. This is not a good sign, and does not leave me with a warm-and-fuzzy feeling; but let’s deny the setting of the cookie, proceed onward, and see what happens.

Can this be true? I’d like to know. Looks like this will be soon, as while I was writing this the bell rang: It’s my new Ruby and Rails books! Looks like my productivity might drop just a little bit in the coming days ;).

“Pro Hibernate 3″ review

Published by ugo on October 31, 2005 in books and java. 0 Comments

Pro Hibernate 3, by Jeff Linwood, Dave Minter (Apress)

The good stuff:

  • Clear and consistent.
  • Very few errors (spotted just a couple, minor ones).
  • Good typography.
  • The authors know their stuff, and it shows.

The not so good stuff:

At 242 pages, this book is too thin. No, let me restate it: it is way too thin. I’m not particularly fond of very thick books, but when the subject matter is complex, you simply can’t get away with a cursory glance at its intricacies. You see, at 408 pages, I still think that Hibernate in Action, though it is probably the best book on the subject, would be just great if it packed a few more pages.

The problem with Hibernate is that beneath its apparent simplicity lie a large number of difficult problems. Don’t get me wrong, I still think Hibernate is the best ORM tool out there. Unfortunately, Object-Relational Mapping is a hard problem. Solving the Object-Relational impedance mismatch in a fully transparent way is probably impossible: all proposed solutions so far are, in the end, yet another abstraction layer. And as we all know, all abstractions leak, one way or the other.

If you are just beginning to approach Hibernate and think that you will get a decent coverage of the complexities, traps and pitfalls of a tool like Hibernate in just 242 pages, you’re bound to be disappointed. Here are just a few subjects that I would have liked to see covered much more deeply:

  • HQL syntax. The official Hibernate documentation already gives some more complex samples, but their explanation is too concise. A good complement to the docs should probably clarify what you can and what you cannot do in HQL.
  • Exotic mappings.
  • Tuning and optimization.
  • Caching. What are the benefits and drawbacks of the various caching strategies and implementations?
  • Lazy loading. It is my experience that novices sooner or later will get the dreaded LazyInitializationException. What techniques can be used to avoid it?
  • Cascading rules and their effect on the lifecycle of entities.
  • Bulk loading and saving.
  • Using versioning to implement optimistic locking.
  • Others that I don’t remember at the moment.

All in all, I don’t think this is a bad book. Quite the contrary. It’s just that I think the authors could have dispensed some more of the goodness they are evidently capable of. As it stands, you will at the very minimum need to have a copy of the official Hibernate documentation, plus Hibernate in Action, on your desk, together with Pro Hibernate 3.

How do I produce well-formed XML with Velocity?

Published by ugo on October 27, 2005 in java. 4 Comments

The title pretty much says it all. I’ve been reading the docs, googling around and asking the only person I know who actually likes Velocity, but I could not find a solution to this simple question: Is it possible to guarantee that the output of a Velocity template will always be a well-formed XML document?

Of course, the template must have all tags balanced and such, to start with. Consider this simple template:

<tag>$value</tag>

As long as the string representation of the value variable in the Velocity context is something innocuous as “foobar”, everything is fine. But if it were “foo & bar” instead, you’d get this output:

<tag>foo & bar</tag>

which is most definitely not valid XML! The correct output should have been:

<tag>foo &amp; bar</tag>

This makes me wonder: Do people who use Velocity to generate Web pages never need to generate valid XHTML pages? I simply can’t believe this!

So there must be a solution. Of course, there is a really obvious and bad solution, which is going over all the values passed into the Velocity context and escaping all XML special characters like ‘&’, ‘<’ and so on. This might work for a simple case like the one above, but would break down horribly when your data model is a complex collection of arbitrary objects.

Please, don’t tell me that Velocity sucks as much as I think it does!

Searching domain objects

Published by ugo on September 23, 2005 in java. 3 Comments

Ryan Sonnek: “Wouldn’t it be great to be able to use a powerful search engine on your business objects? Searching is becoming THE preferred way for user’s to find their data. Emerging applications like Google Desktop and Beagle have embraced the new mantra of user’s to ‘Search, Don’t Sort’. User’s don’t want to be forced to organize their data into limiting categories or folders, or to scroll around applications to find the data they are looking for. Even common GUI practices like table sorting are considered an eye sore compared to a snappy search box.”

Interesting technique. I’m marking this up just because it might come handy in a little while. I’m pretty sure at least one of the readers of my weblog (you know who you are) will find it useful.

Re: The Black Art of Good Design

Published by ugo on September 15, 2005 in java. 2 Comments

The latest BileBlog from Hani strangely resonated with me today:

So what’s the acid test for a good design? I have no idea. The closest I could come up with is A good design allows your code to do things you never expected it to have to do. It’s not about ‘oh I’ll add an interface here so I can plop in different implementations’ when there’s no sane reason you’d ever need more than one implementation, for example. […] For example, there are interfaces for simple objects that have both getters and setters specified, which makes creating a read-only implementation pretty unpleasant. I’d also argue that putting getter+setter style methods in an interface is an implementation leak anyway, mind you.

I just started working on a new project and the colleague I’m working with on it insists on putting interfaces on everything, even on beans which are mostly just containers for properties. And of course, getters and setters are specified in the interface.

I think getters and setters are indeed evil, but they are a necessary evil when your objects are used as containers for data to be shipped back and forth between a GUI and a database. They do not certainly belong to the interface, though.

I’d also argue that specifying an interface for these kind of (pseudo) objects is way overkill. The problem is he is also heavily into TDD, which I heartily applaud, but somehow thinks it’s necessary to test everything via mock objects, which requires having interfaces.

This goes to the point of mocking an OrderItem implementation to test that Order.getTotalAmount will call OrderItem.getQuantity and OrderItem.getPrice once for each OrderItem, which I find a bit too extreme.

Personally, I find this type of test to be:

  • Overspecified, as it does not just test that the correct amount is computed, but also that it is done following a specific algorithm.
  • Brittle, as the algorithm might change and we couldn’t care less as long as the correct result is computed, but we would be forced to rewrite the test.
  • An abuse of mock objects, which IMHO should be used to avoid dependencies on concrete implementations of external APIs. The same test, assuming it made sense, could be implemented in the traditional way without mock objects.
  • Much less readable than a traditional test.

I’m afraid all this TDD stuff, which is certainly valuable if done sensibly, is becoming to be abused as a means for avoiding to have to think about a proper design beforehand, as Hani hints to in hist post.

On the other hand, I will readily admit of being way too lazy in writing proper test cases, so I’ll concede the benefit of doubt. Maybe we can find a comfortable middle ground and I can start being more test-infected, which would be good.

What do you think?

ApacheCon EU 2005: Introduction to Lucene - Christoph Goller

Published by ugo on July 20, 2005 in apache and java. 0 Comments

I attended this talk hoping to find an answer to my problem of finding similar documents in a Lucene index. I pretty much expected not to find anything. After all, the title of the talk clearly gave away its introductory nature, but even asking the speaker did not elicit much. I know I have to use “Term Vectors” but was unable to find a digestible explanation on the web before, and Christoph couldn’t point me to one either, so I’ll keep looking.

ApacheCon EU 2005: Getting Up to Speed with Apache Geronimo - Tom McQueeney

Published by ugo on July 20, 2005 in apache, cocoon and java. 2 Comments

I’m not really into J2EE application servers, but I have an interest in following what’s happening in this field, since from time to time it happens that one of your applications needs to be deployed inside one of them. Open Source J2EE appservers, in particular, are becoming more and more used. Though Geronimo is the new kid on the block, it seems to have enough momentum to become a worthwhile competitor to the established leader in this field: JBoss.

I even briefly considered exploring GBeans as a mechanism for enabling Cocoon “Real Blocks” once. Even though it seems like we’re headed in the OSGi direction, it might still be cool to be able to deploy the Cocoon core as a GBean inside Geronimo.

ApacheCon EU 2005: Maven is your friend

Published by ugo on July 20, 2005 in apache and java. 0 Comments

Carsten Ziegeler is presenting “Maven is your friend”. I always saw Maven as a foe, but my opinion is entirely based on unverified assumptions, so I decided to attend Carsten’s session to see if my assumptions are correct or not.

Turns out Maven has lots of interesting and useful features, but I don’t think that’s enough to make me change my old habit of just using Ant. The problem is, I don’t think I’m going to invest a significant portion of my time to overcome the learning curve, however gentle it might be. But if I happened onto a project that already uses Maven, or someone proposed to use Maven on a project I am already contributing to, I won’t certainly oppose it.

Re: Getting Sprung with Spring

Published by ugo on July 5, 2005 in java. 3 Comments

Andy Oliver: “I doubt Spring will completely fade with the dawn of EJB3, since the prepackaged functionality is useful in other areas. I am, however, doubtful that it will continue to be useful for ORM-based persistence as the built in features of session management and all are more efficient and generally nicer (and will probably work better with a variety of Appserver environments). Spring has a useful place as a cross-appserver stop gap until JDK 1.5 is more widely deployed, but its Hibernate3 support needs some serious rethink especially HibernateTemplate. For the reasons above I would avoid HibernateTemplate and friends when using Spring and Hibernate3 until it has been reworked.”

This is just the conclusion of a long article, and you should really read it all. It has some good points and some not so good ones, in particular the conclusion quoted above.

For one thing, I am pretty sure Spring is not going to fade away, EJB3 notwithstanding, any time soon. Rather, it’s EJB3 that has to face an uphill battle. At the moment, Spring is gaining a very large mindshare and I find it extremely improbable that EJB3 will unseat it, in particular since Spring — as Andy acknowledges — has so much more to offer.

Nor do I think that Spring is a stop-gap solution. And I don’t see how JDK 1.5 can close that gap, per se. But maybe here Andy is referring to J2EE 1.5, or JEE 5, or whatever it is going to be called.

I do somewhat agree on the issue of Hibernate3 support. However, with Spring’s current support for Hibernate2 and Hibernate3, I can move a project from the former to the latter just by changing package names and recompiling, while starting to adopt Hibernate3’s features incrementally, which I already did without pain. This is a huge advantage, in my opinion.

Looking for a feed parser

Published by ugo on July 1, 2005 in java and opensource. 5 Comments

One of the planned features for The Open Source Zone is an RSS aggregator that could be used to fetch and aggregate news channels from project websites, blogs, Freshmeat announcements and the like.

Obviously, I want to reuse the best Open Source foundations available for accomplishing this task. Looking around for Java-based solutions I found Rome and the Jakarta FeedParser.

The latter seem somewhat more mature and it already includes “an advanced networking layer which meets the requirements necessary for providing XML aggregations services over HTTP. This includes support for If-None-Match (ETags), If-Modified-Since (HTTP 304 Not Modified), gzip content encoding (compression), User Agent modification, non-infinite timeouts, event callbacks for download progress, support for setting HTTP Referrer headers, maximum content downloads (no files larger than N bytes), ability to use custom HTTP methods (HEAD, GET, PUT, POST) etc.”

It also supports autodiscovery and apparently it is being used by Rojo, so it’s not vaporware.

On the other hand, a suitable networking layer is available for Rome as a subproject. Moreover, there is at least one implementation of a persistence mechanism for feeds (Aqueduct-Prevayler) while there doesn’t seem to be one for FeedParser.

Everything considered, I’d be inclined to start experimenting with FeedParser, unless you, my dear readers, have some suggestions to make. In which case, please leave a comment.

Update: my first brush with FeedParser didn’t exactly inspire much confidence in me, as there is no downloadable distribution, but you have to use Subversion and the SVN URL on the website is wrong (hint: the correct one seems to be http://svn.apache.org/repos/asf/jakarta/commons/proper/feedparser/trunk/). Then no build instructions are provided. Looks like it uses Maven :(. Luckily, a plain Ant build file is provided and I managed to build a JAR file.

Is EJB3 a Spring killer?

Published by ugo on June 30, 2005 in java. 4 Comments

Templth’s blog: “Is EJB3 a Spring killer?”: “This is one of the most asked question at this time. The EJB3 specification has incopored interesting concepts and ideas from leading open source projects to make easier to use, remove lines of code and improve the time of application development.”

Personally, I think EJB3 is still too little, too late. Even though EJB3 provides valuable simplifications with respect to previous versions, there’s very little that you can do with EJB that you cannot do — more simply — with Spring and, say, Hibernate. Besides, how far form release are EJB3 implementations? You can use Spring and Hibernate today, and they are very mature tools. When, and if, we have a comparably mature EJB3 implementation, they will probably have already outgrown the EJB3 spec in terms of functionality and ease of use.

Anyway, you can make up your mind by yourself by following the many pointers provided in Templth’s post quoted above.