Dreams of a Rarebit Fiend

I deal with a lot of code that has never had any unit tests for it at all. In fact, it was often written in such a way that creating unit tests for it seems pretty horrific because you would find yourself having to load data into multiple database tables, set up all manner of services and files, etc. just in order to test it properly. So what I’m going to tell you is the simple, not-too-painful way I chose to make some of this code testable.

To me it’s all about removing all of the external dependencies from the code. If I can pull out all of the sections that are getting remote connections to EJBs, all of the data source lookups and queries, file reads, etc. and abstracting those out then I can test the code fairly easily because all I’ll be testing is the logic it had that surrounded all of those external calls to get data of one sort or another. So that’s what I do, I remove all of the code that does those lookups and abstract it out.

Note: Some of the feedback I’ve gotten tells me that I should make it clear that what I’m talking about below is only the refactoring part of getting your code to a unit testable state. After you perform some of the steps you might be well placed to look into either Spring or JSR-299 (for example Weld, which is their reference implementation) to do dependency injection. Or even into mock frameworks to do simpler implementations of your FooHelper for testing purposes. If you’ve got one you like a lot, let me know about it. I haven’t used any mock libraries for Java yet.

Step 1 - Use the refactoring capabilities in your IDE to extract some methods

I’m using Eclipse in this example, but I’m sure you could do much the same thing in Netbeans or any other major IDE.

Eclipse has a function on the context sensitive menu to extract a method. Just select a section of the code that goes and looks up something in a file or gets a JDBC connection and executes a query (or calls some code that does) and click the right mouse button to get the context menu, then select Refactor > Extract Method… and fill out the info in the dialog box where it asks you what to call your new method, etc. The refactoring will create an all new function which takes a set of parameters passed in and replace the code in the original spot with a call to that function. Repeat as needed on the offending section of code until you don’t have any code within it that isn’t actual logic that calls these new methods that use external resources.

Step 2 – Pull the new methods out into an external class

I don’t doubt that I could probably get Eclipse to do all of this too but at the moment I perform the next step manually.

Let’s say that the code that I was pulling methods out of was called foo(). Then I would create a new class called ProductionFooHelper at this point. I would pull all of the methods I extracted out of the class foo() was part of and put them into ProductionFooHelper(). That immediately breaks the foo() code because it no longer knows where the functions it used to call are anymore; but it leaves us with a version of foo that doesn’t require any exterior resources. That brings us to…

Step 3 – Extract an interface from the ProductionFooHelper class

Here Eclipse will do the tedious work for us again. Go to the ProductionFooHelper class and right click. Select Refactor > Extract Interface… from the context menu that pops up.

You can just select all of the methods to be in the interface and give it a name like FooHelper. Click OK and it will be created. Note that ProductionFooHelper should be marked as implementing the FooHelper interface.

Step 4 – Fix the failing calls within foo()

Go back to the class containing the foo() code and add a new parameter to it. The new parameter would be something like “FooHelper helper”. Then all the function calls within foo() that are currently showing as errors within the IDE can have “helper.” put in front of them. That will indicate that we’re calling that function on the passed in class. At this point everything in the code should resolve again except for the spot you originally called foo(). It will need to have an instance of ProductionFooHelper created and passed into it before it compiles successfully.

At this point we’ve extracted all the code which had external dependencies into another helper class and we have a production version of that class that should give us the exact same behavior we’ve always had. But if we were to produce a MockFooHelper that implemented FooHelper and produced faked results for unit tests, then we could test foo() at our hearts content knowing that we never have to do database setup or anything else unless we want to. The specific implementation of the functions in the FooHelper is up to us for testing purposes.

This may seem a convoluted way to get to testable code and maybe you’ve got much better ways to achieve this same thing. If you do, I’d love to know about it so I can improve my own coding skills. But if not, I have to say that it actually works. I’ve used it recently in a hierarchical fashion where innermost code had a helper interface extracted, then another close to it, and then yet a third. Then I wanted code that called all of them to be unit testable so I extracted a new interface that implemented the other three interfaces and added all new functions as well. The production helper had all of the methods for the innermost stuff as well as the outermost. The result is that I now have four different test points in the code where I can control everything that goes in and out and I was able to whip off a dozen new tests for code that once had none due to its complexity and the difficulty of setting something up.

Posted by John Munsch at 2:00 PM | Permalink | Comments (0) | TrackBacks (0)

I was just reading an overview of Java EE 6 and I was struck by their handling of the web.xml file. In this article it is trumpeted as a great new feature, the monolithic web.xml file can now be chopped up into a set of files so you can group setup and configuration. And god knows, if there’s something you get a lot of in Java, it’s configuration.

Anyway, the heart of this is good, it’s in a good place. There’s no longer one big file, we can have several files and each one has its own purpose. You might even get a web.xml file that comes with some third party framework you’re using like Struts. However, then it starts to go off the rails (no pun intended):

However, because Servlet 3.0 enables you to modularize your deployment descriptors, the order in which these descriptors are processed can be important. For example, the order in which the descriptors for an application are processed affects the order in which servlets, listeners, and filters are invoked. With Servlet 3.0, you can specify the order in which deployment descriptors are processed.

Servlet 3.0 supports absolute ordering and relative ordering of deployment descriptors. Your specify absolute ordering using the <absolute-ordering> element in the web.xml file. You specify relative ordering with an <ordering> element in the web-fragment.xml file.

Uh huh. When Rails (as in Ruby on Rails) needed to order a bunch of stuff like migrations, they made a simple convention (for example, 001_filename.rb, 002_filename.rb, 003_filename.rb). When that convention didn’t work out for large groups of developers they changed and went with the date and time instead (as in, 0080402122512_one.rb). Rails pretty much always picks a convention whenever possible and then if they need to they come up with a way to override it.

There’s nothing wrong with having <ordering> and <absolute-ordering> elements at all. Give the developer an override, fine, but give them an easy way to just name their stuff and order it automatically without that. What the heck is wrong with files named 001_web.xml and 200_web.xml? Seriously? Why can there never ever be a convention that the software reacts to and uses so you don’t have to hack up some configuration file 100% of the time?

Posted by John Munsch at 9:50 AM | Permalink | Comments (0) | TrackBacks (0)

Microsoft is famous for having a really bad case of 'not-invented-here' syndrome. They don't like to accept any protocol or standard or even take a perfectly working piece of software and include it. It wasn't invented at Microsoft so it's automatically crap. They have to "fix it". Yahoo! appears to have turned that on its head.

Yahoo's biggest competitor is arguably Google. Google invented an algorithm for data processing called MapReduce. They use it to process the terabytes and petabytes of data they grind through on a regular basis. They piggy back that on top of their storage system called GFS (Google File System). Because Google published papers on all this software, even though they don't make the software itself available, there was enough description for people to start developing their own versions of the Google tools.

Yahoo has now decided to both use and endorse the toolset Hadoop. Hadoop encompasses implementations of both GFS and MapReduce so arguably Yahoo is now running software that is based on ideas from their direct competitor. They aren't shy about it either, they aren't hiding it, rather they are telling the world that the software is good, they like it, and they intend to support it.

Bravo. I'm impressed.

Posted by John Munsch at 12:55 PM | Permalink | Comments (0) | TrackBacks (0)

I mentioned the other day that Sun was making their JavaOne technical sessions available online and they have continued to upload more and more of the multimedia versions since then so you can listen to the audio while watching the synchronized slide presentation. In addition to that they've uploaded the instructions and materials from their hands-on labs as well. If you'd like some in-depth step by step tutorials on a variety of different subjects then you should look through and see if any of them appeal to you. I spotted at least three that would be worth the time for me.

Posted by John Munsch at 9:59 AM | Permalink | Comments (0) | TrackBacks (0)

Sun is now making all their technical sessions from Java One available online. You can get the PDF for any of them and they are gradually getting the full audio plus slides up (e.g. all the 2006 presentations and about 20-25% of the 2007 presentations are up in full audio/slides form now, the remainder of the 2007 stuff is PDF only for the moment). You have to join the Sun Developer Network (SDN) but signup for that is free.

http://developers.sun.com/learning/javaoneonline/

The presentations are pretty awesome. I'm watching the one on the Java Persistence API from 2006 and there are several others I have my eye on for later. This is an excellent educational resource and if you develop in Java for a living you would be remiss not to go through what's available there.

Posted by John Munsch at 10:56 AM | Permalink | Comments (1) | TrackBacks (0)

Google has a regular internal lecture series on mostly technical topics with guest speakers and some of their own employees. This is their TechTalks Series and the best part of it is that you and I can see them too. They record and digitize the talks (close to 300 of them to date) and make them available on Google Video, using a consistent tag on each one so you can easily search for them and see if any interest you. The link above will do the search and show you all the videos so far.

Some of the titles that caught my eye:

Privacy Preserving DataMining

Turning Email Upside Down: RSS/Email and IM2000

Strike Up The Brand: How to Design for Branding

Ruby And Google Maps

Ruby Sig: How To Design A Domain Specific Language

Note: I'm not endorsing any of these, I haven't had a chance to view them yet. They just looked interesting to me.

Posted by John Munsch at 3:54 PM | Permalink | Comments (1) | TrackBacks (0)

I had never really learned regular expressions. Oh sure, I could use * and ? as well as the next guy, but throw [0-9]+ at me and I had no idea what it meant. That is, until the last year or so. Regular expressions can be very helpful in pattern matching against file names or user input and I dislike having gaps in the overall toolset of things I'm comfortable using.

So I set out to correct it. I'm still pretty ham-handed when it comes to typing in a regular expressions and I end up having to consult cheatsheets in order to remember the syntax to do a lot of things, but I discovered online tools and websites that helped me overcome the gap in my knowledge. Here are my favorites:

• txt2re: headache relief for programmers - This lets you input a piece of text you want to match against using a regular expression and it displays different expressions you could use depending upon which parts you want to match against. It can give you a quick start on matching even if you aren't yet very regex savvy.
• RegEx: online regular expression testing - This is the other handy part of the equation. Here you can input several items of sample text and a regular expression you wish to test. Hit the test button and it will show you which test text matched, what parts were matched, etc. It's somewhat Java oriented but might be as useful for any language with fairly standard regex syntax. I've found it very helpful for iterative development of complicated regular expressions.
• Regular Expression Library - A library of already crafted regular expressions (with various levels of complexity and robustness) to validate things like email addresses and telephone numbers.
• Regular Expression Tutorial - A tutorial capable of teaching you enough to be dangerous in a fairly short time. Good info and it's not intimidating.

Posted by John Munsch at 3:44 PM | Permalink | Comments (0) | TrackBacks (0)

Why it isn't the biggest boldest headline on every major tech website is beyond me, but Sun has apparently commited to open sourcing the Java compiler (the part that takes Java source code and spits out Java byte code for VMs to run) and the HotSpot VM (an excellent virtual machine with really nice optimization) by the end of the year. They will also be open sourcing the Java Micro Edition (popular on cell phones and other small devices) and almost all the rest of the Java Standard Edition stuff by the first half of next year.

Oh, there's been talk about doing something for ages, but real action?!? Real dates with real pieces of software attached to the dates? Real dates that are in the near future?!? Wow! Simply WOW!

I've long argued that Sun was a company that did not get open source. Even though they had projects like NetBeans and OpenOffice, they frequently showed off a real ignorance of what we as Java users and they as Java owners stood to gain by making it all one big group effort. But when Jonathan Schwartz was put in as CEO there was a lot of talk about the fact that he did get it. Clearly the people who said that were right.

Expect Java's already huge lead on .NET to become insurmountable, this will likely be the final nail in the coffin for that particular mistake. Also expect to see releases of Java come much more frequently as we get group effort from corporations with a vested interest in Java throwing resources at it (i.e. IBM, BEA, Google, etc.).

More details are available in this article: Sun expands open-source Java plan | Tech News on ZDNet

Posted by John Munsch at 12:34 PM | Permalink | Comments (0) | TrackBacks (0)

This just in, Sun sacrifices puppies to a pagan idol in order to try and regain market share and they also bundled a database with the upcoming JDK.

Reaction: OH MY GOD! They bundled a database! Kill it. Kill it with fire!

Posted by John Munsch at 4:02 PM | Permalink | Comments (0) | TrackBacks (0)

Google used to be wrapped in mystery. Most developers knew little about how they do what they do. But over the last year or so they've been pulling back the curtain to reveal things like the Google File System, how they process enormous datasets, and in some cases even some details of what tools they are using to do things like Google Mail (Java, of course :) ).

They took that to its next level by releasing a beta version of a Java toolkit for Ajax work called the Google Web Toolkit. It offers a lot of the same kind of remote procedure calls and DHTML/JavaScript stuff we've seen before in nifty toolkits like DWR except that this time I see just a few things I haven't seen elsewhere. One of those things is that when you do a web interface which has multiple tabs and you use their toolkit, you can actually bookmark individual tabs and even use next and previous in the browser correctly. This is something that is broken on many websites that use Ajax today.

I haven't put it to use yet but I will be trying it out in the future and comparing it to DWR unless someone else beats me to it.

Posted by John Munsch at 3:15 PM | Permalink | Comments (0) | TrackBacks (0)

I have liked Swing ever since I first used it. It makes far more sense than any of the Windows/GDI, X Windows, or Amiga UI work I had ever done in the past. It offers far more flexibility (often without a lot of pain) and I've never understood why anybody would be down on it other than because it has something of a learning curve associated with it. Nevertheless, it has gotten bashed because it is slow (I never thought so), ugly (can't agree), or just not cool enough.

Both of the latter two perceptions, I won't even refer to them as problems, are being addressed by people like Romain Guy who are working hard at technology demonstrations that show what Swing is really capable of and how cool and sexy it can be. If you want to see some pictures of the latest demonstration of what Swing is capable of, you can check out Aerith, a Very Cool Swing Demo. It features all kinds of 2D, 3D, and other effects to look like the latest thing from Apple.

Go there, check it out and maybe it'll influence you to try something in Swing that you might not have otherwise considered.

Posted by John Munsch at 10:35 AM | Permalink | Comments (0) | TrackBacks (0)

I know a new release of Eclipse is coming soon. Release Candidate 1 can be downloaded right now for Version 3.2 if you are interested. But I have to confess I didn't have much of a clue what I was supposed to get in this release that would be different and worth upgrading for. After having looked through the documents below, detailing the new and notable changes for each milestone release up to today, I'm probably going to stick with 3.1.X for the moment and wait for the final release in June. This isn't the kind of major release that made an easy choice between learning Eclipse 2.0 or working with the milestone releases of 3.0, this is smaller incremental improvements befitting the minor version number increment it's getting.

• Eclipse Platform 3.2 M6 New and Notable
• M5 New and Notable
• M4 New and Notable
• M3 New and Notable
• M2 New and Notable
• M1 New and Notable

Posted by John Munsch at 11:12 AM | Permalink | Comments (0) | TrackBacks (0)

Peter Cooper has developed a simple source code snippet repository with tagging that I like. It's far from perfect, the syntax highlighting is often squirrelly and if you enter in a multi-word tag like this "unit test" when you go to edit the code you get your tag back as two separate words so you always have to put the quotes back in place. Nevertheless, it works and it's a good start. Plus people aren't being shy about putting code out there.

What we need at this time are a small army of Java developers putting their code snippets into this repository. In no time it could be the place to go for a quick routine to fix a problem.

Here are my snippets thus far:

• Ant 101
• Getting A Data Source From Tomcat
• Data Source 101
• Velocity 101
• Velocity 101 Unit Tests
• Email 101
• Email 101 Unit Tests

They will even give you a feed for when I post new snippets. Unfortunately they don't have feeds for individual tags (e.g. Java) working yet. That's a shame and it's actually one of several glitches I've noticed. But even with the bugs this is still a more believable code snippet repository than many I've seen over the years. The tags go a long way towards making it really searchable and usable. But it will only be really useful if _everybody_ enters in some of their favorite utility functions and classes. So go sign up this minute and put in just three Java code snippets! It will take you less than 15 minutes and we will all benefit.

If there aren't any more improvements or he never releases the source code or it never gets full text search then maybe I'll move my snippets to another repository in the future. But it needs to be one with syntax highlighting, an easy framework for inserting the code in the first place (this is very very easy), and tagging.

Posted by John Munsch at 10:03 PM | Permalink | Comments (0) | TrackBacks (0)

Like many, I use UrbanCode's Anthill for automated builds. It's easy to setup, easy to run, and it has the basic features I need even in its open source version. But recently I noticed that it was ignoring failed builds and at first I couldn't figure out why. Everything else seemed to be working just fine and even installing the new Anthill 1.8.1 release didn't fix the problem.

Just in case you run into the same problem, it was due to me installing a new version of Ant (1.6.5 in this case) and the ant.bat file, which is what Anthill runs under Windows XP, not passing through the error code to Anthill. This message from their mailing lists a few months ago includes a replacement ant.bat file you can use and it will fix your problem.

