John D. Mitchell's Blog

Open Source Archives

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.

JavaOne 2007, Startup Camp 2

Is this really JavaOne? Walking around downtown San Francisco in May wearing a t-shirt and shorts and not freezing to death? Record setting heat must be boiling my brain!

I spent most of Monday at the Startup Camp 2 festivities over at the old Argent Hotel. Startup Camp is an open space unconference hosted by Sun and run by the nice folks over at Mass Events Labs. If you've never participated in an open-space style conference, you definitely should -- but don't expect to just sit there -- it's really exactly what you make of it. Note that the notes from each section should eventually make it up to the wiki so check that out for more information.

I went to a session lead by Josh Berkus that was about MySql vs. PostgreSQL. It was much less contentious than I expected. :-) It's great to see PostgreSQL getting more exposure -- especially given how much (undue) credit MySQL gets around being "open source" when it's not completely true. I.e., when it comes down to it, the single biggest reason to chose one or the other is licensing. PostgreSQL's BSD license is a Very Good Thing(tm). In terms of performance, there's definitely a lot afoot with both projects... MySQL is getting better at vertical scaling and PostgreSQL is getting more horizontal support (for things like "clustering").

Another session that I went to was lead by Jason Hoffman of Joyent about the tradoffs of hosted vs. building and managing your own data centers especially as your service starts to grow and you need to start worrying about scale. What made this session cool is what open space conferences are all about -- audience participation. Lots of experienced folks in the audience sharing their war stories.

The money quote of the day came from Josh Berkus (gee, am I a stalker?): "Databases scale poorly." This basic sentiment came up over and over when talking about how to effectively and efficiently get better performance for those hard-earned (or hard-begged :-) startup dollars. Databases don't scale linearly in terms of cost. Moving business logic out of the database leads to up to a 5X improvement in terms of cost (according to a study by Sun). That's a big deal but I'll leave further exploration of that to a future blog.

The wackiest thing at Startup Camp 2 was the "Speed Geeking" general session. Think: speed dating for startups. Each startup that wanted to present itself was given a big round dinner table and had a few minutes to make their pitch/demo/whatever to each small group of interested people. I'm sorry but the Rate My Poop idea is not something that I even want think about -- I'm going to have nightmares.

I also attended a session on pricing of SaaS/"on demand" services. Alas, I hosed my notes of who was running that session -- my apologies. Lots of good discussion but two key takeways were to remember that it's not just "software" but also a "service" and that trust is a key component to any relationship.

JavaOne 2006: Questions

As JavaOne 2006 officially starts today, there are lots of excited attendees floating around with lots of questions in their heads: How do I write Java code to deal with all of these new multi-core chips? How do I create Java-based web services quickly and easily? Who's giving out the cool schwag? Where are the parties worth going to? What sessions should I attend? Is Ruby (and Ruby on Rails) really kicking Java's ass? Why hasn't Sun given me a T2000 server? Why is it so cold in San Francisco in May? What is Sun's marketing team going to try to shove down everybody's throat this year? You know, the usual gamut of questions. :-)

Of course, with Jonathan Schwartz taking over for Scooter, the key question for a lot of people is: "Will Sun 'open source' Java?" Well, perhaps a better way to phrase the question is: "How will Sun deal with the issue of 'open sourcing' Java? Will Sun continue pretending that Java is already "open source" or will they actually take a true leadership role in moving Java forward?

Frankly, given Jonathan's latest blog entry, it sounds like he's going to continue Sun's delusional posturing. If so, he's going to have lost his best opportunity to ensure Sun's continuance as a company, let alone as any kind of leader. We need look no further than the most recent round of SGI's implosion to see a very clear example of what happens when a once-dominant company gets so entrenched in their own delusions of grandeur that they fail to adapt to the reality all around them.

Hopefully, Sun will be able to overcome its own fear so as to be able to make the next step.

GPL v3, draft 1 released

The Free Software Foundation has released the first public draft of version 3 of the Gnu Public License. The rationale document might be a more interesting place to start reading to about what they've changed so far and why.

