Open-Source keeps me ‘coding fit’

Open Source software has had a major role to play in the growth of Java. Apache and in particular the Jakarta project has been the birth place of several top Java components like Struts, Ant and Tomcat. In this interview, we speak to Henri Yandell, the current chair of the Jakarta project.

Henri speaks about open source software and its contribution to Java. He also shares his thoughts on why one should contribute to open source and his views on open sourcing Java itself. He also tells us about projects he thinks have a lot to offer to Java developers and which projects hold promise for the future.

IndicThreads >> Hello Henri. We are glad to have you on IndicThreads. Could you introduce yourself to IndicThreads readers?

Henri Yandell >> I’m an English Java developer, proud father of a recently born son and barely average football player. To hide how abysmally average I am at football, I moved to the US where I write code to monitor the US and European power grids for Genscape Inc.

I commit to various Jakarta subprojects,
mostly to Jakarta Commons,
and am the current chair of Jakarta…

The other major component of my life is being involved with the Apache Software Foundation. I commit to various Jakarta subprojects, mostly to Jakarta Commons, and am the current chair of Jakarta.

IndicThreads >> Considering your long association with Java Open Source, you are in a good position to tell our readers why they should contribute to open source projects?

Henri Yandell >> The best reason is because we all have itches, and open-source lets us satisfy those itches. I recently installed an mp3 server in the basement so my wife could play music upstairs (computer attached to the dvd speakers) and soothe the baby. The server had bugs with play-lists and the apostrophe character, and because it was open-source I was able to dig into it and fix it. You hear this kind of story again and again: “Use open-source products, scratch the itches, join the conversation by offering your fixes/ideas.”

The Internet is good at creating larger communities,
and open-source projects are very good at using the Internet…”

So that’s the first reason; the bait on the hook that lures you in.

After that things snowball. Contributing to open-source projects is a great way to learn from other developers. Most of us don’t work in environments in which large numbers of developers regularly interact. It may be because there are only a handful of developers at your workplace, you live in a non-major city (Louisville, Kentucky for me), or just that you’re divided into small teams at a large employer. The Internet is good at creating larger communities, and open-source projects are very good at using the Internet. Another situation might be that you’re finding yourself in a non-programming role for a short period, being involved with a community project is a great way to keep yourself ‘coding fit’.

Being involved with a community project
is a great way to keep yourself ‘coding fit’…

The fix a problem itch I initially mentioned is a very good lesson. I don’t usually code in PHP, which this server was implemented in, and so it was a good code exercise for my PHP abilities.

IndicThreads >> Right. However developers often say that they are indebted to open source projects and wish they could contribute. However very few manage to contribute. What do you think are the reasons and how does one overcome those issues? How did you start contributing to open source?

Henri Yandell >> Online gaming at University gave me an awareness of open-source communities, but my first contribution was when I bought Psion’s superb netBook PDA in late 1999. It was really a mini-laptop, slightly cheaper than a laptop, and had a JRE 1.1 environment on it. I quickly wanted to code Java on it and found the JPE (Java Psion Editor) project from Daniel Ockeloen, a very minimalist IDE. That Christmas I found myself with a) frustration at the lack of search and replace and b) time. 10 days or so of hacking around with the code led to a list of new features and I emailed Daniel to let him know. He’d grown frustrated with Psion’s lack of support/future for the netBook and had quit the platform, but gave me his blessing to release my enhancements, which I did as a replacement jar/patch.

Online gaming at University gave me

an awareness of open-source communities…

There were quite a few hurdles to overcome here, and they are many of the ones that face us all when looking to contribute to open-source.

  1. Itch:I had to get frustrated enough to want to do something. In this case there were no other options to switch to, so the only way to allay my frustration was to look at the code. This is the hardest hurdle to overcome, often you can just choose a different product or process and avoid having to look at the code.
  2. Time:I had to find time to scratch my itch. Fortunately I had a 2 week vacation just starting and was just planning to laze around with my family. This is less a problem for open-source and more a problem for our lives in general. Initially my open-source time was just a part of my general personal education time. Reading books, articles, websites and playing with code.
  3. Community:Once I’d made my changes then found that the existing project was not as active as I’d like. Although I made a couple more releases of my patch, I ended up growing as disheartened as Daniel with Psion’s lack of direction for the PDA. Dead, inactive and dormant projects can be very frustrating to deal with, especially when you’re feeling your way in the general open-source world. The thing to remember is that in a non-open source world, you’d have never even have heard of the project, or it would have been a site with an unanswered phone number. SourceForge is excellent in that regard, even when the project dies/sleeps it’s still there to be resumed or reworked someday. I think this is the least of the hurdles, but can feel like a big one.

    Around the same time, I had various bits of code from home that I wanted to use at work. Sadly my then company did not want to enter the confusion of using code at work that I owned, so I hit the 4th in my list of issues:

  4. Day-job:What’s the impact on coding outside of work, and can you use that code in your work without problems? This can be the biggest hindrance once you have built up momentum in open-source; legal-crap.

    This issue is also the reason why I tend towards the BSD style licences and not the GPL licences. If I GPL a utility library at home, it involves much more in the way of legalities to use it at work. So I go for the simplest possible.

