DZone
Java Zone
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
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > 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?

Sebastian Daschner user avatar by
Sebastian Daschner
·
May. 27, 16 · Java Zone · Opinion
Like (3)
Save
Tweet
5.19K 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.

Popular on DZone

  • Ultra-Fast Microservices: When Microstream Meets Wildfly
  • Top 11 Cloud Platforms for Internet of Things (IoT)
  • What Is Cloud-Native Architecture?
  • Ultra-Fast Microservices: When Microstream Meets Payara

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • 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:

DZone.com is powered by 

AnswerHub logo