Updates:

Note that folks using non-Gecko based browsers are not able to view or add comments about the draft on the web site but you can submit comments via email.

For those who can't read the draft easily on the official website, Tim Bray has put up an easy to read version that is suitable for printing.

Simon Phipps and Danese Cooper co-wrote their notes from the release presentation.

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.

Sun to open-source SPARC architecture

Sun's open-source evangelist, Simon Phipps says that "the Verilog source code, tools and more behind the UltraSPARC T1 (the "design point") will be released under an OSI-approved open source license next year." They will supposedly be trying to create a hardware development community around SPARC computer architecture via OpenSPARC.net.

Given that the SPARC architecture has, like MIPS, been relegated to the "who cares" leagues in recent years, this move is a chance for Sun to (try to) save its hardware-based lifestyle. Of course, it remains to be seen what all of the details are in terms of things like patent and trademark legal land mines.

Of course, for those following along, look at how Sun's "born again" take on open source is proceeding everywhere except for the Java core. That's an awfully good indication of where Sun thinks the real power is (and what they are afraid of losing their control of).

ObJava: Sun's David Dagastine shows benchmarks of running Java J2SE v5 on Sun UltraSPARC T1.

Code Naked

Finding yourself naked, in public, is a dream/nightmare that many people have. It could just be me but when I was first starting to program, I had a nightmare that not only was I coding naked but my code was naked, too. Partly in response to that, I became much more diligent about writing excellent code so that I'd never be embarrassed by my software.

Over the years, I've joked with various people that I "code naked" but most folks stop at the (all too frightening) image of me coding while naked. Alas, I've never thought about a more palatable phrase enough to come up with anything worth mentioning. Various industries like to use the term transparency but methinks that's too opaque and wishy-washy.

A student of Bob Koss comes to the rescue with the term Refrigerator Code:

It's code that you’re so proud of that you want to take it home and hang it on the refrigerator, right alongside of your children’s drawings.

On the other hand, one of the underlying reasons of Why Software Sucks is the fact that most software written is really what I call Toilet Code:

It's code that's so mediocre that when somebody encounters it, they just want to flush it down the toilet.

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.

Sun nukes SISSL

Sun's "Chief Open Source Officer", Simon Phipps, just announced that Sun is retiring the Sun Industry Standard Source License. He's putting Sun's money where it's mouth is and actually getting rid of the license to help reduce the ridiculously rampant proliferation of "open source" software licenses.

Fer shizzle!

If you're interested in why license proliferation is so lame, read Larry Rosen's short paper, License Proliferation.

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.

Googlezon

EPIC 2014 is an 8 minute, Flash movie from the year 2014 about a very 1984-ish outcome to the juggernaut that is Google.

Hilarious, in a scary way. :-)

Passionately Curious

What do you really look at when you're hiring people?

Does your team fall into the various mental traps that Malcolm Gladwell talks about in his latest book, Blink? I.e., do you look for people who fit your conscious and/or unconscious biases? Wouldn't it help if, like the symphony committees, we only hired people based on their ability to code where we could not see them?

Does your team fall into the hiring hubris fallacy that Joel talked about recently? Is this just another example of the Lake Wobegon Effect where organizations are trying to make themselves feel better? Wouldn't it help if we only hired people we thought were better than us?

Does your team fall into the Certification Fallacy -- believing that a certificate means that a person is good/qualified/etc.? Do you only look for resumes that have the ridiculous laundry lists of keywords that the HR people can put into their filtering software? Wouldn't it help if we actually looked at what the actual work that a person has produced?

Or, is your team tragically hip and hires open-source commit sluts? Wouldn't it help if we actually spent some time working with people and the software that they've worked on?

When it all comes down to it, aren't we really looking for how we connect our true passionate curiosity with each other?

Software Freedom Law Center

Eben Moglen heads up this new organization, the Software Freedom Law Center, to "provide provide legal representation and other law related services to protect and advance Free and Open Source Software." The center has been established with a $4 million fund raised through the OSDL.