IndicThreads >> Is open source work essentially free work that a developer does so as to learn something new or is there some way in which you can actually make money by contributing to open source projects?

Henri Yandell >> There are definitely ways to make money. I’m pretty lax on doing that; I mainly do open-source for the community involvement and so I can have a personal library of code that I can use at each company I’m employed at. That said, I’ve been remunerated a bit for reviewing a handful of draft books for the last few years by various publishing companies, and open-source involvement is how I got into that.

I mainly do open-source for the community involvement…”

Others write books or speak at conferences, which while not highly profitable endeavours, pay back in terms of industry respect and in job interviews.

Chances of an open-source contact

providing me with something I need

in the future are much higher than somebody local…”

Of course, there’s the commercial-open-source avenue, companies like JBoss Inc and MySql AB who are the central supporting experts for their particular project. I’ve not been involved in this style of company yet, so very little of this discussion relates to how those groups work.

Lastly, there’s the classic “it’s not what you know, but who you know” adage. I know a handful of Java developers where I live, a few from my time back in the UK, and many, many more via the open-source community. Chances of an open-source contact providing me with something I need in the future are much higher than somebody local.

IndicThreads >> What are your thoughts on open sourcing Java and on suggestions that Java should reside at Apache?

Henri Yandell >> (Before answering, I need to underline that I’m a spectator on the sidelines for much of this, so it’s all just opinion and not speaking for Apache.)

I think open-sourcing Java is a popular band-wagon that lacks good direction. What would an open-source Java get us? What do we actually mean by the term? Do we want a spec that is freely implementable (which it already is)? Do we want Sun to give the Java trademark to the community? Do we just want an open implementation?

I think open-sourcing Java is a popular band-wagon that lacks good direction…

What we really want are for Sun and the JCP to ease some of the barriers to an open-source implementation of Java. We want to be able to look at the source code, submit fixes, compile our own fixed version or port it to the Psion netBook when the vendor abandons us.

The good news here is that we already have an example of this. Kaffe is most of the way there and recently applied for a TCK Scholarship. Fosdem 2005 (Belgium) had a meeting in which Kaffe, GNU Classpath, GCJ and Apache people met up and learnt about each other. There was an earlier get together in the US on much the same topic. Apache Gump‘s continuous integration project currently builds projects under Java 1.4, Java 1.5/5.0, and under Kaffe, which helps to bring the community awareness together, and hopefully the Apache JCP seat can help with things like the TCK scholarship.

As to whether an open-source Java should reside at Apache, that speaks to everything that is wrong about the “make Java open-source” mantra. Find a community to support an open-sourced version of Java first. While there may be interested parties at Apache, I’m pretty sure there’s not a community of people who get excited at the JVM hiding in the wings. You’re looking for a group of C programmers who want to spend their time working on Java which seems like a rare blood-type to me.

IndicThreads >> What are your thoughts on the three new J2SE licenses? Do you think they will lead to a significant change in the way Java evolves?”Â

Obviously the jury will be out on the licences until we see them in action
in 2006 with Mustang, but I think they are a step in the right direction.
I don’t think they’re likely to help much with Kaffe’s TCK, but hopefully
the spirit of trying to open things up will help Kaffe reach a point where
it may be called Java officially and we’ll have a community supported JVM.

“The new J2SE licenses are a step in the right direction…

What really interests me is whether we’ll be able to share the patches we
make to Java under the Java Internal Use Licence (JIUL). If the source patches
are distributable (and not the Java source or a binary produced from it),
then we could build a community, much like the Fink project on OS X, who
would supply a patch to the latest Sun JVM.

