---

There's been a lot of talk about the Oracle vs Google court case, and I was reading this when it occurred to me that I have a few reservations about the strength of Google's argument, and perhaps you'd like to hear them.

If you know about the technology you might want to skip ahead a bit, but I have to cover off some background, so we all know what we're talking about.

My thinking first took shape when the Apache Software Foundation (ASF), of which I am a member, was making its initial steps towards developing a Java Virtual Machine(JVM). At its most simple abstraction the JVM is the thing that runs on your computer, and in its turn it executes the java programs, they are loaded into it. The JVM "hides" the differences between operating systems from the Java programs. For example Mac's and Windows might have different ways for a program to interact with memory, the JVM provides memory management which is the same for all java programs, to make this happen a Windows JVM will be different "inside" than a Mac one.

So Apache were attempting to create an Open Source JVM called Harmony, and it was during early discussions about the "Java Mail API" which I was involved in that I first ran into the issue which is being tested in court right now. (we will ignore the definition of an API at the moment, because we come to that a bit later, it stands for "Application Program Interface" but you don't need to know what that means)

 I was PMC Chair of Apache James, a 100% Java email application server, and I had got chatting to the Harmony folks about one thing and another when the subject came up about whether an ASF licenced version of the JavaMail API  would have a more natural home amongst the java email fanbois of the James project because it is a framework that allows people to write java programs that handle email more easily.

So I started to think about what this would mean from a code perspective, and began to untangle things in my head, here's where I get to the point, stop skipping!

The thing that we call "JavaMail" is composed of three parts, and this is true for many other Java API's including the ones in the court case, and in fact much of the JVM itself. Those parts are:

i) A specification or definition, this part is the API specification.

b) An internal component which makes one half of the software, This part is the API interface.

2a) An example of the other half that you are free to use, or to replace with an implementation of your own. This part is an implementation of the API, whoever wrote it.
 
If we use an analogy here, to avoid getting bogged down in abstract descriptions of computer science ideas, we can imagine that an airliner manufacturer would manufacture the floor in such a way as a seat manufacturer could manufacture seats which could be installed after the plane is built, without the plane having to be adapted.

In order for this to happen the specification for the floor connections would be published and made available to seat manufacturers, who would then compete their little hearts out to make the best/cheapest/lightest seats on the market compatible with the floor specification, and sell them directly to the owners of the planes to be installed after the plane is delivered.

The airliner manufacturer will make floors and install them in customers planes.

The specification is a piece of intellectual property, it has taken time to produce and does have some intrinsic value.

The situation in the Oracle v Google case would be analogous to the situation in which a rival airline manufacturer has published an identical copy of the specification of the floor, manufactured compatible floors and is wooing customers and seat manufacturers from the originator of the specification with the promise of compatibility for all the seats and tooling and expertise that they have invested in.

What Oracle are contending, or trying to, or failing to, or *ought to be* saying, is that the specification is not in the public domain, it is their intellectual property and they are within their rights to restrict its use to allow people to implement the replaceable parts (the implementations, the seats), and not the internal part (the interfaces, the floor). In other words, not only is it breach of copyright (as the court has recently determined) but it is also probably not "Fair Use" (which they are still to decide upon) for Google to produce an API of their own to Oracle's specification. If it is, then people are going to very quickly stop publishing API's that allow competitors to benefit from years of research and development.

Of course this is then masked by a big shit-storm of FUD and misdirection by both sides, trying to veer off the subject onto other more easily determined areas of IP law where they believe they have an edge, such as:

The "field of use" restrictions, which are important but not directly relevant to the API arguments.

Patent infringement, of course, which is the modern lawyer's soup-of-the-day for the whole decade and IMHO totally irrelevant here.

And the distracting but easy to comprehend copy'n'paste IP crime where code appears to have been copied from somewhere that it couldn't have been legally.

The last one is the worst FUD of the lot because that is copyright infringement, as is the case where the specification is used in contradiction to the terms of its licence, but its a different crime, a separate incident, qualitatively something else altogether .

From this point of view I don't think Google's position is as solid as they might want it to be, or as solid as the judgements may suggest, but the truth of the matter is that Sun caused this whole debacle by vacillating over the legal status of Java, the API's the JVM, the TCK and a raft of other things that they thought morally *ought* to be open source and free for people to use for any purpose but weren't in law, because they never made it clear enough what was being explicitly permitted and what was being benignly tolerated.

