Java

Almost exactly a year ago, Google made one of the most remarkable press releases in the Web 2.0 era. Of course, by "press release", I actually mean keynote at their own conference, and by "remarkable" I mean potentially-transformative and groundbreaking. I am referring of course to the announcement of Google Wave, a real-time collaboration tool which has been in open beta for the last several months. …

Sometimes, the simplest things are the most difficult to explain. Scala's interoperability with Java is completely unparalleled, even including languages like Groovy which tout their tight integration with the JVM's venerable standard-bearer. However, despite this fact, there is almost no documentation (aside from chapter 29 in Programming in Scala ) which shows how this Scala/Java integration works and where it can be used. So while it may not be the most exciting or theoretically interesting topic, I have taken it upon myself to fill the gap. …

Last week, we looked at the unfortunately-unexplored topic of Scala/Java joint compilation. Specifically, we saw several different ways in which this functionality may be invoked covering a number of different tools. Among these tools was Buildr, a fast Ruby-based drop-in replacement for Maven with a penchant for simple configuration. In the article I mentioned that Buildr doesn't actually have support for the Scala joint compiler out of the box. In fact, this feature actually requires the use of a Buildr fork I've been using to experiment with different extensions. Among these extensions is a feature I've been wanting from Buildr for a long time: the ability to launch a pre-configured interactive shell. …

Just in case you thought Christmas was over, I have a late gift for the world: I'm available for hire! Ok, so maybe this wasn't exactly the stocking-stuffer you were expecting, but it's the thought that counts. …

For the past two years or so, there has been an increasing meme across the developer blogosphere encouraging the application of the polyglot methodology. For those of you who have been living under a rock, the idea behind polyglot programming is that each section of a given project should use whatever language happens to be most applicable to the problem in question. This makes for a great topic for arm-chair bloggers, leading to endless pontification and flame-wars on forum after forum, but it seems to be a bit more difficult to apply in the real world. …

It’s surprising how universal XML has become. It doesn't seem to matter what the problem, XML is the solution. For example, consider a simple client/server architecture where the communication protocol must transmit some sort of structured data. Nine developers out of ten will form the basis of the protocol around XML. If it’s a lot of data to be transferred, then they will compress the XML using Java’s stream compression libraries. If there’s binary data to be transmitted, it will either be stored as CDATA within the XML or as files within the same compressed archive. Very few developers will actually stop and consider alternative solutions. …

In recent years, we have seen a dramatic rise in the number of languages used in mainstream projects. In particular, languages which run on the JVM or CLR have become quite popular (probably because sane people hate dealing with x86 assembly). Naturally, such languages prefer to interoperate with other languages built on these core platforms, particularly Java and C# (respectively). Collectively, years of effort have been put into devising and implementing better ways of working with libraries written in these "parent languages". The problem is that such efforts are crippled by one fundamental limitation: circular dependencies. …

As I have previously written, I have recently been spending some time experimenting with various aspects of Scala, including some of the frameworks which have become available. One of the frameworks I have had the privilege of using is the somewhat unassumingly-titled Specs, and implementation of the behavior-driven development methodology in Scala. …

This is definitely old news by now (in fact, almost a month old), but I'm just now discovering it myself so I decided to share. The jEdit project is renowned for two things:
…

I'm not entirely sure what these metrics mean, but they give me a warm feeling inside. :-)

Most of the badness seems to stem from EntityManager, which makes a lot of sense given the way it is designed. EntityProxy also poses issues, but in practice this isn't a real problem because of how extensive the JUnit tests are for just this class. Overall, ActiveObjects testability isn't anywhere near to the Guice score, but it's not as horrible as JRuby. …

As some of you may know, I've been following the Buildr project with a fair degree of interest of late. Just last week, Assaf announced their first release as an Apache project: Buildr 1.3.0. Being of the inquisitive bend, I decided that this would be an excellent time to reevaluate its suitability for use in my projects, both commercial and personal. …

