00:12:44 video length
Bio Martijn Verburg (aka 'the Diabolical Developer') co-leads the London JUG (a JCP EC member), and runs a couple of open source projects. He's become a regular speaker at conferences on Java, open source and software development and has recently published his first Manning title - "The Well-Grounded Java Developer" with his co-author Ben Evans.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
My name is Martijn. Basically I’m probably most well-known currently for co-leading the London Java user group. We’ve been making a lot of noise in the Java community in general recently; in and around the OpenJDK and JSRs and Java Standards and things. I’m also sometimes known as "the diabolical developer" for my somewhat irreverent talks that I give at conferences. Yes, that’s me in a nutshell really.
It’s currently sitting at two thousand two hundred members and we're growing at a rate of about a hundred members a month at the moment. So, from a small beginning, it’s ramping up rapidly.
Almost weekly; we’ve got a massive array of events. We don’t have the sort of size venue that could hold four or five hundred people every single time, so we prefer to have lots of smaller events instead. That is working out quite well for us so far.
A massively wide variety. Obviously you’ve got the stock standard financial services, as you’d expect in London, and also the large telcos, insurance companies, that sort of thing. But we also have a very large academic base, and an increasingly large sort of undergraduate or student base in the community as well. Most recently, we’ve found a lot of new people joining us from the sort of startup community in London; the whole silicon roundabout and the so-called digital village or tech village that is growing up in East London. Some of those startups have grown to the sort of size and scale where they need to perhaps move to the JVM; they are certainly coming to our community because of that.
Well we had been one of the voices that were fairly loud and discordant, should we say, on mailing lists, and in public forums and things, and it was politely suggested that we actually put some work behind our words, as it were. So we decided to nominate ourselves for a position on the Executive Committee, and that was really more sort of a protest, or not even really a protest, but just kind of an indication that we were actually willing to do a bit more than just spout words on a mailing list. But we didn’t expect within a million miles that we’d actually get the seat.
So the rationale behind that was simply that we felt there was an over representation of investment banks on the JCP Executive Committee, and that was purely our only reasoning. We prefer to see a balanced Executive Committee, for example with ourselves and SouJava, the other Java user group that is now on the committee. Before then there was no user group representation, so there was no one representing the nine to ten million Java developers out there. But there was a heavy lean towards investment banks and other industry sectors, so that was purely our reasoning; there was no other reason than that.
Not at all. We contacted their representative immediately afterwards and explained why we’d given our no vote. He was very gracious and very understanding about our reasons why, and actually, as it turns out, Goldman Sachs have been one of the most strong voices for change within the JCP; positive change, that is; the sort of change that perhaps, sort of, user groups and free and open source software type folks would typically go for. Which I think, given Goldman Sachs’ reputation in the media, is somewhat surprising, but they’ve been an incredibly valuable partner in the Executive Committee. So who knew?
It was purely the openness and the transparency. The history behind JCP.next, the first one, it was actually something that had been instigated by Oracle and other folks quite some time ago. But due to all the legal wrangling and the buyout of Sun, and other stagnation bits and pieces, it just hadn’t been pushed through. So it certainly wasn’t a case of ourselves and SouJava coming in and rattling - the openness and the transparency banner had already been on the way before we joined. But yes, the major issue has been openness and transparency. If you have discussions on closed mailing lists, if there is no way for the community to raise issues about a JSR, or if there is no way for them to communicate with an expert group, then you have what we call 'the EJB 2.0 situation' happen all over again; which was a very well-meaning specification made by very smart people, but had not been field tested early enough against the developer community.
All of the JSRs that have been led by Oracle, bar one, have been applied retrospectively. The only other one that has not is, I believe, the Lambdas specification. That's almost been completely opened up; I think Oracle is just waiting on some legal clearance in the background there. As Oracle keeps stating, they funnily enough actually don’t have enough lawyers to go through this stuff in detail; but the intent is very clearly there. I think apart from that there might only be one or two other old JSRs that are running under old rules now. So it’s been very successful in terms of people actually voluntarily wanting to change; which has been nice.
Yes, it’s changed recently. So Mark Reinhold and the OpenJDK governance board, they put into place something called a JEP, which is a JDK enhancement proposal. This is certainly separate from a JSR but some JEPs can turn into JSRs, so the two are fairly complementary. If you look at the sort of rigorous requirements of a JEP, they are actually very similar, in terms of their openness and transparency requirements, as a full JSR would be anyway. So we see the two blending together fairly nicely at the moment. There is a little bit of legal language around things like the TCK and evaluating JEPs and JSRs before the final license has been specified. That is been tidied up as we speak, sort of thing, so yes we see the two blending fairly nicely at this stage, although it is still early days to be fair. The JEPs have only been going for maybe six months to a year, at the most.
We probably want to see a little bit more involvement from all the EC members, in terms of really deep diving into JSRs and evaluating them. We don’t think there is enough due diligence being done quite yet; there is a good level, but I think there could be more done; and we will hold up our hand and say, "We could do more as well," especially given the developer resources we have behind us. But, all in all, just keep pushing the openness and transparency; and clearing up the legal issues I think is the other main thing that we want to... by the time we leave the JCP EC, assuming we do at some stage, we would like it that there's no more situations where our community and our industry are arguing over interpretations of licenses, and interpretations of text; we want things to be absolutely clear. Whether that’s a rule, or a licensing rule, that maybe the community is not happy with, that is kind of another matter as long as it's very clear what that rule is and it's not open to these interpretations; that is very important to us.
That was sort of an idea floated around several of us in the LJC, and then we quickly discussed it with a whole bunch of other Java user group leaders; so it is very much a global effort; it's not just something that's come out of us. The idea behind it is to simply... as I said before the EJB 2.0, sort of semi disaster shall we say, it was simply a problem that developers were not involved early enough in designing the specification, testing the specification, seeing whether a standard even needed to evolve around that particular space. Sometimes there are certain technologies that are very new, that should not perhaps be standardized early on. Perhaps people should wait until there are some completing implementations.
As, previously to JCP.next, there were a lot of closed off mailing lists, closed off issue trackers, it was very hard for developers to get into JSRs. So the adopt a JSR program also is kind of a bit of a PR effort to tell all the Java user group members that this is now an open process; you can now get involved and here is where you go to go do that. Because when you talk with a typical Java developer on the street, they do not know what a JSR is; they don’t even know what the JCP is. Yet it affects their working daily lives, so it is very important.
Really, really positive. So to go back a little bit, we launched back on October 31st last year; we now have seven Java user groups involved, actively working on JSRs. We also have a couple of corporations who’ve also joined the program, despite it being a user group lead effort. So we are seeing pretty rapid adoption, but we are aware it takes a long time to build a community with deep roots, and we still have a long way to go, we feel.
14. I’ve had a couple of people suggest to me, actually at QCon this time, that there are dangers inherent in the more open approach; so that it might result in people who are maybe not qualified to take on a job on the spec side getting involved in doing so, or likewise through the Open JDK. Do you think that is a risk?
It can be a risk with any type of open source project; these things do need to be carefully managed. One of the key things we state on the Adopt a JSR program, on the front page, is that we want the Java user group members to have a laser-like focus on what they do, and to contribute at a level that is appropriate for them. If we are talking about, for example, implementing Lambdas for Java 8, not everybody is an expert in this area; there are very, very few language designers who are qualified mathematically and language design-wise to deal with this. Can an average Java developer, as it were, download a beta version of Lambdas and just try out the API and try the syntax and give feedback? - Absolutely! Can they help triage bugs? - Yes! Can they help administer the mailing list? - Absolutely! All those sorts of things; so there is plenty of work for everyone.
It started off pretty poorly when they took over initially, which was, I can’t remember now, a year and a half, two years ago, and has rapidly improved since. I think it’s helped a little bit that they have managed to maintain some of the ex-Sun employees who were on the community side of things as well; but the community relationship people, they absolutely get it; and they are trying incredibly hard to do their utmost to work with the community. And they’ve also been battling internally, I think, with Oracle as well, in some cases, to persuade internally the value of the community and the importance of it all. I think things have improved massively, especially in the Java space.
I’m certainly aware that Oracle and other open source communities, such as MySQL and the Hudson/Jenkins debate, shall we say, has been held in a very negative light. But people also have to remember that Oracle is a very large organization, and all of these different silos - the Hudson silo, the MySQL silo and the Java silos - are all very different parts of their business, and you are dealing with a completely different sort of smaller organization and different people; so I think, on the Java side, things are going quite well actually.