And that is why I have mixed feelings about the merit of Google's case, and some grudging understanding of Oracle's position, and a bad taste in the mouth about Sun's failed attempts to be Machiavellian with the IP laws.

And if you're wondering what happened to James and the JavaMail API, we never did take it on, its a very poorly designed API and would have brought us a lot of work with precious little benefit.

---

---

Happy Birthday Apache!

I was checking out the 10th anniversary press release

Several Apache projects also celebrated their 10th anniversary

and realised that Apache James is 10 years old this year as well. Way to go James Team, 10 years and we still haven't resorted to physical violence. Check the wayback machine if you don't believe me.

The top level project was established by the Board on January 22, 2003, with these ugly dudes on the 1st PMC:
Serge Knystautas
Danny Angus
Peter Goldstein
Noel Bergman
Charles Bennet

And I read the two documents The ASF was sent, I think I'm going to move to Oakland, or at least adopt their public holidays.

The Mayor of Oakland's proclamation that november 4th is Apache Software Foundation day wierd, but cool.

The Letter from Arnie. Question: Will he be back?

---

---

Here are some links I found for James related things,

Most notably I found this site JavaEye I can find a few mentions of James but the content is in Chinese. This really begs the question how can we encourage Chinese, Japanese, and people from other cultures who are not as likely to communicate in English as Americans, Europeans, and people from India, to engage with our projects?
I would love for the people who are writing on JavaEye to make themselves known to the James community, we'd be happy to help spread the word about James, and are always grateful to people who can help us to get in front of a non English speaking audience.

"James is a very solid and reliable piece of software" Thanks Ant, nice of you to say so.

Niall Commiskey wrote EMAIL notifications with Oracle SOA Suite 11g which illustrates nicely what a useful role James can plan in enterprise systems. Even if it is only used to provide a development or test environment for email, James gives java developers standards compliant protocols *and* full control over the message content and routing, you can create testing stubs, reports, and integrations into other systems that will fully expose the output from your system.

And finally this Yet another email client – Apache James Hupa from Sree Balakrishnan, talking about the latest James sub-project Hupa (IMAP-based Webmail written in GWT) If you're interested in Hupa check out the site first but you may want to read this, if there haven't been any releases yet.

---

---

I wanted to print a checklist as the final task in a release management Ant job.
We have a predominantly windows environment on the desktop, so I thought I'd try using the DOS print command, but was initially foiled when trying to use a network printer.
I was then mislead slightly by this: NET USE LPT1: \\MY_SERVER\PRINTER which I found here.
In the end the obvious solution (to use the share name for the device) was the right one.
Reproduced below, it works a dream, now you too can spam your office printers!

<exec executable="print">
<arg value="/D:\\dundonald01\panasoni"/>
<arg value="${doc.dir}\checklist.txt"/>
</exec>

---

---

Well yes, I've spent the past week or so trying to apply a load of stuff that I want to do from the world of Java to the word of LAMP, or php to you and me.

I should also say that before I embarked on my career as a java-weenie I'd spent four years man-and-boy programming perl, so the php itself wasn't any kind of hurdle, my challenge has been to see if I could introduce all of the application architecture patterns which I know and love from Java world.

So what things have I uncovered?

1/ IDE - the Eclipse PDT, with zend debugger, is excellent. Not quite as robust as Eclipse java tools, there are still some flaky moments and the code completion can't always work out what class $this->thing actually is, but that is all made up for and more by subclipse and the zend debugger. Keep up the good work PDT guys. For others who want to investigate I followed these instructions.

2/ OOP Yes, PHP5's OOP is pretty decent, but (obviously) it is weakly typed which I find annoying coming from a strongly typed background. And surprisingly I had to write my own classloader, which was fun and instructive and it seems to work fine, but why? I haven't started using exceptions yet, hopefully they'll be familiar.

3/ ORM Oh yes, this is cruicial to my plans Mua hahaha, and it seems so far that the excellent Doctrine ORM is well up to the task, if not quite in the same league as Hibernate.
One thing thats puzzling me is where the transactionality has gone, but perhaps thats because I haven't read the manual fully yet.

4/ Logging, oh wow- log4php - in incubation at Apache this is the php sibling of log4j it works fine and smells very familiar.