For those of you who don't know, polyglotism is not some weird religion but actually a growing trend in the programming industry. In essence, it is the concept that one should not be confined to a single language for a given system or even a specific application. With polyglot programming, a single project could use dozens of different languages, each for a different task to which they are uniquely well-suited. …

Ah, the saga of misinterpreted micro-benchmarks! Developers advocating one technology over another have long used micro-benchmarks and trivial examples to illustrate their point. This is most often seen in the area of language implementation, where performance is a critical (and often emotional) consideration. The Computer Language Benchmarks Game is a good example of this. …

Happy Easter everyone, we've got a new release! ActiveObjects 0.8 is simmering at low heat (and footprint) on the servers even as I type. This is probably the most significant milestone we've released thus far in that the 1.0 stream is now basically feature-complete. I won't be adding any new features to this release, just polishing and testing the heck out of the old ones. We've already got a suite of 91 tests and I've got lots of ideas for more. Expect this framework to get very, very stable in the next few months. …

The practice of learning multiple languages has really become dogma in the modern developer community. Everyone knows that you should study different languages, different paradigms and various techniques for accomplishing the same thing. Why? The canonical answer is that it helps you grow into a better programmer in your primary language. After all, if you know how to compose functions in Lisp, naturally that must make it easier to design flexible systems in Java. I would beg to differ. …

I've been writing quite a bit recently about the differences between languages. Mostly I've just been whining about how annoying it is that everyone keeps searching for the "one language to rule them all", the Aryan Language if you will. Over the course of some of these articles, I've made some rather loosely defined references to terms like "general purpose" and "mid-level" when trying to describe these languages. …

Too often these days I see Java developers new to the psuedo-science of UI development finding themselves completely lost before they even get started. There are a lot of misconceptions about the "best" and "easiest" way to create a professional UI in Java, and precious few resources which attempt to clear up the confusion. …

I just ran into an article on DZone that totally threw me off my chair in terms of content. It's titled (ambitiously enough) "Functional Programming For the Rest of Us". Basically the article attempts to explain many of the common FP techniques in terms that imperative programmers can understand. More importantly, it motivates these explanations with a long and rambling set of real-world reasons. It's extremely long, extremely involved and well worth the read. …

Nathan Hamblen (otherwise known as n8han from Coderspiel) has been putting a lot of work recently into his persistence interop framework, Databinder. Interestingly enough, some of this work has involved ActiveObjects. Nathan has taken some of the code I did for the wicket-activeobjects module, adapted it to Databinder and enhanced it 10 fold. As of right now in the Databinder SVN, it is possible to achieve complicated interaction between your Wicket views and the ActiveObjects database model without any undo hassle. (announcement) …

I usually try to avoid such negative topics, but this time I really couldn't help myself. Once in a while something in the "current events" section of the blogosphere will bug me enough to merit a slam post. The "support" for Google Guice in the latest stable release of Wicket is one of those things... …

Just in time for the Christmas holidays, I give you ActiveObjects version 0.7! This release sports a whole slew of minor performance tweaks and bugfixes, providing better reliability. Also, we've greatly increased the number and scope of the unit tests running against the core. This gives us more confidence that the code is indeed as stable as we hope. …

I've never been a big fan of useless syntax sugar. I've always thought that the simpler a language is syntactically, the better. If you think about it, there's a lot of merit to this sort of viewpoint. I mean, which of these is easier to read? …

Google made the headlines last week with their announcement of a brand new API for graphical display of data, supporting several different display types (line, bar, pie, etc). The API (such as it is) works by taking different parameters as part of a URL and then generating a PNG chart based on the data. For example: …

Remember when I said that ActiveObjects would always attempt to take the simplest approach to any problem, even when it meant eschewing some more esoteric features? Well, this is probably a bit of an exception. Polymorphic types are most certainly not simple (at least, not from an ORM design standpoint) and I had to do a bit of hackery under the surface to make them work. However, given the usefulness of this feature, I think that it was probably worthwhile. …