Note that the free assistance is only available to eligible (i.e., non-profit) F/OSS projects that can't afford their own legal representation. The center will also provide services on a fee basis.

JCK's New Bait-n-Switch Licensing

Sun's Graham Hamilton has just announced the release of the Java Compatibility Kit (JCK) for J2SE under a read-only license.

Whoopity do!

If, heaven forbid, one wants to actually use the JCK at all, you are required to either submit to the onerous SCSL (Sun Community Source License) or upcoming JDL (Java Development License). If you want to use it commercially, you have negotiate a commercial license with Sun (at least $50,000.00).

Geez, doesn't this remind you of Microsoft's incredibly lame "shared source" insanity?

As always, I'm a firm believer that, hey, it's Sun's property and they can do whatever they please with it but Sun's mealy-mouthed, half-assed, Janus-faced approach to "opening" up Java is, frankly, insulting. Sun: if you want to continue with your dictatorial control of Java, just be honest and say so but stop all of the weasely, self-righteous BS -- or return to your bold roots and get serious about truly opening Java up to the world.

Is it stew, yet?

Before directing you to an essay on Language Oriented Programming, I want to make one other comment about this particular pumpkin soup. We're eating it today and yet I made it Tuesday night. I learned this at a restaurant I worked in. The chef served "yesterday's soup" instead of "the soup of the day". He said that most people know that soup always tastes better the next day so that's when he serves it. This gets to John Mitchell's Slack post. It would be nice to have the time to work ahead on some project and let it sit. You could then come back to it in a couple of days and have the fresh perspective to improve it before serving.

In XP, one of the benefits of pair programming is the difference of perspectives between the current driver and the copilot. Another refreshing perspective change comes when shifting between the two roles. One of the biggest benefits of test-driven development is the forced change in perspective as you shift back and forth between test writing and code writing.

If you're not working in a pair, you can simulate this yourself by working on a task for awhile and then put it aside and come back to it later.

Obviously, the relatively short granularities on the order of minutes are good for getting some kinds of perspective, it's critical to also sprinkle in the larger granularities of days and weeks. There's nothing like a sleep cycle or three to let your brain disengage consciously but continue percolating on it unconsciously to brew some fresh thinking.

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.

Security: Open source vs. Commercial

Security guru John Viega confronts the myths surrounding the security of open source software in his recent article: Open Source Security: Still a Myth. With a title like that, you might want to read through the hullabaloo in the comments at the end of the article.

There's only two differences that open source brings to the security equation... First, because the source code is available there is the possibility that security problems may be recognized by one of the more eyeballs. Second, because the source code is available there is no place for the developers to hide when a security problem is found.

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.

Java Quake

Bytonic Software has released their open-source (GPL'd) Java port of the Quake2 game engine, Jake2 v0.9.1.

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.

Sun to meet with IBM on open-sourcing Java?

Eweek is claiming that, in reponse to IBM's open-letter to Sun to open-source Java, unnamed sources at Sun are telling Eweek that Sun representatives will meet with IBM to discuss open-sourcing Java.

IBM's open lettter to Sun: Open-Source Java

In response to Sun's Simon Phipps' rant about Eric Raymond's open letter to Sun to open-source Java, IBM Vice President Rod Smith has called for Sun to open-source Java in a letter to Sun Vice President Rob Gingell. Smith offers IBM's support to create an independent organization to control Java.

Sun's Phipps rants on Raymond's open-source rant

In an article in the UK's PC Pro magazine, Sun fires back over Open Source Java accusations, Simon Phipps, Sun's Chief Technology Evangelist and java.net blogger, rails about Eric Raymond's recent open letter to Sun, Let Java Go.

Seems pretty clear that both sides make some points and miss their marks. I don't have the time right now into a blow by blow analysis but I will say that I'm personally sick and tired of Open-Source fanatics saying that everything should be open sourced. It's Sun's property and they can do whatever they want to do with it (whether we like it or not). On the other side, I'm equally sick and tired of Sun saying that they do NOT have any extra level of control over the rest of the JCP powers -- that's patently false -- check out my earlier blog on that particular subject, Open, Independent JCP?.

JSR 166, A Case Study

Check out my Artima blog entry on the case study of JSR 166: Concurrency Utilities.

XWork v1.0 and WebWork v2.0 released

Version 1.0 of the XWork command processing framework and version 2.0 of the WebWork web application framework (which is built on top of XWork) have been released.

Whitespace, The Language

Whitespace is a language whose syntax comprises only the whitespace characters space, tab, and linefeed.

Erik on Velocity Templating

Erik Hatcher writes Velocity: Fast Track to Templating -- a nice and quick introduction to the Apache Group's Velocity Templating engine.

Hibernate turns 2.1

The Hibernate project has released version 2.1 of their open-source (LGPL) object/relational persistence system. Hibernate v2.1's claims to fame are Query-by-Criteria, Query-by-Example, and pluggable high-level caching support.

More on "Java Desktop System"

There's a big thread over on /. about the "Java Desktop System".

Note clearly that the thread contains the typically low signal-to-noise ratio that /. is so famous for. You have been warned! :-)

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.