5/ Unit testing, haven't tried it yet but while I was talking through my researches with the guys who will have to suffer the consequences of my decision making they said phpunit, which certainly sounds like the right thing!

6/ MVC I'm not keen to adopt a big framework wholesale, for reasons which I can't be bothered to explain now, but its been relatively painless to knock together an OO MVC framework using Doctrine, homespun controllers, and Views generated by the Smarty template engine which at least lets us bind, using simple {$my.attribute} syntax, display elements to objects from the model, not sure how far Smarty will suit at this early stage but its looking promising for now.

I have no stirring conclusions at this stage, but its looking good, stay tuned and I'll let you know how it all turns out.

---

---

The Apache James team have submitted two proposed student projects for Google Summer of Code 2008, you can read them here.

In brief they are:

1) Develop a VERP Mailet to allow James to write VERP modified return addresses on outbound messages, and an inbound mailet/matcher to identify VERP bounces and invoke configurable "do something" code.

And 2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features subscriber and message moderation, double opt-in and bounce handling.

Spread the word, James needs Students!

---

---

I read a post on the James dev list that mentioned this blog posting which goes into some detail of the method Jukka Zitting used to create a JCR message repository (using Apache Jackrabbit) for Apache James in the James sandbox. I thought this would be a good excuse to mention that work here.

I find it an exciting idea because it takes the inherently richly structured MIME messages and stores them in a way that can cope with the full richness of the structure including the mixture of content types, the recursion of nesting, and the mixture of encodings and character sets supported very well by the totally fan-bloody-tastic MIME spec. In fact JCR is much more aptly suited to storing MIME structures than a traditional RDBMS or the filesystem because it is flexible in the right ways and can also manage the metadata.

The expensive act of parsing the MIME message is only carried out once, when the message is exploded into the store, and thereafter the whole message, or just specific parts of it, can be passed around as a serialisable reference to a location rather than as unserialisable streams, or big byte[]'s.

What's more any system that can manipulate the JCR repository can become involved in the life of the messages, for example web mail stops being a web interface for traditional mail protocols and becomes a first class citizen, web applications built straight ontop of the repository.

Add Web Services and the repository can participate in CRM systems which use WS to integrate channels and systems into a single Agent Desktop and a Single Customer View.

The fact that Jukka made the James JCR repository (with an html viewer as well) in a few hours at Apachecon EU is testament to the suitability of JCR, the extensibility of JAMES and the value of the Hackathon as a tool for innovation.

Have a look at the code here or subscribe to the server-dev@james.apache.org list to discuss it.

---

---

We here can cope with using JAXB generated models with hibernate HBM.XML mapping. But Colleague X, working with Axis 2, is struggling to find a way of using ADB and Hibernate together without having to write converters or delegates or whatever by hand.

I know one of you knows how to do this, after all how unusual can it be? So please... Send Help to the usual address (danny at apache dot org)!

---

---

Aaron Farr posted this about the frustration of modern web design, including an exellent pie chart of the time breakdown. Well colleague X has sent me an updated version showing the breakdown of time spent developing tapestry/spring/hibernate J2EE web-apps.

---

---

Apache Jakarta is a project which has spawned many significant landmarks in open source Java; Ant, Tomcat, Jakarta Commons, Maven, and Struts amongst many others.

In years gone by it was a widely known and respected "brand" which working java developers trusted.
I trusted it, I got free stuff to help me with what I was doing but more important than that I knew that I could make Jakarta my first stop if I had a problem that needed solving.

However the world moved on and two things happened:

Firstly the ASF Board indicated three years or so ago that the Members weren't happy that Jakarta should be as large, powerful and autonomous as it was fast becoming, and so after much debate the agreed direction was clear, Jakarta sub-projects would be encouraged and supported in becoming top level projects of Apache, deflating Jakarta and restoring balance and oversight. Most of them have been promoted in the intervening years, and only a few die-hards remain, but this is changing and they are now preparing to leave as well.

Secondly the Java ecology has changed radically in the past few years. Not only through the normal maturing of ideas and the distillation of best practice, but also from the introduction of resources like java.net, the entry of other trusted (often commercial) players into the open source arena, and changes to the JCP which have resulted in JSR's actually completing their life cycle. All of these have significantly enhanced the pool of "trusted sources" that java developers can go to.

