Why Oracle Should Cede Control of Java SE (infoworld.com)

An anonymous reader quotes InfoWorld: Now that Oracle wants to turn over leadership of enterprise Java's (Java EE's) development to a still-unnamed open source foundation, might the same thing happen with the standard edition of Java (Java SE) that Oracle also controls? Such a move could produce substantial benefits... Oracle said it has no plans to make such a move. But the potential fruits of a such a move are undeniable.

For one, a loosening of Oracle's control could entice other contributors to Java to participate more... [W]ith the current Oracle-dominated setup, other companies and individuals could be reluctant to contribute a lot if they see it as benefiting a major software industry provider -- and possible rival -- like Oracle... Indeed, the 22-year-old language and platform could be given a whole new lease on life, if the open source community rises to the occasion and boosts participation...

Despite the potential to grow Java SE by ceding control, Oracle seems content to hold on to its place as the steward of JDK development. But that could change given the tempestuous relationship Oracle has with parts of the Java community. Oracle has been at loggerheads with the community over both Java SE and Java EE... Oracle may at some point decide it is easier to just cede control rather than having to keep soothing the ruffled feathers that keep occurring among its Java partners.

Comments

Re:What about following the Rust model?

[Anonymous Coward]

You joke, but this is what the Rust Code of Conduct says (with emphasis added):

We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.

The same paragraph that states "we don’t tolerate behavior that excludes people" starts with "We will exclude you from interaction".

potential fruits?

[Gravis Zero]

But the potential fruits of a such a move are undeniable.

How are these "potential fruits" going to help Oracle? I ask because that's the only thing Oracle actually cares about.

Oracle has no interest in doing "the right thing"

[gavron]

Public corporations tend to do things to benefit themselves. Oracle fought to get APIs covered by copyright -- and won. That's a step backward in the US software world in an amazing amount. Yes, the court didn't make Google pay because fair-use, but fair-user is judged on a case-by-case basis _at trial_. So going forward, because of Oracle's greed and unbending desire to control all of Java everything (and Android) all software developers in the US have this API pitfall to watch out for.

Second, even if there is no direct benefit, there's no indirect benefit to Oracle to open-source Java (or anything). So long as they can extract complex licensing and other fees from everyone wanting to use Java (EE) or the JDK or the API... that's exactly how they work.

Oracle wants to dominate The Market, All Markets, and Larry Ellison has an ego to rival anyone. Unfortunately people with large egos are unable to make decisions that benefit anyone other than themselves.

E

Re: Not a moron to face facts

[Anonymous Coward]

Netflix's backend is Java, among others. Java 8 / Spring Boot / Hibernate / Hysterix / Eureka is an extremely capable setup.

Java EE and JSP is old and shitty, but it doesn't mean all of Java is.

Re:Leave it for dead

[Anonymous Coward]

Native look and feel? Java's place is on the server. It's fucking huge there and going nowhere. This is where real software runs and where 'newer' things are not valued unless they're so much better than what they're replacing that it's worth the effort, which it hardly ever is. Java replaced COBOL here. Nothing else is even on the horizon right now.

Re: Plenty of facts

[Miamicanes]

The main problem with Scala is that it enables experienced Scala developers to write idiomatic code that's utterly indecipherable by anyone besides other, comparably-sophisticated Scala developers who've internalized that same idiom.

With Java, a less-experienced Java developer can still generally make sense of code that's above his skill level and eventually figure out how it works. With Scala, a less-experienced developer is just plain dead in the water because Scala allows *so much* to be implicitly defined by context & convention.

IntelliJ's Scala team is painfully aware of this. For years, they've been trying to mitigate Scala's problem at the IDE level by having the IDE sniff out code idioms defined by convention & context and display them semi-inline with the code itself. It helps, but in many cases it's more like fragile training wheels subject to breaking off at any time. And it makes Scala even more IDE-bound than Java... with Java, a good IDE is necessary for keeping sane & grunt-work automation... with Scala, it's an almost-essential part of deciphering code written by someone else *at all.* It's very hard to join a team of experienced Scala devs as an experienced Java developer and work efficiently alongside them... the Java-to-Scala learning curve is nowhere close to being as straightforward as most people initially think.

In short, Scala attempts to resolve Java's endless boilerplate code that needs an IDE for humans to manage efficiently with dense, idiomatic code that needs an IDE (doing de-facto realtime-decompilation & reverse-engineering) to be understood by humans.

With a good IDE, both meet somewhere near the middle of the "source readability" spectrum. My point is that Scala trades one major shortcoming (excessive boilerplate) for one that's approximately equal in magnitude, but opposite in details.

In theory, a good Scala developer can find a "happy middle path" that straightens up Java's boilerplate mess without becoming unreadable... but in the real world, Scala tends to just invert the old problem into an equally-bad new one.