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 Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • How I Fixed a Silent Production Bug in Apache Airflow That Affected Thousands of Deployments
  • Accelerating Your Software Engineering Career With Open Source and Jakarta EE
  • Deterministic AI With OpenSymbolicAI
  • Automating Behavioral Evaluations for LLMs: A Practical Guide to Bloom

Trending

  • When Perfect Data Breaks: The Journey from Data Quality to Data Observability
  • Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack
  • RAG Is Not Enough: Advanced Retrieval Architectures Using Vertex AI Search on GCP
  • Edge Computing in Utility IoT: Two Architecture Patterns That Actually Work
  1. DZone
  2. Popular
  3. Open Source
  4. Thoughts on JSRs, TCKs, and Open Source

Thoughts on JSRs, TCKs, and Open Source

Most Technology Compatibility Kits are closed source, making it difficult to get reference implementations of JSRs certified. Is it time to change this?

By 
Sebastian Daschner user avatar
Sebastian Daschner
·
May. 27, 16 · Opinion
Likes (3)
Comment
Save
Tweet
Share
6.0K Views

Join the DZone community and get the full member experience.

Join For Free

In the Java EE umbrella every piece of technology is standardized under a JSR (Java Specification Request). The Expert Groups of the JSRs have to deliver the specification, a Reference Implementation, and a TCK (Technology Compatibility Kit). For most of the JSRs, the TCK is licensed as closed-source software and is not available for the public.

That has the implication that any vendor who wants to implement a specific technology has to explicitly apply/ask for/buy the TCK in order to test their implementation and get officially certified. The problem with this situation is clearly that it raises the barrier for potential vendors. Or, in other words, it would be a benefit for vendors to more easily join in the game. Having that said it would then also be more favorable for users of Java EE to have more competition among implementations.

If we follow the thought experiment of having solely OSS in the JSRs, another big change could be how users and developers interact with vendors. If somebody finds a bug in an implementation, then they could not only report the bug to the (certified) vendor but also report (and contribute!) to the TCK directly—as the tests obviously don’t cover that specific case for certified implementations. Then the providers would be notified about the change and some potential maintenance release of the TCKs could be delivered from time to time to check whether implementations are still certified. As a result, we all could ensure better software quality as anybody would be able to improve the tests of what is standardized in the specs.

Unfortunately only very few JSRs are fully open source currently, e.g. Bean Validation.

Other thoughts? Feedback is very welcome.

Open source

Published at DZone with permission of Sebastian Daschner. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • How I Fixed a Silent Production Bug in Apache Airflow That Affected Thousands of Deployments
  • Accelerating Your Software Engineering Career With Open Source and Jakarta EE
  • Deterministic AI With OpenSymbolicAI
  • Automating Behavioral Evaluations for LLMs: A Practical Guide to Bloom

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

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

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook