You are currently browsing karianna01’s articles.

LJC Election Position Paper

  • Openness and Transparency
  • Advocacy and Adopt-a-JSR
  • Technical gravitas

TLDR Summary: The LJC stands for active developer participation in standards, openness and transparency, promotion of F/OSS implementations and has no direct commercial interests in any proposed standard. We have initiated global programmes (Adopt a JSR, Adopt OpenJDK) directly involving developers in standards, improving them for the entire ecosystem.

History & Detailed Position

The London Java Community is a large (~2750) and rapidly growing group of developers who actively meet, discuss and work on the Java ecosystem.

During the 18 months we’ve been a JCP Executive Committee member, we’ve actively participated in reforming the JCP process itself and eroding the disconnect between developers and decision makers, through practical programmes and advocacy.

Our original goals were based on a few simple ideas:

  1. Openness and Transparency are essential for any functioning standards body, and the JCP must be reformed where necessary to achieve this.
  2. Better Standards are produced when ordinary end-users are fully engaged in the process of producing standards from start to finish.

As a user group, we have no direct commercial interests in the space.

Open-Source Software reduces barriers to entry for companies and reduces cost for non-commercial projects. We therefore seek to ensure that zero-cost open-source implementations of all standards are possible, and have the maximum possible patent and IP protection.

The LJC has made a major impact on the JCP, and its relations with developers and the Java community since being elected, by:

  • Being vocal advocates of reform and transparency in the relevant JSRs (348, 355)
  • Ensuring that commitments made by Spec Leads were followed through to completion.
  • Investigating JSRs which did not meet accepted standards of openness, and helping them to address any issues.
  • Founding the Adopt-a-JSR programme – to give a place for ordinary developers to get more involved in emerging standards and to start concentrating the enthusiasm and energy that exists in the community.

If re-elected we commit to:

  • Finishing the JCP reform efforts started in JSR 348 (JCP.next) and JSR 355 (EC Merge) by fixing IP Flow and Licensing issues in JSR 358 (JCP.next.3).
  • Taking our Adopt-a-JSR programme to the next level by seeding new Adopt-a-JSR teams in JUGs and organisations around the world.
  • Continue to run and promote workshops, talks and global collaboration by developers on JSRs.
  • Continuing to always stand up for the interests of developers and community – including promoting open-source implementations and projects.
  • Maintain a deep bench of talent in our committee, to ensure that developers are represented with the same time commitment that a major corporation can provide.

Our Committee

The LJC operates a JCP committee. This group is made up of volunteers who have agreed to abide by confidentiality rules, meet their commitments (including time commitments) and to work towards the goals agreed by consensus. The current committee members are: Ben Evans, Martijn Verburg, Trisha Gee, Richard Warburton, James Gough, Somay Nakhal and David Illsley.

This enables the LJC to avoid problems related to key person risk – with 7 members on the team, if one person needs to reduce their level of commitment then others can pick up their workload. We have discovered that running an effective EC seat requires at least 20 hours per week – equivalent to ½ person full-time. Given the LJC’s size, we feel confident that we can continue to staff the committee at the required level to provide a real voice for developers.

Openness and Transparency

We believe strongly in openness and transparency:

  • We publish the motivation behind previous voting decisions on the LJC blog in order to ensure complete transparency and open access.
  • We also publish the minutes of our committee meetings on the blog.
  • We are active promoters of transparency for JSRs. For example, we regularly monitor all JSRs to ensure that they are meeting their obligations in accordance with JCP 2.8 (JSR 348). This means open mailing lists, issue trackers etc.

Advocacy and Adopt-a-JSR

The LJC pioneered the Adopt-a-JSR program, encouraging developers to actively participate in specifications. Involvement includes everything from trialing beta APIs through to helping define the standard and implementing the Reference Implementation (RI). We are actively involved in the standardisation of JSR-310 (Datetime), and have run hackdays for JSR-310, JSR-335 (Lambdas) and JSR-308 (Type Annotations). These hackdays provide feedback on the usability of new features to the expert group and help prepare developers for upcoming changes to the Java language.

Adopt-a-JSR also highlights to developers the relevance of the JCP, and shows how they can impact the language and ecosystem they work with. To achieve this goal, the LJC has run talks, workshops and advocacy via social media such as Twitter and Java conferences such as JavaOne, Devoxx etc.