Posted by John Munsch at 4:48 PM | Permalink | Comments (0) | TrackBacks (0)

Over and over I encounter Java code that hard codes database connection creation or resorts to pulling all of the connection parameters from a properties file bundled in with the .WAR or .JAR, or even a resource bundle (yes, that's you Kasai). QUIT IT!

There are these things in Java called data sources. They are an object you can go to and ask for a database connection, it hands it off, you use it to perform a query or two, you close it. That's it. If any database pooling, testing of new connections, etc. takes place it is hidden inside the data source and you don't have to think about it. In fact, because some data source implementions do things like pooling and testing of connections, they will probably work better than that five line version of "how to create a JDBC connection" you found online and pasted into your code.

Just about any type of server or framework you might choose to use around your application typically makes it easy to create data sources, specify all the details of how they connect to a database, and all you have to do is perform a couple of calls to get a data source. In the majority of your code, you don't even worry about the details of how the data source was obtained, you just accept it as one of the parameters to your class or to your method and you use it.

If your application isn't running inside a J2EE server, or Tomcat, or Spring, or some other place where a data source object is easy to come by, you can use the Jakarta Commons DBCP library to quickly create one of your own (hopefully configured using parameters that can be easily changed).

Here's an example of what I'm talking about that takes its configuration from system parameters:

BasicDataSource dataSource = new BasicDataSource();

dataSource.setDriverClassName(System.getProperty("driverClassName"));
dataSource.setUsername(System.getProperty("username"));
dataSource.setPassword(System.getProperty("password"));
dataSource.setUrl(System.getProperty("url"));


There you go, a data source that has caching and all kinds of other features you can tweak if you need them. Once you've got it you can call dataSource.getConnection() and out pops the connection ready to use. If you are running inside of Tomcat or WebLogic or something like that then you have even less of an excuse. In Tomcat for example, they provide a way to create data sources inside the Administration interface, you can just go to a web page, log in and create them. Retrieving one of the data sources you created in your code is this simple:

// Obtain our environment naming context
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");

// Look up our data source by the name we gave it when we created it. In this case that's "jdbc/EmployeeDB".
DataSource ds = (DataSource) envCtx.lookup("jdbc/EmployeeDB");


If you keep making everybody jump through hoops to set up your database connections when all we want to do is configure a data source, we'll just start rewriting your code. If you are writing a library to be used by other people, or an application that has to be configured by someone other than you, make it take a data source!

Posted by John Munsch at 6:12 PM | Permalink | Comments (0) | TrackBacks (0)

I usually don't get to attend conferences, but given the significance of Waterfall 2006 - International Conference on Sequential Development I'm positive I'll get to go.

Clearly their lineup of sessions, keynotes, and workshops eliminates the need for JavaOne, No Fluff, or any of the other big conferences.

Posted by John Munsch at 6:01 PM | Permalink | Comments (0) | TrackBacks (0)

At work there was a desire to put news items onto an internal page of a web application our customers log into. After the request was made, there was talk of including a page supplied to us by our internal customer representatives, providing a form they could type news into, etc. Basically a variety of solutions that all involved us writing something and/or getting directly involved in posting news. Perhaps even teaching HTML to somebody who normally just dealt with numbers and people.

I felt that was just a waste of resources. Why not just use Blogger? It has a better interface than anything I'm going to throw together in a couple of days. It will generate a page and dump the result via FTP to another server (exactly what we needed). And it doesn't need my intervention to get the news up. Blogger is perfectly capable of generating a JSP page instead of an HTML page as its output, and if you dump it in a directory where the server (e.g. Tomcat) will notice that the original page has changed, the server can automatically recompile the page next time someone requests it and they will have updated news but any Java scriptlets on the page will still provide their dynamic output.

When you are setting up Blogger, just make sure it knows that the output file it will generate has a JSP extension, the template for your page will be a normal JSP page with whatever scriptlets and custom tags you normally use. You just have to include the Blogger tags in the section of the page where you want the news to appear. Then Blogger will replace its tags and only its tags with the HTML representing the latest news items, produce a JSP page ready for processing, and publish it to its final destination via FTP.

Definitely an easier solution and it can be setup in thirty minutes or less vs. trying to cobble together your own solution or setup some software like Movable Type or WordPress.

Posted by John Munsch at 8:53 PM | Permalink | Comments (0) | TrackBacks (0)

Since Google started their search engine schtick their front page has remained basically static. A logo, which might change with the season, mood, or to celebrate an occasion, a place to type your seach query and two buttons to perform your search and return the results or, if you were feeling "lucky", take you directly to the best match Google could find. Yesterday, that changed as Google moved a portal page they had been working on for some time to be the default for Google. If you already have a GMail account you can log in and you'll see your most recent messages, you can get stock quotes, news, local film listings, etc. Pretty much what you can do on Yahoo's portal and others.

The thing is, it's like deja vu all over again. It reminds me a great deal of the great Netscape Portal five or six years ago that had the same kind of box structure, similar content, but one thing most of us hadn't seen up to that point was the ability to put news from any random site on the portal as long as the site supported this new "RSS" thing. It was Netscape's portal support for RSS that prompted me to add automatic generation of RSS to the news system of GameDev.net and then I could have GameDev's news on my Netscape portal just like we were some bigshot Associated Press or something.

Google has resurrected that portal from half a decade ago, thrown in some fancy JavaScript to allow you to drag boxes from one place to another and to have it automatically update. There's nothing amazing there. Except that they have also provided the Google Homepage API that allows you to build your own modules that can pull XML from other sites, process that XML with JavaScript, and produce any HTML you need for the user's page. That's a far cry from the heavy restrictions imposed by Netscape on their portal. They would go and get the RSS from a channel for you, parse it and store the results and present that result to you in just one format.

Here you can go and build widgets of almost any sort provided you can find a way to represent the output in HTML form. They can also be interactive with the user, requesting input, allowing choices, and altering their behavior based on the input. So modules can perform searches, display maps, do calculations, or a great deal more. Thus the widgets have more in common with Yahoo! Widget Engine (nee Konfabulator) widgets than they do with the limited extensibility of My Yahoo!, which was, up till now the most configurable of the big portals. MSN.com and Netscape.com both seem to remain firmly stuck in the distant past and allow very little choice for what is on "your" page.

Now the question is, who will use this ability to create some cool modules that will make the Google homepage an improvement over the other big portals?

Posted by John Munsch at 5:03 PM | Permalink | Comments (1) | TrackBacks (0)

The old adage about only having a hammer and thinking everything is a nail can apply just as easily to programming. If you blindly apply the rule that appending strings in Java is way more expensive than using a StringBuffer you can end up with some strange and arguably wrong results.

Take for example the PreparedStatements in a large piece of code I'm charged with working on. The SQL queries in this code are quite large and would stretch out to several hundred characters if they were not wrapped in some way within the code. So they were broken up into multiple strings, but the original author apparently feared the horrific overhead that String could impose and we ended up with a lot of code that looks like this.

StringBuffer selectStatement = new StringBuffer();
selectStatement.append("select blah, blah1, blah2, blah3, ");
selectStatement.append("blah4 from BLAH where );
selectStatement.append("...");

I did a really short one as an example but imagine this going on for 20+ lines because the individual field names are long, etc. And it's all completely pointless in this case. We aren't building a dynamic string that has changing elements in it. There aren't any other strings being passed into be appended, they are all just static strings containing text and question marks where the paramaters will later be put by the prepared statement. So it never changes!

In this case the StringBuffer is actually slower than just using plus signs where we had to break the lines and a String that the entire thing is assigned to. Any compiler worth its salt will take note that all the strings are static and append them into a single string at compile time without any .append() calls being needed. Plus all the extra function calls are just an obfuscation around the SQL query which you would like to have easily readable in the code. Note: The thought of moving the queries out of the code completely using something like iBatis hasn't even been touched yet. This is really straight up JDBC stuff here.

Please, think before you blindly follow rules. Why is the rule there? When does it make sense to break the rule?

Posted by John Munsch at 11:21 AM | Permalink | Comments (3) | TrackBacks (0)

Years ago, I naively thought that Google somehow had amazing machines and software that managed to do most everything in real-time even though the huge amounts of data they process pretty much preclude doing any such thing if I had bothered to think about it rationally. I imagined that they were processing each site they crawled as soon as they found it and into the search engine it went. Each news item from RSS was similarly fed straight into an index and made available immediately and no batch processing of reams of data was done.

Fortunately, such magical thinking has not persisted. Google does not use elves in a hollow tree to produce their results, they use intelligent engineers and many of the same tools available to you and me. They have developed all kinds of innovative solutions in order to be dealt with the huge amounts of data they have. Those solutions include:

• Building a truly enormous array of commodity PCs on which they run Linux to handle the computing needs for all of Google. When individual computers fail, their software simply shifts the workload to other functional machines. Supposedly, they buy large quantities of parts in bulk and make their purchases in a variety of ways to avoid being gouged by vendors.


• They created a distributed filesystem that spreads all files across hard drives on three separate machines in order to reduce the chance of failure causing loss of data.


• Built software that makes it easy to handle machine failures, distribute computing tasks across a large number of CPUs, etc.

The best thing about all of this is that they haven't been particularly quiet about how they do a lot of it. For example, if you go to their Research Publications site you'll see papers about The Google File System and Web Search for a Planet: The Google Cluster Architecture.

Now, I'm not going to snow you on this, if you aren't of a technical bent, this stuff is going to be a hard boring slog. Michael Chabon it's not. But, if data analysis of truly ginormous data sets interests you, then you want to read their paper on MapReduce: Simplified Data Processing on Large Clusters [PDF].

It's all about how they split up many data analysis processing in such a way that it is easy to write the algorithm to process the data and not spend time worrying about hardware failures, how many machines you might be allocated to run your software, or how to optimally use those machines to get the data processed in the least amount of time. Instead, it forms a kind of support system that reminded me of using the genetic programming package JGAP. I'll talk in a future entry about how JGAP can make it easy to find optimal or near optimal solutions for problems that would be tedious or impossible for humans. But the important thing it did was to make it easy for me to focus on the specifics of my problem and not on the mechanics of a framework. MapReduce is one of Google's means to achieve that same kind of focus and I think it makes for a really interesting read.

The Java Nutch project includes a Java version of MapReduce and a distributed file system that you could use as part of your own huge data set processing so reading these articles isn't just an academic exercise. You can actually put this to use if you have a project that needs it. Be sure to check out the wiki for the Nutch project for more helpful information.

Posted by John Munsch at 7:17 PM | Permalink | Comments (0) | TrackBacks (0)

I recently mentioned that we installed Jive Messenger at work to get a good instant messaging server that we could control and which didn't result in important conversations leaving the building to talk to distant servers. In the time since I wrote that, Jive Messenger has been renamed to Wildfire Server and it has had a dramatic speed improvement. Jive Software: Wildfire Optimization is an article briefly detailing the optimization Jive Software did for the new version of the server and might be instructive if you haven't done optimization on a Java project before.

Posted by John Munsch at 6:44 PM | Permalink | Comments (0) | TrackBacks (0)

I've rewritten this entry because I was told by multiple people not the least of whom was my wife (a person who can actually write sentences that make sense) that an instant message chatlog between myself and Don Thorp didn't make for a readable weblog entry.

It all started when Don pointed me to this entry about what should and should not go into Ruby on Rails: http://www.loudthinking.com/arc/000407.html. The way he put it, it gave him heartburn.

I read it and agree. The position of the author is that higher level constructs have no place in Rails and that in general it's futile to try and construct higher level software components for websites. I consider that to be a big mistake. They are missing is that the underlying model of, for example, ZWNews and MovableType and Wordpress is fundamentally the same. Most blogging software, forums, comment software, link counting, polls, etc. can be reduced to a basic subset of features which are in just about any of the software that various sites are using. If there's that much commonality then you can produce that subset of functionality, offer a few simple hooks into it so it can be extended in a couple of places and it'll probably serve the needs of 80% of the people who are building sites.

I would argue that they make this mistake because:

• They don't spend their time building one weblog after another or five or six forums in succession so they don't see the common elements which underly all of them. This is similar to the fallacy of so many game developers who start off by building a "reusable" sprite library or 3D engine before they begin their first game. They either fail completely or they succeed at building something but pronounce it impossible when they cannot then reuse it themselves later for another project or persuade anyone else to reuse it. It's a poor fit because they didn't grow the API based upon the needs of multiple projects, they instead attempted to divine the interface and capabilities based upon what they thought it would need.


• They imagine both a model and a UI which goes with it. That never works. You can have a UI which is a starting point or an example but the focus of the code has to be on the model and the administration for that model.

Kasai is an excellent example of this. It's design is a good one for an authentication and authorization system which will serve the needs of 80% of all web applications. I know what I've needed in the past and I can look at it and assess whether this would have met the needs of a large number of sites I've worked on and the answer is yes. In fact it really could stand to be reduced or simplified in a few areas and it would still have served my needs.

I think what most people fail to see is what is really a reusable component in real life. In the world of IC components a digital micromirror is a reusable component. It's not a TV all by itself. It has no tuner, memory, light source, etc. etc., yet it's a reusable piece. It's going into all manner of TVs today, all different in subtle or large ways, and for all I know somebody is building a huge array of them for a high resolution video wall.

So when I switch to the world of software, specifically, web applications I should be able to identify reusable pieces that occur over and over again with variations. In the world of websites you frequently have comment systems that have the following characteristics. There are a large number of unique conversations. The conversations are not linked to each other. Each one is a straight linear series of comments. Each comment needs to be attributed to an individual which could easily be referenced via a unique ID. Each comment may have some numeric rating associated with it or a pointer to another set of properties. That is a reusable component. I can build it and you could drop it into the user ratings at the bottom of Amazon products or the file comments at Stock.Xchng or Fark or half a dozen other places and you wouldn't notice that it had changed. Even if the first generation of the component isn't a great fit and needs work (like Kasai) the second or third will be because it was adapted to the real needs of a lot of users.

It's good that there is a major emphasis on making the infrastructure solid in Rails but saying that there shouldn't be a set of libraries that go with it to provide some reusable components for counting links clicked on, comments, authentication/authorization, etc., etc. is like saying that Java would have been better off being just like C++. A language without its huge supplementary library. That library, a well designed one which provided pieces we use every day for things like collections, XML parsing, regex, etc. determined well what some "high-level" components were which could be widely reused. Rails doing the same would only strengthen the framework not weaken it.

Posted by John Munsch at 3:54 PM | Permalink | Comments (0) | TrackBacks (0)

We were communicating confidential information back and forth between each other using an instant messenger which regularly sent messages outside the building to servers we didn't control. To get it back to being an internal only thing, I setup Jive Software: Jive Messenger XMPP (Jabber) Server and had everybody connect to it with Jabber compatible clients like Gaim, Psi, and Trillian.

Setup was a breeze. I had it up and running in 30 minutes and was connecting our first machines to it. It has a nice admin console (accessible via browser) which I've barely had to use so far. It's open source, it's written in Java, it's easy to setup, what's not to like.

If you need instant messaging and you need to control your own server, I think you will be happy with this.

Posted by John Munsch at 4:19 PM | Permalink | Comments (1) | TrackBacks (0)

We use Kasai for security on some applications at work now. I was responsible for the choice of Kasai and I recognize that it has some serious problems, in fact, I have a kind of love/hate relationship with it because of the way it is written and maintained. However, before I do an entry complaining about it, let me talk about why I love it and why most people don't seem to understand some aspects of security.

Let me say it simply. Roles are not equal to permissions. Way too many systems (like Tomcat) and way too many people I've worked with treat roles as though they were a valid form of permission control rather than a way to simplify permission grouping. Kasai does this correctly. It treats permissions as though they were the low level access controls that they should be. Every thing you want to control access to, perhaps down to the page or function call level, can each be a separate permission. Because that many permissions can quickly become unweildy they allow for permission groups and roles to group permissions at higher and higher levels of abstraction.

Let's take a real world analogy for an example. Let's say you had a business where you had a lot of cabinets to which you needed to control access. If you did things they way most people do you'd try to do that with as few keys as possible, one key handles the first five cabinets, the blue one is only for special cabinet 'A', etc. Then, if you suddenly have to shuffle around the contents of the cabinets or add somebody new who you only want to open some subset of cabinets for which no key combination exists, you are in a world of hurt because you may end up having to change the locks on each cabinet and get a whole new set of keys.

That's what most people do when it comes to using roles with security. They try to boil down security to a couple of keys which open a lot of locks. They create Admin, Editor, and User roles and "hope" that it will all work out. Then they code up their application (web or otherwise) to check for those roles and in effect, code the security into their application. If somebody comes along who needs to cross over a couple of roles (i.e. James is just a regular user in most respects but we trust him to review newly added forum posts to filter out the junk so he's like an editor in just that one respect) then you end up creating an all new role just for that one flavor of user (and modifying all affected pages), eventually, if carried far enough for enough users, roles become finer and finer grained and can approach being individual permissions again. Except that you won't have any roles or other higher level abstraction to group those permissions for easier application to the majority of users who aren't exceptions and fall nicely into the easy partitions you wanted in the first place. Every user will have to have 20 different "roles" to be able to function.

What you would ideally do is put a different lock on each of your cabinets and have a different key for each lock. Then, even if you rearrange the contents of the cabinets you can just collect all the keys and hand them back out again in the new combinations and your security is restored. Your cabinets didn't have to be modified and the only problem, at least in real life, is the proliferation of tons of keys to deal with. And in the computer world, we can use abstractions like roles and groups to gather together the most common arrangements of "keys" (permissions) that we will be applying to the majority of users.

Get yourself a real security system which has at least permissions and groups. Use permissions in a fine grained way to control access to individual functions. Use the higher level abstraction(s) to group the fine grained permissions into easy to apply units because most of your users will fall into easy to label categories. If you don't do this right though, it's the exceptions which will eat your lunch.

Posted by John Munsch at 9:54 AM | Permalink | Comments (0) | TrackBacks (0)

I watched this Flash based presentation on the NetBeans 5.0 Beta over at JavaLobby and I was very pleased. I used NetBeans for many years as my IDE for Java development and I only moved to Eclipse because it had things like refactoring that I just wasn't getting from NetBeans.

NetBeans didn't just go stagnant in the face of a superior product though. Quite the contrary. They've been frantically adding new features and refactoring to improve speed and usability. Overall, what I saw in the above presentation and the last one on NetBeans 4.0 (where they shifted to Ant for all project management, hear that Eclipse?) is very very encouraging. With this kind of serious competition between two free IDEs I feel very lucky to be doing Java work.

Without a doubt, between Java and all the open source libraries and servers and tools available for it, I am more productive within a given unit of time than I have ever been in the 18 years I've been doing software development.

Posted by John Munsch at 10:28 AM | Permalink | Comments (1) | TrackBacks (0)

I have the misfortune of working periodically on a legacy Java application which uses Java 1.1.8 (!!!) and BEA WebLogic 4.5. It was decided more than a year ago that trying to move this mess forward to a later version of Java and WebLogic was going to be as much trouble as simply rewriting it and trust me, it really needs to be written from scratch. The first attempt was a train wreck. Needless to say, this combination is a spectacular pain to work with because it lacks such niceties as the collection classes (a Java 1.2 thing), and it didn't use Log4J, Ant, or pretty much any of the things a Java developer might consider part and parcel of any application today.

I was working on some new code for this mess last week and today and I wanted to write some unit tests for the code I was about to write (good little "test-first" developer that I am) and I realized that while it was easy to get the latest JUnit, that when I looked around the JUnit website I couldn't even tell where I would get the older versions nor would I know which ones were compatible with older versions of Java when I did find them. In fact, scratching around various places I found that most Java library websites seem to forget about older versions of Java soon after they are gone. That doesn't really mean that they are gone, but they might as well be.

Posted by John Munsch at 4:26 PM | Permalink | Comments (2) | TrackBacks (0)

One thing I've not seen mentioned elsewhere is that there are some screencasts covering new features that go with the new release. They aren't necessarily on the very first page you'll look at so here's a link to the page that has them: Eclipse 3.1 Releases

Posted by John Munsch at 11:51 PM | Permalink | Comments (0) | TrackBacks (0)

Desktop publishing meant that anybody could create books, magazines, etc. and if they had the talent they could make it look as good as a major publisher. The World Wide Web was much the same thing again except that it went beyond just the creation of material, it included a distribution method as well and we've all gotten to enjoy the results of that great experiment.

Podcasting has given us narrow cast radio for any topic and stars and shows that are so far removed from "radio" that I could almost dance for joy. Of course part of that might come from the fact that I live in a radio market with at least four Clear Channel stations in dominant positions on the dial and another channel that prides itself on how different it is but in truth it's just a station sans DJ run from a hard drive. It's like borrowing someone else's iPod except that they added commercials to their playlists.

I'm going to jabber on at lenth about podcasting in the future but I just wanted to put in a quick plug for Tim Shadel's Zdot podcast. It's all about professional development using Java and other tools like Subversion which are language agnostic. If you do development for a living it's well worth dipping into the archives for a listen. My only complaint is that sometimes he's not working from a tight set of notes or watching the clock so you could probably cut 5-10 minutes out of every show without any real loss of material. But that's easy for me to say, I'm not doing a show myself :)

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte." I did this one (letter) longer only because I didn't have the time to make it shorter. - Blaise Pascal

Posted by John Munsch at 11:48 PM | Permalink | Comments (0)

I was buying a book online. This one in fact: Lucene in Action and I thought that while I was at it I would check out what other titles Manning might be offering. I purchased an ebook of a Struts title from them a while back because I could get it immediately and because it was a simple PDF. No stupid site I have to access it through (raise your hand Safari/O'Reilly) and no *&#*ing "digital rights management" (DRM). DRM is a code-word for, "All the rights for us, none for you. But you can still pay us the same or more. OK?"

Unfortunately, the first book I looked at was another Struts title from Manning and it included this wonderful tidbit..."Ebook edition not available. (Due to excessive piracy of this type of book,
we will release it as an ebook when a new ebook protection mechanism becomes available in the coming months.)"

I have a better idea Manning. Don't bother. I cancelled my Safari subscription and I don't think I'm likely to start it up again. I'm not going to download any ebooks from you if they are crippled in any way. So you can save yourself time on looking for the DRM technology and just simply cease putting out books in ebook form at all.

Posted by John Munsch at 3:44 PM | Permalink | Comments (3)

This is at least new to me. luntbuild appears to be a new entry into the field of automated build software for Java projects. I've only used the free version of AntHill but CruiseControl is a popular alternative.

Could anyone comment on luntbuild? It looks very nice and the support for subversion and more control over tagging of a build are appreciated. Anybody out there familiar with several of these who could give a comparative review?

Posted by John Munsch at 3:25 PM | Permalink | Comments (0)

i-Technology Viewpoint: Laziness Sometimes Pays (SYS-CON) As the author of this piece says, it is very very common for server applications to write out the same file over and over again. If a given page already exists in exactly the form you are about to write then why write it again, end up changing the date on the file, and then cause the user to download it again? So he substitutes a specialized version of the OutputStream that compares the data you are writing to the file that already exists if there is one there. As soon as it notices a difference it begins to change the file, but should it never change, then it leaves the file untouched so the browsers on remote machines may skip downloading it if they have a copy cached.

Simple, but clever.

Posted by John Munsch at 9:27 AM | Permalink | Comments (0)

Back in April 2003 I mentioned a piece of software then called Out-of-the-Box. It installed a wide variety of open source development software with a particular emphasis on Java tools like Ant, JBoss, etc. The name has changed but OpenLogic is still selling updated versions of Out-of-the-Box, now rechristened BlueGlue for $200(US)/year. You can get a one month trial for free to see if it appeals to your company.

I still think it's neat software, but I find the price tag is going to put me off using it personally nor would I be likely to recommend it for most, not all, but most companies looking for easy ways to quickly build development environments and keep them up to date.

There is a new competitor though. MyJavaPack Home is open source software trying to fill basically the same niche. It does installation of lots of Java development tools and a few common open source tools that aren't just for Java (e.g. MySQL). It doesn't have as many different tools it can install nor does it offer to install example projects which use subsets of the other tools to confirm that installed everything correctly or to give you a quick starting point for your own work. But even without those, its $0 price tag and open source could make it a popular choice for people who want a quick and dirty solution to setting up a development environment (and it's more IT people and team leads than you may think).

I hope future versions of both packages emphasize installation of groups of software based on common sets you see in work. Ant, Log4J, etc. would always be installed but there could be a group for web applications that would include Tomcat and/or JBoss plus Spring, a web service group could have Axis and/or Apache XML-RPC in it, a graphical UI one could install the JGoodies Forms and L2FProd.com's Common Components. Toss in some sample apps or even better, some templates for applications using Megg and you've got a hell of a starter kit.

Posted by John Munsch at 2:41 PM | Permalink | Comments (0)

As with many things that "lots of people say", the adage that Java is not or cannot be successful on the desktop is bullshit. Don't believe me? Take a gander at the top ten most downloaded programs on download.com in any given week. LimeWire is always in the top ten and usually in the top five. Azureus used to accompany it in the top ten but the version that was being distributed over there had had adware added to it by a third party so Azureus now recommends everyone get it from SourceForge instead. What's that I hear you say? A couple of titles in the top ten most downloaded applications doesn't make a desktop presence. Well, you know, you are right!

That's why Sun's decision to acquire the rights to the Watson software on Mac to make a Java version of it made for another app that could easily reach the top ten or twenty. But according to this weblog entry and this one here from another person who was working on it, that might not become available. Arrrgggh!

Fine. I'm no idiot. Sun has to prioritize and we know they can't do everything. They have to pick and choose what is the highest priority. But if they can't find the time to do this one themselves, ASK FOR HELP! Open source the thing and get some help finishing it. It has the potential to be another top twenty program when .NET has, well, none...

So, if what I'm saying has some resonance with you. If it makes sense. Talk about it. Write about it in your weblogs. Make enough noise to get some brief attention from Sun to the idea of giving it out for further development rather than letting it rot on a shelf.

Posted by John Munsch at 1:44 PM | Permalink | Comments (1)

To my way of thinking, Java is a natural for building a comic book reader. It's just viewing images and lots of people are going to want to do the same thing and use the same viewer on multiple platforms. So I started working on one a while back called FourColor. I got it to a point where you can actually read .CBZ and .CBR comic book files with it and in some ways (but only some) I like it better than CDisplay or Comical but I never released the code. I think it's definitely time to do so even if I don't do much more work on it for a while. Three other Java based readers have appeared in as many weeks and maybe someone so inspired can put bits and pieces of the four available together to come up with one really great reader.

Asparagino's Comic Viewer | java-gnome viewer for zipped comic scans is a little different because it uses GNOME for its UI. Apparently Swing wasn't good enough for something that only has a handful of controls on the screen, it was much better to pick a GUI that had limited availability.

Jomic is neat and despite the suggestion that you need Mac OS X on the front page (another person apparently missing the whole "cross platform" part of Java) I was able to run it successfully on Linux. I've not yet tried it on Windows though. It's nice that it handles two pages at once, it's not so nice that you have to do the installation by hand and that you have to install Java Advanced Imaging (JAI) just to run it.

CBViewer tries to outdo Jomic in strange requirements by requiring the not yet released Java 5 rather than the plain old mainstream Java everybody is likely to have on their machines. It supposedly works with Java 2 as well but after downloading it and trying it, it seems clear to me that you would have to recompile it to get it to work with Java 2. The provided binaries were compiled under Java 5.

I have no idea why you need either JAI or Java 5 for simply loading some JPG images and displaying them. FourColor seems to do just fine now without that. What all of these readers suffer from is a common problem that pretty much any Java program is going to face. The stupid, proprietary .RAR format has been used to compress many many comics. That's where the R comes from in .CBR files, .CBZ files use .ZIP compression. Because there is no library to handle .RAR files directly under Java, you have to have the UNRAR command installed in your path whether you run Linux, Windows, or Mac OS X for FourColor to work. How Jomic avoids the need for UNRAR on Mac OS X is something I haven't looked into yet. It's this requirement that keeps FourColor from being all it can be. Otherwise, it's simple Java Web Start installation would make it one of the simplest ways to get read a comic book file.

Anyway, since I haven't filled in anything on my project page for FourColor yet, here is a plain old .ZIP file with the source code for FourColor. Don't imagine that just because I have criticisms of the other three Java comic readers that that means I think mine is perfect. Far from it, just click the "more" link to read about what I think is wrong with FourColor and a multitude of features I think it needs to become a better reader. If you'd like to give it a quick try here is a Java Web Start link to try out the latest version.

Continue reading "Java Comic Readers Begin To Appear" »

Posted by John Munsch at 7:13 PM | Permalink | Comments (5)

I haven't tried out Rome yet as a RSS parser, I'm still using Informa to handle all my parsing in HotSheet and my new project. I've been considering it though and if they add a liberal parser like is suggested here, P@ Sunglasses I think that would be a great feature.

You know another feature that would make a nice benefit to both the Informa and Rome parsers (and anyone else who wanted to use it). An ultra-liberal RSS channel locator like that described here. Anyone needing to pull RSS could then just say, "Type in the URL of the website and I'll look for RSS feeds." Then the function could go out and find the list of one or more RSS channels associated with that site and present them to the user for subscription. It doesn't really do parsing so it would be agnostic to the RSS parsing library it was paired with.

Posted by John Munsch at 10:37 AM | Permalink | Comments (2)

It isn't immediately obvious if all you look at is the released files directory but jdic: JDIC - JDesktop Integration Components is chugging steadily along. I put the very first bug in for the software, which offers various packages to make it easy to integrate browsers, display tray icons, etc. and now there must be close to a hundred issues which have been put in for it. The great thing is that they have fixed a little more than half of them.

It still won't bring up a browser inside a window for me on Linux and that's very important. But all those fixed bugs mean that it's not going to turn into another abandoned project and when it is released that we can count on support and people striving to make it into a solid library of functionality that I would argue is much needed.

Posted by John Munsch at 11:28 AM | Permalink | Comments (2)

I ran across this list a while back but I didn't remember all of them: Enhancements to Java Web Start Technology in J2SE 1.5.0

I really look forward to those improvements. Especially things like being able to associate my apps with specific data files and shortcuts for Web Start apps on Linux desktops.

Posted by John Munsch at 4:36 PM | Permalink | Comments (0)

Oh, that's right, because SWT just roxxors. Except when it doesn't as with this little glitch: Bug 24796 - DCR - No printing on Linux GTK

I develop on Linux and SWT doesn't have printing support under GTK. It kind of sucks when you want to print out a file and can't ever do it. However, my Swing apps continue to print just fine. Since the most recent update to this bug indicated that there was still quite a bit of work to go, I doubt I'll see my eclipse "Print..." menu item ungrayed before this bug hits its second birthday in October.

I know this sounds a little snarky, I'm just a little irritated.

Posted by John Munsch at 4:00 PM | Permalink | Comments (0)

Here's a kind of nice replacement look and feel you can use in a Java application instead of Metal, it's called Tonic and there are lots of screenshots on the site to let you know what it looks like in action as well as the ubiquitous demo you can launch via Java Web Start to see it in action.

Posted by John Munsch at 6:15 PM | Permalink | Comments (0)

Michael Gloegl has taken my toolbox entry from a few weeks ago and turned it into a big wiki page. I'll be adding a permanent link to it from my resources page and updating the wiki with my own additions and changes rather than continuing to keep an outline that is only of use to me.

Posted by John Munsch at 12:36 PM | Permalink | Comments (9)

Normally when I'm about to start a new Java project I go and get my skeleton project and make a copy of that to the correct directory name to get started. Maybe you call your skeleton something else, a template, a prototype, whatever but I'm curious if you have one. Mine consists of an already created directory structure, a build.xml file that serves as a good starting point, a handful of libraries that appear in 100% of all my apps (logging, unit testing, etc.), the shell of a ReadMe.html, etc..

Download newProject.zip

Personally I don't think this is much of a solution. What I wish I had was something that was like what the old Visual Studio did. It had a wizard that you could step through and it would ask you a set of questions before producing what was largely the same application skeleton every single time :) Why don't we have something better than that for eclipse, NetBeans, etc. It wouldn't have to be proprietary to any one particular vendor because the core code would be agnostic to any IDE. It would be a set of instructions to ask some questions and generate files.

You could have templates for a web app, a Swing app, an SWT app, and a console app. Each one would be responsible for creating directories, writing out a build script, asking you the name of the application, the packages where the files would be put, features for that particular kind of application, etc. Where is this feature? It's not complicated, most of it could be done by scanning through some XML that told you which directories to create, some Velocity templates that created all of the files you needed, etc. and yet the two IDEs I've worked with the most (eclipse and NetBeans) seem more focused on helping you create individual files but not starting points for entire applications. NetBeans did have the ability to create a simple Swing app but all it created was a file or two of Java, no build structure, place to put documentation, etc.

I do know about AppFuse and Equinox and I think they are really cool. However, correct me if I'm wrong, but I don't believe that even those offer a wizard to tailor anything in their skeletons. Where there are choices mentioned in the documentation (e.g. iBATIS and Spring for AppFuse) they are just more documentation on what you can change, not a checkbox that you check and the change is made for you. The closest they seem to come is changing some names via ant when you create a new instance.

I can anticipate one of the biggest objections likely to be raised to this. If we do this, then how many developers are going to become dependent upon the crutch of wizards creating the shell of an application for them and they won't understand the very IOC container or persistence framework, etc. they are using because they didn't have to set it up. If that is your objection then I agree, but I'm not sure it makes sense to deprive the more skilled developers of the tools because others might abuse them. I'm betting with a little collaboration we could come up with some killer starting points that would be tailor made to cut time off the front of a new application.

Posted by John Munsch at 3:43 PM | Permalink | Comments (5)

OK, I interviewed three people today for positions at my company. As one of the questions in the interview I thought I'd give them my list of the names of ten "obscure" Java projects and see which ones they could describe. My hypothesis going in was that: a) Everybody would get some of the easy ones like Velocity and Lucene (after all, they are Apache projects) and b) I would prove my critics wrong because nobody would get all of them right or even eight out of ten.

None of the people in question listed less than several years of Java work and most claimed good knowledge of various J2EE technologies like JDBC, JSP, Servlets, and EJBs. Based on the interviews, they weren't very strong candidates but two of them were so-so.

At the end of the third interview not one of them had come up with even a one sentence description of any of the ten items that came close to the project. I got one who referred to Lucene as that "text formatting thing", I think he may have confused it with Velocity. Another referred to Apache XML-RPC as something to do with Apache's web services stuff, "like SOAP." Grand total I had gotten maybe six guesses and/or mumbles about the items and that is as close as it came folks.

I'm curious to see if anyone next week will be able to identify any of them and if anybody else has any interviewing to do, what are your results?

Posted by John Munsch at 11:50 PM | Permalink | Comments (9)

OK, this needs work, I took the outline file I keep in JOE (the Java Outline Editor, yay!) and put it's OPML through a hastily generated XSLT to produce the following mess. No doubt I can now receive a volume of criticism for poor formatting.

Note: I've moved the list to the extended entry so it doesn't all show up on the main page of my weblog. I've also fixed the first few bugs I found in the list (no doubt the first of many. I'll keep working on the formatting and fixing bugs until it is fairly readable.

Continue reading "My Java Toolbox Circa 7/2004" »

Posted by John Munsch at 4:14 PM | Permalink | Comments (5) | TrackBacks (1)

Carlos Perez took exception to many of the items I included in my own list of obscure Java projects from yesterday. I'm very pleased that he chose to do his own (wonderfully titled :) ) Manageability - Top Ten Truly Obscure But Useful Java Projects. I hope others do the same to shine the spotlight on projects which they believe aren't getting the mainstream attention they deserve.

Posted by John Munsch at 10:20 AM | Permalink | Comments (0)

I spend a lot of time on the web watching for useful stuff because I believe that knowing about some of it ultimately saves me more time than it costs me to keep up to date on what's new. Among the things I found are projects which, in my opinion and mine alone, don't get much respect, mention, or recognition. Hence, here's my top ten list of projects which I've mentioned to people and gotten a, "Huh, never heard of it," in response.

If you've seen all ten of them, bravo for you, please don't write me to ask, "How could you include _______! I use it all the time." Instead just leave me a comment at the end including a project I left off the list which should have been included. Then maybe everybody will learn something.

My Top Ten Obscure Java Projects

1. JiBX - In a sense, this is not that obscure. After all, there was a four part series of articles about JiBX on the IBM site. But where I think it seems to blend into the wallpaper is that there are a hundred different XML persistence mechanisms out there for Java. Every week you see a new one that somebody rolled for some project added to Freshmeat.net. But JiBX is different than any
   other one out there I've seen, including popular ones like Castor and Digester, because it puts Java byte code directly into the classes themselves to perform conversion to and from XML. As a result, performance blows away anything else I've seen. If you have to convert large volumes of XML to Java objects or vice versa and do it at high speed, this is the ticket. However, if you need flexibility in parsing an existing XML format into Java objects I'd still have to give the nod to Digester, it seems to be
   able to handle a lot of odd structure.


2. Bean Scripting Framework - As hard as it is for me to believe that this is obscure, it really seems to be. What if I told you that for a couple of hours of your time you could
   expose internal components from one of your programs for control by different scripting languages and that people could then create scripts to work with those components in languages with which they are already familiar like JavaScript, Python, Rexx, etc. This used to be an old IBM project but even after it made a move to Apache its profile still didn't seem to increase that much.


3. the display tag library
   - How many web based applications display tables? Yeah, pretty much all of them.
   DisplayTag makes displaying a really really nice table easy. It handles alternating line highlighting, pagination, and altering the appearance of items in the table through the use of a simple table decorator class. This is a tag library that anyone who has to build web applications needs to have in the repertoire right along side the JSTL.


4. Batik - I've extolled the virtues of Batik before in this weblog. You've got an vector graphic rendering library that can work at a huge range of scales. It handles standard XML Scalable Vector Graphics (SVG) format files and they have pretty much the same level of expressiveness as PostScript. It's written entirely in Java and you can incorporate it
   into your application. Wow. Simply wow.


5. Anthill - When you want to start having automated builds for your application, Anthill is probably the easiest way to go. It allows you to take the already existing Ant build script you should already have for your application and make it run on a regular schedule. It can automatically notice when there are changes to your code within a CVS source repository, check out the latest version of the code, build it using Ant, and perform post processes like JUnit tests or moving build products to a directory for download. Best of all, when a build fails to compile or fails JUnit tests Anthill will let you know via email so you can fix the problem. I love the way Anthill is simply built on top of most projects already existing build process so it can often be implemented and running in a couple of hours. A commercial version is available that has more features than the open-source version if you need them.


6. Lucene - An indexing and searching library you can embed into your application. I like the fact that it will let you distinguish between text that you need to be able to search upon but not necessarily store (e.g. the body of an HTML page) vs. something you want to both search on and store (e.g. the title of that web page).


7. Velocity - A straightforward, easy to use boilerplate system where you can create textual template files and then fill in portions of the text with values you set. Perfect for sending out emails, generating HTML, SVG, XML, and who knows what else without having to write a bunch of parsing code to handle your own template formats. I've used this in two different projects now and both times I ended up pleased.


8. Prevayler - Easily the most controversial entry in the list. After breaking out with grandiose claims of huge performance improvements over relational databases and SQL, many dismissed this storage technology. Personally, I think that's a mistake. Prevayler is not for every program. It really only works if you can fit all of the data you are trying to persist in memory. If 32GB databases are your stock-in-trade, move along, it's not for you. On the other hand, if you have just a few megabytes of data to store and it will easily fit in memory then this is a good way to add storage of that data, have high speed access, and continue using internal data structures like Lists, Maps, etc. that you may already have rather than being forced to map to RDBMS table structures.


9. Picocontainer - This is one of the lesser known of the newly popular "Inversion of Control" (IOC) or "Dependency Injection" containers. Spring is probably the best known of these type of object containers. Picocontainer is just an extremely lightweight container for putting a bunch of Java objects together and having each one get the other objects it needs in order to perform its functions. In many Java applications this is accomplished by hard wired code at the start of the program that creates each object and then passes references to other objects. Or worse, each object is left to its own devices and is allowed to get its own references to other objects or create them and the result tends to be very untestable code with a lot of dependencies. With Picocontainer the constructors on the objects specify the other objects they need and/or a set of interfaces for which they need object that implement those interfaces. The container is responsible for creating objects, doing so in the correct order, and connecting them up to satisfy those requirements. Spring is more flexible and powerful, but also significantly larger than the ~50K weight of Pico.


10. Apache XML-RPC - SOAP is all well and good for making function calls over the Internet. It is interoperable across languages, implementations, yadda yadda. It's also overkill for 80% of what most developers want to do (i.e. make a couple of simple calls to remote websites). XML-RPC is a much simpler XML format that is perfect for this and I can guarantee you that you'll be able to create servers which can be called from many more languages than an SOAP service simply because just about any language you can find has an XML-RPC implementation. SOAP's complexity ensures that many more obscure scripting languages have no client side implementation. Also, the simplicity in implementation carries over into simplicity of use. You could build both a simple server and client within an hour of picking up the library.

Posted by John Munsch at 4:48 PM | Permalink | Comments (11)

It's a single test rather than a whole suite of tests which might reveal more about the different servers, but this Servlet Performance Report is a really interesting read if you have to do servlet or JSP work regularly.

In particular I found it interesting that Tomcat 5 had performance that was that good, even compared to some commercial competitors. That brings up the quality of all the products including it as well, like JBoss and Sun's Java System Application Server (what a catchy name).

Let's hope that BEA's WebLogic is included next time (or perhaps added ex post facto).

Posted by John Munsch at 8:56 AM | Permalink | Comments (0) | TrackBacks (0)

Many might think the JReleaseInfo project is overkill but I've worked on several projects where we wanted something exactly like this. It provides an easy way to embed some variables into a class that is automatically built using Ant. It can also handle automatic updating of a build number. I've already put the class generation into HotSheet and very shortly I'll have the dialog displaying the info rather than some hard-coded nonsense that I have to remember to update.

Posted by John Munsch at 4:51 PM | Permalink | Comments (0)

There's a recent article on IBM's Developer Works site that begins like this, "Most Java developers agree that there's only one domain where Swing/AWT is superior to the Eclipse platform's Standard Widget Toolkit, and that's Java 2D."

Really? Was there a poll I missed somewhere that hit "most" Java developers? Because I would have liked to have participated.

I love eclipse. I use it every day now and I greatly prefer it to NetBeans. However, I think the time spent on SWT is time wasted and I don't think grandiose proclamations like that do eclipse (or likely SWT) any service.

Posted by John Munsch at 8:49 AM | Permalink | Comments (1)

Some developers at Sun have produced Rome to parse all RSS variants as well as Atom. I've yet to evaluate it for use in HotSheet (which I intend to do) but I'd have to say that I'm still of the same opinion that I had before with regard to reinventing the wheel.

Make no mistake, I'm no huge fan of Informa because I think that most of its features are not well documented, lack examples, and don't build on each other in a clear fashion. I really just want basic functionality and a cookbook that shows what the other features in the system are and how to add only the ones in which I'm interested. However, with that said, I still think it likely that three developers could have refactored the Informa code to get it into a more clearly delineated set of functionality and added the parsers they wanted to add (e.g. Atom) with less effort than starting over from scratch. But that's just my opinion...

Posted by John Munsch at 4:27 PM | Permalink | Comments (2)

For those keeping score, here is the responses so far:

Lighten up - 7 votes
You're an asshat - 2 votes
You're both an asshat AND you need to lighten up - 2 votes
You've got some points - 3 votes

Yeah. So clearly I didn't make my point well at all. I've got an idea for something to do that will show how I think things should be rather than just tell people. Standing up on a soapbox and shouting just attracts people who want to know why you are shouting, what makes you worthy of shouting, etc. I need to do something which cannot be mistaken for self-aggrandizement nor for a personal attack on someone.

Posted by John Munsch at 9:32 AM | Permalink | Comments (19)

>Life's to short to spend it wound up in a knot of needless fury. - James Gosling

How very true. However, as I said in the first line of my comment yesterday, I'm not mad, I'm disappointed. The other title was more of an in joke with JavaBlogs because everybody who reads it knows that a big controversial title is guaranteed to draw everybody and his dog to read what you wrote.

I think from the comments I got on the article I've learned something. That is, that I take Open Source (and I usually think of it with the capital O and S :) software way more seriously than a lot of other people do. I read The Cathedral and The Bazaar by Eric Raymond. I read Young's book on the founding of Red Hat. I stopped using Windows and moved to Fedora Core Linux and then wrote a tutorial to help others get started on their move off of Windows. I've got a couple of open source projects far enough along that I can share the code and perhaps it will prove useful to someone. I want to write a whole hell of a lot more.

Often I take a hard look at my own work and slink away realizing that someone else has put in more time, more effort, had a better idea, or just done a better job than I did and their effort is the one which deserves to be promoted rather than mine. Informa is an excellent example of this, I did a RSS parser that is buried in the older version of HotSheet but nobody ever used it to build anything else that I know of and it is quite clear to me now that any further effort in that direction is counterproductive to both myself and others. If I do have anything to contribute to a RSS library then it should be somebody else's so that we all benefit. As for why I continue to plug along on HotSheet, when there are better readers out there, I'd say that it is because mine is one of the few Java readers and thus it is also one of the few cross-platform options, and also because I'm planning to do some things with it that nobody (and I do mean nobody) is doing right now.

The same is at true of FourColor, a viewer for comic books in .cbz and .cbr formats that I wrote. I'm divided over whether or not it makes sense to continue on it now that Comical is out. But Comical isn't advancing all that fast, nor is it any more feature rich than FourColor at this point, so at the moment I'm leaning towards releasing the code just to see if anyone else is interested in adding to it and seeing whether it can overtake Comical or whether it is just another useless also-ran. If Comical started to really take off though, the topmost link and text on the page for FourColor would be one to direct people to go work on and use Comical instead. I think that a ruthless attitude, even towards your own work and your own desired projects is the only thing that helps everyone advance. Building another text editor or RSS reader, or anything in a dozen other grossly overcrowded categories is a huge waste of time. There are programs which practically go begging to be written, write one of those.

Here's an example of a comment I got that strikes me as if it came from another planet than the one I live on:

"The guy thought it would be a cool hack, over a weekend. Who cares if he didn't look around to see what was out there already? There's no "rule" out there (thank God) that says people need to look at what other people have done, before doing something themselves."

In my book, yeah, there is a rule like that. People who do otherwise, when it is so easy to go to Freshmeat and browse to the Java section and type the letters RSS just to see everything RSS related under Java (I just did it to time it, I had a list of 22 items in under 1 minute 30 seconds) is wasting their time. There's no law against wasting time and there never will be. However, I felt that not choosing to take the very limited amount of time necessary to do that was indicative of the problems that Sun has with open source at this time. Does it not strike you as strange that Sun didn't learn from the fact that Blackdown did a huge portion of their work for them in porting Java to Linux?!? They benefitted already from others having the code and working on it, but they don't see the benefit to opening it up. Here for example:

"Oh, yeah. I've always felt that sort of in the abstract, open-source is the right thing to do for a lot of the kinds of things that we do. There are a variety of issues that make it a very complex discussion as to whether it actually works as a business." - James Gosling on favoring open sourcing Java

Hmmm, whether it actually works as a business. Hmmm. How's that whole Java Desktop working out for Sun? I hear that it's making a lot of sales and that Sun is very very pleased with it. Isn't it based on Linux? It certainly seems that someone at Sun figured out how that works as a business. Maybe it's only other people's source that should be open.

"Where in the Open Source Law Code does it say "Though shall read all the code on freshmeat.net before reinventing the wheel"

Since you asked, I'll tell you. In the second point from Eric Raymond's Cathedral and the Bazaar article, "Good programmers know what to write. Great ones know what to rewrite (and reuse)." Constructive laziness got us Linux, your attitude got us NOTHING! You don't read the code on Freshmeat, you just scan through to see if there's a couple of things you should look at real quick. If that's too much effort for you, do what you do and keep it to yourself, don't release something and pat yourself on the back for your "open source."

"Perhaps James Gosling, like myself, programs in his spare time because he finds it an entertaining and thought-provoking exercise. In many ways the process is more important than the end result."

Again, I don't agree. It may be more important to you. To the guy across the street who washes and re-washes his car all weekend, that's damned important stuff. But for everybody else, it does jack squat. So in summation, I'd have to say that I still don't think Gosling gets open source and neither do a lot of other people. Had this been anyone else other than Gosling I would have let it pass without comment. Lord knows I've seen a lot of wheels reinvented over and over again through the years. But in his case I felt that it shows the attitude towards open source at Sun beautifully. There's a complete lack of it really penetrating or being understood in any way.

"I should learn more about RSS, so I'm going to take James' lead and go write a feed reader..."

Sigh...

Followup: Shortly after finishing my posting I read on JavaLobby that Scott McNealy has no interest in open sourcing Java. I know that some programs are already starting to rewrite their licenses to exclude SCO from being able to use any future versions of their software, perhaps if the same happened to Sun and their Java Desktop it might help them figure out, "what problem does it solve that is not already solved."

Posted by John Munsch at 11:14 PM | Permalink | Comments (27)

It's a freakishly long title, but my initial title, "James Gosling Is A Clueless ****tard," made me sound angry and I'm not, I'm disappointed. But it did have the benefit of knowing that it would draw everybody from JavaBlogs to come read it. It was one of those angel on one shoulder, demon on the other moments...

Anyway.

After a long hiatus I've been working like hard on HotSheet again. I ripped out all my old RSS parsing code and replaced it with Informa and fixed a major bug. At the present time I'm completely overhauling the model (as in model-view-controller) to make something that is much simpler for the UI to deal with. The refactored version should be easier to modify and get undo/redo because I'll be using the command pattern for the various actions you take with the model. Expect an update to come to you via Java Web Start in less than one week.

Then late last week I noticed that James Gosling released a new project. It's yet another RSS aggregator (lord knows we need more) called JNN - The Juicy News Network. Wow! Ignore my cynical take on RSS aggregators, I'm deeply impressed with "The Father of Java" doing something like this and I rushed to go look at it. My excitement quickly turned to, "Oh oh." For example, I read this quote from him even before I downloaded the app.

"The application itself is pretty straightforward. The most interesting thing is what it does to be fast at startup: all news feed reading is done by a swarm of low priority threads, one for each feed. So all feeds get fetched in parallel. This is very easy to do in Java: the threading API and networking support made it all straightforward."

Yeah... Multi-threaded pulling of channels might have been original when I did it in HotSheet THREE YEARS AGO, but I don't think it was, I think I ripped the feature off from somebody else. There were a lot fewer aggregators then but that's a pretty basic feature. The fact that he doesn't know that there are already other Java aggregators that do it (and there aren't more than a handful of those) suggests that he didn't bother looking at the existing open source before hacking this together. One look at the source code to JNN confirms that it is a glop with no documentation, no JavaDoc, no use of other libraries like Informa to do the RSS parsing or the Jakarta Commons Pooling to help with the multi-threading. Nope, just raw, crank-it-out code. Through much of it he doesn't look like he could be troubled to put blank lines between sections of the code itself just to group it.

All in all, he rebuilt the same stuff many others have done before him. He could have easily taken HotSheet as a base and added drag and drop of channel links (his only cool feature) and a three pane view to it. Even if he had decided that what I did sucked he should have used the Informa library to handle parsing and tried to focus only on the UI portion of things. Instead he's done something that he should have known better than to do, start from scratch, waste time re-inventing the wheel, and set a bad example with something that could not be built upon itself without major effort, and which added nothing to the pool of code that really does stand a chance of being shared and reused.

So, although James Gosling favors open sourcing Java, it apparently never occurs to him to build upon any of the open source that is already out there. So if you are hoping to see an open source version of Java soon, I think this might be a signal that the messages of open source, BSD licenses, etc. have not penetrated into Sun's psyche yet.

Posted by John Munsch at 10:19 AM | Permalink | Comments (26) | TrackBacks (1)

Don't get any ideas that I'm switching to .NET (or even to Mono) but I thought this article where Miguel de Icaza goes through creating a Java program which will run on Mono was an interesting read.

Posted by John Munsch at 12:40 PM | Permalink | Comments (0)

No matter what you think of JSF, I found the fact that Sun allowed a link to an article with commentary critical of a new API and a decidedly harsh title to appear in the news on the front page of Java.net. This is the house organ for Sun folks, over at Microsoft, the house organ only plays the tunes the management likes. Do you ever expect to see something like this on Microsoft's site or gotdotnet.com? Hell no.

Programmers Underwhelmed by JavaServer Faces

Posted by John Munsch at 8:54 AM | Permalink | Comments (0)

A handy item for finding SQL performance problems when you optimize your applications.

Posted by John Munsch at 11:06 AM | Permalink | Comments (0)

If you've ever had to deal with Sun's date handling in Java you know that the design can be a head scratcher at times. Things that are simple should be easy; but they aren't. And things that should at least be possible, you may end up having to implement yourself. Joda Time is a new open source library designed to give new classes to handle dates and times. The next time I have to do some date and time work I'll definitely give them a try.

One thing does give me pause though and that's that the Maven website for the project doesn't show any JUnit tests. For something as fundamental as a date/time library a good suite of tests is an absolute must have so hopefully the tests exist but are just not hooked up to the Maven reporting yet.

Posted by John Munsch at 8:59 PM | Permalink | Comments (0)

ONJava.com: What's New in Tomcat 5 [Jan. 28, 2004]

Posted by John Munsch at 4:38 PM | Permalink | Comments (0)

I've recommended Lumbermill in the past as a good GUI to watch your Log4J output. I preferred it over the Chainsaw GUI included with Log4J itself. Back in the November timeframe Lumbermill woke up from a nine month sleep to issue a new 2.0 beta and a couple of more since. It's now up to 2.0 beta 3 and it's a definite improvement over the old Lumbermill.

Not to be outdone, Chainsaw has also released a new version. Version 2 of Chainsaw may have managed to leapfrog even version 2 of Lumbermill! Nice work all around. I can hardly wait to see the final releases of the new versions. Both offer the ability to work with SocketHubAppenders (connect/disconnect to logging at will and allow multiple clients), searching, and more data in better formatting. The Chainsaw project is even promising Java Web Start support for easy installation/upgrading once the final release is ready.

Posted by John Munsch at 11:05 AM | Permalink | Comments (0)

DbVisualizer 4.0 is out and you can see the new features. Even the free version of this excellent SQL development tool is better than many tools that ship with the relational databases themselves (e.g. MySQL) and the commercial version is not expensive.

Posted by John Munsch at 3:48 PM | Permalink | Comments (1)

What one single program could increase the gross national product of the US by 1-3% all by itself? Why the Wheel 'O Yum can!

How does it do it? See if the following exchange sounds familiar. You've wandered out to the parking lot with X numbers of your co-workers. You have no idea where the hell you are going for lunch. "Where do you want to go?" "I don't know, where do you want to go?" "I don't care. Anywhere." "How about The Mexican Hat?" "I just had Mexican last night." "OK, well where do you want to go?" "I don't care, as long as it's not The Mexican Hat."

Yes. This is the problem that the Wheel 'O Yum solves. Everybody votes on the restaurants they do and don't want to see, the WOY server adjusts their size on the wheel and then it is spun to let you know where you should go. Also, it's written in Java so everybody can use it even in environments like the one I work in where there are both Windows and Linux machines.

Posted by John Munsch at 12:01 PM | Permalink | Comments (0)

I really liked the old version of XPlanner for handing of Extreme Programming (XP) stories, durations, tasks, etc. But the new 0.4 release
(XPlanner Home) looks like it is leaps and bounds beyond the old software.

I'm looking forward to trying it out and I especially like the fact that it features a SOAP interface to make marrying it to other software (like bug trackers, forums, etc.) not just practical but potentially quite easy.

Posted by John Munsch at 2:56 PM | Permalink | Comments (0)

Vikram Goyal wraps up his three part series on the Jakarta Commons with ONJava.com: Using the Jakarta Commons, Part 3 [Jul. 23, 2003]

Overall, an excellent series of articles.

Posted by John Munsch at 10:30 AM | Permalink | Comments (0)

Some software we are building now to connect some legacy software to a new web service depends upon the Digester software from the Jakarta Commons. It does the job and gives us no problems. That's what I like in software.

So I think these articles that introduce you with brief examples to each of the major projects in the commons are really a worthwhile read: ONJava.com: Using the Jakarta Commons, Part 1 [Jun. 25, 2003] and ONJava.com: Using the Jakarta Commons, Part 2 [Jul. 09, 2003].

Posted by John Munsch at 10:22 AM | Permalink | Comments (0)

The slides for this year's JavaOne sessions are now available: JavaOne[sf2003] - Conference - Sessions You have to login with your usual name and password for Sun's Java development area to be able to download them (which is free if you haven't ever registered).

If you want to watch the presentations complete with recorded audio from the sessions you can apparently pay $100 to get that ability and a few other frills. But if you don't feel like springing for that at least you can get the presentations for free.

Posted by John Munsch at 11:04 AM | Permalink | Comments (0)

There's a really interesting debate on Prevayler vs. database usage for storing data going on over here at The Fishbowl: Prevayling Stupidity.

Lots of interesting points are made both for and against and when it is and isn't appropriate to use an in-memory system like Prevayler, but one comment in particular stood out for me. It was this one:

And even if you have a dedicated machine, you have to wonder what happens if you're providing some kind of service that gets really popular, really fast. Brad from Livejournal originally wrote the site to host him and a few friends. If he'd written it using Prevayler, it'd have fallen over the moment it got really popular, and today he wouldn't be running a website with half a million users.

OK, now hidden in that statement is an instance of really bad design. I hope you see it but just in case you don't, here's what's missing. Any application which is storing and retrieving data needs to have abstracted out all of that process into data access objects (DAO). Even if I'm writing something "for my friends" or "just for me" I assume nevertheless that I may someday change how I store and retrieve the data for my program. It may be something like a switch from database to Prevayler or from local storage to access via a web service to a remote server. Either way, because I've abstracted out the operations I need to perform I can write those quickly to get something which functions and then tune for performance later or completely replace the whole DAO implementation with another that simply implements the same interface.

So, take this to the bank, never never ever embed your data access in the rest of your application in such a way that you have to change any code in the meat of that application simply to replace something as simple as a persistence mechanism.

Posted by John Munsch at 9:52 AM | Permalink | Comments (2)

Sun has rolled out their new java.net site to act as a new collaboration/community spot for Java development.

Given that the organization of the development stuff on java.sun.com was never that good, this seems to hold some promise. For one thing they provide project hosting and they do it in ways that are different and sometimes better than Sourceforge. For example, you can have a wiki tied to every project and you can also have projects within projects (i.e. the JGoodies encompasses both Forms and Looks projects.

They also have a site wide wiki, weblogs, and several focus areas that concentrate on desktop applications, games, JXTA, etc. All in all, I think it's pretty cool.

Posted by John Munsch at 10:35 AM | Permalink | Comments (0)

To me this is an absolute no-brainer. Sun makes play for games market | CNET News.com

Sun has tried in the past to get some movement in the games market and failed outside of J2ME stuff on phones. Their last attempt gave birth to the JavaGaming.org site which I believe was a serious mistake. The site floundered around for a long time without accomplishing much and now exists only in the form of its forum section. They have promised a new site for some time without any visible progress. If Sun is really serious about gaming this time they will persevere and spend some money. They have no idea what it takes to build a large successful gaming development site, nor do they have a significant way to promote it. I know how to do both and it's called GameDev.net.

GDN has a built in audience of people to whom a Java gaming site could be promoted and more traffic than any other game development site in the world. Sun, you need to hire us to build and promote a new site for Java game development. You need to sit down with developers and find out what things are addressed in DirectX or Sprockets that are not addressed in the J2SE (e.g. if support for joystick, gamepads, and steering wheels is going to be sequestered off in the in the Java 3D API then the API needs to be expanded to become your new Java Games API so people know what to download and install). You need to provide examples that make it easy to get started building a wide variety of different games and you need to pay for articles and more sample code to jump start your market.

Remember, Microsoft struggled with the games market for a looonnngggg time before they got it right. They tried every hair brained thing under the sun including WinG and some pathetic wrappers over the Windows GDI before they brought out the first version of DirectX and they started to make headway. It doesn't really matter that there have been some missteps in the Java arena, developers forget that stuff in a hurry if they find there are good reasons to develop for a platform. Lots of games would work as well under Java as they do at present under C++ because they don't require screaming performance, not every game is Doom III so giving developers a chance to have their game on both the Mac and PC and easier portability to phones and handhelds will appeal to many of them. But not unless you get your message out in front of them, keep it out in front of them, and build a resource that they can turn to every day for news, code, support, etc.

Posted by John Munsch at 1:30 PM | Permalink | Comments (0)

It's tough to say whether this would work well for anyone other than the demo crowd but TinyPTC offers a simple way of quickly updating the graphics on your display, even if you are in a Java applet!

Be sure to check out the Java applet demos they have links to on the page. They all boast impressive performance.

Posted by John Munsch at 3:51 PM | Permalink | Comments (0)

After being horrifyingly quiet for a long time, the Batik SVG Toolkit has a new version. Beta 5 fixes bugs and adds features. One thing the documentation doesn't really talk about much (at least anywhere I could find) is how to make use of its extensions for things like text wrapping. With SVG as it was originally there was no way to just wrap multiple lines of text within a space. That made some things that should be easy really, really, hard. That was because you had to figure out on your own where text was supposed to break due to font sizes, line widths, word breaks, etc. rather than leaving it to the rendering engine in your SVG renderer.

But Batik has extensions to add this and some other capabilities. So code that used to look like this:

<!-- Card Text -->
<text x="78" y="570" style="font-family:Times New Roman; font-size:27">
Threshold -- Mystic Zealot gets +1/+1</text>
<text x="78" y="600" style="font-family:Times New Roman; font-size:27">
and has flying. <tspan style="font-style:italic">(You have threshold as</tspan></text>
<text x="78" y="630" style="font-family:Times New Roman; font-size:27">
<tspan style="font-style:italic">long as seven or more cards are in your</tspan></text>
<text x="78" y="660" style="font-family:Times New Roman; font-size:27">
<tspan style="font-style:italic">graveyard.)</tspan></text>

<text x="78" y="700" style="font-family:Times New Roman; font-size:27; font-style:italic">
Nomad youths aspire to one of two roles in</text>
<text x="78" y="730" style="font-family:Times New Roman; font-size:27; font-style:italic">
the tribe: priest or warrior. Their secret</text>
<text x="78" y="760" style="font-family:Times New Roman; font-size:27; font-style:italic">
dream is to become both.</text>

can now look like this:

<!-- Card Text -->
<flowText font-size="27" font-family="Times New Roman" xml:space="preserve" xmlns="http://xml.apache.org/batik/ext">
  <flowRegion>
    <rect x="68" y="540" width="480" height="258"/>
  </flowRegion>

  <flowDiv>
    <flowPara>Threshold -- Mystic Zealot gets +1/+1 and has flying. 
<flowSpan font-style="italic">(You have threshold as long as seven or more cards are in your graveyard.)</flowSpan></flowPara>
    <flowPara top-margin="10" font-style="italic">Nomad youths aspire to one of two roles in the tribe: priest or warrior. 
Their secret dream is to become both.</flowPara>
  </flowDiv>
</flowText>

Now which one would you rather work with? Just be sure to start up the Squiggle SVG browser that comes with Batik using the command "java -jar extensions/batik-squiggle-ext.jar". If you do you can run the flowText.svg and flowTextAlign.svg files in the samples/extensions directory and they will work correctly. If you specify the regular Squiggle jar file the extensions won't be loaded and neither of their examples will work.

Posted by John Munsch at 2:12 PM | Permalink | Comments (0)

At the company I work for we've struggled for many weeks with using a commercial library for object to relational database mapping. It is supposed to hide the details of the database, make changes to the database easy (i.e. a change to a table doesn't alter the code), and get caching of data as well. It has definitely not worked as we expected and in the end we are going to have to replace it.

Apparently in this day and age using simple SQL to access your data is just too arcane to speak of so you have to have some kind of tool to map your objects to a database. Two of the ones we are looking at are both from Apache:

• Torque
• ObjectRelationalBridge

I'm very interested to see whether either of these will make the job of moving data into and out of an application any easier.

Posted by John Munsch at 3:01 PM | Permalink | Comments (10)

I downloaded an interesting thing yesterday that I had meant to try before. It's Out-of-the-Box 2.0, a piece of software designed to automatically install numerous pieces of open source Java development software on a Windows or Linux machine (I didn't see any mention of OS X but I'd hope they are working on that as well).

They have both a free edition and a commercial one which differ primarily in the number of different pieces of software they can install (four times as much for the commercial one) and how many example projects they provide to demonstrate the different libraries and tools working together.

After having played with the free edition for a while I have to say that I'm impressed but with a big proviso. It works but it can be a little confusing. For example, when it says it has "installed" software like BCEL, JUnit, etc. and it's not one of the primary pieces of software, they don't mean installed in quite the same way that I would. To me, those things would be installed if all of their documentation and examples had been installed as well, not just the Jar file necessary to make their other projects run. But that's exactly what they mean for most of what they class as mandatory. They are there in spirit but if you want to use something like BeanShell or the Bean Scripting Framework then you'll need to acquire the download separately or go to their online documentation. I'd really like to see that change so that you could install all of the documentation for any of these libraries (maybe another checkbox column) and a set of links to the various important documents would show up on a "master documentation" page. Then I would have one place to go to for documentation on all of these things.

Even without that, they have apparently improved Out-of-the-Box a lot between versions 1.0 and 2.0 and I think it holds a lot of promise. I'm likely to pay a one month download fee (just a few bucks) so I can download the commercial version to try it out and post a review here.

Posted by John Munsch at 12:08 PM | Permalink | Comments (0)

I complained to Sun about a month ago because they never bothered to update the page they used to keep up to date whenever new downloads or early release downloads for developers became available. It was an excellent place to watch every week and see what all had been released.

Then, last August, it just stopped. After I sent my email they sent back half a dozen replies from different people explaining that they were working on some new page and that it would be available "real soon now". I just checked today and finally you can once again go to their New Downloads and get up-to-date information on new APIs, reference implementations, and JSR specs as they get released.

Posted by John Munsch at 9:54 AM | Permalink | Comments (0)

I've mentioned Plucker before because it represents an open source alternative to Avant Go for gettng HTML documents downloaded (and automatically resynced) with a Palm. Along comes BlogPluck to give you a way to automatically get RSS newsfeeds and convert them to documents that Plucker can read on your Palm.

Installation is via Java Web Start so it is pretty much trivial on whichever platform you normally run. I look forward to when the author releases the source.

Posted by John Munsch at 11:45 PM | Permalink | Comments (1)

I've plugged The Free Network Project almost since I started this weblog more than two years ago. My first entry mentioning it was only a couple of weeks after I started. But only recently has it finally reached that magic point where performance and usefulness are finally here.

So what is the promise of this project? Well, it's two-fold. One thing is absolute anonymity from others being able to tell what you post and what you choose to download. Want to say something politically unpopular? Go right ahead, there won't be any repercussions for you. You can also utilize its other major feature, peer-to-peer distribution of files to offload bandwidth responsibilities to a host of servers for popular content.

OK, so how is all of this relevant to Java (after all, I posted this as a Java development link and that means it'll appear on JavaBlogs)? Well, the primary version of Freenet is written in Java and many of the tools released for it so far are also written in Java. It doesn't have to be that way, it just is. So, I'm just curious to hear what people would come up with if they could build web services or websites where bandwidth (currently several US dollars per GB transferred) cost nothing, zip, zilch, zero or alternately where anything can be shared or retrieved in absolute anonymity.

Posted by John Munsch at 10:13 PM | Permalink | Comments (1)

OK, hopefully this link is the last Struts resource I used a lot that I forgot to site in my first posting: Java Guru: Struts FAQ Index By Topic

Here's a quick follow-up about being able to read the RSS feeds that JavaShelf offers in various categories (i.e. to find out about new Struts books for example). I checked out the example channel that Bertrand mentioned (http://www.javashelf.com/servlet/books/rss?category=struts) and HotSheet had no problems with it. So you can easily use HotSheet to watch JavaShelf for books and it will handle filtering out books it has already seen (i.e. it only shows you a RSS item once that has a particular title and link) and you'd only see new items when new books were added.

Finally, here's some of the wonderful things you can learn via JavaBlogs.

• The rest of the world and the nation hates Texans.
• The movie The Recruit, might or might not be good.
• William Tecumseh Sherman graduated from West Point sixth in his class in 1840.

And it's all 100% Java information. Or not.

Posted by John Munsch at 2:18 PM | Permalink | Comments (0)

I forgot to mention the tool I used to do all my editing of the Struts config file: Struts Console

Simple. Straight-forward. Works. Some of the Eclipse based stuff I tried I just couldn't get working. That's not to say that it won't end up better in the end, but I really dislike having to fight to get my tools working. That's why I picked Java Web Start to launch the stuff I distribute. It's simple, it works.

Posted by John Munsch at 10:52 AM | Permalink | Comments (0)

Several people are mentioning Struts in their weblogs recently and since I am just finishing up my first web application using Struts I thought I might add my two cents to hopefully help anyone just starting out. Here are the resources I used and an opinion or two on them:

Struts In Action

Manning offers you the opportunity to buy this one as a PDF (bravo!) from their website for less than what you have to pay for the paper version. Alternatively you can buy it using the link above and I get a tiny amount of money. :)

Programming Jakarta Struts

I got this one through my Safari subscription but again, you may prefer the paper version.

The Struts user and developer guides

Contains some IMHO can't-do-without information that is skipped by both of the two books above.

The Struts user mailing list

Rapid responses to your questions and a huge searchable database of answers that prevent you from having to ask them in the first place most of the time.

Basically, the conclusion I came to after having worked on this a while is that although the state of the documentation for Struts is better than it has ever been in the past (I first looked at it a long time ago when its documentation consisted of a couple of tutorials), any single source of information still leaves much to be desired when you are actually building a web application.

I found myself frequently flipping back and forth between the two books and the official Struts documentation to answer questions I had as I worked and there were questions which I only found the answers to in each of the three books independently. There was no single book that answered all the questions I had. So my recommendation at this point is to lay your hands on all of the resources you can afford to purchase.

Posted by John Munsch at 9:50 AM | Permalink | Comments (3)

Several people have mentioned JavaShelf.com: Your Java book store on the Web! in their weblogs recently and I'd just like to make a small observation.

While this makes a nice all-in-one place to look for books, it has the same problem that small bookshops tend to have. Price. They will tell you about prices at only three places, Amazon, Powells, and Blackwell. Not familiar with Powells or Blackwell? Wondering why they were chosen over Half.com (where you could buy used copies of many Java books) or BookPool (which usually has much lower prices on technical books than anybody else)? The answer is simple, all three have associates programs that pay JavaShelf money if you buy the book through them. So be sure you shop around before you take the best price among three prices that might not be so good.

Posted by John Munsch at 9:37 AM | Permalink | Comments (4)

I know this is a news bulletin to a lot of people but it's not about pet deaths, visits to the vet, the cute girl you met at the club last night or (and this may be the real shocker) that cool new CD you like a lot. It's supposed to be, and you agreed to this when you signed up, primarily about Java. I saw one new blog added in the last couple of days that had three Java items and eight that had nothing to do with Java. It's definitely not for your political diatribes about pinko leftists, the far right, or those damn centrists.

Much of the modern blogging software has the concept of categories and can separate out one category of material from another. For example, I run MovableType and MT allows me to have a regular RSS feed that includes everything as well as a Java only feed that only includes items from the "Software Development In Java" category. If I don't put it into that category, you still might see it on my homepage when you visit but you won't see it popping up as a new item on JavaBlogs. This is not hard! If the channel becomes filled with so much detrius that we can't find the cool nuggets anymore then it will have devolved into nothing more than a bad mailing list where I can't reply directly and I get to hear about the minutia of people's lives.

Posted by John Munsch at 9:02 AM | Permalink | Comments (3)

For some bizarre reason I see people write this little meme periodically about how C# and .NET will "catch-up" to where Java is now in the next year or two so while there might be social or philosophical reasons to go with one or the other, there won't be any tech reasons.

Whoa, whoa whoa, whoa whoa. I hope that I didn't give the impression that I believed any such nonsense the other day when I gave my list of reasons I hope .NET fails. I just said that I don't think the arguments get anybody anywhere. But if you are deluding yourself into believing that .NET is somehow going to magically "catch-up" to where Java is today in the next year, 18 months or even longer, you need to open your eyes.

What follows is a quick dump from an outline I keep using the Java Outline Editor. I call it my "Java Toolbox" and I keep and categorize links to technology that looks promising in it, this is a short list that skips mounds of stuff I have never had reason to look at and it also blows by reams of excellent commercial tools as well. Look at the length of this list and imagine the veritable army of open source .NET developers (who are apparently going to have to thicken from etherial vapor because I haven't seen them yet) required to build all of this stuff. But, and here's the part that I can't seem to figure out why people don't see it, do you think that Java developers are just going to sit there and watch them do it? Are we just supposed to halt all development and sit on our hands for a couple of years so they can catch-up? No. Catching-up implies that they have to be able at some point to outpace us and I've yet to see anything that has proven to me that that is even a possibility.

Posted by John Munsch at 11:54 AM | Permalink | Comments (1)

I just looked at CVS for HotSheet and I haven't checked anything in since July of last year. Which sounds about right because I made some mistakes in writing it initially and then I got it to a state where it kind of limped along well enough for me to use it every day so there wasn't a huge drive to do all the improvements it needs.

But I'm finding myself annoyed by the problems it has and I'm wanting it to start realizing more of its potential so you can expect a new version soon. It will have at least the following changes:

• The item history is currently staying around even if you delete the item history file. This odd quirk is a side effect of my using serialization to save off my internal structures and a minor bug in my code playing off of each other. [100% done]
• The default browser that launches for Unix/Linux users is now Mozilla. Since most users run the software through Java Web Start, this won't change things an iota for you. Only if you were doing development with the code and running it from the command line or from the Ant buildfile. [100% done]
• Many channels were including HTML tags right in their RSS entries. This made the results almost impossible to read when you saw them rendered in HotSheet. New code in the RSS library allows for getting either the raw descriptions or the description with all tags removed and HotSheet now uses the latter. [100% done]
• Prevayler will be used for a new version of the item store, channel store, and item history. This will make a huge difference in HotSheet's ability to deal with crashes or other problems. Fortunately, due to how the first version of the RSS library was written, this isn't going to be too big a deal. [0% done]
• I went on a mission to cut as much as possible from the download so it would be a quicker download and I wouldn't expend as much bandwidth for new people trying it out. I dropped quite a bit by removing all the XML libraries that are now part of the Java Runtime and even more by dropping the scripting support that isn't even properly incorporated anyway. As a result it should be a lot trimmer and faster to install than before. If I was willing to cut my usage of Log4J and instead substitute the J2SE 1.4 logging I would have cut it from 4.2MB to .2MB. But I'm not willing to do that so you'll have to settle for a .4MB download instead. [100% done]

Posted by John Munsch at 2:37 PM | Permalink | Comments (0)

For some reason, one guy chose to fire up a flame war this week by writing 101 reasons why Java is better than .NET. Sadly, this is much like my doing a list of 101 reasons why cats are better than dogs. It's likely to "get a response" and, ultimately, it's unlikely to sway anyone's opinion one way or the other (or at least anybody who you care whether their opinion was swayed).

Here's one of the first "rebuttals" I've seen to the list and it tries to go point by point through the first list and say nah, nah, nah to most of it. Pretty much what you would expect and it features the equally non-inflamatory title of "25 pathetic attempts to make .NET look bad". Lovely...

So normally I'd just blow all this by as yet another useless flamewar like the old Amiga vs. Atari ST, Mac vs. Windows, etc. etc. of old but I think I've got a perspective that might be a little different on this. You see, I used to do Windows. Not in a little way, in a big way. I started developing for Windows when Windows 3.0 was in beta and I didn't stop until mid 2000. In that time I developed software on Windows 3.0, 3.1, 3.1 Multimedia Edition, 95, 98, NT, and 2000. I used Visual Basic from 1.0 on. I developed in C++ using Borland and Microsoft tools. I've developed using libraries and APIs that Microsoft put together from COM and DCOM to TAPI and DirectX. I can go on and on about this but the point is that I've used Microsoft tools, software, and development kits up one side and down the other and because I worked for a long time at Tandy (now RadioShack) and Tandy worked closely with Microsoft I did a lot of it with beta stuff that the public never saw.

On the other hand, I only started using Java tentatively in 2000 and really went full bore with it when I moved to a .COM in 2001 so my history with it is relatively short. Nevertheless, the differences between the two environments is striking. There's an old phrase something like, "there's no religious man like the converted sinner." I guess that describes me in this case. I see what the hell was wrong with staying with Microsoft so long and now I feel like I should witness for a bit.

So let me look at this list from my perspective as: Lots of reasons I want .NET to fail and fail badly

1. It's benefits a criminal organization. Not one that's been found guilty of crimes once or maybe twice, but lots and lots of times. Those crimes are many and varied, but here's just a few of them: Stac Electronics v. Microsoft, DOJ v. Microsoft, Sun v. Microsoft.

   P.S. If you want to split hairs, Stac v. Microsoft isn't a criminal action, it's doesn't stem from a criminal abuse of their monopoly like the other two cases. Instead it was just a case of a small company being driven out of business by willful patent infringement, theft of trade secrets, etc.

2. Microsoft isn't just one thing anymore. It's too damn big for that. I'm sure even Bill himself knows better than to think that he truly controls the whole ship because it's become big enough that he can't possibly know all the projects, people, etc. anymore. But even a really large company still has a kind of collective personality that it exudes and a large part of the personality both internal and external to Microsoft for many years now is that of a total control freak.

   If they don't own it, if they don't control it, if they didn't create it, if it doesn't have a broad stamp from Microsoft on it, then they don't want it. Sometimes it's sufficient for the thing to merely exist and they'll refuse to acknowledge it, other times they need to actively stamp it out because they can't control it.

   When was the last time you can remember Microsoft saying they supported a standard? That is, not something they invented and submitted a RFC for, an actual, take it off the shelf and re-implement it without renaming it or "improving" it so it doesn't work with anybody else standard. C++? Basic? HTML? A video or audio codec? Java? Anything?

   I'm sure there's something, somebody will point out their excellent support for TCP/IP or something and I'm sure that's true. But if you were to look at Microsoft as a person in your life, you'd wonder what was wrong with him or her such that so much had to be controlled by that person.

3. When your business is selling the operating systems that 90+% of everybody uses, software development tools should not be a profit center.

   Why should I have to plunk down a couple of thousand dollars for a "universal subscription" in order to have access to compilers and basic development information? Sun doesn't have to do that? On this point I'll quote from the .NET "rebuttal" that I linked to above, "For non-profit use VS.NET can be had pretty cheaply, especially if you know anyone that is in college somewhere." Pretty cheaply? For a non-profit (that means charities, churches, universities, the hobbiest who is going to give away his work for FREE)... pretty cheaply? Wow. That is well and truly pathetic. To try and justify it, and say, oh well, you can try to scam an educational discount so it won't be so dear, is even more pathetic.

4. Marketing. Have you been "lucky" enough to catch one of the .NET commercials with William H. Gacy telling you how great it is without really ever telling you anything about it? Microsoft doesn't trust .NET to stand on its own technical merits and it knows it may go like cod-liver oil down the gullets of a lot of people who have seen how the company works behind closed doors even if it were the tech shiznit.

   So they are going to pull a page out of Intel's bum-bum-buh-bum "Intel Inside" playbook and try to sell the brand like it's sneakers and cola. Trust us, you'll look cool if you use it, and we'll keep hammering the brand on TV so somebody who doesn't have much tech savvy in your organization will ask you if you are using it, or have plans to port to it, or whatever, even if he hasn't got a clue what "it" is in this case.

5. They don't trust you. They don't like what they can't control and they can't control you. They can try and they always will keep trying but ultimately you are going to see them keep trying to do things and always keep a step towards the door just so they can bolt if they have to. Want to see what I mean? Go visit GotDotNet sometime if you haven't already been there. It's the grassroots community website that Microsoft put up to support .NET just in case there wasn't any grassroots community who actually wanted to do it. Or maybe just in case there was and they couldn't control it.

   Ever been to SourceForge? Of course you have, everybody has because that's one of the hubs of all open source projects. You can go there and get the source of thousands of cool open source projects and it really serves the community well. There's even hundreds of projects now that list C# among their programming languages. So why did Microsoft feel compelled to create their own GotDotNet Workspaces that is clearly just a ripoff of SourceForge?

   A few reasons are fairly clear: First, at many of their workspaces you don't get in unless they know who you are. Ever been stopped at SourceForge and asked for a name and password to look at a project? What about download binaries or source? No? At GotDotNet you will, lots of projects are marked with a lock. Second, forget about all those messy licenses that Microsoft might not approve of, you don't need to worry your little head about BSD vs. GPL vs. LGPL. You've got the one true workspace license that you have to agree to, or else you won't be putting your project there. Lastly, well it's kind of obvious, but it's really all about control isn't it. After all, if you aren't under their thumb, that has to be a bad thing. So a SourceForge that they control is pretty much a requirement, isn't it?

6. It's a really sad way for a lot of people to waste a whole lot of time rebuilding that which already exists. Wouldn't the whole computing world be a lot better if there wasn't a team of people, maybe a couple of teams of people building complete copies of .NET for other platforms? If those same people were working on giving us new libraries and new tools for an already existing language instead of pouring in the thousands of man hours it's going to take to build a copy of the C# compiler or a .NET version of Ant and JUnit?

   In the end, we'll all just be left with another way to do the exact same thing only in a different language. Lord knows the world benefits now from being unable to share media between France, Germany, Italy, Spain, the US, and Japan because we can't all speak the same language. I benefit every day from the fact that I can't read a Japanese manga I might enjoy or understand a TV show from Europe. Once you are done building this tower, go build a few more right beside it using Perl, Python, and Ruby too. They're all trailing behind in certain areas, we need to make sure the same set of stuff is reinvented and rewritten for all of them too.

I'm tired now and I'm sure I can probably come up with some more stuff to add to rant but it's not really going to change anything anyway.

Posted by John Munsch at 5:16 PM | Permalink | Comments (4)

The Bean Scripting Frameworkhas finally made its transition from IBM (where it has been neglected for some time) to the Jakarta group of projects at Apache. Yay!!!!!

For some bizarre reason this isn't being trumpeted across every Java website in existence but I'm going to tell you why it should be. The BSF gives you the ability to hook many different scripting languages into your applications with only a little work. I myself used it to hook scripting into HotSheet and it took me 30 minutes. After that time I was able to run scripts written in any of six different languages and have them manipulate parts of my program that I had exposed to the BSF engine not to each individual language. Then the BSF made sure that each scripting language could access and work with my internal Java objects.

This gives your end users the ability to script your applications and they don't even have to switch to some scripting language that you cobbled together (ick!) or which is totally different from anything they are used to using. If they are already comfortable with Java or Javascript or Python or Rexx, they can feel right at home scripting your program using any of those or a few others.

Posted by John Munsch at 2:56 PM | Permalink | Comments (0)

I've released two presentations I wrote to teach Log4J and Ant. They are available from the new Presentations project I added to my project list. Please, please, please, give me feedback if you use them, look at them but don't use them or learn anything from them. I'd like to find out what worked and what didn't and find ways to improve the teaching materials.

Posted by John Munsch at 11:26 PM | Permalink | Comments (0)

When I was working for Vast Solutions in 2001, I built built a management console for JMX servers. It was very handy because Don was building a message-oriented-middleware server and it ran on top of JMX. So we had a server and an administration console that could run against multiple servers. I've never tried to reproduce that server as an open source project but I've wanted to. Now maybe I don't need to as the MC4J Management Console is now out.

It has the graphing ability that we had intended to add but never did. It doesn't seem to have the cool remote logging capability that we added though. Maybe somebody could merge in the code from Lumbermill. Now that would be really cool.

Then maybe they can add in the IBM Bean Scripting Framework and you'll have a scriptable management console.

Posted by John Munsch at 1:16 PM | Permalink | Comments (0)

The latest version of the Sun Java Development Kit has been released. It's a free download and it contains every single tool you need to be able to write simple or complex programs that will run on every major consumer computer out there. It doesn't matter if you want to target Linux, Windows, or Mac OS, you can do it.

If you've been thinking about developing stuff using something else, look at the tools available with Java and ask yourself why you would limit yourself to one platform or, if you have a multi-platform language, why you would limit yourself to the lessor tools and libraries available for Perl, Python, or Ruby.

Posted by John Munsch at 8:54 AM | Permalink | Comments (1)

One topic that has come up at work recently is teaching developers who do not know Java, or any object oriented language for that matter, how to program in Java. IBM's innovative solution is a game called Robocode. Developers can code up simple tanks that battle it out inside an arena that is provided by IBM. Each tank is a little software program which can be quite simple initially but get increasingly complex as the developer learns more and more about how to program in Java. It's a fun way to learn and IBM has tried to keep the barrier to entry low by providing simple instructions on getting started and lots of tutorials and articles to get you started.

Posted by John Munsch at 3:38 PM | Permalink | Comments (0)

If you have ever asked yourself, "Self. How should I really screw up an application that otherwise works pretty well," and you weren't sure what to answer, I can tell you. What you do is you use serialization for several large data structures and allow the serialization code to stay in the code long after you should have replaced it with a database.

Needless to say, that's precisely what I've done with HotSheet and I'm paying for it now. If you allow yourself to get up to many hundreds of news items in your list then performance is poor, startup time and shutdown time suffer, and best of all, if there is a crash or other event that causes HotSheet to exit without getting a chance to save, you are thown back to whatever the last saved version of everything was. Ow...

Posted by John Munsch at 12:37 PM | Permalink | Comments (0)

New versions of the NetBeans Java IDE (v. 3.4) and the JUnit unit test framework (v 3.8) are available.

I haven't put the new JUnit to use yet but I have started using 3.7 in a real XP environment (i.e. we are writing unit tests first and then coding to the unit tests). I can vouch for the new NetBeans though, it's got a degree of polish that the is really impressive. Having had a chance to look at the Personal edition of JBuilder 7 in just the last few days, I can't imagine why you wouldn't use NetBeans instead.

Also in the news, I was going to remove Blender from my list of resources because the company went under a while back. But then they announced a new drive to raise 100,000(Eur) to pay off creditors of the company so they could open source their 3D software. They are almost there, now is an excellent time to go pay and start anticipating the release of this software. With an excellent starting base like that for developers to work from, companies with crappy attitudes like the makers of 3D Studio need to seriously fear for the future of their over priced, dongled, can't resell it on ebay software.

Posted by John Munsch at 8:12 AM | Permalink | Comments (0)

You may have noticed my link to the Java Developers Almanac 2000 on my resources page before. It's an excellent catalog that cross references all kinds of Java classes, exceptions, parameters, etc. Because it's a reference book it's the one I pick up more often than any other Java book I have.

Well, Volume I of the new edition is out and Volume II is due next month if there aren't any delays. In the meantime you can buy the first volume and get access to all the highly useful code snippets from the book at the website for the Java Almanac.

Also, soon to be released is the third edition of Bruce Eckel's excellent book for learning Java; Thinking in Java. From the link to his website you can download either the complete second edition or you can download a beta version of the new third edition.

Posted by John Munsch at 4:04 PM | Permalink | Comments (0)

Two releases that are likely to be important to you if you are a developer, one is the new DbVisualizer 3.0 release and the other is the Ant 1.5 release.

Posted by John Munsch at 3:15 PM | Permalink | Comments (0)

There's a nifty looking site entirely devoted to sound programming under Java at Java Sound Resources. Might be a good thing to consult if you are planning to do a game or other sound program in Java.

Posted by John Munsch at 10:43 PM | Permalink | Comments (0)

I've always used a self-generated key to sign HotSheet (currently my only Java WebStart application) but it has always bugged me that it had to pop up this horrific warning whenever somebody ran it or else I had to pop for an expensive key ($200 first year w/ $100 each successive year). But not anymore, now there are instructions for signing Java WebStart apps using a free key and you might even be able to turn it into a full-fledged signature with a little work.

I hope to follow these instructions soon to clean up my own application.

Just a follow up: I have since followed the directions and it does indeed work. If you try out HotSheet you'll find that it no longer displays the alarming message it used to display and instead just asks for approval to run my app. Much better. Now if I can get Thawte's "Web of Trust" to authenticate me I might be able to get it to show my name on the screen instead of theirs.

Posted by John Munsch at 8:06 AM | Permalink | Comments (0)

Surely I'm not the only one to have shied away from setting up CVS access to SourceForge. In the past it has been highly cryptic and, in my opinion, pretty darn difficult for a Windows based developer.

But that's changed. If you use the new WinCVS setup instructions it will tell you step-by-step how to set up everything and get it working. As a result of those simplified instructions I've finally got CVS up to date (and it'll stay that way) for HotSheet.

Posted by John Munsch at 6:12 PM | Permalink | Comments (0)

UberCard has its first real update in a long time. I've put the draft text of the first three articles that discuss the development of UberCard on the project page and also put the information that used to be on the main page into the fourth article (which is not nearly as far along as the other three).

Please, send me some feedback if you have some either positive or negative on the articles.

Posted by John Munsch at 2:04 PM | Permalink | Comments (1)

There's a book on Java Look and Feel available at the bookstore that I'd not seen before Java Look and Feel Design Guidelines: Advanced Topics. As with the regular Look and Feel Design Guidelines the entire text of this one is available online. That leaves you with no excuse for producing Java programs which don't make sense and which don't look like the rest of the Java applications out there.

Posted by John Munsch at 12:47 PM | Permalink | Comments (0)

JRockit is a high performance Java Virtual Machine. It's designed for people running server side software (as so many are these days) using Java. BEA purchased the company and is now making it available for free for Windows and Linux based systems.

What would be really super cool is if they would open source the thing. I'm willing to bet that a few hundred eyes turned on the source code could find new ways to make it even faster.

Posted by John Munsch at 9:27 AM | Permalink | Comments (0)

Everything is new again so I'm going to do a quick roundup. There is a release candidate for Velocity 1.3. The SkinLF library has released version 1.2. The Poseidon UML editor is up to version 1.2. ArgoUML was the open source project from which the Poseidon UML editor started. It seems to have people working on it again after a long hibernation as it just released version 0.9.7. JGraph/JGraphPad recently released a new version with automatic realignment of items in the connected graph as you connect them. Lastly, Bouvard & Pecuchet 1.3 is out, it appears to be largely a bug fixing release.

Posted by John Munsch at 5:27 PM | Permalink | Comments (0)

Here's another connect the projects idea. What could you make from these projects?

• A Java library to playback MP3 and Ogg audio formats
• Catalog software for your MP3/Ogg files

One thing I can imagine is a "smart" version of the popular music players out there like WinAmp or Sonique. Most music players only have two basic modes of operation: play a specific song or sequence of songs (where the user is responsible for selecting and ordering the sequence) or play at random from a collection of songs.

But that's not really what I want. I want a DJ that plays only what I want and knows how to rotate the sequence in a way that I'm not going to get sick of. If I add a new song to the mix, I'm probably going to want to listen to it more often in the mix for a while with some kind of curve that pushes down the frequency over time so I don't get totally sick of it. Other songs in my collection may just be there because I grabbed them with the rest of the album when I ripped my CD and I don't really want to listen to them, nor do I want to delete them from the collection. So I need ways to put input into the system and give songs a thumbs up or down to inform the DJ how I feel about tunes.

Posted by John Munsch at 10:56 AM | Permalink | Comments (1)

There's a new Java game development website in town. http://deustachio.8k.com/ GameDev.net already reported this item but I thought I'd pick it up here too, because I get a different audience here.

Posted by John Munsch at 7:15 PM | Permalink | Comments (0)

Well, anything worth doing is apparently worth doing twice. Chainsaw is another UI to display log4j information. You may remember my mentioning Lumbermill just a few weeks ago. Hopefully they can work together to produce one uber log ui because I've got features I want. I'm trying to debug multi-threaded applications and I need to be able to see all the log events on one thread sometimes and all of the threads interleaved other times.

Posted by John Munsch at 4:45 PM | Permalink | Comments (0)

Here is a whole series of articles that IBM has done on the subject of usability. Usability of software is something that not a lot of people talk about. If HotSheet were much more than just a testing platform for me I'd probably spend the time to paper prototype the interface. In fact I may do it anyway because I know just how helpful paper prototypes are at smoking out serious problems in an interface with minimal work and I've already gotten a couple of complaints about the UI on HotSheet. BTW, some of these might sound like they are slanted only towards web usability but at least 90% of the stuff is generic to any kind of application, it isn't just for web based ones.

• Paper prototyping
• Empowering users with launchpads
• Crafting a wizard
• More Web-based wizard tips and tricks

Posted by John Munsch at 2:35 PM | Permalink | Comments (0)

Programming is becoming more like building than it ever used to be. We still haven't reached the kind of "Software IC" nirvanna laid out in the old book Object-Oriented Programming : An Evolutionary Approach but it's getting there very slowly. Now you can start to pick up all these different pieces when you look around and you start to see how they might be combined together. Some are tools and some are like different colored and shaped Lego bricks. There are still horrible hurdles to be surmounted because different languages don't necessarily mesh well, there aren't a lot of ways to call from machine to machine and from program to program but these are gradually getting easier. XML-RPC, SOAP, XML, and languages that work with a virtual machine like Java and Python are making programs more portable and making them work together better.

This is one of those pieces I pick up periodically and it just looks like it belongs in that toolbox that I'm building mentally. It's designed to make it easy for you to build programs that pipe XML data back and forth between them for processing. No one program might be able to do everything but given enough translators and workhorse programs to sort, chop, dice, translate, etc. it becomes possible to use something like this for tons of day to day work on everything from image processing to stock portfolio maintenance and website creation. And it would all work because XML can be treated as either a very specific thing relating only to a certain problem domain or it can be treated as a simple hierarchy of elements and attributes. But a good framework to work with it is always a start: XPipe

Posted by John Munsch at 3:59 PM | Permalink | Comments (0)

As promised I got around to testing the Log4j tool Lumbermill. Although it shows a lot of promise, at the moment it has only very basic functionality. Basically it just receives logging messages from a program using Log4j to do its logging and it builds a tree of log categories on the fly from the entries which can be used to set filtering levels (i.e. the standard levels for Log4j which are DEBUG, INFO, WARN, ERROR, and FATAL). Lumbermill recieves the log messages via TCP/IP so it can run on the same machine as the logging application or any other machine with a network connection.

Pros: Easy setup, simple interface.
Cons: Few features, out of memory errors when attached to a program that can generate 40MB of log data in a single run.

Also tested was the new version 1.1 release of Bouvard and Pecuchet. I have to confess that the last version looked neat to me but I never could get it to run properly. This version was pretty easy though. One thing to look out for though is that Pecuchet expects to be hooked to a good XML parser and it appears to be a bit fussy. I tried two different ones before I found that Xerces 1.4.4 worked well. For those who don't remember my previous mention of B&P, it is a tool that provides a more interactive view of all the data that can be gleaned from Javadocs.

Posted by John Munsch at 1:39 PM | Permalink | Comments (1)

There's a cool new project over on SourceForge to provide a nice logging interface for Log4j (and soon java.util.logging as well). It's called Lumbermill and I'll be trying it out tomorrow at work because we used Log4j throughout our latest project.

Posted by John Munsch at 8:41 PM | Permalink | Comments (0)

JavaGaming.org finally manages to get a semi-professional look to it. It's still very content light at the moment but we can always hold out hope that it will work hard to rectify that as well.

Posted by John Munsch at 11:53 PM | Permalink | Comments (0)

If you are at all interested in the direction that Java Web Start takes (it's now available on Linux, Windows, Solaris, Mac OS X, and probably soon BSD as well) then fill out the Java Web Start Survey here. Sun is trying to find out more information to improve an already excellent technology and they are wisely soliciting that information from outside.

Why did I say that BSD would probably soon have Java Web Start? Well, it's because of this announcement about FreeBSD. I was sure all along that the work done porting the JRE to BSD for Mac OS X (which is based on BSD) would pay off with a dividend sooner or later. Glad to see that it is sooner.

Posted by John Munsch at 9:13 AM | Permalink | Comments (1)

NetBeans 3.3 has been released as has Velocity 1.2. Last but not least is Batik 1.1.

Note that the new version of Batik now passes all of the static SVG test cases (i.e. image drawing where the image doesn't change over time). Nice job.

Posted by John Munsch at 10:31 PM | Permalink | Comments (0)

Even thought the idea of having Javadocs tags in your source is an old one, people are really trying to take it to a new level with applications that make better use of all that metadata about the code. For example, there is Xref-Java2Html which pulls together Javadocs and source code. Bouvard & Pecuchet is another project which attempts to give you a better, more graphical browser on the information in the Javadocs rather than being forced to work within the constraits of a browser and HTML.

Posted by John Munsch at 2:05 PM | Permalink | Comments (0)

The first generation of catalogs for applications that could be started via Java Web Start included Connect & Work, Puzzlecode, and Up2Go.net. Each hand edited its list of programs to keep it up to date and as a result have fallen farther and farther behind as new applications were released.

Puzzlecode has now introduced the next generation of the catalogs with a new release that allows you to submit the address of a new application and it will pull relevant details from the JNLP file itself to add it to the catalog.

Posted by John Munsch at 10:17 AM | Permalink | Comments (0)

DbVisualizer 2.1 is available. Because DbVisualizer is written in Java and uses JDBC it is a database tool that is independent of any particular database or operating system. That comes in mighty handy. Plus it's just a really good tool for database work. I prefer it to some of the tools that ship with the databases themselves. Let's hope it keeps improving.

Another nifty release today was the third beta of the Java 2 v1.4 SDK. Code named Merlin, this version adds pieces that were previously separate like Java Web Start, includes new APIs for handling I/O, logging, preferences, etc., and of course fixes bugs that existed in previous releases. Sun earlier said that this new version would be released before the end of the year and it looks like they are on schedule for that.

Posted by John Munsch at 1:31 PM | Permalink

Sun has decided to follow Microsoft's lead with Internet Information Server. Microsoft includes IIS (their web server software) with the server level of their operating system. Now Sun includes iPlanet with Solaris. I haven't decided yet whether I think this is a good, bad, or indifferent thing but it seems like an interesting thing.

Also on the news front is the release (finally!!) of MIDP for the Palm OS. With the MIDP you can write Java applications which run on Palm based handhelds. I haven't decided yet whether there is anything I really want to write that runs on a Palm but now I know that I can. Of course the libraries that are available on a Palm do not compare to what you can get on a desktop machine but you can do all the things in the Java language itself that you are normally used to doing so developers don't have to relearn everything to be able to develop for a handheld.

Posted by John Munsch at 9:57 AM | Permalink

Sprint is sponsoring a Java programming contest because the next generation phones they are rolling out next year feature J2ME. Obviously I think that is an excellent development, unfortunately the contest itself suffers from horrible execution. For example, your entry becomes their property whether you win anything or not. And you have to attend their developers conference in order to even submit your entry?!? No, I think it best to give this contest a skip but lets just admire Sprint for their wise choice of the best technology for embedding in their future phones.

There is a new release of my favorite file sharing program LimeWire Version 1.7 adds useful new features but the most important change is that it is now open source! Yippee! I hope somebody adds mousewheel scrolling using JMousewheel and allows installation via JNLP so I can be automatically upgraded when there is a new version.

Posted by John Munsch at 9:07 PM | Permalink

I've unloaded NetBeans 3.2.1 and substituted Forte 3.0 Community Edition. It adds more wizards and support for things like RMI, XML, and JDBC. They still keep their J2EE stuff in the Enterprise Edition but I think it's ahead of what comes with NetBeans 3.2 and way ahead of what Borland lets you have with JBuilder 5.0 Foundation Release. Like NetBeans the Community Edition of Forte is free.

Posted by John Munsch at 10:58 AM | Permalink

It's time for another quick round of "pieces that make building applications easier or cooler". Catchy name isn't it. Here are today's candidates:

• Skin Look And Feel 1.1 - Gives you an easy way to add "skinning" to your application. Among the features of the latest version is a new Windows XP look and feel.
• Ant 1.4 beta 2 - Actually, Ant already does pretty much everything I want and I haven't even begun to explore all its powers so I don't need a new version. But when a new version of one of the most important Java tools out there comes out, you should still at least take a moment to check it out.
• Velocity 1.1 - In the past I had only considered using XSLT to build templates and format data. But Velocity is so easy to use I'm rethinking that. I used Velocity once already to build a quick application and template that took a number and used it to build a custom graphic (data + Velocity template -> Velocity -> SVG file -> Batik -> .png file). It was very very easy and "very very easy" is not something I have ever associated with XML and XSLT.
• Vanessa, Rachel, Hazel, Clare, etc. The guy seems to have a thing for naming his programs after girls. But they are all nice girls. They help you look at your Java Web Start cache, verify that your JNLP file is correct, load resources and more. I've got this website listed on my resources page because of the excellent JNLP FAQ that is maintained there and the Venus app publisher you can use to help you publish your applications via JNLP. But you should also pay attention to the plethora of utilities that the author has created and all of them are centered around Java Web Start and JNLP.

And something that isn't really pertinent to anything but is cool nevertheless: dungeon, tunnel and castle pieces for roll playing

Posted by John Munsch at 12:40 PM | Permalink

Cool crap you can download and plug together to build amazing programs:

• JGraph - Easily the slickest of the graph libraries I've seen out there so far. It had no problems redrawing that I've seen, which is far more than I can say for GEF


• Batik 1.1 rc 1 - I've mentioned Batik before but it really needs your undivided attention. Batik takes a file in a format known as SVG (Scalable Vector Graphics) and renders it. SVG is XML based and like any XML or HTML can be easily generated by people or programs. Folks, this is like having an Adobe PostScript interpreter that you can embed right into your own application. Tell me you can't think of a use for that.


• Aglets - IBM's open source library for building agents has finally gotten some attention and there is a SourceForge project for it and the library has been updated for Java 2. For those with a long memory, this was one of the four projects I named in the past as being abandoned that should not be.


• Jabberbeans - A Java library to access the Jabber instant messaging system. Jabber technically specifies the protocol only so you can do either the client or server in any language on any platform. In practice it seems like everybody is still using just one server but there are already dozens of clients out there.

If you have enough of these pieces, programming starts to become more like master level Lego assemblies than like the painting process it has been in the past. Always before you had to paint every brushstroke on a canvas yourself. Now, you can take whole sets of material and begin assembling it to create something bigger with connecting code that you come up with yourself. It's more about how creative you are with the pieces than whether you have the endurance to write War and Peace.

Posted by John Munsch at 12:40 AM | Permalink

Good grief. I think I'm going to have to open a new resource section just to deal with all the:

a) Directories of Java programs available via JNLP
and b) projects associated with JNLP

Add to that list Jsh : OpenSource Java Shell. This one has several twists on the usual theme of supporting JNLP because it tries to run multiple Java programs in a single VM in order to speed up launching and reduce memory requirements. In addition, it supports regular Java applications in addition to JNLP ones.

Also, another directory of JNLP applications. This one is called Puzzlecode. They read my description the other day of the kind of features a better JNLP directory would have and it was indicated that I should keep an eye on them to maybe see some of those features in the future. I certainly hope that's the case.

Posted by John Munsch at 10:11 PM | Permalink

The source zip to the latest version of HotSheet is available on SourceForge. Just follow this link to the SourceForge project.

Is there going to be a war waged to be the central directory of all Java apps at some point in the future and nobody told me? I ask because I just found another new directory to compete with the Connect & Work External Catalog. It's called Up2Go.net and although its HTML is not nearly as polished, it has managed to find some new links to applications that I've not seen before. The sad part is that so many of the things you see right now available via Java Web Start are just proof-of-concept things. Most aren't complete enough to really attract people to the format. What is needed is a Freenet install, Photomesa, Limewire, and more real world tools and utilities that would attract end users to download and install Java Web Start or OpenJNLP in the first place.

Posted by John Munsch at 12:52 AM | Permalink

Been wanting to package up your application using a nifty JNLP file so users can download, install and run your program with a single click of the mouse? But you just aren't sure you want to spend the time to learn how to build a JNLP file? Try the Venus Application Publisher! (Note: I can't personally vouch for this application, I built the JNLP file for HotSheet by hand. But it sure looks neat and I think it would be hard to screw a program like that up. Plus the author seems to have four other JNLP related programs on his website as well.)

Once you have your program all ready to go off of a website, send a link to it to the Connect & Work External Catalog. They maintain a list of Java applications that can be run via JNLP and news about JNLP and the various installation programs that can use it (e.g. Java Web Start or OpenJNLP).

P.S. I've already sent them an email telling them about the Poseidon UML editor, HotSheet, and the Batik demo application. I'm sure they'll get them in the catalog soon.

Posted by John Munsch at 12:06 AM | Permalink

Interesting Articles:

Posted by John Munsch at 11:49 AM | Permalink

Could somebody please explain any of the following to me?

• Why does Sun have the JavaHelp system if they aren't even going to use it themselves? When you download documentation for the Sun JDK your available options are PostScript/PDF or HTML (nearly 7,000 files of HTML!). No JavaHelp option where we might have searchable documentation. Instead, Sun offers a link to a third party gizmo called DocFather that you are supposed to download if you want to be able to search the documentation?!? What the hell is that all about?

• And why does every Java paint program on the web have to look like this? That's not painting, that's Etch-A-Sketch with color selection. Yet there are dozens of applets on the net exactly like that one.

  Java 2D has enough built in features to help you construct Adobe Photoshop if you are so inclined and anything it doesn't have is contained in the new Image I/O API or the Java Advanced Imaging API. So why don't we have a real Java paint program?

Posted by John Munsch at 5:04 PM | Permalink

Correction: I mistakenly said that AmphetaDesk is written in Python. It is actually written in Perl. I also received word from the author that he plans proxy support in a later version (both AmphetaDesk and Peerkat could not be run from work because they had problems with the proxy server there).

Sun has been making various rumbling noises lately about games. That they intend to take games more seriously than they have before. In fact, they seem to have arrived at the point that Microsoft arrived at many years back when they finally threw away all their laughable half-assed attempts at games and settled down to do DirectX. Let's hope that Sun can learn from Microsoft in this case and produce some really good cross platform game libraries with some consistency to them. Good documentation and examples wouldn't hurt either. This article on IBM's developerWorks website summarizes some of the recent announcements from Sun with regard to Java gaming. The resources section at the bottom of the article has links to items mentioned in the text.

Posted by John Munsch at 8:26 PM | Permalink

I hope to eventually add scripting capabilities to HotSheet and also to another project I'm working on now. Over on Windows the best way to add scripting support to your application is to use ActiveX Scripting. Then you can support either VBScript or JScript or one of a few other third party choices like PythonScript.

The Java equivalent to ActiveX Scripting is IBM's Bean Scripting Framework (BSF). It allows you to choose between quite a few different scripting languages for your program so users don't have to know one particular language you chose but rather can use one that they are already familiar with if it is supported by the BSF. All well and good except that the BSF page only mentions Python support through the older JPython. The project that replaces it, Jython, which is currently supporting Python 2.0 and has beta versions that are closely tracking the current language isn't mentioned at all so I wasn't sure it would be available if I used the BSF in my programs. However, I ran across this today and it not only tells me that it is possible but how to do it. Now I can feel comfortable using the BSF as my scripting extension.

Posted by John Munsch at 1:08 PM | Permalink

Information about directions for Ant in a future 2.0 version have been posted. This is definitely a step in the right direction as it will make it easier in the future for Ant to be integrated as the build mechanism into software like Forte/Netbeans, JBuilder, or whatever else.

Had little time for programming over the weekend. My son turned eight (!) so there was a birthday party, etc. I did find time to add mousewheel support to HotSheet though. I haven't uploaded the change yet because it will require some testing first but it makes the user interface nicer for Windows users who have a mousewheel while we all wait for the native Java support for the feature in Sun's JDK 1.4.

Posted by John Munsch at 12:29 PM | Permalink

There's a new release of JBoss out. JBoss 2.2.2 has various bug fixes and you can download a version that is integrated with the new Tomcat 3.2.2 release.

What is QUB? QUB is a universal boardgame engine that lets you put the pieces and board for any game into it and it manages all the graphics and helps you play a game on the computer. While it currently has no real-time network support (no playing Ogre in a half hour against an old friend half way across the country at lunch), it is suitable for play-by-mail gameplay now. Since it's an open source project it is also likely to get somebody interested enough to try and add that network support.

The bad news? I'll let the developers tell you that one:

QUB is written under Linux, but it uses very little Unix-specific code. It should be possible to get it compiling under Win32, if we can get our hands on a Qt Win32 lib to link against. If you would be interested in doing this... (hint, hint).

That's a word I love to hear, "possible". WoW! You mean I can try and hack your code into working on Windows! Or the Mac! And do it again for Solaris! And god-knows-what else! Bestill my heart. Or better yet, drop the language with no support for the net, no cross platform capabilities, no built in UI functions at all and move to Java, or even Perl or Python for goodness sake. At least then it will come to my platform without my having to sweat over it first. Personally, I would love to have this program but I really want it to be a one-click install with automatic updates whenever new versions come out. Do we know any languages that have that?

Posted by John Munsch at 10:13 PM | Permalink

Very interesting review comparing one developer's experiences with WebLogic 4.5.1 and 6.0 (as well as the commerce server) with JBoss. Hint: He likes JBoss way more than you might think.

Posted by John Munsch at 10:30 AM | Permalink

Whoa Nelly! Hot on the heels of their 1.3.1 release Sun has released a beta of the Java Development Kit v1.4!!

There are a whole variety of diverse improvements promised in 1.4 including support for mousewheels, improved speed in offscreen rendering, speed improvements, and lots lots more. I'm definitely keen to try it out.

Posted by John Munsch at 8:18 AM | Permalink

There are just not enough hours in a day to do all the stuff I want to do. Anyway, to the updates:

• Java Web Start 1.0.1 is out and it seems faster and has a variety of bug fixes and improvements. One thing to note however is that after installing it HotSheet would not run from the shortcuts it had placed on my desktop and main menu. I had to click on the link on the HotSheet project page and it downloaded, installed, and ran it just fine then. Perhaps installing it dumps the cache of existing applications you already have but it doesn't get rid of shortcuts you may already have. Anyway, it works great now and starts up quicker too.
• Want to do nifty vector type graphics from within a Java program but don't feel like mastering Java 2D in order to do it? Well, one option would be to output a Scalable Vector Graphics (SVG) format file describing the graphics, like a complicated graph for example, and then using Batik 1.0 to render the SVG file. Apache comes through once again with excellent Java technology that you can put to real use in real programs. If you are keen to try it out, use your newly installed copy of Java Web Start and click on the demo link on the Batik website. You can do a one button install of a demonstration of the Batik engine from the page and try it out.

Posted by John Munsch at 8:18 PM | Permalink

NetBeans 3.2 final has been released. If you haven't already looked at it, go do so, it is among the very best Java IDEs out there. If you have already looked at it then you are likely using it, so upgrade.

Posted by John Munsch at 8:25 AM | Permalink

Not a lot to report today. Wanted to get a plug in for my best friend Don Thorp's site, he's just getting a new XML/XSL version up and going which means I'll probably tap him as a guinea pig at some point when I've got a web logging tool ready :)

Also, the first release of code for the JXTA project. Juxtapose is an incubation project from Bill Joy and Sun to produce an infrastructure of common elements needed by peer-to-peer software. I've downloaded it but a quick attempt at running didn't tell me much. I think I may have to try actually reading the documentation.

Posted by John Munsch at 10:49 PM | Permalink

Netbeans 3.2 RC3 is out and it really has some nice improvements over v3.1. The form editor is much much more WYSIWYG and you can run it in MDI mode so you don't have half a dozen windows floating around on your screen anymore. If you haven't picked a Java IDE yet or you are using JBuilder then you owe it to yourself to at least give Netbeans a look. I believe that Netbeans is much better than JBuilder and if you are using JBuilder because you need to have a commercial IDE with support you can get Sun's Forte which is an enhanced commecial version of Netbeans with support.

Posted by John Munsch at 11:10 AM | Permalink

There's a new project I ran into today that I'm not sure I understand. It's called OpenJNLP and if you are familiar with Java WebStart you know that JNLP is the file format that tells WebStart what to download and how to run what it downloads. This is an open source version of Java WebStart and at present I can't see a lot of use for it because WebStart works quite well.

A project that is very very clear in its usefullness is jBoss. jBoss is an open source J2EE application server that provides all of the things you expect (i.e. EJB container, JSP support via Tomcat, JMS, etc.) Since I need to immerse myself in J2EE to extend what I've already learned about J2SE this looks like what I'll use to do most of my development.

Posted by John Munsch at 2:35 PM | Permalink

Want to know what is going to be in the Java SDK 1.4? Sun has posted a final draft of the JSR describing it: JSR-059

Lots of other Java news today including one item that should be near and dear to the hearts of Java programmers everywhere but all too often is obviously not. The Java Look & Feel Guidelines 2nd Edition is now available! You don't even have to buy the thing folks, just go look at the HTML version online whenever you've got a UI question (i.e. which menu should this item should go on, what should I put in the title of this error message box, etc.) It takes only a few minutes to go look up one of these answers and people might actually know how to use your application if you tried to be at least a little bit consistent.

Here's my new business card:

Rockelle and I designed it and I'm really really happy with it.

Posted by John Munsch at 12:06 PM | Permalink

Another new article on the JDK 1.4. It pulls material from some of the items I listed before but includes some things that I hadn't seen.

The magic of Merlin - JavaWorld March 2001

Posted by John Munsch at 9:21 AM | Permalink

Today is musings day at Rarebit Fiend:

I can't help but wonder why there aren't a million interfaces to Freenet available already. If you want to interface the Java code directly into your program or call it from the command line it would take some effort to build an interface. But with the proxy interface (FProxy gets started automatically for Windows nodes) all that you have to do to download a file is pull a URL. You really can't get any easier than that in Java or most other languages these days, it's only about one line of code.

I've played EverQuest a few times recently. It is truly, seriously butt ugly! I developed a very simple 3D world for Crystal Semiconductor several years back using the old Direct3D Retained Mode (which is no longer updated as part of DirectX so don't bother using it). That engine was developed five years ago and yet I'll swear that EverQuest doesn't look one bit better. You'd think that with all the really nifty 3D engines out there that they would have simply licensed something and used it.

Speaking of 3D, Java 3D has evolved to a point that installation and use (at least on Windows) is really quite easy. All that it does is put a new extension JAR file into your extensions directory. After that you can go to their examples page and it will display various 3D examples using the Java plug-in. Because it uses the plug-in, it's compatible with any popular browser from version 4.0 on. I wonder how much effort would be required to get an engine that looked as good as EQ going using Java 3D. Given the wide availability of Java 3D on different platforms you would have the first multi-platform massively multi-player online game :)

Sun just released a sample application showing off Java 3D called the Java 3D Fly Through. This picture shows what it looks like:

Posted by John Munsch at 9:19 PM | Permalink

Feeling like crap today. Sandpapered throat, aches, usual &(*@. Anyway, enough of my whining.

I did manage to look at the JAXP 1.1 library from Sun last night and they have an example called SimpleTransform that simply combines an XML and XSL file dumping the result to a third file. I can just take the very simple code out of it for my weblogger. Likewise the FTP example that goes with NetComponents seems to work well for uploading a file but only if you don't have a proxy and I can't find anything about how to set the proxy settings in the documentation. I find it hard to believe that they don't have support for proxies so I'm going to send them some email to see if I can get an answer and post my question on jGuru to see if anyone else answers it. If they give me an answer then I can make my first contribution to the jGuru FAQs.

Posted by John Munsch at 7:42 AM | Permalink

I've had a devil of a time finding a lot out about the next version of Java (SDK 1.4, codenamed Merlin). Here's everything I've managed to dig up so far:

• Java 1.4 and Beyond
• Merlin Feature List
• Coming Swing API Changes for Java TM 2 SDK, Standard Edition, v. 1.4
• New Java 2DTM Features in the JavaTM 2 SDK, v1.4

Posted by John Munsch at 11:24 AM | Permalink

NetComponents a Java library for FTP, NNTP, and many more protocols. Looks pretty solid, guess I'll find out if it really is :)

Posted by John Munsch at 2:41 PM | Permalink