An article about the origins of the Mac OS X Cocoa framework and the history of the architecture of the modern attempts of Apple to design a modern and high quality operating system, and the dismissal of the Java-like technology that Apple acquired from NeXT when it bought back Jobs to the heart of Apple.
I found a great article on the JSF 2 Spec (the View technology of choice for the Java EE 6 stack) and what's new/updated from JSF 1.2.
It serves as an overview to the new features in the JSF 2 and not as a comprehensive review of a single feature, it covers:
The article is available here What’s New in JSF 2 by andyschwartz
For some time now, I've been learning parts of the Java Enterprise Edition platform, and what I've seen is a great platform that can be the best-in-class if used properly and if it was easier to learn.
But what I find so much interesting is the multitude of frameworks in the market, two different presentation layer standards (JSP and its successor JSF), many different JSF extension frameworks (Apache MyFaces Tomahawk, Sun Woodstock, ICEfaces, JBoss RichFaces, Apache MyFaces Trinidad, Oracle ADF Faces), other not-in-the-specification frameworks (Tapestry, Struts, Apache Wicket, GWT, Spring MVC and others), many implementations of the JPA standard (the de-facto standard Hibernate, the JPA2 reference implementation EclipseLink, the Oracle TopLink, OpenJPA, and others), many Servlets containers (Tomcat, Jetty and commercial offerings) and various EJB containers, the complete enterprise applications building frameworks as Spring, Seam, and many others.
And that's just for the parts I explored so far.
Also the desktop front suffers from less overlap/duplication with 2 GUI widgets framework (the Java standard Swing, and the IBM/Eclipse influenced SWT framework) and their respective applications framework (the Swing Application Framework and the Eclipse Rich Client Platform).
The same is true in the IDEs front, we just don't have 2 major IDEs (Eclipse and NetBeans), but we have many commercial IDEs built over the Eclipse foundation (many of the IBM Rational offerings, RedHat/JBoss Developer Studio, Embarcadero/Borland JBuilder), some commercial offerings (most notably the IDEA IntelliJ) and the Oracle free (but less fair to play with the market standards) JDeveloper.
At first I just thought that is a waste of brain cycles and time of a talented and very smart community, and not just how many things has been done and redone and then-again redone, it is just plain confusing to try to learn or even design an application while taking in consideration the pros and cons of each framework/standard/application/library and presents a real challenge for a topic that could be easier to penetrate and learn, also such duplication creates many different-and-separated camps of experienced developers in the market.
But then I found that the real reason all these people are still in the Java camp is because of the ability to do things just as you want it (just think of any barely-reasonable way to do enterprise applications and chances are that a framework is out there waiting for you to be used) and the many different ideologies behind each framework (ranging from heavily-closed source and commercial frameworks to BSD-style open source frameworks) and that the ability of the Java community to re-invent the wheel when desired easily a key feature for the backing of virtually all the big software companies in the world (except Microsoft of course, not because it was uninterested, but because it wanted to play it too-hard with the market).
How such community will be affected by the Oracle acquisition is yet to be seen, but I'm not so optimistic as before, the Java EE may grow better under the Oracle umbrella, but it may be less free and less open to the community, which is exactly what the Java EE community doesn't need, the backing of the various software companies and open source communities what makes Java a market leader and the biggest player in the enterprise applications market.
I hope that Oracle understands the chemistry between Java and freedom (or it keeps enough Sun executives to keep such freedom possible) and that only a multiplayer game is a game worth playing.
I've started to use JDeveloper the last few days, and as a Java novice that is drowning in the sea of acronyms and the multitude of implementations in the market of Java Enterprise Edition, I find the JDeveloper as the solution to any Java Developer looking for an Oracle-centric IDE (that is half open and half tightly-coupled with various Oracle flagship applications).
As Oracle will now have the upperhand in the Java world, I assume that going the Oracle way would not bring the best value to the Java EE applications, but would bring the best integration of the various Java technologies.
Oracle Buys Sun (from Oracle.com) | Sun and Oracle (from Sun.com)
Earlier yesterday, Oracle has announced that it has reached an agreement to purchase Sun Microsystems for $9.50 per share, making it a $7.4 billion deal, by this acquisition, Oracle will have a complete end-to-end product line that focuses on data and business requirements in the largest enterprises.Oracle has been trying to enter the hardware business lately by its HP Oracle Database Machine, which is essentially a complete rack of HP hardware and Oracle Software, but this last acquisition will bring Oracle completely into the major hardware business, this will give it a complete line of products, from the largest UltraSPARC supercomputers Sun creates and maintains, to its mid-range SPARC servers, , to its Blade servers and high-density computing, to its carrier-grade Netra servers, to storage-oriented servers, to the entry-level x86/x64 servers, down to workstations and thin-clients; not to mention a complete processor architecture and alliances with both the major x64 market players, Intel and AMD.
Oracle will also get a complete software stack to build complete systems using its Oracle software, this includes the Solaris/OpenSolaris operating system, which is (quoted from the Oracle press release) the largest platform Oracle is deployed on, the bleeding-edge ZFS storage engine, the Lustre filesystem which is geared toward clustered supercomputers, and engineering expertise Sun have for building such large-scale installations.
But the crown jewel in this purchase is definitively the Java platfrom, Oracle has been the third-largest contributor to the Java environment (after Java's Own creator Sun, and IBM with its Eclipse/Rational product-line and its WebSphere middleware), Oracle has its Oracle Fusion Middleware product-line which it enhanced by its acquisition to the BEA WebLogic product line, its JDeveloper IDE product, it contribution to the Eclipse Foundation, and its native support for Java inside its core Database product-line.
Oracle will also benefit from Sun earlier acquisition to MySQL, which fosters its position as the major (and mostly the only) player in Linux database business (keeping only the relatively smaller player PostgreSQL) and IBM current offerings, DB2/Informix which focuses more on IBM integrated services/platform than being an active player in the Linux market.
Oracle does have overlapping products with the Sun portfolio, like its GlassFish Application Server (which overlaps with Oracle Application Server and BEA WebLogic), its NetBeans IDE (which doesn't completely overlap, but somehow, with the JDeveloper and the contributions to the Eclipse foundation), its MySQL database product (which is not positioned as a direct competitor to the Oracle database, but none the less it has managed to grab a good market share in the Internet-centric database field), and its open source VirtualBox virtualization software (which overlaps with the Oracle VM product, which is based on Xen).
This is no where the overlap that was to be there if the deal with IBM has managed to succeed, it would give the new IBM overlaps in its complete hardware business (which Sun competes across the complete line), its processor business (the POWER vs. SPARC), its Operating Systems business (Solaris vs. AIX & z/OS), its development tools business (NetBeans vs. Rational/Eclipse), its application server business (GlassFish vs. WebSphere), and its database business (MySQL vs. IBM DB2/Informix); this would leave IBM with just one piece of software it really wants from Sun (beside its server market-share), which is of course the Java platform, and quite frankly, it is not worth the $7.4 billion Sun was asking for (which is the same price Oracle agreed on to complete its acquistion).
I was worried that such a merger/acquisition would make too much mess in the Sun portfolio, but now as Oracle is the new Sun, I'm not so worried; Oracle will benefit directly from the hardware business, the processors business, the Operating Systems business, the Java platform, the office productivity products; and will have minimal impact on the development tools and the virtualization products; the remaining parts where Oracle will probably have a major impact is the database business and the application servers business (which are minor parts in the Sun products line).
We will see how such acquisition will result in the near future, and how the open sourcing of many products of Sun will shape the future of such products.
Setting the layout of the Workbench in any Eclipse RCP application can be a daunting task if your application needs any control over the placement of views and editor area that is not directly exposed through the RCP interface.
But some techniques can be used to provide (relatively) more control over the layout by managing the perspective settings and hinting the view size.
In the class implementing IPerspectiveFactory (the class that implements the Perspective to the org.eclipse.ui.perspective extension point), you can:
Enable or disable the Editor area, if you are to design an Editor, this setting should be kept to true
layout.setEditorAreaVisible(true);
You can also use the Fixed Layout option, this removes he ability o maximize and minimize views and the editor area (through the min/max buttons and through the double clicking on the view title.
This keeps the ability to resize single views (as if they are included in Resize composites, but without the ability to reorder the views, or stack them or minimize them as fast views)
layout.setFixed(true);
The order of the views to be added decides who gets the full layout to take part of it and what views get the remaining of the layout to take further parts of it
Views
Views can be standard views, stand-alone views or fast views:
layout.addStandaloneView(MyOwnView.ID, true, IPageLayout.TOP, 1f, editorArea);
Standard view is a simple view in the Workbench that can be docked, stacked, minimized, maximized or detached inside the Workbench window
layout.addView(SampleView.ID, IPageLayout.LEFT, 0.5f, editorArea);
Fast views are shortcuts to the actual views put in the toolbar at the bottom of the Workbench window and shares the status bar if visible
layout.addFastView(SampleView.ID, IPageLayout.DEFAULT_VIEW_RATIO);
Views and hinting its size (in Eclipse 3.4 and upwards)
By implementing the ISizeProvider Interface in the ViewPart class that is creating the view, you can get the view to set its minimum and maximum size, given that the view doesn't get docked into other views (which can be easily made by using stand-alone views), the simplest implementation would be:
@Override public int computePreferredSize(boolean width,
int availableParallel, int availablePerpendicular, int preferredResult) {
return width ? 100 : 110;
}
@Override public int getSizeFlags(boolean width) {
return (SWT.MIN | SWT.MAX);
}
I've started in my quest to learn the Eclipse RCP Platform, the Java Rich Client Platform built on the Eclipse foundation softwareand using the Standard Widget Toolkit (SWT).
While I think that Swing and the Swing Application Framework (JSR 296) would be a more pure Java approach, I personally prefer the Eclipse RCP approach for large scaled projects, where it can provide high degree of modularity to the system (this can be also achieved in the NetBeans Platform, but I prefer the look and feel of the Eclipse-based applications).
Also I think that the NetBeans IDE is better in the more broad Java picture, where I assume it is better in handling the Java EE and Java ME applications and provide a higher of community participation in its code base (this may not be correct, but I got this impression, maybe because I was a close watcher for the NetBeans news earlier than Eclipse).
But the Eclipse RCP won because of its large base of implemented applications, one for example was the main reason that I tried the Eclipse RCP in the first place, uDig, the internet-friendly desktop GIS application, and i don't know until now if I'm gonna to run inside it with my plug-ins, or that I will embed its plugins inside my application(s).
Also the Eclipse SWT library is more responsive and native-looking than Swing (personally I love the Java Metal look and feel, but thats just me, everybody else hates it).
So, in the next few days, I will start posting about my findings in the Eclipse RCP world and the Java world in general.
