当前页面: 开发资料首页 → Eclipse 专题 → 深入观察Rich Clients, Java与Eclipse

深入观察Rich Clients, Java与Eclipse

摘要: 深入观察Rich Clients, Java与Eclipse

最近以来，关于Rich Client的讨论越来越多。在FTPOnline上看到了这篇在2004/8/31发布的一则关于Rich Clients，Java和Eclipse访谈。受访者Mike Milinkovich是Eclipse组织的执行主席。

Insights on Rich Clients, Java, and Eclipse
Posted 12:32 PM

Mike Milinkovich was the newly minted executive director of the Eclipse organization when he participated in our Java Technology Roundtable during the JavaOne conference. But some of his comments stirred our interest, so we followed up to get you more detail. Here's Mike's original comment and our subsequent dialog:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Milinkovich: With rich-client platforms you can build user interfaces in Swing, with roots. So, rich-client platform is not about SWT. I mean it does support SWT out of the box, obviously, and the Swing support is only currently working on Windows and Linux, so we still have some work to do. That's why I said in terms of being able to provide a plug-in application, plug-in architecture for developers who are building rich-client applications, being able to have an update manager so you can find other plug-ins and new functionality, to have a generic workbench so you have an abstraction you can plug your other applications into and you can brand for your corporation. Those, to my mind, are all interesting features.

Q: Can you expand on your comments and update us on what Eclipse is doing in the rich client area?

Milinkovich: The main benefits of RCP [Rich Client Platform] include:

• RCP provides a pre-built, extensible, well-designed architecture that allows developers to immediately begin working on adding application functionality rather than on building infrastructure. When building desktop applications on the Eclipse RCP, a development team can quickly begin designing end-user functionality, and delivering it. Without the RCP, they need to talk about window management, toolbar management, menu management, and get solutions for these and other basic infrastructure issues in place before they can really build an application.
• The ability to create rich user interfaces for client-side applications using SWT and JFace. Developers can deliver rich client applications written in Java, which are essentially indistinguishable from native applications written in languages such as C/C++/C#. But at the same time, these applications are portable across all supported platforms.
• The ability to provide a managed code environment that is not browser-based. With RCP, developers can provide a desktop environment that is packaged to link to a server-based update manager. This provides the ability for end users to discover new and updated functionality and apply it to their desktop environments. At the same time, system administrators can be confident that they can control what is deployed on the managed desktops.
• The ability to create, manage, and brand desktop applications using the GenericWorkbench allows enterprise developers to create a well-defined end-user environment to which they can deploy new applications.

There is a wealth of information available on our Web site that discusses what the RCP is and how it can be used. Pointers include:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/rcp/index.html

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/rcp/faq.html

http://help.eclipse.org/help30/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/rcp.htm

http://www.eclipsecon.org/EclipseCon_2004_TechnicalTrackPresentations/11_Edgar.pdf

http://www.eclipsecon.org/EclipseCon_2004_TechnicalTrackPresentations/14_McAffer.pdf

Q: How can smaller, potential GUI component suppliers participate?

Milinkovich: Eclipse has a well-known and vibrant commercial ecosystem. For people who are interested in creating components and making them available—either in open source or commercially—they can work with the Web sites listed at http://www.eclipse.org/community/index.html (then click on "Sources of Information about Eclipse"). There is a wealth of technical information as well. For those interested in getting started, I would suggest the three-part technical tutorial at http://eclipse.org/articles/Article-RCP-1/tutorial1.html.

Q. Re: JSR 198. You commented that it was technical feasible, then the discussion went off in another direction.

Milinkovich: The key point I was making is that we can adopt plug-in models that technically address the issue. For example, Eclipse has a very mature plug-in model. In particular, it was designed with scalability on the order of a thousand plug-ins in mind. The details of the JSR 198 plug-in model are not available to the development community. However, given the diverse interests of the players in the JCP, it might be difficult to obtain a consensus. 198 has been in existence for almost two years now. I am sure the development community will be interested in seeing tangible progress from the JSR.

As Eclipse is a strong supporter of open standards, we needed to look elsewhere for a plug-in standard to base our component runtime on. More details on that are below.

Q: What is Eclipse doing about IDE component plug-ins, and how does this relate to JSR 198?

Milinkovich: Eclipse has a plug-in model based upon the Open Services Gateway Initiative (OSGi) standard. The entire Eclipse platform is built on top of this open plug-in model. This approach has proven to be very successful. The open, pluggable nature of Eclipse has spawned a large ecosystem of third-party providers that are shipping commercial and open source plug-ins for Eclipse today.

Q: Do you expect a standard to be adopted?

Milinkovich: I believe that there already is a standard—the OSGi-based plug-in model that is used in Eclipse. Eclipse provides a real implementation that exists, is open source, and is well-documented. At the current time, the JSR 198 team has not yet issued a public draft specification, so it is difficult for the open development community to evaluate the proposed technology because of the closed nature of their proceedings.

The idea of "write a plug-in once, run it in every IDE" sounds appealing. However, one has to understand that this is a comprehensive problem. Interesting IDE plug-ins are deep. That is, they seamlessly integrate into the IDE and add interesting new functionality.

Consider a UML modeling tool that can update the diagram when the source in the code editor changes. To do so requires more than an API to add an action to a menu. What is needed is an API to the abstract syntax tree of the edited source. This requires us to standardize many non-trivial APIs.

Any spec that emerges from JSR 198 will clearly introduce a lot of new APIs. These APIs will need to be validated, and industry adoption will depend heavily on the success of the validation process. The Eclipse approach is different. APIs are specified, validated, and kept stable as part of an open development process.

Q: Do you expect a market to emerge for UI and other IDE plug-ins as has happened with Visual Basic? If yes, when and how?

Milinkovich: It already has. The Eclipse Foundation currently has more than 50 add-in provider members—companies that are developing pluggable technologies that interoperate with Eclipse. In addition, there is a vibrant open source community that has built up around Eclipse technology. The Eclipse market is robust and rapidly growing.