Download Sun’s JVM. Download JIUL-Share. Recompile Sun’s JVM with
JIUL-Share applied. Use internally.

It’s a nice daydream isn’t it.

IndicThreads >> The Jakarta project has been the birth place of many popular Java applications. Which projects do you think can be useful to most developers?

Henri Yandell >> I really liked using Velocity on a web-agnostic report tool recently, but I’m not involved with it community-wise (apart from vague worries). It embedded nicely into the engine and was very easy for the developers to use to customize the report output.

My next suggestion is going to show my bias as I’ve been very involved with it for the last few years. Jakarta Commons is a very useful assortment of (usually) simple libraries. It’s often extremely easy to dig into the source if you have a problem, as the source is often a shallow method and not a large framework of classes. The Commons mailing list can be quite a hurdle to overcome. As well as being a reusable collation of libraries, Commons is also a social experiment in having a highly overlapping set of sub-communities within a larger community. The various sub-communities of Jakarta operate pretty independently on day to day issues, but the tiny Commons sub-communities interact and feed off each other constantly.

Commons and Velocity should be of most use to most people…

I pick Commons and Velocity because they’re very independent of the web-layer, and should be of most use to most people.

If you’ve not noticed it yet, I say community a lot. Community is very much a watch-word at Apache, and it’s something I’m a strong believer in. I’d much rather we were talking about open-community projects than open-source projects, what would be the point of an open-source project with a closed mailing list, no bug tracker and no CVS access?

Community is very much a watch-word at Apache,

and it’s something I’m a strong believer in…

IndicThreads >> And which projects are still in the nascent stages but you think hold a lot of promise for the future?

Henri Yandell >> Hivemind and Agila. I’d like to learn more about both and how I can use them in my day to day job. Hivemind looks like it will be like Velocity and Commons, a completely web-agnostic reusable tool, and I’ve heard interesting things about its configuration format.

Hivemind and Agila hold a lot of promise for the future…

Agila (currently in the Apache Incubator) is a business rules engine and that’s something I’ve never played with before. I used Jess a long time ago and am interested in whether I’m even on the right track on using them in the same paragraph.

IndicThreads >> Object relational persistence tools like Hibernate and frameworks like Spring have become quite popular. Do you think Java development over the next few years will be driven by such tools?

Henri Yandell >> Struts can answer that I think. Hibernate and Spring will probably follow the same adoption model that Struts had, in fact if you could figure out the correct events to model, I’d bet that the lifespans of Hibernate and Struts look very similar while Spring is probably still on the way up the ladder.

Hibernate and Spring will probably

follow the same adoption model that Struts had…

If we look at it like that, Java development for the last few years has been driven by these sorts of tools. The really interesting part is that the de facto success of Struts has pretty much driven the de jure specification of Java Server Faces. Equally, I’m constantly reading website reports about Hibernate’s influence on EJB-3 and the wonderful JCP politics between EJB and JDO, so this seems like it will be another case of today’s de facto open-source project becoming tomorrow’s de jure JSR.

This seems like it will be another case

of today’s de facto open-source project

becoming tomorrow’s de jure JSR…

In addition to Struts, you pretty much have to add Ant, JUnit and Log4J as major de facto open-source projects. The existence of Log4j had a lot of influence on java.util.logging’s second specification, and JUnit has if nothing else got many Java developers used to the assert concept that was introduced later as a Java keyword.

Throw in Doug Lea’s concurrency library, and the influence of the Java community on Java today is etched very deeply. Probably only the release of C# has affected it more 🙂

What effect will Spring be having on the JSRs in 2006?

Which begs the question of what effect Spring will be having on the JSRs in 2006.

IndicThreads >> You have been a regular contributor to Jakarta Commons. Do you think components like those in the Commons project are underused by developers and that developers should put more effort into reusing code?

Henri Yandell >> Reusing code is hard and I completely understand why developers may shy away from it. A large part of my day job involves juggling CVS branches, modules and Maven dependencies so as to avoid creating new branches, which are really just clever and hopefully temporary ways to do copy and paste. Probably the biggest pain has come from a single reusable library at the heart of everything, if you put too much in there, it comes back to haunt you, too little and it’s useless.

Reusing code is hard and I completely

understand why developers may shy away from it…

