 |
|
 |
|
|||
|
From: Sun Microsystems, Inc. | |||
Sun's Open Letter to Eclipse Membership |
An Open Letter to Eclipse Membership
January 30, 2004
Sun would like to congratulate the Eclipse organization on the eve of the transition to independence. This move proves again that the Java[tm] technology ecosystem is capable of spawning new value and continued technical diversity.
Given this noteworthy accomplishment, and the recent creation of javatools.org, Sun would like to reflect on what we hope the future has in store for Java technology-based tools and the enduring Java platform.
What we have in common: the Big Picture.
First and foremost, the main goal for all of us in the Java development community is to achieve the strongest possible technology and market position for the Java platform. The Big Picture is a Java technology solution that ensures no "lock in" to a given platform, one that generates competitive markets and technologies, and one based on standards. That way developers, deployers and consumers continue to have choice and benefit from technological diversity.
Thanks is due to Eclipse for joining Sun in genuinely exploring options.
Since July 2003, Sun and Eclipse have held many candid conversations and explored various options to join, merge and otherwise combine forces. In the course of these discussions we were able to set aside differences of technical opinion to pursue our common goal -- the Big Picture.
All those involved in the meetings would agree that the sticking points in the discussion were not so much technical in nature as they were business-related. Sun bases all of its commercial tools products on the NetBeans[tm] open source IDE. The required mandatory transition to the Eclipse platform would inhibit development of innovative technologies like the Sun Java Studio Creator product (code-named Project Rave), and require a reconstruction of all of our existing tools. Any entry criteria requiring that Sun abandon the NetBeans open source platform directly conflicts with the concept of choice and diversity, the very bases that gave Eclipse its beginning. If this condition were to change, we would be happy to reconsider. In the meantime, it is worthwhile to explore how we (and others) can work with Eclipse to align in a way that benefits the strength of the Java platform as a whole, especially with the multi-partner javatools.org community recently announced.
We hope in the near future to find a solution that benefits both the Eclipse and NetBeans communities -- in very visible, open ways -- where Sun can be an open contributor to Eclipse, and Eclipse can do the same for the NetBeans platform. In that manner, technology and IP can flow more freely so that both communities benefit. This tight alignment ensures that the Java platform wins.
Choice does not mean fragmentation!
Competition and technical diversity are not equivalent to fragmentation, as some would define it. In the process of your achievement, you've shown that competition and diversity have in fact helped win over more developers and software vendors to the Java platform, and further demonstrated its staying power and value. Technical diversity is always beneficial when it's aligned with accepted standards. And, regarding alternative GUI technologies, Sun is even working to ensure effective standards-based interoperability there as well.
Some key issues to watch.
Once the Eclipse organization files for incorporation, Java technology developers and the entire industry will be interested in the following issues:
* Independence of the Executive Director of Eclipse -- The organization's bylaws have given the director an unusual amount of power to form projects and assign resources. Will the director be an impartial guardian of the community (or be partial)?
* Project staffing -- Today, IBM controls 70 to 80 percent of the project staffers, who effectively operate independently of what the Board declares. Will this continue to be the case?
* Inclusion of outside IP -- If Eclipse is to grow, it must accept outside contributions from other platform vendors and should be willing to invest in the costs needed to accrete outside ideas. Ideas don't come free. Can you toe the very difficult line of being sensitive to the business interests of the participating vendors, and not just look at technology for technology's sake?
We're willing -- and able -- to help.
Sun has much to contribute to the community of tool vendors and to Eclipse in particular. For example, the NetBeans open source IDE, which has achieved well over 1.8 million downloads of NetBeans version 3.5 since its release in June, 2003, already delivers superb support for Web applications, for mobile clients, and for visual development of rich Java GUIs. And, the forthcoming NetBeans 3.6 release, available at in February, will support Web apps for the newest J2EE specifications including Servlet 2.4 and JSP 2.0.
Also, Sun has already been working to ensure that Swing GUI components can run inside of SWT containers such as Eclipse. Sun is in fact committed to actual Java technology interoperability, and committed to improving developers' lives to make it easier for portable Java technology-based code that works across the different vendors IDEs.
Advice and suggestions from our experience.
After years of driving the Java platform and community innovation and being the lead advocate for Java technology, Sun is heavily invested in Eclipse's mission -- and has a few suggestions.
Challenge yourselves to be more than an "exemplary framework" as stated in the Eclipse mission. Push the organization to be a unifying force for Java technology.
Diversity -- with alignment -- will aid in creating a stronger Java community and industry. You've proved it. But don't define "interoperability" on your own terms, but rather work with other major players in the industry to achieve actual interoperability. Working with the Java Community Process[sm] (JCP[sm]) and the Java Tools Community (JTC) would be great entrees into the discussion.
The question is no longer: "Will the Java tools industry move to one common source base?" That's always been a non-starter when you think about the players involved. The question is: "Will the new Eclipse work with tool vendors and developers to provide the richest set of offerings and maintain the Java technology and platform leadership in a competitive marketplace?"
We need to work together to make the Java platform a better, broader base for tools. That is the real issue. We trust Eclipse will help, not hinder, the effort.
Sincerely,
Sun Microsystems, Inc.
|
View all java.net Articles.
Showing messages 1 through 15 of 15.
-
SWT is the real problem . . .
2004-02-02 17:11:34 sleepy [Reply | View]
I think it's nice that Java users have several strong choices in terms of IDEs . . . Netbeans, Eclipse, IntelliJ. I myself have used all 3 and find the freedom of choice quite nice compared to Visual Studio.
However, in terms of application development, I hope SWT does not gain traction since it will fracture the Java community. Java developers will be faced with the choice of either Swing or SWT. Learning both is not practical for many developers. I truly hope that Eclipse will continue as a product and that they switch over to the Swing API. Besides, JVM 1.5 will provide 2D hardware acceleration via OpenGL (albeit for non-Windows platforms), thus taking away some thunder from SWT's native appeal. -
SWT is the real problem . . .
2004-02-05 06:20:12 flozano [Reply | View]
Well, SWT may be the biggest reason of Eclipse momentum. Swing has long had a bad reputation, it's pointless to fight with that. Besides, Swing has been a major blocking from having alternative Java VMs (IBM? BEA? They license Sun's one!)
Eclipse is already becoming part of Linux distributions. NetBeans never did. Why? Because you can't run it on any free software Java VM. But Eclipse you can, thanks to SWT.
I can't see why SWT fractures the Java community. Who defined Swing? Only Sun. Who things there's a need for something else? Everybody at the Eclipse Consortium, which may have today more members than the JCP, and many free software projects using SWT. So fracturing is just disagreeing with Sun?
Is JCP *the* Java community? No. It's a bunch of companies that sell Java products. It'll become a real community when everyone can observer everything that goes by and vote. Sore today JCP is more transparent than it was before, but it's very far from being "he voice of the community".
Besides that, no real community will have allways the same vision. There'll allways be divergences, and that's what enables evolution. So criticizing whoever has a different opinion is bad for the community.
Swing and SWT can be acomodated together. See for example SwingWT, a free software library which implements the Swing API on top of Swing. Why the JCP doesn't recognize the need for better native integration on the GUI and promotes something similar to SwingWT? So who needs native speed and lokk-and-feel gets, and who needs portability gets also by using the pure-java, traditional Swing. -
SWT is the real problem . . .
2004-02-06 18:11:09 sleepy [Reply | View]
"Who defined Swing? Only Sun."
I read the first 2 replies to my post. I do admit that you have some good points in your posts. I think the biggest message people should be taking away from this SWT/Swing affair is that the bottom line is about advancing Java, and that surely is something we all agree on. My original post was written in that spirit. Perhaps I should add to that post by saying that I sincerely do hope that whatever GUI API is adopted (whether that be only 1 or perhaps many), the API should truly allow developers to write the kind of rich-client apps Java developers are wanting. I also sincerely hope that to the many people involved in this discourse whose statements are derived from whether they like Sun or IBM as a company, be less heard compared to the people who truly discuss for the sake of Java.
Also, I'd to point out in reply to your statement:
"Who defined Swing? Only Sun."
Who defined SWT? Only IBM. It may be open now, but the majority of it, done by IBM, simply will not be changed. Instead of looking at this from company perspective, I think we simply need to find a way to make Java even better. I think an interesting question is whether or not having 2 large GUI APIs will effect the development community in terms of reading others' code (some people may only be familiar with one of the APIs) and in terms of whether a majority of developers will learn both SWT and Swing? -
SWT is the real problem . . .
2004-02-04 08:38:47 pulse1014 [Reply | View]
" truly hope that Eclipse will continue as a product and that they switch over to the Swing API"
Why fix something that isn't broken? Majorly refactoring the most popular Java IDE just because one company wants more control is ridiculous. Doing so will only slow down Eclipse's momentum.
SWT UI performance and the Eclipse application framework is here and now. Moreover SWT is open, Swing is not. Also while all the performance gains that Swing will get in 1.5 are great - it's also good to note that 1.5 is not here yet - right now they're just promises.
-
Eclipse's reply
2004-02-02 13:11:13 pulse1014 [Reply | View]
"Dave Bernstein, a former senior vice president and general manager of products for Rational Software Corp., worked as a consultant to the Eclipse Consortium after IBM acquired Rational and the Eclipse Consortium began to develop plans to spin off to form the new independent Eclipse Foundation. Bernstein led the committee that defined the new organization and spearheaded negotiations between Sun and Eclipse.
"I take Rich Green's [vice president of Sun developer tools and Java software] letter at face value," Bernstein said. "If Rich's impression that Sun must abandon NetBeans in order to join Eclipse is the only remaining impediment, then that's good news because there is no such requirement. I hope that Rich will engage with the Eclipse Foundation Board of Directors and agree to join as a Strategic Developer."
Bernstein added: "A key objective in creating the independent Eclipse Foundation was to evolve from a loose federation around IBM-driven development to a vendor-neutral non-profit corporation driving collaborative development among multiple industry leaders and open source projects. Launching the Eclipse Foundation is a very big step forward, but there's much more to be accomplished. I have no problem with Sun pointing out pitfalls and/or offering guidance based on their own experience." "
-
Sun is too full of itself
2004-02-02 07:08:11 pulse1014 [Reply | View]
Everyone knows the Eclipse consortium is much larger than the Netbean's JCP (whatever you call it). Everyone also knows that Eclipse will formally break away from IBM this week. Eclipse has a large momentum (just look at the consortium members http://www.eclipse.org/org/index.html) that is only going to get bigger. It only makes sense for an smaller organization to join a much larger and open one - not the other way around.
Besides in all this bickering we're ignoring the real enemy - .Net Visual Studio - which I hate to say this, from a usabilty and development perspective (disregarding stuff like vendor lockin) is better than Eclipse, which would win more developers... -
Sun is too full of itself
2004-05-21 09:36:46 cpk [Reply | View]
The main reason that Eclipse has a bigger following is because it has a wider scope. Eclipse is a universal IDE written in Java, while NetBeans is a Java IDE that Sun has chosen to extend in ways related to Java. If the letter indicates that the (admittedly core) Java plugins for Eclipse have given Sun a run for its money, then it only confirms that the universal IDE approach can produce a development tool for a specific language that is as good, if not better than the language-specific IDEs. There is no need of or merit in merging NetBeans with Eclipse. The competition of the language-specific NetBeans will only spur the Java plugin developers to improve their product. Similarly, competition from the Java plugin for Eclipse should encourage Sun to improve NetBeans, perhaps by scrapping Swing and going with SWT.
The same applies for Visual Studio.Net versus the C++ and C# plugins for Eclipse. I would question, though, whether Microsoft really has the upper hand "from a usability and development perspective". They only have an upper hand in their C# and J# areas but that comes at a substantial cost. Their MFC customers which they have marooned and have then half-heartedly tried to un-maroon really only have an interest in their reasonably priced "Standard" product. However said product does not have their source code control interface (SCCI) whereby developers could use CVS or even VSS. Long and short of it is: you can not have version control in VS.Net unless you pay big bucks.
Eclipse, on the other hand, comes standard with a CVS integration which is, in many ways, superior to SCCI in VS. This is one reason why we are taking our GUI out of VS and into Eclipse.
The other reasons have to do with our backend and my first point: PERL, UNIX C/C++ and Java.
Eclipse is not, in my opinion, about advancing Java, but in providing an IDE that allows developers to choose the most appropriate language for their application, be it C or Java or ML or Prolog. The latter two are only a plugin away.
-
Where Sun could help
2004-02-02 00:29:23 mayhem [Reply | View]
I think would be great if Sun could help out with the Eclipse project. I personally prefer Eclipse as an IDE over NetBeans, but NetBeans is definitely moving in the right direction and 4.0 looks promising.
One thing I (and Sun too I think) don't like is SWT. I think Eclipse would be a better product if it would use Swing instead. Maybe a good task for Sun developers would be to port the Eclipse UI to Swing. It would be a great example on how to create a good UI using Swing, and maybe Swing will gain more popularity after some unfair criticism (from some open source communities). -
Where Sun could help
2004-02-02 06:55:35 pulse1014 [Reply | View]
"I think Eclipse would be a better product if it would use Swing instead."
Why do you think Eclipse's UI is more responsive than Netbeans?? Yes, Swing is architecturally more sound than SWT - just like how Itantium is a true 64 bit proccessor (compared to Opteron)... unfortunately the real world, theory doesn't always equal reality, there are things like cost that exist. People do care about performance and Swing's current performance is unacceptable - Swing costs people time, just like Intel thinking everyone would port their code is very naive -Itantium costs are in software dev.
Maybe Swing will finally be a UI for the real world when 1.5 (Tiger) comes out. Until then, it's only good for small apps and the classroom. -
Where Sun could help
2004-02-03 01:28:22 mayhem [Reply | View]
On the machines I use, which are of average performance with lots of memory, Eclipse is not more responsive than a Swing application. I'm not saying Eclipse should abandon SWT at this point, but it would be nice to have a Swing version as an alternative. -
Where Sun could help
2004-02-03 00:30:19 aaime [Reply | View]
"Why do you think Eclipse's UI is more responsive than Netbeans?? "
More responsive on Windows, but on my Linux box
is just dog slow. I consider SWT a (good) Windows only toolkit, since using it on Linux is just a joke.
The only reason I use Eclipse is because it is
more feature-full, in particular because of its
very good editing and refactoring support, but on
my Linux box the Netbeans GUI is way more responsive. -
Where Sun could help
2004-02-05 06:25:17 flozano [Reply | View]
My experience on linux is far better performance from Eclipse than NetBeans. And if you use the GCJ-copiled version of Eclipse, the difference gets bigger.
But it's true SWT can impove very much on Linux. Talk to the java-gnome developers, they can explain many design flaws from SWT regarding it's use of GTK.
But see hot things change! A few years ago NetBeans would be "more featured" because of the visual editor (which was not availabe on Eclipse until recently). Today codding is more important than "visual" things.
That makes me wonder if we really should target "the myriad of VB developers ou there". :-) -
Where Sun could help
2004-02-02 00:50:38 jwenting [Reply | View]
Eclipse chose to create SWT to get around the inherent performance problems in Swing and succeeded quite well in that.
I'd rather see a working group of both powerhouses (and possibly others like Borland as well) creating a common plugin standard outside the JCP (and then maybe submitting it direct to the JCP as a fait accompli.
Working within the JCP is far too slow and would effectively kill the product (which might be the intention of Sun all along in this given their statement that having several tools platforms in competition is not a good thing...).
 java.net RSS Feeds
|
