John D. Mitchell's Blog

Tools Archives

JPC: x86 Emulator on the JVM

Okay, I must be slipping... I can't believe that I've either totally missed this or completely forgotten about it:

At each JavaOne, I end up asking lots of people what, if anything, they've seen that's particularly cool, interesting, etc. This year, I was chatting with Cliff and he mentioned JPC -- an open-source emulator for x86 code.

JPC is written Java and so you can run all sorts of old DOS programs on any machine that supports the JVM. This includes a lot of old DOS games. [And now I feel old for playing too many of them when they were new.]

Hmm... I wonder if I can find some old GEOS disks and get it installed and running. :-)

FindBugs in Anger

If you aren't already using Findbugs then hopefully you've at least heard about it by now and have some idea of how useful it can be.

If not, then let me say that FindBugs is a must have tool in the arsenal of any Java developer and any development team that's not using it as part of their regular development practices is incompetent.

Bill Pugh has done a fantastic job making FindBugs a great F/OSS tool which helps detect a large variety of all too common programming mistakes in Java.

You can find an online demo, slides from last year's FindBugs introduction , and can even run FindBugs over the web.

If you aren't yet convinced that FindBugs is really useful, let me point out that I've used FindBugs as an expert witness in cases where outsourcing projects had gone wrong and people were arguing about the quality of the delivered code (among other things). You have been warned. :-)

Go wild!

JaveOne 2007, Enterprise Search-Driven Developement

One of the most exciting things at the show this year is that my company, Krugle, announced the beta of an enterprise search appliance for development teams.

After all the months of labor, I can finally share our little bundle of joy with the world. :-)

In my experience, one of the biggest problems that enterprise developers face every day is finding useful information across the bazillion different silos of information that we have to deal with just to be able to work on our projects. Specifications, design docs, source code, issue trackers, mailing lists, notes, blogs, wikis, souce code control systems.... Mixing in time-to-market pressures, cost reduction, reuse goals, agile methodologies, and the like pushes us to a just in time way of life.

Finding relevant information amid that chaos is all too often painful and labor intensive. So, the core feature of the Krugle Enterprise appliance is to pull all of those silos together and make information available via search. This search-driven development approach is how development teams really work these days -- developers looking for example code, QA looking for bug fixes, maintainers trying to figure out the impact of making a change, managers looking at risk indicators, etc. -- we're bringing it all together.

Of course, I'm totally biased so ignore my blathering and check it out for yourself and your team.

JaveOne 2007, Community One

Sun is, as everybody knows, struggling to get mindshare around their products. This is especially true as they try to get uptake as they open source more of their stuff -- such as Solaris.

Hiring Ian Murdock of Debian fame is a pretty good idea to me. One of the biggest hurdles to (Open) Solaris uptake is the fact that so many things in dealing with Solaris are so annoyingly odd to all the folks who are used to the relatively consistent GNU userland experience and the usable package managers on Linux and *BSD distributions.

Another item that came through over and over again throughout the day was that one of, if not the key reason to use Solaris is DTrace. DTrace is an efficient execution tracing framework and if you haven't used it, you're missing out. Story after story from a wide variety of developers, sys admins, QA folks, etc. touted how using DTrace allowed them to get insight into the actual running of their systems and how big a difference that can make. While it's an open question of whether/when this will make it to Linux, DTrace is already in the next version of OS X and will be in the *BSDs sooner rather than later.

I must say that I was surpised how little I saw emphasizing the coolness of ZFS. It's a modern filesystem designed for the current disk storage and usage reality rather than how things were 20 years ago. Coupling ZFS with Sun's Thumper box is, IMHO, a compelling reason to actually buy Sun hardware. There's no really good filesystems in the open source world if you actually care about your data and want good performance and manageability. ReiserFS is pretty much orphaned and while the ext family are okay for desktop and non-critical servers, they just don't cut it when the data really matters.

Of course, for Java developers, the question is pretty much moot as to whether it's any advantage to go with Linux or Open Solaris. Java runs well on both. It was quite funny to hear some pushback to Greg Luck's (of ehcache) comment that OS doesn't really matter -- just a good JRE implementation. That's just playing out the old Java mantra of "write once, run anywhere" in the real world. Of course, operating system choice does matter to a point -- Greg's own company is an example of moving from ASP.net to Java because of scalability / performance reasons and days vs. months and years of uptime.