Commons isn’t aware of your particular business domain though, so the likelihood of such pain is much diminished. The major pain I know of through using Commons libraries are a symptom of their success: it’s too easy to end up with the need to have multiple versions of the same component in your classpath. The same problem exists for other things, XML parsing for example, and the issue is really at the Java level. Jars need to have a way to state their desired version, much like how Java Webstart/JNLP can say it depends on JDK 1.3+ or just bugfixes of JDK 1.3. For me this is just a problem to be faced when it occurs.

Benefits of code reuse are so huge that they outweigh the pain…

The quandary we face with reusable code is that the benefits of code reuse are so huge that they outweigh the pain. Even reusing tiny methods can help to avoid seeing the same bug again and again. Speaking from experience, a system that is rife with copy and paste is far more painful to deal with as it grows larger than a system built on reuse. Even if both had the same level of pain, embracing reusable components forces the developers to manage their codebase and not let it evolve into anarchy. At the end of the day that management is very noticeable.

IndicThreads >>You did your studies and even worked for a few years in the UK before you moved to the US. Also through open source work you must have worked with developers from all over the globe. So did you find a difference in how developers and companies from different nations function?

Henri Yandell >> Sadly I’ve not worked in as many cultures as I’d like to. Various parts of the UK, though chiefly London, here in Kentucky, USA and a brief project in Vienna, Austria.

The pace of life is different between them, but the developers and companies are largely the same in style. I suspect you could draw a matrix with ‘Large | Small’ on one side and ‘Product | Consultant’ on the other and you’d have categorized the major styles of company, and I suspect this would be true of any major IT country in the world. One constant is that it is rare to find communication moving across the boundaries of a company. Few developers talk regularly to a group of developers at their competitors.

The Internet lets us talk, and open-source communities ride this wave…

The Internet lets us talk though, and open-source communities ride this wave. The only difference I’ve ever found in the open-source community is when there is a separation by language.

To finish this with something very on topic to your site; this puts India in a pretty good position. Brazil, China and Japan all seem to have their own very strong Internet cultures, and thus, I think, to a certain extent their own open-source communities. While the large projects like the Linux kernel, Apache Httpd and Tomcat will be a part of these communities, and have members from these communities, it seems likely that a lot of the energy spent will remain inside these cultures.

As this (open source work) means contacts,

free further education and CV/resume strength,

it can only be a good thing for Indian developers…

If and when India explodes into open-source, and forgive me but it seems as though it hasn’t yet, it seems very likely that they’ll be affected and have a much larger effect on the global/western/English-speaking/whatever-name-won’t-offend open-source community than the other nations India competes with in the global IT market. As this means contacts, free further education and CV/resume strength, it can only be a good thing for Indian developers.

IndicThreads >> Thanks Henri. It?s been good talking to you. We look forward to many more super projects from Apache.

Henri Yandell >> My pleasure. So do we.

IndicThreads >> A last note for our readers. If you wish to stay updated about Henri’s Java and football exploits, check out his blog: The Goldfish Chronicles.

The following two tabs change content below.
Content Team

Content Team

The IndicThreads Content Team posts news about the latest and greatest in software development as well as content from IndicThreads' conferences and events. Track us social media @IndicThreads. Stay tuned!
Content Team

Content Team

The IndicThreads Content Team posts news about the latest and greatest in software development as well as content from IndicThreads' conferences and events. Track us social media @IndicThreads. Stay tuned!

  • Usagi

    I prefer the following getInstance method:

    public static Singleton getInstance( )
    {
    synchronize ( Singleton.class )
    {
    if ( null == instance )
    {
    instance = new Singleton( );
    }
    }
    return instance;
    }

    This way the check also will be synchronized.

    By the way, point 3 from Other issues does not apply, as long as class Singleton has its static variable ‘instance’. This holds a reference to the class, thus making the GC not to dispose of it…

  • Guest

    Hai,

    Good to see i could provide the itch in the form of the little JPE editor on the psion :grin

    I was at the time working on several opensource projects and indeed got a little upset with psion. The fun of opensource is that someone else can pick up the stick and run with it. With powerful tools like google providing a rich world of learning and sharing.

    Even at the time of JPE i was working (lets call it a day job) on MMBase a opensource cms product (http://www.mmbase.org) that today uses many of the jakarta products.

    Thanks for the work and the sharing,

    Daniel Ockeloen
    daniel@mmbase.org

  • dumbjavacoder

    Thanks Henri for sharing your ideas on opensource especially, for your views about why a developer should involve in opensource and contribute to it. Thanks Harshad for a nice interview with an apt title.

    Rajendra Alapaty
    http://jroller.com/page/dumbjavacoder