So as we now approach the end of the reorganisation of Jakarta we're faced with a big decision, should we consign the brand to the history blogs? Or does it continue to represent something valuable to Java developers?

Successful brands are hard to create and easy to destroy, if we act without thinking about it we might be making a big mistake. On the other hand I am too close to it now to know whether or not this brand still means something to people who are, like I was then, the geek on the street.

So Please let me know whether you think the Apache Jakarta brand is worth preserving, or not worth loosing too much sleep over.

---

---

Jonathan Schwartz is quoted by Tim O'Brian as having said "There is nothing at all right now stopping Apache from shipping Harmony. Nothing, they are free to do so, the code is available they can distribute it wherever and whenever they want…We’re very, very, very focused right now on the GPL community."

I have to ask whether he (as a busy guy with lots of PR plates to keep spinning during conference season) has just misunderstood the issue, or whether this reveals an attempt to divide the OSS community and reduce their influence over Sun's baby.

I hope that Mr. Schwartz just missed the point here, which is that the Apache Software Foundation (ASF) want to be able to give their users software which passes certification, and the use of which is unrestricted.

The alternative implication is much less pleasant. It's well known that the ASF and the Free Software Foundation (FSF) (publishers of the GPL) have repeatedly failed to find enough common ground to achieve compatibility between their licences, and now that the ASF has come out publicly against some of the IP restrictions around the JCK (the TCK for JSE) Sun seems to be moving towards the GPL. Is it coincidence that the FSF's GPL prevents downstream users from benefiting commercially whereas the Apache Licence deliberately allows anyone to profit as long as the code is "free" (free as in speech, not beer)? I really hope not, that would just be bad for everyone.

**NB I'm not trying to score any points here, just saying it as I see it, if I'm wrong post a comment. **

---

---

The JCP have voted the Apache Software Foundation as "Member of the year 2007".
In the light of the recent waves Apache has been creating around IP restrictions on test kits this is either very ironic, or something of a show of support from the other members. In either case well done to the Apache folks who participate.

Geir Magnusson Jr. told ASF Members,

"It's a combination of our broad and deep participation in
expert groups, our numerous implementations of specifications, and
our activities as a EC member, where in our drive to bring our values
of transparency and openness, we push the JCP out of it's "comfort
zone", in a constructive and progressive manner that is good for the
ecosystem as a whole."

---

---

Thanks to everyone who helped, we now have a site for the Mailet API.

---

---

Steve Loughran took the piss out of architects during the lightning talks at Apachecon, claiming that we (and when I say we I was the only mug to put my hand up!) worked only in M$ Word and PowerPoint. Well, I'm glad to say that I put him straight on that one, his blog post on the subject which proposes "ArchitectUnit" now acknowledges that I was right all along and there is a lot more to the job than that, namely Visio diagrams as well. Hopefully we can now expect to see our efforts recognised for the true value they add, with not only ArchitectUnit but why not an ant task to turn our priceless hard work directly into fully operational systems? Thus avoiding all the opportunities for mistakes to creep in during the so called analysis and development phases of a project, and highlighting the fact that innacurate claims in the vendor marketing literature on which we base our product selections is the *real* reason why IT projects so often fail to live up to their promises. ;-)

---

---

The Apache JAMES project is happy to announce the final version
of JAMES Server 2.3.1. This is a bugfix release. You should upgrade as soon as possible.


JAMES Server 2.3.1 can be downloaded at:

http://james.apache.org/download.cgi


The bugfixes / tasks since 2.3.0 are:

* Remove ordb.org from docs
* OOM caused by unbounded cache in InetAddress (was James leaks memory slowly)
* sendmail.py doesn't handle multiple TO-recipient
* sendmail.py crashes on line "from_addr = os.environ['USER'] + '@' + socket.getfqdn()"
* ServerConnection doesn't properly handle the TCP/IP backlog
* Search & Fix broken links on the new website
* MBoxMailRepository.remove(String key) causes ClassCastException
* Failure to correctly set mail.smtp.localhost leads to mail servers
being listed on cbl.abuseat.org and mail being rejected by Spamhaus.
* MailAddress not check for valid syntax if new MailAddress(user, domain) is used
* sendmail.py use localhost to connect to local smtpserver. We should use 127.0.0.1
* exporting variables using build.sh on solaris breaks
* James will not start if there is directory with too many files and folders in the repostiory path
* python/sendmail.py is not added to the binary distribution package