For me, I've used all of them for so long that it's mostly just a question of using what works for any given need. I'm hoping that the continued opening up of Solaris will help spur improvements in the Linux world and that many of the things that we love about the OSS operating systems will help improve Solaris so that moving around from one to the other is even easier.

Krugle is hiring

Yes, it's true that I've been lax in my blogging so far this year because I've been working as the Chief Architect of Krugle. Sure, I've written some entries on the Krugle blog but living the startup life is definitely not conducive to regular blogging -- even at a company whose blogmaster is none other than the wild and crazy Chris Locke of e.g., The Cluetrain Manifesto fame (and the rest of the team ain't too shabby, either :-).

What we're creating with Krugle is a search engine for software developers. I.e., no more pawing through pages and pages of Google searches, hunting around various web sites, etc. trying to find useful results for technical information. We're crawling millions of technical pages and sucking down terabytes of source code using Nutch, processing pages with Antlr-based parsers, and serving up the search results using Lucene.

The site is currently in a limited beta and we're getting great feedback. I just saw that we're the most anticipated launch on the Museum of Modern Betas. Heck, that's even cooler than winning a DEMOGod award.

So, if you know any take-no-prisoners, hardcore people who want to work on a project that's actually making developers' lives better... Krugle is hiring.

Humane interfaces, simplisticity, and domain languages

Elliotte Rusty Harold has touched off a small war in his response to Martin Fowler's recent entry on so-called Humane Interfaces.

One facet of the debate is an example comparing the equivalent "List" classes from Ruby (Array) and Java (java.util.List). Java's list class has 25 methods while Ruby's has 78 methods. Martin uses that fact to conclude that Ruby's list class is somehow more "humane" while Elliotte's thinks it's just bloated and that a minimal interface is better in terms of how people work.

Martin's primary argument for the "more is better" approach is that:

Humane interfaces do more work so that clients don't have to. In particular the human users of the API need things so that their common tasks are easy to do - both for reading and writing.

More buttons/methods does not make an object more powerful or more humane, quite the opposite in fact. Simplicity is a virtue. Smaller is better.

As you might have guessed, I think both of them are partially right and that there's something even more important that they are really bringing up that should be discussed.

For example, list.first() is actually more humane/usable/readable/etc. than list.get(0). Why? Because the intent needs to be clear and obvious to humans, not just the compiler. Even worse, crap like list.get(list.size() - 1) is just plain wretched compared to list.last() -- intent, clarity, complicatedness, easy to get wrong (off by one), etc. Also, look at how many parts of the list abstraction are "leaked" in just those two examples such as linear positioning, indexing, zero based indices, the first element is "always" at position zero, reliable sizing, etc.

However, Elliotte is completely right that having 78 methods in any class is an atrocity. Something that has that much surface area is way too complicated for humans to keep manageable. In addition, it also sets a bad example for coders learning the recommended ways of doing things -- i.e., "just throw anything you feel like in there."

Going to the opposite extreme of a bare minimum, necessary set of methods is also too simplistic. For example, Elliot throws downs an image of various remote controls, two fairly complicated "universal" remotes and a minimalistic one from Apple. But, who gets to chose what that minimal set will be for everybody? In software, almost everyone will end up wasting time and introduce bugs by writing their own versions of truly common bits of code. Software is, in this regard, much more of an engineering practice than a mathematical reduction.

Hopefully it's obvious that there's a reasonable middle ground. Like any good standard, deciding on what to put into the core library should be about codifying truly common behavior rather than what might sound good to any one special interest group. Other important tools in this effort are things like good design principles and refactoring. [I find it ironic that Elliot brought up the issue of refactoring in a debate with Martin.] Also, the both extremes miss out the addressing the specific needs of the context in which the code is being used: a pro using something everyday vs. a serious hobbyist vs. a random user vs. a half-blind grandmother with rheumatoid arthritis vs. .... Context matters.

Alas, arguing back and forth over those sorts of details makes it easy to miss a fundamental, crucial point: no software (library, application, language, operating system, or whatever) can be all things to all people. Fighting that war is not only pointless but is one of my definitions of insanity. The point of a chunk of good software is to enable the effective and efficient creation of more good software and to help inhibit the creation of bad software.

So, how do we then build up our own code to fix whatever shortcomings we find? Build our own libraries on top of whatever the core gives us which provide the clean abstractions and domain specific languages to get our jobs done, well.

Piss Poor Web Security Approaches

Pete Freitag writes up 20 ways to Secure your Apache Configuration. Now, all 20 tips are useful to help make Apache less insecure but they certainly don't make an Apache installation actually "secure."

First off, note clearly how many things you have to go out of your way to turn off. That is, look at all of the extraneous, insecure junk that is installed and configured as part of a default Apache setup up. That's a big violation of the security dictum that we should be secure by default and have to explicitly take action to add in extra, insecure things. An example of why this is so important is that if you actually go through all of this tightening and then upgrade that server and forget to go back through and do all of the tightening again... Oops, not only will your system be insecure again but you'll probably be under the false assumption that your system is secure when it isn't. I've seen this happen way too many times to my clients and friends.

Second, if one really cares about security, why on earth would anyone consider Apache at all? There are many much better http server solutions out there for anyone needing serious security such as publicfile. Publicfile takes an arguably extreme approach and is fundamentally incapable of the vast majority of web server security problems. Therefore, other web servers such as the venerable, static-speed demon thttpd, the new, feature-rich kid on the block, LightTPD, or even the commercial king-of-the-hill Zeus Web Server can be a much better blend of increased security and increased performance.

Of course, if you're doing Java-based web server applications, Jetty and Resin are great solutions but they also tend to err by having way too much enabled by the default configurations.

DSLs feelin' groovy (or, graduating from elementary school)

Ben Galbraith has posted the first of a series of blog entries about How I Learned to Love Domain-Specific Languages. It's great that more and more people are starting to see the value of explicit, focused languages over ridiculously inhumane "formats" like XML. Hopefully, we're finally reaching a tipping point.

Explicit DSLs feel weird to a lot of programmers because there's been so little mainstream focus on them. I.e., as shown by one of the comments, developers have been herded and otherwise sucked in by shiny-looking tools (by poor education, management, laziness, peer-pressure, ignorance, lack of training, marketing hype, etc.) and haven't (consciously) realized the power of domain languages. It's amazingly odd to me how little energy has been applied to languages among mainstream developers given how much programmer time is spent arguing about the minutia of programming languages and tools.

The fact is that we're already surrounded by and are constantly implementing "DSLs". Look at the "language" of printf and friends, the declarative "specification" of makefiles, the myriad "protocols" that we deal with everyday like HTTP, SMTP, SSH, and FTP, the "APIs" of code libraries, the "design patterns" embodied in frameworks, the analogies and "metaphors" we use to described software architectures, the implicit languages that we create each time we define a class, the jargon we use to talk with each other, etc.

A big part of the problem that I see happening right now is that too much of the discussion around "DSLs" is being framed as some sort of "either/or" / "black/white" conflict when it's really just a more conscious and explicit approach to things that we've already been doing. Whether it's the hype juggernaut of Ruby on Rails or the Java is old, boring, bloated, etc. ideas exemplified by Beyond Java or the "IDE" wars between Eclipse, NetBeans, IntelliJ IDEA, and Emacs, or whatever, the biggest issue with this "us/them" thinking, IMHO, is that people are fighting the wrong fights. The leverage that matters most is the ability of developers to think and communicate clearly with themselves, each other, systems, business folks, and users. Biologically and sociologically, human are built to be linguistic.

That is, languages are fundamental to how we work internally and with each other. Sure, we have various tools to help us communicate but isn't it clear that e.g., PowerPoint isn't the point, it's just a tool — and, alas, a tool that usually induces poor communication rather than enriching conversations). On the other hand, look at the "modern" killer apps and how they are all about helping us (manage our) communicating: email, web, blogs, P2P, wifi, cell phones, faxes, VoIP, agile/XP, open source, etc. I.e., we've graduated from the elementary school building blocks (word processing, spreadsheets, databases, Belief of Control, etc.) to the middle school of communication. Now, we just need to learn and develop languages and tools built around this new level of understanding and put aside our old, comfortable, but ultimately dead-end habits.

GCC turns 4.0

The GNU folks have released version 4.0 of the venerable GCC compiler with built-in support for the C, C++, Objective-C, Ada, Fortran, and Java programming languages.

The biggest general change is the completely new intermediate language representation based on tree SSA. SSA (Static, Single Assignment) is a modern approach to the intermediate representation of the parsed programs which allows for a much more sane and aggressive approach to optimization.

On the Java front, the GCJ sub-project has made major improvements including better support of AWT and Swing and a lot more of the other Java libraries such as java.util.regex. If you didn't know, GCC can generate native (machine-specific) binaries directly from Java code.

Check out the ChangeLog for more details.

Steele Fortress

Guy Steele is leading a group to build a new programming language called Fortress. In homage to the old SATs, Fortress is to Fortran as Java is to C++. :-) That is, Fortress is about doing high-performance number crunching. Alas, Fortress is not yet available for us to play with. The complete article is: The Soul of a New Programming Language.