"Java Desktop System"?

Well, Sun is releasing their so-called Java Desktop System this week. What, exactly, is the "Java Desktop System"? Plain and simple: it is Sun's Linux distribution focused on desktop users. Of course, Sun has too much invested in things like Solaris (which is losing market share since The Bust (and I'm not even going into the loss of mind share)) and Java for them to be clear in their marketing messages.

Okay, let's hear Sun's official story of the naming of the Java Desktop System:

Q. Why was the product name Sun Java Desktop System selected?

A. Java technology plays a very important role in the Java Desktop System - the Java Virtual Machine is integrated, the Mozilla browser is Java-aware, Java is the preferred development environment, etc. To reinforce this, we have selected the name Sun Java Desktop System.

Yeah, sure, uh-huh, whatever. Did you notice how little actual Java there is in the "Java Desktop System"? Yep, in amongst all of those applications that users are going to actually care about such as the GNOME desktop and the Star Office application suite, Sun installs the JDK and JavaWebStart.

Now, since flogging the Solaris brand against Linux is about as succesful as Hollywood's Solaris movie was at making money, Sun is betting the farm in their ability to market "Java Everywhere". So, Sun is going to flog "Java" (to death?) by slapping "Java" on more or less everything that they are trying to sell. Gee, as if the term "Java" isn't already way too overloaded (is it a language or a platform or a mindset or a community or one product or 8,000 products or...). Let's face it, Sun has pretty much always sucked at marketing and I don't see this as any sign of improvement.

Can this flogging of "Java" possibly be a good thing? Can Sun carve out a niche using a "Red Hat Enterprise Linux but we sell hardware too" approach?

China options push Sun to consider open-source J2EE app server?