Technical Gravitas

As a large organisation of technologists we have expertise throughout the Java Platform, from deep dive tech to blue chip enterprise development. This gives us great insight into the technical merits of each JSR. Since we seek to represent a broad cross section of the community, our voting decisions are based not on the opinions of one person, but the consensus of a committee of peers.

In Summary

Eighteen months ago, the London Java Community pledged to improve the openness and transparency of the Java Community Process if elected to the JCP Executive Committee. We promised to help bridge the gap between the decision makers and on-the-ground developers. Our voting record and active participation in the JCP show that we have made real progress towards these goals. In addition, we achieved more than even we imagined by launching and championing Adopt-a-JSR, a program that has both improved feedback to expert groups from developers, and increased involvement from the people who use Java everyday in their professional capacities.

If re-elected, we will continue actively improving the openness and transparency of the JCP, and expand our successful programs to voice the needs of developers and communities worldwide.

Thanks!
The LJC JCP Committee

Attendees:

  • Martijn Verburg
  • David Illsley
  • Somay Nakhal
  • Jim Gough
  • Trisha Gee
  • Richard Warburton

Adopt a JSR

General consensus to run the Adopt OpenJDK style hackdays for the Adopt a JSR program.

Action Items:

  • RW/JG/MV/BE – Write a “How to run your hack day” article for Java Magazine and the wiki – Google doc
  • RW – Organise a 308 Type annotations hack day
  • RW/MV – Organise a F2F with JAX organisers to sort out JAX London Lambdas Hackday in October
  • SN – Organise hackdays for CDI (contact Luigi) and JSON + Websockets
  • MV – Get hold of Colin Crist for JMS 2.0 (or IBM)

Voting:

  • We will vote yes on SIP Servlet 2.0 (JSR-359), it simply brings an existing standard up to JEE6 which we think is a good thing.

Action Items:

  • BE – Submit “Yes” vote for JSR-359 (Done)

Misc:

The rest of the meeting was spent discussing aspects of Java 8 and its modularity story, a decision was made to discuss further with Oracle.

Cheers,

Martijn (on behalf of the LJC JCP Committee)

Simon Maple has withdrawn from the LJC JCP Committee to focus on his exciting new position at IBM as well as other exciting changes. We’d like to thank Simon for all of his amazing contributions!

Simon’s help in starting the JCP committee and his early insights on a bunch of JSRs was instrumental in us voting in a credible manner. He also wasn’t shy of injecting a bit of lighthearted-ness during tough legal sessions by instigating a few chip wars between committee members:-)

From the JCP Committee we’d like to say “Thanks Simon,  and see you at the Open Conf!”

Cheers,

Martijn (on behalf of the LJC JCP committee)

Hi all,

Minutes for 3rd Jan 2012, as always, questions, comments etc are welcome!

Attendees

  • Ben Evans
  • Martijn Verburg
  • Michael Barker
  • Somay Nakhal
  • Richard Warburton

Minutes

  • JSR-331 – Concerns were addressed, EG is more diverse
  • Voting record on Java.net was updated by MB
  • BE Waiting for Spec lead of 351 to set up webinar
  • TG has set up a shared calendar for early JSR reviews and dissemination of our reviews
  • Get a volunteer to introduce Raoul-Gabriel Urma to the right people in the OpenJDK for his ‘Relationships in Java’ prototype or more likely, set-up a project so people can take a look (via patches) (MB/MV)
  • JSR 344: JavaServer Faces 2.2 – Early Draft Review – (Committee to seek volunteers)
  • JSR 339: Java API for RESTful Web Services – Early Draft Review – MV found an Adopt a JSR Lead
  • JSR 346: Contexts and Dependency Injection for Java EE 1.1 – Early Draft Review – (Committee to seek volunteers)
  • JSR 342: Java EE 7 – (BE to investigate EG composition further, raise at F2F in Jan)
  • Jigsaw: – Committee to investigate progress of JEP (MV to chase Neil Bartlett / Tim Ellison)
  • Adopt a JSR materials for JUGs:
    1- MV created the overview presentation. 5 minutes on what the JSR is about and what it means for the regular developer
    2- Technical deep dive – 10-60 minutes on how to use the result of the JSR, implementation details, best practices… All a developer needs to get from “Haven’t heard about” to “Almost Guru” (MV/JG)
  • MB to lead OpenJDK Adoption and set up a monthly regular session – find a venue via BC
  • MV to investigate with Oracle about access to statistical analysis tools.
  • MV to ask JUG leaders list to assist with further JSRs
  • F2F – Ben has raised discussing all active JSRs for Agenda