I realize the very last thing I said about Java on the Mac was extremely negative, and I think that still holds. Apple screwed up, big time. What I'm talking about is a grass-roots effort to port Sun's FreeBSD version of Java 6 over to MacOS X. I'm talking about SoyLatte. …

There's a consistent problem with developing applications of any reasonable size, a problem which has dated back even before the early days of C. The problem is that any application of significance will be composed of several source files. In fact, reasonable applications are often found to be composed of thousands if not hundreds of thousands of files. Back in the day, it was felt (for some reason which escapes me) that it would be poor practice to type "gcc -Wall -o filename.o filename.cpp" several thousand times every time the app needed to be recompiled. …

The main obstacle in building an ORM is deciding how to map between a class hierarchy and a database table set. While this may seem fairly clear cut in many situations, it's unfortunately not so easy once you get into more complex issues like inheritance. …

This post, and all associated comments, has been deleted under threat of legal action. …

It seems that for any conceivable functionality in Java, there exist a myriad of frameworks which accomplish the task in more-or-less the same way. ORMs for example; I can count five different Java ORMs without even trying, and I'm sure that number would expand exponentially if I actually sat down and used Google to get a more precise estimate. …

So I sat down this week with the intention of writing a post about Fuse, the resource injection framework I worked on with Romain Guy. I wanted to get into some of the best-practices of the framework, touching on how it can be applied to a real-world application. To that end, I started out writing a simple demo application with a few custom controls and a UI delegate. The app itself was pretty simple and quite enjoyable, especially as I've been doing so much low-level backend work lately. :-) …

Well, I did it again. I pushed out 0.6 with a critical (and fairly obvious) bug. Basically, it involved the way I was handling column names and MySQL in result sets. Thus, 0.6 probably won't work with the 5.1 version of the MySQL JDBC connector. :-S My bad. …

As some of you may know, I've been doing some work for Teachscape (think Eelco Hillenius) on their Wicket-based application. It's been a learning experience for me as much as a working position in that I've got to experiment with a lot of technologies and techniques I haven't tried before. For example, Teachscape is based on Hibernate and Spring, so I've been getting some really in-depth exposure to both technologies (I still dislike them both). More interesting to me though is the way the application is run in a developer environment. …

I don't normally do this, but I think this is interesting enough to be worth a cross-post. Jonathan Locke (originator of the Wicket framework) has proposed two polls basically asking the question: Would you pay Sun for a port of Java 6 on OS X, and if so, how much? …

As a minor side-bar in this (hopefully) noise-less blog, I'd like to announce the release of ActiveObjects 0.6. If you could care less about ActiveObjects and/or random announcements about it, please feel free to completely ignore this post. …

I hate to be yet another blogger taking a potshot at Apple in the wake of the Leopard release, but I just have to say it: Apple, WTF are you thinking?! There, I said it, now we can be rational about things. …

ORMs really interest me, so naturally I read a lot of material regarding ORMs of all kinds, especially Hibernate and ActiveRecord. One of the more interesting reviews I read recently complained about the rigidity of the type system in the Rails ORM. According to the author's examination of the code, ActiveRecord just uses a monolithic switch/case statement to determine the appropriate Ruby type from the SQL type in the result set. This may make sense from a simplicity standpoint, but it may not be the best approach when it comes to flexibility. …

One of the main complaints I've heard leveled against ActiveObjects is that it's just not suitable for mapping to legacy schemas. More generically, concerns have been mooted that it enforces naming conventions and field conventions which aren't suitable/preferable for some projects. I suppose at first both of these were true. After all, ActiveObjects's entire premise was convention over configuration, and this requires some restrictions by default. However, I don't think it's entirely accurate any longer. …

I was reading this blog entry a few days ago, and it started me thinking about full-text searching. That wasn't the main topic of the post, but I think the little side-trek into the field was interesting enough to merit some thought. Right smack in the middle, Jamie goes on a bit of a rant about the pain of what is effectively two, separate databases (for example, MySQL and Lucene): …

