These are the final results of the JSR Renewal Ballot for JSR #377. The EC has approved this ballot.

JSR377

StageJSR Renewal Ballot

Ballot durationFeb 16, 2016 to Feb 29, 2016

Special Vote Instructions

The Specification Lead has provided this statement of intent to continue the JSR: "Development of the JSR-377 spec was successfully started in early 2015 and continued of to this date. Online discussions and face-to-face meetings have occurred during the whole year, this includes EG members and external contributors. A version of the current API design has been posted to the code repository. Still pending: posting updates to the specification documentation with more explanations of the overall design and reasoning behind each of the API's elements."

Votes

EC

Arm Limited

Azul Systems, Inc.

Credit Suisse

Eclipse Foundation, Inc

* Ericsson AB

Fujitsu Limited

Gemalto M2M GmbH

Goldman Sachs & Co.

Hazelcast

Hewlett Packard Enterprise

IBM

Intel Corp.

Keil, Werner

London Java Community

Magnusson Jr, Geir

MicroDoc

NXP Semiconductors

Oracle

Red Hat

* SAP SE

Software AG

SouJava

TOTVS

Twitter, Inc.

V2COM

* EC Member: Voting rights have been suspended according to JCP 2.8.

Vote Log

EC

On 2016-02-28 MicroDoc voted Abstain with the following comment:
MicroDoc voted abstain mainly because of the slow progress and missing implementations to review.  
------------------------------------------------------------------------------
On 2016-02-29 Twitter, Inc. voted No with the following comment:
Twitter: We're voting no for the reasons that have already been brought up. First, the progress on this JSR has been very poor (low number of commits, long intervals with no activity, etc.), especially given how ambitious it is. Second, we also agree that the EG seems too narrow and not as inclusive as it should have been, given the scope of the JSR. We do like (and agree with) LJC's suggestion that this JSR should be relaunched as an open-source project to first get buy-in from potential users before standardization.
------------------------------------------------------------------------------
On 2016-02-19 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-28 Fujitsu Limited voted Yes with the following comment:
Fujitsu believes that the maintainers of Swing/JavaFX should join the JSR 377 EG.
EG should avoid to have any incompatibility in the existing desktop framework (Swing or JavaFX).
------------------------------------------------------------------------------
On 2016-02-29 Magnusson Jr, Geir voted No with the following comment:
As others noted, EG remains narrow, which to me is indicative of limited ecosystem interest, which then begs the question of why this should be standardized at this time.  I too suggest that the efforts be converted into an open source project to broaden community engagement and develop and prove technology that can later be proposed for standardization.
------------------------------------------------------------------------------
On 2016-02-26 Credit Suisse voted No with the following comment:
Despite the high goals set at the start of this JSR, there has not been a significant interest from others involved in the desktop or embedded application space. The TCK has no content and the suggested API has not had any real world testing against existing application frameworks, nor have others expressed significant interest despite a presentation at JavaOne. With the limited impact this JSR has had over the last year, and the fact that the initial review suggested getting others involved to move this JSR forward, Credit Suisse votes to not renew this JSR again.

------------------------------------------------------------------------------
On 2016-02-24 Arm Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-16 Keil, Werner voted Abstain with the following comment:
While a member of the EG (and also involved in at least 2 of the F2F occasions mentioned at JavaOne and a Hackergarten) I prefer to abstain at this point. I may reconsider this based on discussion with other EC and/or EG members but right now, the activity on GitHub:
https://github.com/jsr377/jsr377-api/graphs/contributors 
compared to e.g. JSR 354
https://github.com/JavaMoney/jsr354-api/graphs/contributors
which also faced a Renewal Ballot, and in the period before that started (Jan 21, 2013) saw over 10x more code contributions than JSR 377 API to this day: https://github.com/JavaMoney/jsr354-api/graphs/contributors?from=2012-11-28&to=2013-01-21&type=c (not even counting what was done mostly on java.net before) I am not convinced, that based on this activity we'll manage to get this JSR to a similar stage as 354.
------------------------------------------------------------------------------
On 2016-02-16 Software AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-16 TOTVS voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-16 Azul Systems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-29 IBM voted Abstain with the following comment:
IBM is abstaining from voting on this JSR. While we continue to believe the technical scope of the JSR will likely create significant difficulties in its implementation and adoption, we see no reason the JSR shouldn't proceed.
------------------------------------------------------------------------------
On 2016-02-29 Hewlett Packard Enterprise voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-29 NXP Semiconductors voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-25 Gemalto M2M GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-24 London Java Community voted No with the following comment:
In the previous vote for this JSR, we voted yes but raised concerns about the makeup of the EG (which impacts the relevance of this JSR). Despite efforts put in by some EG members to recruit key stakeholders in the industry and to produce some technical work, the LJC does not believe that this JSR should go ahead.

Without the explicit support of the maintainers behind SWT, Swing and JavaFX (the 3 dominant desktop UI toolkits for Java today), this does not seem to be an area which the industry is wanting/expecting standardisation.

We do believe some of the ideas in the JSR have strong merit, especially in the embedded space and encourage the EG to create an OSS project around those to test the market (before engaging in a standardisation process).
------------------------------------------------------------------------------
On 2016-02-29 Goldman Sachs & Co. voted Abstain with the following comment:
We're voting abstain because of the slow progress and lack of involvement from maintainers in the Swing, JavaFX and SWT communities.
------------------------------------------------------------------------------
On 2016-02-29 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-23 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-28 Hazelcast voted No with the following comment:
Hazelcast votes with no for this renewal. Despite the actual very interesting goal (even though we're not in the desktop space ourselves) neither the API not the TCK seem to have evolved far over the last year. Unfortunately there are only about 40 commits combined in both repositories.

Additionally Werner, who is part of the EG, stays abstained and Credit Suisse itself already voted against the he renewal.

Anyhow we really want to engage the initiators and any interested person to start this effort as an open source project and to gather broader interest in the community.
------------------------------------------------------------------------------
On 2016-02-29 SouJava voted Yes with the following comment:
SouJava votes YES, because we think we should allow the Spec Lead some time to regroup the EG. We would like to stress that this was not an easy decision, and our members had many concerns about the status of the specification. 
We will not vote YES again, unless the following is addressed by the Spec Lead:
- Increase contributions: we don't see enough contributions both from the EG and the wider community
- Increase the pace: this specification had to request a renewal because things are moving too slow 
- Show clear progress: there is little indication of evolution on the spec or on the implementations 
- Increase participation and diversity: there isn't enough participation in the EG, and it would be important to include representatives of important Desktop APIs like Swing, JavaFX, NB Platform, Eclipse Platform, SWT
Since this JSR failed to gather interest from the wider community, we fear that either the Spec Lead has failed to involve the right people from the industry, or worst, there is little interest from the community on the subject matter. 
If the later is the case, maybe the JSR is out of its time, and needs to be disbanded. If the Spec Lead believes there is indeed interest, maybe there is need of creating specific activities around this JSR through the Adopt-a-JSR program to increase awareness? As part of the EG, we are available to help.
------------------------------------------------------------------------------
On 2016-02-29 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2016-02-29 V2COM voted Yes with no comment.
------------------------------------------------------------------------------