Cheers,
Martijn (On behalf of the LJC JCP Committee)

Hi all,

Here is the reasoning behind our recent votes.

Please refer to our detailed explanation of each criteria –>
https://londonjavacommunity.wordpress.com/2011/11/08/what-we-look-for-in-a-jsr/

JSR-321 – Trusted Computing

Why we’re voting yes for Trusted Computing (JSR-321)

Transparency

JSR-321 is fairly transparent (open wiki, good documentation, RI and
TCK available) but lacks in some areas (no observers alias mailing
list, no public issue tracking). This JSR is run under JCP 2.7 and it
is not obliged to meet the transparency goals of JSR-348. However, we
feel that a good JSR should run an open observers mailing list (i.e. a
read only copy of the EG mailing list) so that potential participants
can see why technical decisions were made. Likewise, a public issue
tracker (such as JIRA provided by java.net) would go a long way
towards gathering feedback for this JSR.

User & Vendor Participation

The LJC feels there is a reasonable balance within the EG, but does
question the slight lack of vendor participation.  This could hinder
the adoption of the JSR. Open Source RI and TCKThe LJC fully supports the decision for the RI and TCK to be under the
GPLv2 with ClassPath Exception license.  Open RI’s and TCK’s are
important! Does it Work Well as a SpecificationThe LJC does not have direct expertise in this area but does note that
this is effectively a re-implementation of the Trusted Software Stack
in the C standards space. This stack is used fairly widely and so it
indicates that there is a need for a Java compliant standard in the
same space. There are not a lot of competing Java implementations, but
the EG has based the RI off the lessons learned from the C standard
and we think this is a good thing. General Merit

This JSR has reasonable merit and has clearly had a lot of time,
thought and effort put into it by the EG.

JSR-352 – Batch Processing

We voted “No” because at the time we cast the vote, JSR-352 had not met all of the openness and transparency requirements of JSR-348.  Those issue have since been corrected and despite our “No” vote we made at the time it would today be a “Yes” vote.

For the curious, JSR-352 had made mention of EG-confidential business being conducted on a private mailing list, which would have contravened JSR 348.  Specifically: “The Expert Group will conduct business on a publicly readable alias. A private alias will be used only for EG-confidential information, as needed.”

The LJC would like to thank the EG of JSR-352 for resolving this matter quickly, and wishes it had been possible to change our vote in time.

If you feel that there are other criteria that should be applied by
the LJC JCP Committee when assessing JSRs, then feel free to contact
us.  Either on the LJC mailing list or directly, we tend to be at a
lot of the meetups if you want to chat face to face.

Cheers,
Martijn (on behalf of the LJC JCP Committee)

Hi all,

Minutes for Dec 6th, as always, questions, comments etc are welcome!

Attendees

  • Ben Evans
  • Martijn Verburg
  • Trisha Gee
  • Michael Barker
  • Somay Nakhal
  • Richard Warburton

Minutes

Carried over from last meeting

  • JSR-331 – BE to send to SE/EE list saying we’re going to vote no and here’s why. Before he does, check with Werner Kiel.
  • We need to update our voting record on Java.net (BE/MB)
  • Accept 351 invitation for webinar (BE)
    • JCP.next.next solicit comments before the vote (BE to ask Patrick)

From this meeting

  • Set up a shared calendar for early JSR reviews and dissemination of our reviews (TG)
  • Get a volunteer to introduce Raoul-Gabriel Urma to the right people in the OpenJDK or his Relationships in Java prototype (MB)
  • BE reported that the proposed Currency JSR was still dormant.
  • MB reported that the tuples JEP this was very long term work
  • JSR 335: Lambda Expressions for the Java Programming Language – Early Draft Review – (RW to lead the Adopt a JSR for this one)
  • JSR 344: JavaServer Faces 2.2 – Early Draft Review – (Committee to seek volunteers)
  • JSR 339: Java API for RESTful Web Services – Early Draft Review – (Committee to seek volunteers)
  • JSR 346: Contexts and Dependency Injection for Java EE 1.1 – Early Draft Review – (Committee to seek volunteers)
  • JSR 342: Java EE 7 – (BE to investigate EG composition further)
  • Jigsaw: – Committee to investigate progress of JEP
  • Adopt a JSR materials for JUGs:
    1- The overview presentation. 5 minutes on what the JSR is about and what it means for the regular developer
    2- Technical deep dive – 10-60 minutes on how to use the result of the JSR, implementation details, best practices… All a developer needs to get from “Haven’t heard about” to “Almost Guru” (MV/JG)
  • MB to lead OpenJDK Adoption and set up a monthly regular session – find a venue via BC
  • MV to investigate with Oracle about access to statistical analysis tools.
  • Committee had a discussion on licensing in preparation of JCP.next.next, conclusion was that until the lawsuit is settled, we have to wait.
  • MV to ask JUG leaders list to assist with further JSRs
Cheers,
Martijn (On behalf of the LJC JCP Committee)

Attendees

  • Richard Warburton
  • Somay Nakhal
  • Ben Evans
  • James Gough
  • Martijn Verburg
  • Trish Gee
  • Mike Barker

Agenda

  • Review TODOs from last meeting
  • JSR-331– Constraints Programming for Java – Proposed Final Draft. We have Openness and Transparency Concerns.
    • There’s one potential Adopt a JSR LJC member that we can use to look into this (Lanre)
  • JSR-333 – Content Repository API – Early Draft Review, last day of review: 30 October 2011.
  • JSR-351 – Identity.  As we have major concerns about the validity of this JSR we should discuss whether to get them in for a presentation.
    • Meta: Stimulating discussion about JSRs on the SE/EE list. e.g. we didn’t publicise our concerns about JSR 351 on the SE/EE EC alias – and I think a lot of other members would have had more concerns if we’d spoken up on-list
  • Adopt a JSR program
    • Progress Reports on existing Adopted JSRs
    • Discussion on where we go next with this
    • Publicising the list of people who have joined the program back to the LJC (and beyond)
  • Adopt the OpenJDK program
  • Discuss candidates for the upcoming JCP elections
  • Other business

Minutes

  • Issues from last meeting were reviewed
  • JSR-331 – BE to send to SE/EE list saying we’re going to vote no and here’s why. Before he does, check with Werner Kiel.
    • We need to list our criteria for voting on any JSR on the Java.net wiki (MB)
    • We need to update our voting record on Java.net (BE/MB)
  • Look into into 333 for our voting stance (MB)
  • Accept 351 invitation for webinar (BE)
    • JCP.next.next solicit comments before the vote (BE to ask Patrick)
  • Launch Adopt a JSR by end of Oct (MV)
    • 350 report, new Java.net project, (SM will adopt a JSR)
    • Submit a BOF on JSR-310 at Open Conference (JG)
    • Find people to ‘Adopt the JMS 2.0 JSR’, (TG talk to BE)
  • Set up a JCP Committee voting poll (MV)
    • Post early endorsement of a candidate (BE/MV)
    • Promote this election (All of us)
  • Lead an ‘Adopt an OpenJDK’ (TBA)
    • Get a collection of LJC people to work on the build (MV)
    • Propose Oracle to allow JEPs without being a committer (MV/BE/TG/MB at Devoxx)
  • Next meeting to be scheduled for November, the week after Devoxx (BE/MV)
  • We need to have our contact details in a Shared Document (Everyone)
  • Martijn to buy the next lot of Wine (MV)
Cheers,
Martijn (On behalf of the LJC JCP Committee)

Hi all,

We realised that at the recent Open Conference that there were a lot of new faces to the LJC. It has been 6 months since we won the elected seat for the JCP Executive Committee (EC) and formed our own committee to review and vote on JSRs (and deal with any other JCP activity).

There have been a number of posts to this list on the topic of the committee and it’s activities, but we thought we’d better bring it all together under one post with regards to how it came to be, its structure and how you can join in!

