Discussions

Apache Foundation Blogger Greg Stein asserted that open languages are not required, that Java being potentially closed and proprietary to oracle is not a problem for java developers and users.

He uses Visual Basic as an example, probably appropriate considering what a baby language Java is. Microsoft controlled Visual Basic entirely, and has taken care of its community through MSDN; migrating to .NET means that Microsoft has to take care that backwards compatibility is mostly preserved, that "there is an implied agreement that software developed today will continue to run tomorrow. There is a very real business need for Microsoft to avoid alienating their developers."

His concluding statements are these:

"I do not foresee Oracle imposing punitive licensing fees for the Java environment. Oracle is anything but stupid, and they will work hard to ensure that Java remains a useful development strategy. Building and deploying Java software is and will continue to be a very viable approach to enterprises.

"To further drive this point home, imagine if an enterprise chooses to "save costs" by avoiding the Java runtime costs. That implies a move to a different language (assuming that the majority of enterprises are using Java today). The cost of a move, in terms of training, hiring experts, rewriting entire application and tool suites, rounds of testing, and final deployment, will easily run higher than continuing to build and deploy Java applications.

"The right choice is to not worry about the state of Java's open or proprietary nature, despite some of the discussion occurring in the news today. It is not relevant to your business needs or the long term health of your enterprise software ecosystem."

From a strictly commercial reason, I couldn't care less (actually, I think unless you're working in a niche, closed languages should still be avoided). However, the reason why non-free and closed languages should be avoided is the Java Trap. Reverting to a closed Java would be a setback to the FOSS world.

I am not following this. What he is saying is it does not matter if only super expensive, proprietary java servers and development kits can get licensed by Oracle? So basically, if you want to use Java in an enterprise, you have to pay a vendor or work with an unofficial Java version which most likely will get sued into oblivion?

I am actively looking into how to migrate our code off Java and onto something not single vendor controlled. the question is what? If it comes down to being locked to a vendor, i would rather be locked to the super expensive, proprietary Microsoft stack.

Java is controlled by what real standards body? Oracle controls it and that is it. Why do i have to get my Java JDK from Oracle's OpenJDK project? Why can I not have a choice to use Harmony? Why is Oracle afraid of competition?

That's a reasonable question. For the past few years, Java was controlled by the JCP, which is an open standards body (albeit one in which Sun had a form of "final say" using its veto power, which it never used but could have).

Right now, the JCP vote is going on for the Java 7 specification. So technically one could argue that Java is still controlled by the JCP, although that is arguably just "theory" now since no new Java standard has come out under Oracle -- that is, until Java 7 is ratified by the JCP (or not ratified and then we see what has to change in order for it to be ratified).

Nathanial: Oracle controls it and that is it.

You do have a theoretical point, since Oracle is much more effective at exercising tight control on things that it owns and chooses to exercise control over. My hope is that Oracle both acts as a steward of Java (as Sun did) and participant of a vibrant community, but also that Oracle is able to build a profitable business around Java itself, so that the language and platform will qualify for signficant investment over time.

Nathanial: Why do i have to get my Java JDK from Oracle's OpenJDK project? Why can I not have a choice to use Harmony? Why is Oracle afraid of competition?

I'm going to assume what you really meant is "Why doesn't Apache have a license to the TCK?"

Answer: We are still hoping to come to a positive resolution with Apache on this matter, but it's not a simple matter because of "field of use" restrictions that Apache and Sun (now Oracle) were unable to come to agreement over. That said, we are actively working to see if this issue can be resolved, in the same spirit as we worked with Apple to resolve the "deprecation" issue (remember "the sky is falling! the sky is falling!" episode a month ago?)

Comparing 1990 with today makes no sense. The world has changed and the business are not exaclty the same. Today there is a healthy open source market. The same is not true for 1990.

On the other hand, the article seems a little contradictory: it says that Oracle is smart enought in order to not charging punitive licences... but also says that migrating to a new language would be very expensive for companies. So, Oracle CAN charge a good licence fee.

There is another mistake: the current licencing model doesn't prevent Apache Harmony of being tested as conformant. Apache guys doesn't want to pass the TCK because of the Field Of Use clause, wich contradicts open source principles. OpenJDK doesn't have this problem.

On the other hand, the article seems a little contradictory: it says that Oracle is smart enought in order to not charging punitive licences... but also says that migrating to a new language would be very expensive for companies. So, Oracle CAN charge a good licence fee.

Indeed! I noticed this as well. Another reason why it's a bad idea to use CLOSED languages.

On the other hand, the article seems a little contradictory: it says that Oracle is smart enought in order to not charging punitive licences... but also says that migrating to a new language would be very expensive for companies. So, Oracle CAN charge a good licence fee.

Indeed! I noticed this as well. Another reason why it's a bad idea to use CLOSED languages.

Honestly, that statement doesn't make any sense. Delphi was a closed language, but many people loved it. C# is technically a public standard, but there's so much left out of the spec that for purposes it's a closed language. Sql is a public standard, but there's so much variation between products that it's easy to "get stuck" with one vendor. Look at open source languages for example. Ruby has no official specification, so those trying to implement it on other platforms have to spend a ton of time validating their implementation. Python is another example of a language that is popular, but has no official specification.

I can understand people having irrational fears of certain companies, but saying all CLOSED languages should be avoid just doesn't hold water.

Honestly, that statement doesn't make any sense. Delphi was a closed language, but many people loved it. C# is technically a public standard, but there's so much left out of the spec that for purposes it's a closed language. Sql is a public standard, but there's so much variation between products that it's easy to "get stuck" with one vendor. Look at open source languages for example. Ruby has no official specification, so those trying to implement it on other platforms have to spend a ton of time validating their implementation. Python is another example of a language that is popular, but has no official specification.

I can understand people having irrational fears of certain companies, but saying all CLOSED languages should be avoid just doesn't hold water.

There are two different things here that need to first be examined separately and also holistically.

1. Quality: e.g. Closed languages tend to be more stable, well-supported, and consistent across their supported platforms than open languages. Obviously there are exceptions.

2. Strategy: e.g. lock-in and the risk of unforseen cost changes.

So a langauge (or tool) may be awesome but adopting it may completely terrible strategic decision. Alternately, a language could be really great from a strategy perspective and a complete pile of garbage to use.

Both options have to be weighed. Just because a developer loves a tool doesn't mean it's a good choice.

Honestly, that statement doesn't make any sense. Delphi was a closed language, but many people loved it. C# is technically a public standard, but there's so much left out of the spec that for purposes it's a closed language. Sql is a public standard, but there's so much variation between products that it's easy to "get stuck" with one vendor. Look at open source languages for example. Ruby has no official specification, so those trying to implement it on other platforms have to spend a ton of time validating their implementation. Python is another example of a language that is popular, but has no official specification.

I can understand people having irrational fears of certain companies, but saying all CLOSED languages should be avoid just doesn't hold water.

There are two different things here that need to first be examined separately and also holistically.

1. Quality: e.g. Closed languages tend to be more stable, well-supported, and consistent across their supported platforms than open languages. Obviously there are exceptions.

2. Strategy: e.g. lock-in and the risk of unforseen cost changes.

So a langauge (or tool) may be awesome but adopting it may completely terrible strategic decision. Alternately, a language could be really great from a strategy perspective and a complete pile of garbage to use.

Both options have to be weighed. Just because a developer loves a tool doesn't mean it's a good choice.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.