The most telling quote:

"I'm now not convinced that a single programming language can serve everyone's needs, because the needs are so diverse." —Guy Steele

Thanksgiving, Reuse, and Slack

In Leftovers, Dan "Superman" Steinberg brings up the question of how to deal with reuse in this age of agile, lean development.

One trick is to just have a really good memory. Alas, given that most of us are human, that doesn't seem to work too well in practice. :-) Given that we're tool users and creators, we do have some options in helping us remember. A classic is a catalog of index cards -- the post-modern equivalent: a big junkyard of code (and you do, of course, keep *all* of your code in a repository, right?) and a local search engine. Another trick is creating and using an orphaned code wiki -- i.e., if the code is something interesting enough to save, add it to a wiki.

Dan asked "With coding - how do we think of reuse? Are we at a point where we start planning for our code leftovers? XP teaches us not to code for situations we don't yet need, but a customer could have a reusability story." Basically, the question is where does "reuse" fit in with the core computer science notions of necessary and sufficient? IMHO, the missing key is the notion of slack. Is there enough slack in the system to allow it to function reliably and robustly in the face of change? Most developers are exposed to this notion in practice in dealing with performance but slack is crucial in all aspects of software. To continue with Dan's food analogy, the orphaned code wiki, for example, is akin to putting leftovers in the freezer.