What’s the goal of this Committee?

  1. Primarily we want openness and transparency in the creation of Java Standards.
  2. Equally as important, we want the end users of these standards (that would be Java developers) to have a say in the standard before it becomes ratified.

What if I don’t agree with the committee?

We don’t own anybody!

The reality is that with >2000 members, all we can do is try to represent you as best as possible. We do this by canvassing opinions, especially at events such as the developer sessions, talks and of course, the recent open conference. You’ve probably also seen the regular blog posts and mails asking for feedback as well.

‘Adopt a JSR’ is yet another feedback mechanism we have in place.

We especially want to hear from you if you do disagree with us! The wide range of opinions we have, the more accurately we vote for the community at large. And of course you can join the committee and add your direct vote (see “How do I join?” below).

Who’s currently on the Committee

  • Ben Evans (The designated rep for JCP EC meetings)
  • Martijn Verburg (secondary rep)
  • Trisha Gee (tertiary rep)
  • James Gough
  • Richard Warburton
  • Simon Maple
  • Michael Barker
  • Somay Nakhal

And of course Barry Cranford keeps his hand in as the Founder of the LJC and keen ‘Adopt a JSR’ supporter.

How did this committee form?

We originally sent out several posts asking for volunteers for the LJC JCP Committee. The initial group of people that volunteered was Ben Evans, Martijn Verburg, Trisha Gee, Simon Maple & James Gough. Michael Barker, Richard Warburton and Somay Nakhal have been added since (see “How do I join?” below).

How do I join?

The JCP Committee consists of a “meritocracy of the willing”. That is, if you want to join and are willing to put the effort in then after a couple of monthly meetings the committee adds you in (after a simple majority vote). So far everyone that has wanted to join has been accepted, we’re very much an open shop on that front!

The barrier to entry is relatively low. The minimum requirement is that you put in some effort – that is:

  1. Regularly turn up to the monthly meetings
  2. Actively review JSRs
  3. Support programs such as ‘Adopt a JSR’
  4. Write the occasional blog post

It helps to have a good understanding of the overall Java ecosystem and some open source and software patent laws, but we can mentor people in all of those areas. The time effort required is typically about 5 hours a week for a committee member, with the JCP EC reps putting in extra hours for EC meetings and extended research (10-20 hours/week).

Travel is required for the primary rep (or the appropriate back up) for a F2F meeting 3-4 times a year. As we are a Java User Group – Oracle picks up the flight and accommodation expenses for that rep (we’re talking economy class and a reasonable hotel, so this isn’t the 5* perk the rep was looking for ;p).

How does the committee vote/organise itself?

Simple majority voting applies, this includes voting who the primary, secondary & tertiary reps are and voting on JSRs etc.

Is the mailing list public?

Sadly not. This is the unfortunate reality of discussing legal issues (under NDA in some cases) and other information that the committee is given in strictest confidence.

So what do you make public then?

Everything that we possibly can! So our minutes (with some legal stuff redacted), our voting strategy and record. We’re certainly the most open and transparent member of the JCP EC and are encouraging the other members to follow suit.

Hopefully that answers most people’s questions but of course any and all feedback is welcome!

Cheers,

Martijn (on behalf of the LJC JCP committee)

Hi all,

After much thought and consideration the LJC JCP Committee have cast their votes for the JCP elections (Look for the Executive Committee Elections heading at jcp.org).  We’re making our vote public and will give our reasons according to the openness and transparency requirements for the committee.

The list of nominees for the SE/EE seats and the ME seats are as follows:

There were 3 ratified seats and 2 open seats up for election in both the ME and SE/EE ECs.  Although it may seem like the ratified seats are shoe-ins since to the number of candidates == the number of available seats, enough no votes can make a candidate ineligible to take the seat.

SE/EE Ratified Seat Vote

Ericsson AB, Intel and SAP all get yes votes – they are important players in the Java ecosystem and in Ericsson’s case we are also looking to the future of the combined SE/EE/ME EC, where mobile expertise will be required.

SE/EE Open Seat Vote

This was a very close vote as the strength of candidates was unprecedented. Azul Systems and Twitter Inc narrowly ran out as winners for our yes votes with CloudBees losing out by the narrowest of margins.