So in the intervening time since I last updated you on ActiveObjects, I've been busy refactoring and repurposing some of the core. I've added a full JUnit test suite, which definitely helps my own confidence about the stability of the source. Also, there's a whole bunch of new features that have come down the pipe which hopefully I'll get to address in the next few posts. So, without further ado... …

Often times in a large-scale Java project, I find myself in need of performing small, discrete tasks with the existing project infrastructure. The standard way of doing this has always been to add a main(String[]) method to a class or to add a separate driver class to perform the one operation. This is a bit messy though, since it requires polluting your nice clean project with random utility classes. A better way to do this would be if we could have a set of separate scripts which just perform the actions we need. After all, that's what scripting languages are best at, right? Enter JRuby. …

Well, to make a small, side entry out of something which probably should be in bold print on the ActiveObjects website... It's worth announcing that I've merged SaveableEntity into the Entity super-interface. The only reason to keep these two separate was so that some entities could be configured to receive calls to setters and immediately execute UPDATE statements. This is a really inefficient way to code your database model and I think the only real use of it was in my sample code. :-) Since it really was an API misstep, I've decided to do away with it. The save() method is now obligatory for any data modification. Thus, any legacy code you may have which extended Entity may not function in the way you would expect (e.g. the DogfoodBlog example no longer persists data properly). If you have any code which extended SaveableEntity, just change this to extend the Entity interface and everything should work as before. Just thought I'd make a general announcement. …

So ActiveObjects is a fairly cool ORM. However, coolness alone does not an enterprise ORM make. In fact, the real qualifications for an enterprise-ready framework are as follows: …

There has been some talk recently regarding the ActiveObjects lazy-loading mechanism. It's starting to seem that what I thought was a great idea and terribly innovative when I designed the framework might not have been such a great idea after all. :-) That's a good thing though, finding my mistakes that is, it just forces me to think a little harder about how to solve the problem. …

In continuing with my series on ActiveObjects, this post delves into the eternal mysteries of search indexing and Lucene integration. Most modern web applications not only store data in a database, but also in an index of some kind to allow fast and efficient searching. Java's Lucene framework provides an excellent mechanism for this functionality, however it can be somewhat cryptic and hard to use. To ease this pain, ActiveObjects provides auto-magical Lucene integration for specified fields, making it trivial to index and search for entities. Unless there is great public outcry, I intend this to be the last of my "Easier Java ORM" series (with the exception a roundup post for linking purposes). As fun as it is being self-promoting and pushing my favorite open source project, I feel a slight twinge of guilt every time I flood your feed agregator with more information on a library in which you may or may not have interest. I'll probably still post about ActiveObjects from time to time, but only on occasions when there is something of special note. …

Per request in a comment on the previous article, I've decided to devote this post to the subject of relations and how they work in ActiveObjects. There are two types of relations in database design: one-to-many and many-to-many. In a one-to-many relation, multiple rows in one table usually have a reference to a single row in another table (or quite possibly the same table, depending on the design). As a simple example, assume with me that all tapeworms reproduce solely asexually (which isn't exactly true, but that's beside the point). Thus, a single tapeworm would have dozens of offspring. The proud parent tapeworm would have a one-to-many relation to its children (if you could refer to them as such). Another, less parasitic example would be people living in a city. The city would have a one-to-many relation to the thousands of people living within its borders. One-to-many relations are expressed in ActiveObjects about as simply as the concept can be expressed in words: …

In keeping with my ActiveObjects series, here's part 4. In this part, we'll look at schema generation/migration and the ever-interesting topic of pluggable name converters and English pluralization. One of ActiveObjects's main concepts is that you (the developer) should never have to worry about the semantics of database design. You should simply be given the tools to design your models in a natural and object-oriented way, and the database just sort-of takes care of itself. To allow this sort of simplicity, the database schema has to be automatically generated, leaving nothing to the developer in this area. Fortunately, ActiveObjects does poses this capacity. …

