Another defection from the JCP Executive. This time Tim Peierls leaves, questioning whether JCP is now anything more than a rubber stamp for Oracle.

"Today I resigned from the SE/EE Executive Committee of the Java Community Process. I lasted about a year before giving up hope that the ECs would ever do anything meaningful.

"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."

http://tembrel.blogspot.com/2010/12/resigned-from-ec.html

On the positive side, Tim isn't leaving while shouting out a message about how the sky is falling.

But regardless of what is said, the sad message is that the JCP has had another high-profile defection.

go apache!.

some sanity still left in apache. 

JCP should not be called as java commercialization process. Oracle will spin its aggressive sales force and turn java into money making  machine with complete disregard to community.

Cameron Purdy - any thoughts ? :)

The great thing about apache is the community and committers are diverse. Not every apache committer feels that way. I personally don't get all this fuss over jdk TCK.

Shawn: some sanity still left in apache. 

I didn't realize that was in doubt. ;-)

Shawn: Oracle will spin its aggressive sales force and turn java into money making  machine with complete disregard to community.

I think you have two separate points here that you are trying to make. I'd like to address them individually:

* The first is whether or not Java can make money for Oracle. Considering it did not do so for Sun, it's a good question, but I do believe that there are some obvious ways in which Java can become a reasonable sized (and profitable) business in and of itself. I see this as a positive thing for Java, because it will support the investments that need to be made in the Java platform (and there are investments that need to be made!)

* The second is whether Oracle will make these decisions in a way that disregards the community. (Perhaps you really meant "will Oracle piss all the developers off?") While I can't predict the future, there is a strong desire within the engineering organization at Oracle (including the Sun team) to continue to be a great steward of the Java ecosystem, to invest in Java, and to find ways to make it into a healthy business while encouraging the continued grass roots adoption and the health of the developer community. Easy? No. Doable? Yes!

As for Tim, I respect his decision, and appreciate the contributions that he's made over the years. (And knowing his history, I have a hard time imagining that he won't continue to make contributions whether or not he's part of the JCP EC.) He explained his rationale, and it was obviously a decision that he gave a great deal of thought to.

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

Hey guys,

I raised a couple of questions on another thread recently and got an interesting response (thanks Martijn) and to avoid duplicate discussions I thought I would reformulate the questions here. Sorry for the cross-post. :-)

I raised two questions in the context of the recent Java SE 7 and 8 vote at the JCP:

1) Is the real issue for Apache the prohibitive cost of the Java SE TCK license and as a non-profit they want it for free, or is Sun/Oracle simply refusing to allow Harmony to become a licensed Java SE implementation regardless of whether or not Apache can pay the fees?

2) Are the field-of-use restrictions included in the Java SE TCK license really unfair, or do they exist for sound technical reasons, i.e. portability? I don't know the specific differences between the Java SE and Java ME APIs, but I can understand that if multi-threading or NIO or some other Java SE API is not supported across mobile devices then a vendor can't simply implement Java SE "for Mobile" because a lot of developers will be in for a shock when their apps don't work. (Portability is hard enough to achieve without standard, documented APIs suddenly not being available because a particular vendor decided not to implement them, right?)

I'm not looking for speculation here, does anyone have some hard facts on these issues? I have not read the fine print in the TCK license agreement, but I know that other JVM vendors have successfully licensed the Java SE TCK (e.g. BEA, IBM, Apple, etc.). I have difficulting believing that Sun Microsystems wrote the TCK license in bad faith or that having multiple open-source Java SE implementations is somehow a threat to Oracle.

I am not opposed to seeing Harmony certified as an open-source Java SE or Java ME implementation. Is the problem for Apache that once Harmony passes the TCK, the field-of-use restriction applies and Harmony can't be used on mobile devices? If so, Apache why don't you create Harmony SE and Harmony ME and license the appropriate TCKs? How is the Apache license incompatible with the Java SE TCK license?

I know the Java ME spec has not reached its full potential and it seems that now more than ever this is an opportunity for Google and Apache and other vendors to improve things in the mobile Java space. For instance, Java EE 6 introduced profiles, right? Why not do the same thing with Java ME and give vendors more room to innovate without having to implement all of Java ME?

Food for thought.

Ian

--
Ian Hlavats
Author, JSF 1.2 Components (Packt)
JSFToolbox for Dreamweaver - www.jsftoolbox.com

1) Is the real issue for Apache the prohibitive cost of the Java SE TCK license and as a non-profit they want it for free, or is Sun/Oracle simply refusing to allow Harmony to become a licensed Java SE implementation regardless of whether or not Apache can pay the fees?

That is not an issue at all. In fact, the people at the ASF who need access to a TCK need to sign an NDA which is, again, fine. The idea that this is about the TCK not being open source or about it costing money or anything like that is completely bogus. It's the restriction that the TCK places on the distribution of the certified software which is the problem.

 

2) Are the field-of-use restrictions included in the Java SE TCK license really unfair, or do they exist for sound technical reasons, i.e. portability? I don't know the specific differences between the Java SE and Java ME APIs, but I can understand that if multi-threading or NIO or some other Java SE API is not supported across mobile devices then a vendor can't simply implement Java SE "for Mobile" because a lot of developers will be in for a shock when their apps don't work. (Portability is hard enough to achieve without standard, documented APIs suddenly not being available because a particular vendor decided not to implement them, right?)

Oracle allows themselves to NOT have an FOU restriction on OpenJDK. They do not allow Apache, a fellow EC member, nor Harmony the same TCK option. How can that even possibly be justified as a "technical" decision? The truth is that Oracle wants to control Java, and it does so by controlling both the "commercial" as well as the "free" version. But even so, you cannot fork OpenJDK and make your own valid, approved, certified version of MyOpenJDK because even though the GPL allows you to fork the code, Oracle will never grant you a TCK for your fork!

Çini Silimi ve Karo Silimi i?lerine yo?unla?an firmamiz sizin için mermer ve zemin silimi i?lemlerini de yapmaktadir. Dizayn Restorasyon, Restorasyon Çini bak?m?, temizli?i ve beyazlat?lmasi i?lemleri yapilmaktadir.