So despite not getting our vote this time around, a special mention goes out to Steve Harris of CloudBees.  We’d like to thank him for his amazing work at Oracle with JEE and look forward to seeing what his leadership will bring for the EE ecosystem working at CloudBees.

ME Ratified Seat Vote

IBM and Nokia get yes votes as they large global players and have been active participants in the ME EC

SK Telecom receive a no vote because of their attendance and participation record.

ME Open Seat Vote

ARM and Alex Terrazas get our yes votes.

  • ARM because it is vital that Java has a strong story to tell with regards to ARM chipsets.
  • Alex because he’s bought real effort and a breath of fresh air into an ME EC that was largely full of absent members.  His expertise in the embedded space and unusual applications of that (biological interfaces) brings a much needed technical slant to the ME EC.

Summary

Although the Committee has voted for and endorsed these particular candidates, any LJC member who is also a JCP member can (and no doubt will) vote any way they wish to.

Cheers,

Martijn (on behalf of the LJC JCP committee – Ben E, Martijn V, Trisha G, James G, Richard W, Simon M, Mike B, Somay N)

Attendees

  • Simon Maple
  • Richard Warburton
  • Somay Nakhal
  • Ben Evans
  • James Gough
  • Martijn Verburg
  • Trish Gee
  • Mike Barker

(Tasks in Bold)

General Minutes 
  • Welcome Somay Nakhal to the Committee!
  • We need to start having formal agendas before each meeting (MV to create next one)
  • We’d like to have a venue with free WiFi for all  (TG to investigate possibilities)
Update from Face to Face (F2F) EC meeting from BE
  • Hosted at Goldman Sachs in Jersey City, USA
  • Good to put names to faces, made following JSR-348 WG meeting run more easily
  • LJC ‘Adopt a JSR’ program was well received
  • Lots of support for JSR-310
  • JSR-348
    • Main issue was about ballot stuffing.  The PMO will investigate and act appropriately if there is evidence of suspicious voting.
    • SE and ME committees will merge (partly as ME committee rarely makes quorum).
    • 24 seats + chair is the new target, down from 32 today, ‘extra’ seats will die a natural death.
  • Java ME
    • Hardware baseline – so price point drops over time?  In our opinion this does not match what the industry is doing.
    • Code line is currently based off 1.4.2, they’re proposing to do an ME7, base lined against SE 7 but with some features (like invokedynamic) will be removed.
    • ME seems to be heading towards the embedded space.
    • ME for SE developers LJC session by Oracle to help us gain insight into this area of standards (MV to organise).
  • ‘Adopt a JSR program’ is vital. We shall proceed by:
    • Update java.net with our JCP status (MB to follow up)
      • Blog about JSPA signature (BE to post)
    • Producing a Glossary of Terms (TG to update wiki)
    • Push out the ‘Adopt a JSR Program’ post (RW)
      • Give Richard access to LJC blog (MV)
      • Forward post to JUG leaders list during JavaOne once done (MV)
    • Send out details of our java.net page to committee  (MV)
    • At the next JCP meeting, review our JCP/JSR Content on java.net (all of us)
    • Adopt a JSR Logo – CC licensed Duke needs you (MV)
JSR-310 update (JG)
  • Blog post on TCKs etc (JG)
  • Volunteer Cat herding (JG)
  • Next step is to start the TCK planning stage (JG)
  • Contact threeten mailing list (JG)
  • Workshop on TCK at Open Conference (JG)
  • Get Oracle involved – Roger Riggs – (BE)
JSR-349 (Bean Validation)
  • Looking for adoptees, get Spec lead to send out a description (MV)

JSR-350 (session state enhancement)

  • Adopt a JSR – Introduce Madhu Konda and SN (BE)
  • Investigation, talk to Jeff Trent (and his upcoming replacement) (SN)

JSR-351  – Identity Management

  • Contact spec lead for further clarification of JSR  (BE)
Cheers,
Martijn

What is the LJC

The London Java Community (LJC) is a group of Java Enthusiasts who are interested in benefiting from shared knowledge in the industry. Through our forum and regular meetings you can keep in touch with the latest industry developments, learn new Java (& other JVM) technologies, meet other developers, discuss technical/non technical issues and network further throughout the Java Community.

Follow

Get every new post delivered to your Inbox.

Join 1,206 other followers