* Update license headers to follow the latest ASF requirements as of November the 1st
* Merge 2.3.0a1 to 2.3.0 final releases on JIRA
* Upgrade dnsjava to 2.0.3 when available
* Add documentation for the dns ttl issue
* Make sure our container use an expiration for cached dns data


For more information see the changelog page.

Apache James Team

---

---

Well the Call For Papers for Apachecon US 2007 is now open:

• The Call for Papers is now open for ApacheCon US, to be held November
• 12-16 at the Peachtree Westin, Atlanta. The conference will consist
• of two day of tutorials (November 12-13) and three days of regular
• conference sessions (November 14-16).
• Please log in to the website at http://apachecon.com/html/login.html
• to submit your proposal.

I've submitted the talk on James which I'm giving in Amsterdam on May 2nd.

---

---

A couple of days ago I got this email on the JCP interest list:

• The following proposal:
  JSR-000313 Java Platform, Enterprise Edition 6 Specification
  was withdrawn at the request of the submitter.
  http://jcp.org/en/jsr/detail?id=313

This JSR seems to have had attracted some positive interest not least, I suspect, because the stated goals included:

• "the Java EE platform has fostered a vibrant community and marketplace for additional technologies, frameworks, and applications that work with the platform. Some of these provide facilities that are missing from the platform. Others provide alternatives to platform facilities. A major theme for this release is to embrace and support those technologies as part of the overall Java EE landscape, while also continuing to simplify the platform to better target a wider range of developers. To that end we propose two goals for this release - extensibility and profiles"

This seemed to indicate that JEE was about to mature into something which could accept some competition, allow more freedom for architects to build things they way they want to within JEE, and simultaneously resolve the obsolescence and bloat which was becoming apparent by providing alternative distributions based on the needs of targeted application types, e.g

• "... the first version of a Java EE Web Profile - a subset of the Java EE platform targeted at web application development.".

It seems from the vote comments that this has been a victim of concerns over IP, For example SAP said:

• "We will need to get more clarification for the new proposed license terms which seem to require a license fee per Java EE profile. If this means a fundamental change in the Java EE licensing model, SAP may decide to vote "NO" on this JSR based on the proposed license terms. "

and it seems in part to have been fuelled by the ASF's position on the Java SE TCK, Red Hat said:

• "The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.
  
  However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR."

We all know that there's a big gap between intention and execution, and JEE 6 might not have been the universal panacea it hoped to be, but take a second to join me and lets cross our fingers and hope that the value of the changes proposed in this JSR are not lost just because we're having another IP turf war.

---

---

ClassCastException is still the most common search term that sends people to this blog, although "swim across the atlantic ocean" is about to overtake it thanks, I can only guess, to fans of Detroit Roller Derby (don't ask ...).

So to be helpful to those readers who are not from Michigan I thought I'd clarify things as much as I can, be warned though it isn't much.

Because Sun's spec doesn't enforce a requirement for ClassCastExceptions to show the classes of the objects which you are trying to cast (see this earlier post) it is normally only possible to make any sense of a ClassCastException by reading the source code, and you really need to attach a debugger and examine the object that your programme is trying to cast before you can start to figure out why it won't work.

If your object seems to be of the correct class the problem is probably related to ClassLoaders, this article explains succinctly why that happens.

Sometimes, if you're smart, you can make a smart guess.

Sometimes (more often if programmers will take my advice) the exception message will tell you, but don't count on it.


If you are seeing a ClassCastException being thrown by a product you have installed then you need to check its documentation.

If the documentation doesn't help then you need to get help from the people who wrote it.

---

---

Google Summer of Code '07 will soon be accepting applications from students.

If you have an idea for a student to work on as a James SoC project send it to general@james.apache.org or post it on this wiki

If you are a student and want to submit an application to google about James, please discuss it on the general@james.apache.org mailinglist as well.

Not only do we have a lot of knowledge about what James needs (and doesn't need) we also have two years of experience of evaluating the proposals and experience mentoring two former SoC students.

We can help you to polish your application, and introduce you to our project.

James missed out on a SoC '06 student so I want to make sure we do everything we can to get good proposals and have them accepted.

---

---

James developers are currently voting to release jSPF-0.9b4. This release passes all the tests at www.openspf.org

If you want to try it out before its released the rc is here Remember to let us know what you think of it.

---