Hmm... Opening up the Chinese market (that won't pay the ridiculous licensing fees anyway) through the hearts and minds of the developers and hoping that will convince them to buy (expensive) Sun hardware? I'm not so sure about that. Will they buy Sun's services? Perhaps but I'm not going to hold my breath.

In terms of the perennial Sun boogeyman that is Microsoft, going with a viral license such as the GPL would be excellent. Just think... Sun suing Microsoft for violation of the GPL and therefore the GPL getting seriously tested in court!

Apache Software Foundation working on new/updated software licenses

There are a number of proposed changes to the various Apache softwware license agreements. There's a mailing list on which to discuss these issues (along with the obligatory list archives.

Given how many projects and companies use Apache licensed software, I think it would be A Really Good Idea(tm) for as many people as possible to seriously check out the proposed changes and participate in improving them.

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.

Why Humans Should NOT Have to Grok XML

Terence Parr, creator of ANTLR, wrote an excellent essay on why humans should not have to grok XML.

JavaOne 2003: Java's Debutante Ball

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

Opinions on the JRL (Java Research License)

Dan Steinberg put together this discussion between a number of the Java.net folks on the new Java Research License.

Users and Vendors debate JCP vs. Open Source Java

Nice to see some of the vendors go on record about making Java open source.

Here's an artice talking with Oracle and Sun about the JCP and the newly proposed JCP v2.6.

Here's a ComputerWorld article talking with various vendors and users.

Here's an interview with Sun's Jonathan Schwartz on the issue.

Here's more on the subject in an interview with James Gosling and here's my earlier blog on the JCP vs. open source session at JavaOne.

Gosling on Open Sourcing Java

James provides a nice, insider view of some of the thinking around open sourcing Java. There's a nice bit in there about the whole Microsoft fiasco too.

Open, Independent JCP?

I mentioned An Independent Look At the Java Community ProcessSM Program in my first java.net blog entry. The original title was "JCP Better than Open Source?" so you might imagine my expectation for fireworks at the session.

Well, first off, the turnout was pathetic. Seems to me like the piss poor voter turnout thing. Of course, those folks still like to bitch. Sigh.

Frank Sommers was allowed access to the JCP database to do a study on the characteristics of the JCP so far in a piece called Effort on the Edge.

Is the java.net community going to kill the JCP?

Doug Lea pointed out that many things don't make sense as full blown (de jure) standard. I think that, like any other premature optimization, bringing things into a standardization process before they've been fully baked in the heat of real-world abuse and competition is a recipe for adding yet another backward compatiblity anchor around our necks. Remember that in the JCP, backward compatibility is a huge constraint. Given that constraint, the JCP should be much more conservative in what they allow through since we're all going to have to live with it for a long time.

Rob Gingell made some very nice statements that the JCP is really about controlling the definitions of the java.* and javax.* namespaces. Basically, things that don't belong in those namespaces have no particular reason to go through the JCP. He was also very clear in saying that Sun is open to many ways to improve the entire world of Java -- the core platform should only represent a small part. That is, communities such as java.net are resources which people can use to help others while helping themselves without the constraints or goals of the JCP.

Is the JCP open or just a white glove around Sun's fist?

Jason Hunter ranted about the fact that Sun still has ultimate control over Java since they have veto power and control most of the JSRs (and certainly all of the core JSRs). The Spec. Leads in each JSR is basically a dictator and pretty much do what they please (within the constraints of the JCP). But, if people don't like that Spec. Lead, the JCP conventions won't allow for a competing JSR to be approved. So, there's very little incentive for the Spec. Lead to actually have to care about things like building consensus.

Mark Hapner made a good point that one of the really great things about the JCP is that it is also evolving. [In a lovely example of recursion, the JCP is evolving through the JCP.]

Jason also noted that the Spec. Lead can foist onerous business terms in addition to onerous technology.

Jason went on to rant about the fact that the JCP licensing terms often force an all or nothing approach to approving/rejecting the JSRs. There's no way to reject specific chunks and yet still remain in compliance. The easy example here is the whole fiasco around the J2EE certification.

The Bottom Line

The simple fact is that Sun controls the definition of Java through both its founder veto and through leading all of the core JSRs. Oh yeah, I forgot to mention that the Spec. Lead organization cannot ever be forcibly ousted. So, Sun has the power and has it forever (or until they give it up).

Markets are a Good Thing(tm)!

What's up with all of the paranoia from open source advocates w.r.t. java.net? Hello?!? A key part of the whole point of open source is that competition is a good thing. Support the stuff that you like and don't support that you don't like. If there's no acceptable alternative to something that you don't like, make one!

Innovation Everywhere!

Dan mentioned the first use at this conference of Bill Joy's, "Innovation happens elsewhere" second-hand quote. Now, that's the fine and dandy sound bite but...

Innovation happens everywhere. That's the nature of life. Alas, it just so happens that it often gets ignored or otherwise overrun by various kinds of steamrollers.

Will Java.net supplant the JCP?

Interesting article about java.net's potential vs. the continued crumbling of the JCP (Java Community Process).

The main take away for me is that Sun is putting out some effort to work better with the larger community.

This work is licensed under a Creative Commons License.