As a continuation to part 1 and part 2, this article examines a slightly less interesting (though none-the-less important) feature, transactions in ActiveObjects. I also figured I should give a minor update on the development status. Eelco Hillenius (of the Wicket project) has been contributing some code, fixing up areas where I messed up and cleaning up one of the sample projects (the DogfoodBlog sample, based on Wicket). We've also been looking into areas where Wicket and ActiveObjects could be more easily integrated (such as entity-specific models and lists). I've been keeping busy trying to stabilize some of other database providers. We now officially support (in the trunk/) the following databases: …

Well, by popular demand on the first post, I now bring you the second part in my series introducing the new Java ORM, ActiveObjects. In the first post, I gave some very basic examples of how AO could be used to simplify database access in your application. And while trivially interesting, these examples really don't do justice to the power of AO's interface model and how it can best be used to serve you. So, I will be devoting this post to SaveableEntity(s) and implementations. …

There is no doubt that Hibernate is the dominant ORM for Java applications. There are Hibernate conferences and Hibernate user groups. It even has its own shelf at Barnes and Nobel. However, I have always found it suffering from a fatal flaw: it's incredibly complex. Even accomplishing the simplest of functionality requires hundreds of lines of code, reams of boiler-plate POJO definitions, and a fair share of XML. Granted, it's probably simpler and more scalable than using JDBC in its raw form, but I still think it makes things harder than they have to be. This has been a common theme throughout most ORMs in any language. Even various Python ORMs, touted for simplicity and power, still remained burdened with either cryptic syntaxes, or mountains of boiler-plate. This general failing is probably the single most important factor which has contributed to the success of Ruby on Rails. Rails is nothing without its flagship component, ActiveRecord. AR provides an incredibly simple and powerful database wrapper layer which makes working with almost any schema simple and intuitive. Granted, migrations are a bit weird and it's performance is far from satisfactory, but the fact remains that it's much easier, quicker (and thus cheaper, at least in the short term) to develop a database-reliant application using ActiveRecord than it is to build the same application on top of Hibernate or iBatis. This has been carried to such an extreme that developers have taken to using ActiveRecord on top of JDBC through JRuby just to handle the database layer of their Java application. Clearly a better solution is required. Much of ActiveRecord's power is drawn from the fact that very little code is required to interact with the database. For example, extracting data from a hypothetical people table in a database is as simple as: …

