DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
11 Monitoring and Observability Tools for 2023
Learn more
  1. DZone
  2. Popular
  3. Open Source
  4. Why I Think the JCP is Wrong About JSR 357 and Innovation

Why I Think the JCP is Wrong About JSR 357 and Innovation

Markus Eisele user avatar by
Markus Eisele
·
Mar. 20, 12 · Interview
Like (0)
Save
Tweet
Share
4.75K Views

Join the DZone community and get the full member experience.

Join For Free

As of yesterday the newly proposed JSR 357 (Social Media API) was declined by the JCP Executive Committee for SE/EE. With eight clear "NO" votes, two abstain, five "YES" and one not voted member this is a clear result.

 
If you are examining the voting comments, you see two obvious reasons for this to happen. One is the scope of the proposed JSR which "is far too wide" (IBM) and the second is "it's a bit too early to start standardizing on social" (Twitter). While the first has some additional aspects around having to specify relevant domain objects (which is very similar to what the Java Identity API, JSR 351 will have to solve) the second one is surprising.

When should Standardization happen?
Have you ever thought about standardization? When exactly should it happen? And why? First of all you have to look into what standards provide. For a German like me it feels normal to look at what German DIN institute has to say about this:

"Standardization is a strategic instrument for economic success. By becoming involved in standards work, businesses can gain a competitive lead through timely access to information and knowledge. They can use this to their own advantage, reducing the risks and costs involved in R & D as well as greatly reducing transaction costs."
(Source: din.de)

 

Further on the relation to the field of innovation is expressed as follows:

 

"Standards serve as a knowledge base and catalyst for innovation. [...] Standards help researchers in various ways: They lay down terminology in new technological areas, set quality and safety norms at an early stage of development, and introduce the necessary standardized, compatible interfaces. [...] Carrying out standardization at an early phase of development helps establish high tech innovations on the market."
(Source: din.de)

 

This expresses what I have seen in the wild a lot. Take a look at what happened with HTML, WebSockets or NoSQL. Or compare some open source projects. If you start putting a lot effort into something you have a high interest in spreading the word. Even if it only is a small spin off and you don't have too much common sense you start putting your thoughts and code into a sandbox or at least a wiki. To me standardization is the key to innovation because it simply is a short term which means nothing else than "put all players at a table together".

Documenting the status quo?
This is exactly the opposite of what the EC members had to say about the JSR 357. Reading through the lengthy comment section gives you the impression, that there should be standards if some kind of solution is mature enough to be used by a majority already. In other words: We wait for the unofficial reference implementation which drove enough companies into a vendor-lock-in situation (closed- or open-source) and start standardizing afterwards. If you followed the JCP long enough you might have seen this before. Doesn't it sound like Seam 2/Spring for CDI or Guice for JSR 330? I for myself am not sure if this is the right way to go with the JCP in general. If it is common sense to only adopt what is already out there the JCP will fall behind recent developments and trends even faster than it already did in the past. And it always will follow some kind of documenting the status quo approach. Is that, why we need all the "big names" in the JCP? Because having them agreeing to a standards guarantees for their adoption? I don't think it was meant that way.
I would love to call on the EC members to accept their commitment for developing the Java ecosystem and take this more seriously in the future.

Other Aspects
Let's finish this little angry excursion with the still open issues with 357. Yes. It finally is too broadly scoped. The spec leads have accepted this before and addressed it with a direct communication with the EC members.

 

"... the scope of the JSR primarily is Connecting to Social Media Services and Providers, so similar to the first JSON JSR one could see it as Java Social Media Client API"
(Source: Goldman Sachs & Co voting comments, jcp.org)

 

This obviously should have been more clear upfront and the spec leads and the designated EG should have taken some action to address those issues earlier.
Further on it might be a bit risky to rely on things that don't exist yet in the standard. Namely REST client API and JSON processing. But this shouldn't have been a major issue and it happened before to other JSRs.

Bottom Line
It was obviously too early for this JSR. At least for the JCP as it is today. And it showed very clearly what it takes to successfully pass a review ballot. You need a hell lot of support among the EC to move stuff forward. As of today the combination of simply technical voting members like the LJC and the political voting members like SAP and IBM leads to a very easy and fast rejection of a JSR. Maybe it would be a good idea to think about different review ballots for technical and business impacts and define different constraints on JSRs if they are rejected by one or the other ballot. A JSR which was rejected by a business ballot could still be formed and have an active EG which could start developing on it's standard. All under the wings of the JCP. This is exactly what it should be to me. A community process. Not a documentation tool.

Open source

Published at DZone with permission of Markus Eisele, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The Power of Zero-Knowledge Proofs: Exploring the New ConsenSys zkEVM
  • Authenticate With OpenID Connect and Apache APISIX
  • Running Databases on Kubernetes
  • A Beginner's Guide to Infrastructure as Code

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: