Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

JSRs for Java 7 and Java 8 Approved

The results of the recent Java JSRs are in, and all have passed with all but Apache voting consistently against them. Google and Tim Peierls voted against the Java SE 7 and Java SE 8 JSRs, supporting the ongoing licensing issues and field-of-use restrictions for the TCK.

The comments make interesting reading; Steven Colebourne summarises them on one page. Even though the majority voted for the TCK, the comments continue to criticise the licensing issues:

Google: is voting no because of its licensing terms

SAP AG: While we believe it is important for Java 7 to proceed now, we want to express our disagreement about Oracle's decision regarding the TCK for Apache.

Eclipse: is disappointed with the continuing issues around Java licensing

RedHat: is extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead

Credit Suisse: The current battle around licensing term, however, reveals that Java never actually was an open standard.

Many of the comments also show that they are begrudgingly voting for the JSR if only to move the Java platform forwards from the stagnant location it is today. In addition, modularity raises its voice in both the Java SE 7 and Java SE 8 discussions, with OSGi interoperability being mentioned specifically for the Java SE 8 JSR.

This is also the first time an umbrella Java SE JSR has been put to the vote before it's actually ready. Whilst the work on Project Coin and Project Lambda have made significant progress recently, and the other inclusions (such as JDBC 4.1) in Java SE 7 will be welcomed, the contents of the Java SE 8 JSR include a number of not-even-started JSRs. Perhaps when Java SE 8 is ready, Oracle can point back to the votes and claim that it was agreed by most, even if the Java SE 8 content differs markedly from its original version.

However, with the licensing issue left unresolved, some are calling the JCP “Just Customers, Please” – Oracle does not appear to take the JCP seriously any more. The last stage in this saga will be Apache's resignation from the JCP which will follow up on their earlier threat. Here is what may be the Apache Foundation's last vote on a JSR:

The Apache Software Foundation must vote no on this JSR. While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because:

This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions. We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.

On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations. We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.

The spec lead has ignored repeated requests from multiple EC members for and explanation of both a. and b.

The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice. We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP. The rules apply to everyone.

While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.

Tim Peierls has now resigned from the JCP EC

The last straw for me was Oracle's failure to address the ambiguous licensing terms in JSRs 336 and 337 (the Java SE7/8 umbrella JSRs) before the EC had to vote on them. At first I abstained, but I was so dismayed by Oracle's silence that I changed my vote to No, joining the Apache Software Foundation and Google.

So developers should do what then?

Your message is awaiting moderation. Thank you for participating in the discussion.

I'm pretty comfortable with some other languages but the Java platform is where I feel at home. If Oracle makes it annoying for businesses to use JVM technologies because of licensing contracts then are they not killing off Java jobs? This seems to contradict Oracle's, I presume, long term goal of having more people use Java. All the legalities confuse me so any insight people have to share is appreicated.

Re: So developers should do what then?

Your message is awaiting moderation. Thank you for participating in the discussion.

I'm pretty comfortable with some other languages but the Java platform is where I feel at home. If Oracle makes it annoying for businesses to use JVM technologies because of licensing contracts then are they not killing off Java jobs? This seems to contradict Oracle's, I presume, long term goal of having more people use Java. All the legalities confuse me so any insight people have to share is appreicated.

I think there may be a general misconception around this - from where I sit, Oracle's fundamental motivation has always been profit (which in theory is the motivation for all companies - they are there to make money), however Oracle's perspective seems to be more focused upon profit in the shorter term rather than in the longer term (whereas those who tend to foster and grow open source communities are more focused on the longer term).

I don't know if having more people use Java by keeping things open and free is the best way to maximize Oracle's profit from this Java thing which they acquired from Sun - there may be much more profit to be had by raising prices and slowly choking off the Java ecosystem. It may mean that there will only be 5 years of life left in Java, but if Oracle turned around tomorrow and started charging everyone $5k per 2 CPU cores/1 server to deploy the JVM in production environments (and removed the classpath exception on OpenJDK's GPL license, which as I understand it would force anyone writing code to the OpenJDK to GPL their own code unless they bought an Oracle license), what reasonable options would people have? Can you simply dump all of your Java code tomorrow and go somewhere else?

It's entirely possible that the widespread perception that Oracle wants to foster and grow the Java community is simply wrong, and isn't the path of greatest profit for Oracle. I admit that that's a very cynical view, and I don't know if it's correct, but it seems like it may be possible - I really hope I'm wrong.

Re: So developers should do what then?

Your message is awaiting moderation. Thank you for participating in the discussion.

Ryan, I don't think your comment is cynical at all. It's just one way of trying to understand what's going on with Java and Oracle. I think it is a valid assessment.

IMHO Oracle's main competitors in the corporate market are Microsoft and IBM. I don't think they would consider the Open Source community a competitor. Market penetration of application platforms other than the JVM and the CLR is low.

By locking down Java, Oracle can create challenges for one of its key competitors, IBM. But the same move would strengthen the other key competitor, Microsoft. Managers who are choosing between the two might find the uncertainty surrounding Java to be a decision point in favor of Microsoft. Of course, most large organizations have both platforms in house, but they could emphasize one or the other in their future in-house development and choices of COTS packages.

I suspect these competitors are foremost in the minds of business planners at Oracle. The Open Source community will be affected by their decisions, but it is not the target of those decisions.

Interesting...

Your message is awaiting moderation. Thank you for participating in the discussion.

...that several entities voted "Yes" while claiming in their comments that they support (in one case, "demand") open licensing standards. The way to express support (or a "demand") for open licensing standards is to vote "No." No other statement or action means "We support/demand open licensing standards." Period.