Big thanks to Dan for his tireless efforts in making the world a better place.

Java J2SE v1.5.0 FCS Released

Java J2SE v1.5.0, aka "Tiger", has been officially released by Sun.

Is this all that you hoped it would be?

Sun says no decision on open-sourcing Java

Well, the earlier blather about the potential of open-sourcing Java seems to be squashed by this report.

The biggest thing, IMHO, is Gosling's quote implying that there is a serious discussion about this going on inside Sun.

Sun considering some sort of "open source" for Java, maybe

Gee, could this be any more wishy-washy? This article in the Inquirer quotes Sun's Java Technology Evangelist, Raghavan Srinivas saying that there will be an open sourced version of Java: "It might be today, tomorrow or two years down the road."

Ah, the original source article has a bit more information.

Playing with Java v1.5 on Mac OS X

Sam Pullara has done some work to help people run some of the Java v1.5 features on Mac OS X. Note that his work is based upon the bundles made available as part of JSR-14 and is therefore a bit out of date relative to the official releases for other platforms (even more so when the next official beta is release in the next couple of weeks).

I don't know about you but I'm finding Apple's lackluster commitment to Java on Mac OS X a bit frustrating.

SubEthaEdit turns 2.0: Is that a good thing?

For the most part, SubEthaEdit is just a tidy little editor that runs only on Mac OS X. However, it's claim to fame is the fact that it supports concurrent editing of documents by multiple people. SubEthaEdit is a fascinating tool for collaborative editing things like conference notes or, heaven forbid, source code (i.e., pair programming where you don't have to strain your neck peering over each other's shoulders :-).

In the v1.0 days, the license was basically donation-ware and there was a clear statement in the FAQ that talked about them cleaning up the code to release it as "open source". Alas, in this v2.0 release, the license has gotten more pointedly commercial (with a non-commercial/demo/trial exclusion) and all mention of any open-source take has disappeared. Now, it's their code and they can do what they want with it but I must confess that I feel misled.

To add insult to injury, v2.0 has switched to a completely different protocol (based on BEEP, blech) and there's no interoperability between v1.0 and v2.0. What are they thinking?

The Tar Pit of Programming

Frederick P. Brooks, Jr.'s classic, The Mythical Man-Month: Essays on Software Engineering is the first selection for the java.net bookclub.

I'm honored to be the moderator for this first bookclub foray and I expect things to get boiling as we attempt to address the tar pits in which we are stuck. I hope that you will join us in examining and discussing the fads, fallacies, dreams, and harsh realities of modern sofware development.

Would you like fries with that?

According to this EWeek article, Sun has a promotion through June, 2004 wherein a purchase of Sun's Java Studio Enterprise product subscription also gets you an AMD Opteron-based SunFire server.

The catch is that the subscription cost is $1500 per year with what looks like a 3 year commitment.

I do like the switch to focusing on the hardware as a support for the software.

Apple Flashers

Luckily for us, Steve Jobs debuted the iPod mini in his MacWorld 2004 conference keynote. It's tiny and very slick. Even better, the control felt pretty nice. Alas, in all too typical Apple style, the $249 price tag is just plain silly -- they should have hit the $199 price point.

Apple does get the Best Revisionist Video Award for reshowing their seminal 1984 TV commercial with an iPod digitally inserted onto the body of the running woman. Alas, I must say that the giveway of a poster of the ad was a big let down.

Long-term, there are two other announcements that I think are much more important. First off, Jobs also debuted the new G5-based Xserve and Xserve RAID servers. It seems that Apple is finally starting to actually put in the serious enterprise-class features like EEC memory and "dual" everything. I'm going to have to actually consider them now.

The biggest announcement is the new iLife '04 application with the non-i name... GarageBand. GarageBand is basically a music making program. Now, I'm no music software geek but the demo with Jon Mayer was very impressive -- especially supported guitar instruments. Create a garage band without the garage or the band (or any talent :-)! Mayer said that if he had this when he was 13, he would have never left his room.

J2SE v1.5.0-alpha availability with JSR-166 updates

Rather than being forced to register at JavaLobby to be able to get access to the release, you can download the Java 2 SDK, Standard Edition v1.5.0 alpha release directly from Sun.

People interested in the JSR-166 Concurrency additions should note that the Tiger alpha release does not contain the latest version of the package. You can get the latest version from the JSR 166 resources web site.

"Raving" Lunatics?

Dan Steinberg mentions:

Vincent's post about the dependence of Sun tools on NetBeans seems to imply why Sun is not prepared to fold or merge NetBeans into Eclipse.

when talking about Vincent Brabant's blog entry about "Project Rave" and my blog entry about NetBeans staying separate from Eclipse.

Indeed, Sun's own Rich Green has talked about Sun's concerns of that they not "abandon the constituents" (users) of NetBeans. Green also expressed his concerns over IBM's domination of the Eclipse project. Gee, that certainly makes it sound like the negotiations fell through because both sides fought about control over the merged project.

So, even with these nominally open source projects, to the people/organizations involved, it's still all about who's the boss.

Sun bails on NetBeans merger with Eclipse

It seems that Sun has chosen to discontinue discussions about coalescing NetBeans with Eclipse.

From the perspective of Java developers, does this really make any difference? The competition seems to be helping make both platforms improve faster than they otherwise might.

However, from the perspective of trying to grow the Java developer market, especially w.r.t. the Microsoft juggernaut, the lack of a dominant development platform is a bit of a detriment.

Are debuggers a wasteful timesink?

Bob Martin starts a raucous discussion when he states that Debuggers are wasteful Timesinks.

To paraphrase a character from the last Matrix movie... Debuggers are just a tool. It is how the tool is used that is good or bad.

Enforcing Model-View Separation in Template Engines

Terence Parr, creator of ANTLR, writes on why Enforcing Model-View Separation in Template Engines is a Good Thing(tm).

Ter created an implemention expressing this separation, StringTemplate Template Engine, which he's used to build a number of web sites, including jGuru.

JavaOne 2003: Java's Debutante Ball

Check out my article looking back on the weird and wondrous happenings at this year's JavaOne show.

Java Raves

This article talks about the upcoming demonstration of Project Rave from Sun. Basically, Rave is a new, integrated development tool for Java built on top of NetBeans. Though, at this point, I've gotta say that it's going to have to be truly stellar to deserve more than a yawn from hard-core developers.

This work is licensed under a Creative Commons License.