|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Sun's Initial Response to the Open Letter by Apache
As noted by Tim O'Brien, Sun has posted their initial response to Geir Magnusson Jr.'s open letter to them about the licensing terms of the testing compatibility kit for the JDK. A key point in the response: "Java technology has many stakeholders, and we recognize that we will not be able to please everyone as we move through this process."
Other core points in the initial response:- Sun is working with as many communities as possible to create an open source implementation of the Java platform under GPL v2 that mainstream open source communities can work with - this includes TCKs.
- We know that the open source process is a journey and we will continue to work with the open source communities and the licensees to determine how Java technology evolves.
This is only an initial response, of course, and isn't an actual reply. Therefore, the actual response could be very different - but this is also quite in line with much of what Sun tends to say on the subject.
The open letter didn't actually say what the consequences of not opening the license terms would be. What do you think? Is this a situation where Apache's substantial support of the Java community might wither? What are the business implications of there being no Apache-licensed JVM?
|
|
|
Message #231139
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun's Initial Response to the Open Letter by Apache
I know little about this debate. I am interested in a clean version of the latest VM in Ubuntu and Redhat (no gccj stuff). I assume this is an IBM/Sun thing. Also, the quote below is a good point:
"Now that Sun is GPL'ing Java 7 *who cares* about Harmony? Is there really a big demand for buggy, incomplete, two revision old JVM's that may or may not run a Java application??"
|
|
|
Message #231140
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How long until open-source, Sun?
JavaOne is three weeks away and here we go for another conference where Sun's pledge is to open source everything. With this latest round, and especially the quote about "the open source process is a journey" makes me wonder, "How long is this journey?" And I'm not wanting my Dad or Mom to turn around from the front seat of our station wagon car and say "We'll get there when we get there!"
-Frank Cohen
http://www.pushtotest.com
|
|
|
Message #231142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java 6 on Ubuntu 7.0.4
This is a section from my Ubuntu JEE server setup that will allow you to run Sun's jdk6...
Install Sun's Java JDK:
If you have a previous version of the JDK installed you can un-install it.
sudo apt-get remove sun-j2sdk6.0 -y
Wait for Removing sun-j2sdk6.0 ...
Skip to Download JDK step.
sudo apt-get install fakeroot java-package -y
Wait for Setting up java-package (0.28) ...
cd /usr/share/java-package
sudo cp -ax sun-j2sdk1.5 sun-j2sdk6.0
sudo gedit sun-j2sdk.sh
Find amd64|x86_64-linux-gnu) section in case statement. This will work with JDK 6 update 0 through 9. In the following steps make sure you substitute the correct update number.
Add:
"jdk-6-"*) # SUPPORTED
j2se_version=6.0.0+update00
j2se_expected_min_size=105
found=true
;;
"jdk-6u"[0-9]*) # SUPPORTED
j2se_version=6.0.0+update0${archive_name:6:1}
j2se_expected_min_size=105
found=true
;;
Save file and close gedit.
sudo gedit sun-j2sdk6.0/install
Edit suffix=j2sdk6.0-sun
Save file and close gedit.
sudo gedit sun-j2sdk6.0/remove
Edit suffix=j2sdk6.0-sun
Save file and close gedit.
Download JDK from Sun (make sure you select the .bin version such as jdk-6-linux-amd64.bin).
cd to directory where JDK bin is located.
fakeroot make-jpkg jdk-6-linux-amd64.bin
Wait for Is this correct [Y/n]:
Enter Y
Wait for Press [Return] to continue:
Press Enter
Wait for --More--
Press space until Do you agree to the above license terms? [yes or no] is displayed.
Enter yes
Wait for The Debian package has been created in the current directory. You can install the package as root (e.g. dpkg -i sun-j2sdk6.0_6.0.0+update01_amd64.deb)
sudo dpkg -i sun-j2sdk6.0_6.0.0+update01_amd64.deb
Wait for Setting up sun-j2sdk6.0 (6.0.0+update01) ...
sudo update-alternatives --config java
Wait for Press enter to keep the default[*], or type selection number:
Enter 2 for /usr/lib/j2sdk6.0-sun/bin/java
java -version
Java version should be displayed:
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode)
|
|
|
Message #231143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How long until open-source, Sun?
In the words of Talib Kweli: "people ask me when the album is coming out, and I say, 'when it's finished'"... Not sure what your point is Frank other than to snap the fingers and have open source Java appear, again (didn't we just have this convo.) what does it matter?...
There are some limits to the java world that have been documented in the absence of OSS Java, SE, but the reality is that they have put their focus on Java, EE and have delivered a stellar success... anyway, isn't the promise of an open-source JVM predicated on the 'community' of developers who engage Sun on this effort?
|
|
|
Message #231151
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Looking for a timetable
Sun's been doing a good job lately of rennovating their Web properties to make their technology clearer. Just look at the good job they've done with the Web Services pages. They need something along the same lines for their OSS efforts. It would be great if there was a directory of Sun products, a status on their version and a roadmap to the product's open-source release.
To continue my kids-in-the-back-seat-of-the-car analogy, when I'm driving in the back of the Sun stationwagon, I'd like to know how much longer it will be until I can stretch my legs and go to the toilet!
-Frank
|
|
|
Message #231158
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun's Initial Response to the Open Letter by Apache
please note that linux took about 10 years to b a real competitor in the enterprise server market and now it seems that it is better than most commercial server Oses ,can we give harmony the chance to b that for java
harmony in less than 2 years reached more than 95% of the java api (and there is much already in the sandbox waiting to be committed) and several things in java SE6 have equivelant apache implementation(jaxWS->cxf,derby ....) so actually in another one year apache may complete java6 certification, so give it the chance and see,may b u find a better java implementation than BEA's(the fastest)
by the way Harmony have a very advanced and modular VM which can be used for both deployment and research,the new garbage collector implement very advanced concurrency and parellel algorithms and the JIT benchmarks is flying and is constantly evolving,the JVMTI implementation is really great
give that project s little bit of time and support(if u can) and u will c a great platform,if u cannot please let those people work in peace as their real intention is helping u get a better cup of java
Joe
|
|
|
Message #231159
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun's Initial Response to the Open Letter by Apache
The link 'Sun's initial reply' was posted within a few hours of them receiving the letter from the ASF. As such, I would suggest it should be considered to be just a standard holding statement.
Stephen Colebourne, ASF member, speaking personally
|
|
|
Message #231162
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looking for a timetable
Frank,
The web services pages on java.net are OSS pages, they are part of Glassfish, so they are investing a tremendous amount of energy and resources in to the Java OSS initiative. I believe they have given some timetable on the Java, SE efforts, with some estimation, and most likely, more clarity to come in a month,
I am not sure what you are looking for, other than some magic...
As for the Apache matter, I would like to reply to Geir since his comments fell under the radar, falling off the front-page: I am not a conspiracy monger, and there is a middle ground between conspiracy and common wisdom, its called alternative viewpoint, maybe you can appreciate that some people might have a different way of looking at the IBM/Apache relationship as it relates to Sun...
I simply thought about the implications of Harmony being an alternative to Sun's Java, SE OSS, and I am more than happy to continue that debate with you, in the absence of you referring to me as a conspiracy theorist...
|
|
|
Message #231183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun's Initial Response to the Open Letter by Apache
Couple of things.
First, this wasn't "Geir Magnuson Jr's" open letter, it was from the Apache Software Foundation. The contractual dispute is between Sun and the ASF, not Sun and myself. I'm just the member of the ASF currently dealing with JCP issues.
Second, how is
"Java technology has many stakeholders, and we recognize that we will not be able to please everyone as we move through this process."
a "key point"? It's space-filler at best. We're not asking for something new - they helped author and signed the JSPA back in 2002(?), so this can't be considered a surprise or change in process of any sort. Maybe they forgot about the terms in the last 5 years?
The other "core points" :
- Sun is working with as many communities as possible to create an open source implementation of the Java platform under GPL v2 that mainstream open source communities can work with - this includes TCKs.
- We know that the open source process is a journey and we will continue to work with the open source communities and the licensees to determine how Java technology evolves.
A charitable reading is that they are confused about the problem - it's not about "open source", it's about the contractual obligations of a spec lead under the JSPA. It doesn't matter if we used an open source license, a free software license, or a closed source license - Sun's obligations are the same.
Remember, we're not asking for the TCK under an open source license - we're willing to take it under a closed source license (like the 15+ other TCKs for other JSRs the ASF has licensed from Sun...). We just don't want the Java SE TCK license to try and withhold necessary IP from legitimate downstream users of tested, compatible Apache Harmony distributions.
geir
|
|
|
Message #231187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Geir
So you want an extension of the 2002 agreement, because you're Apache? Not because you have a legitimate open source question, but just because it has been done this way in the past? I don't see why this is not a business decision that Sun is able to evaluate on a per-JSR basis, and considering that there is real issues associated with compatibility and ultimately control of the Java platform, why should they not evaluate whether the JSPA applies to this instance...
As others have stated, why would there be a beacon of focus on Harmony when there is an OSS Java, SE effort from Sun, because competition is good for everyone?... Well, everyone, but Sun, in this case. Is there a TCK for multiple JVMs? Maybe there is, but it still remains Sun's decision to justify its own business case of whether Harmony is in its interests or not, you have not specifically spelled out why there is a compelling case, other than to fall-back on the competition is good argument....
Compatibility is a tricky thing at the SE level, as there is a lot to consider and Sun needs to figure out whether they care that there are multiple OSS efforts, Apache is a good test case for this evaluation, but it is not guaranteed consideration and implementation simply because of some press release in 2002...I think you need to consider that keeping Java "pure" is the core objective and not the facility of others to create projects around it, and calling them out in a public forum is not likely to do anything but inflame the debate between Apache and Sun, maybe you don't care, maybe you should...
But arguing over semantics in an open source license is one sure way to lose support for your cause before it even officially hits the market...it makes me think that this is an IBM/Intel effort to hit Sun where it hurts, and if I were Sun, which I am not, I would surely turn a deaf ear to any rumblings from so-called open source stewards that engage at such a level...
|
|
|
Message #231189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
taking the flamebait
I should really stay out of this, since it's not my baby in any sense, and since I really don't know the issues well enough to have an opinion for or against Apache or Sun. But somehow, Doug's posts just keep sucking me in....
So you want an extension of the 2002 agreement, because you're Apache?
I believe that the 2002 agreement that Geir referred to was the modification to the JSPA. I do not know of any time windows that were applied to that revision. So, I don't think that Apache is looking for an extension to the terms, but rather, they are looking for Sun to obey Apache's interpretation of that agreement. Also, I think that they're looking for this because it's how they interpret the JSPA, not because they're Apache.
Not because you have a legitimate open source question, but just because it has been done this way in the past?
... pretty much. It's been done that way in the past because that's what the JSPA spells out (or at least, what Apache interprets that the JSPA spells out -- I'm no expert here). My understanding is that the issue at hand has noting to do with open-source versus closed-source.
I don't see why this is not a business decision that Sun is able to evaluate on a per-JSR basis
... because when Sun decided to run the spec through the JCP, they agreed to the terms of the JCP. The JCP is not Sun; Sun is a (key) participant in the JCP. The JCP rules apply to them just the same as they apply to the rest of us.
there is real issues associated with compatibility and ultimately control of the Java platform
I don't understand where compatibility issues come into play in this scenario. It would seem to me (an outside observer) that Apache is asking for the ability to demonstrate that their implementation is compatible, not that they're trying to get out of any compatibility tests.
it still remains Sun's decision to justify its own business case of whether Harmony is in its interests or not
True enough, but it would seem that the rules of the JCP should apply to this JSR just as they apply to others. So, if Sun feels that the terms put forth under the JCP are not adequate for their IP, they should work to change the JCP rules, or choose to not use the JCP as the avenue to standardize their products. This is not a new idea; take a look at the SCA spec for an example of how BEA and IBM and others did this in recent history.
Is there a TCK for multiple JVMs? Maybe there is
I'm not sure what you mean with the "multiple JVMs" bit, but there is definitely a compatibility suite for the Java spec. In fact, I believe that this is what the whole hubbub is about.
Compatibility is a tricky thing at the SE level, as there is a lot to considerI don't follow... it would seem that if Sun has a JCK, then they're confident that there is a way to gauge compatibility. Also, bear in mind that Sun has plenty of experience with certification of JDKs, or at least JVMs. BEA and IBM have both been licensing the JVM for years now; presumably, Azul and others are licensees as well. From what I can tell, the issue at hand is to do with limitations how a compliant implementation can be used, not with whether or not it can be declared compliant.
>Sun needs to figure out whether they care that there are multiple OSS efforts, Apache is a good test case for this evaluation, but it is not guaranteed consideration and implementation simply because of some press release in 2002...
I'm no expert, but I think that it's not a press release, but rather the terms of the JSPA, that are in question here.
arguing over semantics in an open source license
I don't think that Apache is attempting to pose any arguments at all, semantic or otherwise, about open source licenses.
-Patrick
|
|
|
Message #231205
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Geir
Douglas Dooley :
So you want an extension of the 2002 agreement, because you're Apache? Not because you have a legitimate open source question, but just because it has been done this way in the past?
Did you actually read the letter and FAQ? We're not looking for an "extension" or change. We're looking for compliance with the agreement.
I don't see why this is not a business decision that Sun is able to evaluate on a per-JSR basis, and considering that there is real issues associated with compatibility and ultimately control of the Java platform, why should they not evaluate whether the JSPA applies to this instance...
Because that isn't how the JCP - or any open standards body - works. You can't let one market participant control who can use a spec and how. If you do, then you don't have an open standard - rather you'd have the situation you have with .NET. No one will invest in creating an independent implementation if your competitor gets to tell you want you can do with it.
This has nothing to do with compatibility or control over the Java platform. That's just FUD. We're trying to demonstrate compatibility, and the whole "control" meme is an attempt to divert the discussion. The ASF isn't trying to "control the Java platform". We're trying to implement the Java SE spec. Just like we've done with countless other JSRs, including Java EE. And I'll point out that when the ASF was getting the TCK license for Java EE, we heard the same FUD about "break compatibility", "control of the platform" and similar nonsense, and since then, the sky hasn't fallen - Java EE has thrived.
Did you actually read the letter and the FAQ?
As others have stated, why would there be a beacon of focus on Harmony when there is an OSS Java, SE effort from Sun, because competition is good for everyone?... Well, everyone, but Sun, in this case.
Are you now suggesting that Sun wishes to eliminate competition and choice in the Java ecosytem? Sun has benefitted greatly from the health of the Java ecosystem, and the Java ecosystem is healthy because it's diverse and competitive. Users have choice. Java is fast now because IBM and BEA showed up and built faster Java implementations that Sun did. That cause Sun to make theirs faster. IBM and BEA went faster still. Sun then went faster. How is this bad for anyone? Choose any other JSR with multiple implementations, and it's the same story - the tech improved, the ecosystem improved, the value to users improved.
Is there a TCK for multiple JVMs?
Yes! How do you think BEA and IBM test their implemetnations of Java SE? Java SE is a specification. The JCK tests implementations of the specification. It's not only for Sun's implementation. have you ever seen or used a TCK?
Maybe there is, but it still remains Sun's decision to justify its own business case of whether Harmony is in its interests or not, you have not specifically spelled out why there is a compelling case, other than to fall-back on the competition is good argument....
That's nonsense. Sun contractually agreed to this when they became spec lead for Java SE 5. Sun can make choices about what to do with it's own technology, but people don't participate in the JCP to let Sun tell them what they can do with their own technology. That's one of the broader implications of this disagreement - does the JCP produce "IP safe" (in the conventional sense) specifications?
Compatibility is a tricky thing at the SE level, as there is a lot to consider and Sun needs to figure out whether they care that there are multiple OSS efforts, Apache is a good test case for this evaluation, but it is not guaranteed consideration and implementation simply because of some press release in 2002
I don't think you understand what's going on. This isn't about a "press release" (although I'd argue that any Fortune 500 company would want to stick to it's promises...). It's a contractual dispute about the basic obligations on a spec lead as defined in the JSPA that Sun agreed to in 2002 when they signed the JSPA. Go to http://www.jcp.org/ and read about how the JCP works. You can find the JSPA there. Read that. Then, re-read the open letter and the FAQ.
I think you need to consider that keeping Java "pure" is the core objective and not the facility of others to create projects around it, and calling them out in a public forum is not likely to do anything but inflame the debate between Apache and Sun, maybe you don't care, maybe you should...
This has nothing to do with "keeping Java 'pure'". As we said in the open letter, Sun's intent to place restrictions on how our users can use a tested compatible distro of Apache Harmony is based purely on their own business interests. It has nothing to do with supporting compatibility in the platform (because after all, that's what we're trying to achieve here...) nor does it have to do with "purity". All of that is a distraction to avoid having to deal with the real issue.
But arguing over semantics in an open source license is one sure way to lose support for your cause before it even officially hits the market...it makes me think that this is an IBM/Intel effort to hit Sun where it hurts, and if I were Sun, which I am not, I would surely turn a deaf ear to any rumblings from so-called open source stewards that engage at such a level...
This isn't about semantics in an open source license. The license has nothing to do with it.
I don't think the comment about Intel and IBM is worth addressing - that's just more distracting FUD.
geir
|
|
|
Message #231228
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
zzzzz
I read on ASF's site that the 2002 JSPA extension only applies to 5 projects, and it looks to me to further the cause of JAX, among basic app server implementations of servlets and JSPs. Can you explain why Geronimo has been successful in its relationship vis-a-vis Glassfish when Harmony cannot be with respect to openJDK without a TCK agreement - - just the 'field of use' clause?
I disagree with this statement from your letter:
"The JCP was clearly designed to prevent any single actor from being able to exhibit this sort of market control."
The JCP was organized to maintain compatibility, but Sun as the guarantor of Java can exert market control as it relates to its competitors. Maybe Jonathan will give you what you ask for, and produce an agreeable JCK for SE, but it seems like you will be implementing a competing platform for Java, whether or not you're FLOSS, non-profit, or aligned with corporate/competitive entities...
This is all done within context, I don't think you can overlook the position that Sun is not a non-for-profit and Java is their franchise, I would pay close attention to Harmony becoming the default SE platform, and would potentially introduce some restrictions on the distro. of it in order to maintain compatibility + market control of Java...
Perhaps, and I may be wrong on this, but perhaps, there is too much peace-and-love in the Apache approach, and Sun will need to protect their investment that results in financial returns for investors. Now, that may not be as much return as say compatible implementations brings through diverse representation in the marketplace, but we are talking about SE, which is core, and represents a vital/important element of the Java franchise...
A year ago, i would say that I am all-washed-up in this argument, that the Java 'community' is more important than any openJDK project could be, but after a year of JBI, SCA, Glassfish, and Geronimo, i would be tempted if I were Jonathan to just stick it to you and let Sun claim the prize for dominance in Java - - isn't that what Sun analysts have been calling for from the beginning, or at least since 2000?...
|
|
|
Message #231238
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java 6 on Ubuntu
JDK and JRE 6 have been available for a long time as a regular package - but I think they are in the multiverse. Steps to install:
enable multiverse
search for and install sun-java
|
|
|
Message #231267
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun's Initial Response to the Open Letter by Apache
I think these points would make a useful addition to the FAQ, particularly paragraphs 3 and 4.
On another note, wouldn't it be fair to say that aside from the seriousness of the contract dispute, another important factor in the decision to publish an open letter at this time was that the current situation restrains Harmony's ability to compete with OpenJDK for the first-to-market certified open-source JDK?
|
|
|
Message #231290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: zzzzz
Douglas Dooley :
I read on ASF's site that the 2002 JSPA extension only applies to 5 projects, and it looks to me to further the cause of JAX, among basic app server implementations of servlets and JSPs.
I think you misunderstand. The JSPA was modified for all signatories. Every signer has the terms apply to them, and right now, that's *ever* member of the JCP.
Can you explain why Geronimo has been successful in its relationship vis-a-vis Glassfish when Harmony cannot be with respect to openJDK without a TCK agreement - - just the 'field of use' clause?
The ASF's Java EE TCK license has no such field of use clause. Of the 15 (?) TCK licenses that the ASF has, the Java SE TCK license is the first with such restriction.
I disagree with this statement from your letter:
"The JCP was clearly designed to prevent any single actor from being able to exhibit this sort of market control."
The JCP was organized to maintain compatibility, but Sun as the guarantor of Java can exert market control as it relates to its competitors.
Nope. Please let me know where you see that in the JSPA.
Maybe Jonathan will give you what you ask for, and produce an agreeable JCK for SE, but it seems like you will be implementing a competing platform for Java, whether or not you're FLOSS, non-profit, or aligned with corporate/competitive entities...
Nope, it's just another implementation of the Java SE spec.
This is all done within context, I don't think you can overlook the position that Sun is not a non-for-profit and Java is their franchise, I would pay close attention to Harmony becoming the default SE platform, and would potentially introduce some restrictions on the distro. of it in order to maintain compatibility + market control of Java...
Perhaps, and I may be wrong on this, but perhaps, there is too much peace-and-love in the Apache approach, and Sun will need to protect their investment that results in financial returns for investors. Now, that may not be as much return as say compatible implementations brings through diverse representation in the marketplace, but we are talking about SE, which is core, and represents a vital/important element of the Java franchise...
I think the fallacy here is that Java is solely "Sun's investment". The entire industry has been investing in Java for years now with the understanding as described by the JSPA. Now you think Sun should say "sorry... just kidding! Thanks for the IP" ?
A year ago, i would say that I am all-washed-up in this argument, that the Java 'community' is more important than any openJDK project could be, but after a year of JBI, SCA, Glassfish, and Geronimo, i would be tempted if I were Jonathan to just stick it to you and let Sun claim the prize for dominance in Java - - isn't that what Sun analysts have been calling for from the beginning, or at least since 2000?...
They'd win the battle and lose the war. We're just the canary in the coal mine.
geir
|
|
|
Message #231293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm hoping
My comments on that post about GPL vs. BSD, are conjecture (only conjecture). The only thing I can guess is that they just need time to discuss a real response. I hope this is resolved for the sake of the platform, I hope Sun realizes that Harmony can help push the debate.
But, I think Sun's Java people are focused on one thing right now, preparing for the conference, so I'm not holding my breath for a response.
|
|
|
Message #231294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I'm hoping
But, I think Sun's Java people are focused on one thing right now, preparing for the conference, so I'm not holding my breath for a response.
IMHO, this is a pretty weak excuse. Sun is a multi-billion dollar company. I would hope they can deal with organizing a conference and this pretty important issue, all at the same time.
|
|
|
Message #231321
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Easier
Yes, but will this get you any version you want (easy answer, no)? This methos also work on pre 7 releases.
|
|
|
Message #231325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
who cares?
This is all done within context, I don't think you can overlook the position that Sun is not a non-for-profit and Java is their franchise, I would pay close attention to Harmony becoming the default SE platform, and would potentially introduce some restrictions on the distro. of it in order to maintain compatibility + market control of Java...
WHo cares? Harmony is so irrelevant Sun should just give Apache what they want and save the PR mess Geir is trying to drum up.
|
|
|
Message #232272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Billy Berk cares?
WHo cares?
You care ... enough to post your usual biased drivel.
yeah, it's really astonshing ..... and not even entertaining anymore...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