Well, first I must apologize for not updating my blog in some time. Loads of interesting (and time consuming) things have been happening recently, specifically related to my employment as well as a rather jam-packed holiday week in the US. On a slightly different (but related) note, I resigned from my full time job and am once again "programmer for hire" (if you're interested, you can drop me an email: djspiewak [AT] gmail). Thankfully, all the closing details seem to be in order, so I'll finally have a little more time to devote to this blog as well as to writings on EclipseZone. In that vein I've spent a bit more time with Wicket (now Apache Wicket) recently, and I have to confess even more impressed with it than I was a year ago when I first looked at it. The separation of markup and code is a powerful concept that no other framework seems to have achieved to the same level without massive libraries of custom tags. For those of you who aren't already familiar with Wicket, it's an Open Source, component-based web framework. You create pages in Wicket by writing a standard HTML file, adding a wicket:id="yadayada" attribute to the dynamic elements, then you add the corresponding component instances to the Page instance in code. No Java in your HTML, no HTML in your Java. One of the things I stumbled upon in my latest run at the Wicket is the limitations of its MultiLineLabel component. MultiLineLabel lets you display large blocks of text with the characters appropriately escaped and all line breaks converted to proper < p>

blocks. It's not a complicated component, and this is glaringly obvious if you actually need something a bit more substantial. The site I'm using to experiment has a need for large blocks of (preferably) formatted text. At first, I figured I'd just throw a MultiLineLabel up and call it done. However, the need for formatting seemed a bit more pressing, so I began to look at alternatives. And it occurred to me that perhaps the simplest way to enter formatted text is to use Textile. Unfortunately, this means I need some way to render Textile into HTML within Wicket. After some Googling, I was able to positively ascertain that there are no Wicket components which provide Textile rendering. Not being one to give up there, I decided to roll my own. After all, one of Wicket's major selling points is that it makes custom components dead easy, right? Well, seems the hype is justified in this area too. Although, I must admit the documentation is sorely lacking in this area. I ended up cracking open the source for MultiLineLabel (which was surprisingly readable) and discovering that the key is to override the onComponentTagBody method. With a little more Googling, I found PLextile, which is the most complete Java Textile rendering library. A few minutes of quick hacking later, and I came up with this: …

So I was talking earlier today with my good friend, Lowell Heddings, regarding certain annoyances we had with web frameworks. The conversation started talking about the difficulties of developing PHP applications due to the lack of a debugger, but (as conversations on web frameworks are wont to do) eventually the migrated to Rails. I mentioned how I'd always been a bit distrustful of a web framework which ran on the one-request-per-persistent-process model. My reasons for distrusting this sort of framework were mainly related to performance and scalability, but Lowell brought up an interesting point that I hadn't considered before: process-shared sessions. See, because Rails runs as a parallel share-nothing process (i.e. the mongrel instances don't share memory state with one-another), trivial in-memory data can be a bit of a problem. Also, caching to disk can be a bit problematic since there are multiple processes attempting to access the on-disk data simultaneously. I'm sure many clever solutions have been mooted to solve this problem, but (I think) a new one occurred to me as we were discussing the problem. ( caveat: I haven't fleshed out this solution at all with any code. I'm posting it because Lowell thought it was an idea worth sharing) :-) My solution to the problem drops back into one of the hottest topic in Ruby today: JRuby on Rails. JRuby allows you to run Rails applications in a Java-based and integrated environment, even to the extent of using existing Java tools, libraries and process containers. An ancillary project to JRuby even allows you to package up your Rails application within a WAR and host it directly within a Java application server like Tomcat or Glassfish. Packaging Rails as a WAR obviously necessitates a bit of configuration that wouldn't normally go into the deployment of a Rails application. For example, if you want to serve multiple requests with a Rails app concurrently, you would run multiple Mongrel instances and use an Apache modproxy configuration which would proxy requests to available server processes. Java web application, while they do run on the persistent-process model, are designed to be multi-threaded, rather than multi-process. Thus, Java web applications automatically scale to involve concurrent requests since all that is required is the spawning of a new thread within the application server. Rails however, is designed to be hosted as a separate process and would have to be extensively modified to support this kind of scaling directly. The solution found by the JRuby-extras project is to allow multiple Rails instances to be controlled by a single Rails app WAR. The number of instances is controlled by a configuration option within the web.xml config file within the WAR. Thus, the JRuby WAR will spawn a new instance of the JRuby interpreter for each Rails process (as Rails expects), all hosted in separate threads within the same JVM instance, controlled by the Java app server. Thus, instead of going to all the hassle of configuring a new Mongrel instance and adding a modproxy rule to scale your Rails app, all that is necessary is to change a value in an XML file and to redeploy. This single-process encapsulation of Rails in this way allows us to provide a solution for Lowell's shared data problem. Instead of storing shared data (like application sessions or cached values) within the Rails process itself, the Rails application should use a Java class (hosted within the same WAR) to store the data. Thus, all shared application data should be stored at lower level than Rails, within the Java process itself. Java has some very solid concurrency APIs which would allow this sort of shared state without data corruption. As the application scaled and the shared data requirements increased, the SharedCache class (as we'll christen it) could be modified to cluster, using Terracotta. The Rails WAR itself is already transparently clusterable through Java application servers like JBoss. As Lowell put it, it's like an infinitely scalable memcached, without all the fuss. Well, it's a thought anyway... …

Some of you may know that I worked (and have been working) on a little open source project with Romain Guy called Fuse, hosted under SwingLabs at java.net. (not related to the Filesystem in Userspace project) It's a pretty neat project that was actually started by Romain to assist in the development of the Aerith demo (shown at JavaOne 2006). The whole idea behind the project is to provide a simple, easy to use resource injection library. Resource injection is different than dependency injection for a number of reasons (explained in more detail on the project page), but suffice it to say that this is an incredibly useful little library that makes centralizing your resource configuration a piece of cake. I started using Fuse on a regular basis at about the same time I stopped developing Fuse on a regular basis. :-) After I started my latest contract work (back in early last July), I no longer had enough time to devote to the project, so it went by the wayside almost immediately after the 0.3 release. Romain too, was working on various projects (including the book Filthy Rich Clients , coauthored with Chet Haase), so the project really would have just lain dormant for a while, except that I was actually using Fuse in the project I was working on. This was really the first time (that I know of) that Fuse was used in a solid, large scale application. Those of you that have developed experimental libraries in the past know that you don't really know that an API is working the way you want until it's tested in a bona fide application. Well, that was true with Fuse too. In the process of using Fuse, I was able to isolate and fix a number of pesky little bugs that had slipped through our unit testing, as well as improve performance immensely. Most of the changes made to Fuse were bugfixes, but the big ticket new feature is transparent caching of loaded resources. If a resource has the same value and type as one which has already been instantiated and injected, that instantiated instance will be used. Since Fuse is designed for (though hardly limited to) the injection of immutable resources, this works out really really well. I've noticed a huge return in performance from this simple change (alla GUI load times 2x as fast). Most of these changes (including caching) were made gradually over the last 10 months, so there wasn't really a clear line where we could say "this constitutes a release now." For my project, I was just using a custom build of the CVS HEAD version of Fuse, rather than the 0.3 "stable" release. Ironically, it had gotten to the point where I was actually telling other people to use the HEAD version since I knew that it would be more stable and performant than the 0.3 release. Eventually (as in yesterday), Romain and I decided that there was no real reason to hold off on a release any longer. While our documentation may still be woefully out of date, and while neither of us remembered enough changes for an impressive RELEASE NOTES, we still think that pushing out 0.4 was the right choice. So, the 0.4 release is now up on the java.net servers and available for download here. If you're interested in Fuse, or if you're using Fuse already (especially if you're using Fuse already), I suggest that you run over to the download site and grab the latest version. There were no API changes in this release, so it should just be a drop-in replacement for the 0.3 version you're using now. Oh, if you're interested in Fuse, there's some very good explanatory documentation on the project page. It's a bit out of date (I don't think it mentions auto-injection even once), but it does a good job on the concepts and provides a solid starting point for anyone wanting to try the library for themselves. …

There's been some discussion lately regarding various scripting languages and if they are (or aren't) the salvation for the "dying" Swing API (here, here and here). However, all of these blog entries assume one critical fact: Swing is dead or at least dying. I call that assumption into question. Actually, I was kind of surprised that none of the Sun fan-boys beat me to the punch. Over the years, I've shot my mouth of quite a bit against Swing. So it surprises me greatly that I'd be the first to step forward and try to defend Swing. In fact, if you had talked to me a year ago, likely I would have been leading the charge to bury Swing and move on. Apparently, some things have changed… The first post to hit the blogosphere, JRuby can save Swing summed up the core assumptions of all three pretty quickly: …

For this entry, let's consider a situation which arises fairly frequently in real world development: the need to quickly prototype something. Now, when I say prototype, I mean something even more atomic than building a demo of an application or feature. What I'm talking about is trying out a certain aspect of an API to make sure it works as expected; or possibly something even more trivial like quickly retrieving a system property. Now, Java as a language just doesn't lend itself very well to this kind of development. I've heard it said that "in a world of lightweight tools, Java is a sledge-hammer." While this analogy is somewhat derogatory, it's true to a certain extent. The way the Java language is structured syntactically, coupled with the sheer overly-designed bulkiness of most Java APIs, makes Java utterly unsuitable for quickly trying something with a minimum of fuss. For example: …