Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Java Trends - Exclusive Interview with Amy Fowler
Java Trends - Exclusive Interview with Amy Fowler

Joe Ottinger had the opportunity to talk with Amy Fowler, a senior staff engineer at Sun Microsystems and one of the founding members of the Java Swing GUI Toolkit, and discuss Swing, JSF, the JDNC, and some general trends in Java.

JDJ: Can you tell us what your role is at Sun now?
Amy Fowler: Officially, I'm the technical lead of the Java Desktop Network Component (JDNC) project, which aims to simplify Java desktop client development for Web-enabled applications. Unofficially, I'm a rich-client agitator. I've been at Sun forever and have been an engineer on the J2SE client team since the days we called it the "JDK" and there were a total of eight packages. Most of that time I've spent on the Swing team, with a year-long tour of duty in J2EE as the JSF spec lead, trying to define a component model in the otherwise amorphous Web tier. So I have history, perspective, and a genuine passion for Java and user-interface software.

JDJ: What do you see Java being like in the future?
AF: Almost nine years ago Java hit a developer productivity sweet spot by providing a language that made just the right set of trade-offs between power and complexity. As the demands on software grow (more, better, faster, prettier), Java must target that sweet spot on a grander scale by making a more-capable platform easier to use. Tools are in there somewhere. If I may dream a bit, I hope Java will take advantage of the increasingly mind-blowing GPUs to deliver us from '80s-style user interfaces.

JDJ: As a JCP member (and former spec lead), how well do you think the JCP works? Are there any improvements that could be made.
AF: From my vantage point as a Sun engineer leading a JSR, it seems the JCP is a reasonable framework for involving the Java community in the evolution of Java standards. I think the process works best when a JSR is kicked off with a concrete proposal and working implementation as a starting point. Doing design by committee is like trying to run in the shallow end of a swimming pool.

One change we might need is an expiration on stale JSRs - the ones that get filed but never kicked off. If the leading company fails to take action, it shouldn't lock out other interested potential leaders/participants.

JDJ: Where do you see JDNC falling in the implementation hierarchy? Who are the primary users and developers, and when can we expect to see it in the marketplace?
AF: JDNC fits quite nicely on top of Swing and Java 2D. We've meticulously layered the implementation of JDNC so that developers can take advantage of it at many levels. If you're a Swing developer, you can use our Swing extensions package to get features like integrated table sorting/filtering/highlighting, data streaming, data binding, etc. The higher-level JDNC components wrap Swing and our extensions to provide a simpler API for common use scenarios. This API is targeted at Java developers who aren't necessarily Swing literate. Finally, the XML Schema layers on top to provide a declarative alternative to constructing the GUI, and this can be used by markup developers who may or may not know Java.

My June '03 white paper (www.javadesktop.org/articles/JDNC) focused mostly on the XML layer, but we've spent most of this last year developing the underlying Java APIs, whose simplicity should be reflected in the XML. We don't view Java coding and markup as mutually exclusive; in fact, we expect a majority of applications will do both; JDNC will encourage a sensible division of labor between the two. We hope to get the bits on javadesktop.org before JavaOne to encourage you all to come talk to us.

JDJ: How does JDNC compare with JSF? JDNC's stated goals include less round-trip data, while JSF is likely to mandate more round-trip data - is there a middle ground from Sun somewhere?
AF: Okay, I won't hide my bias. Excessive round-trips and associated page refreshes are an inherent limitation of HTML applications that resulted from jamming a square peg in a round hole - building GUI clients out of a document-viewing substrate. Nonetheless, HTML applications have become a major force in our daily lives and many have gotten quite good (Amazon paved the way). JSF is all about making those Web apps easier to build, which is a very good thing once you understand that doing it well is tricky indeed.

To borrow a term from Dr. Jakob Nielsen (www.useit.com), I think browser clients are well suited for the "ephemeral" use case where users perform limited tasks of a sequential nature. Rich, interactive clients deliver the tempo required by applications that are used intensively. Unfortunately, the user experience is usually not the driving factor in making the decision between the two.

But your question of a "middle ground" comes up a lot and I've been squinting to find it for some time. One potential integration idea is to build some JSF renderers that emit JDNC components as applets in key areas of the page to dial up the view interactivity, like providing a tabular data view that can be scrolled, sorted, filtered, and rearranged without page refreshes. Where this breaks down is when the user triggers an event that is routed back to the server and causes JSF to rerender the page. The applet (and data) must then be reloaded. Bummer. But software has amazing pliability, so I suspect we can solve these problems if we decide they need to be solved.

JDJ: Why has JSF focused solely on Web content? To me, being able to describe a working interface for all client models would be a huge benefit, as I typically develop Web applications but can see a valid use for some Web apps being desktop apps. So far, SwingML, XUL, thinlets, JSF...all are trying to do the same thing in different domains, which seems to beg for optimization.
AF: This is the holy grail of GUI development - the ability to define the UI once and have it magically map to the broad range of scenarios that face users today from small devices to browsers, to desktop apps, etc. The following is my personal assessment of why this won't work.

First, each scenario has distinctly different operational characteristics, such as screen-size, input device, memory capacity, network latency break points, etc., that require thoughtful reconfiguration of the user experience. For example, there's nothing more annoying than an HTML application that tries to act like a rich client - having the page refresh when the user makes a selection from a dropdown choice is an abomination of modern software. A decent client should leverage the network without obfuscating it.

Second, we are by nature visual creatures and are ultimately obsessed with having precise control over the bits on the screen. This almost always requires tinkering, which is tailored for the specific client technology. We'd never be satisfied with visuals that are generated or limited by the least common denominator.

Ranting aside, there is definitely room for significant sharing of some of the nonvisual bits, such as data models, validation, business logic, and application behavior. JSR 227 (data binding) promises the requisite data-binding scheme to support this and we're counting on Oracle to see this through [in the meantime, data binding will be a major feature of JDNC].

JDJ: Since I've brought up Swing...in the JDNC document, you mention some things in Swing as being nontrivial. Given that most Swing interfaces certainly don't seem to leverage what Swing can do (or don't leverage it well), do you see Swing improving in ways that would change that? Do you think Sun will ever revamp Swing's documentation to the point where the average Swing programmer no longer shrugs at "Swing's" poor performance? (I quote "Swing" there because it's my opinion that programmer education is the problem, not Swing.)
AF: Let's nail this right here. Due to tremendous efforts by the Java 2D, AWT, and Swing teams, and the kindness of Moore's Law, Swing performance is no longer a valid excuse for not using Java on the client. Thanks to Chet Haase and the Java 2D team, 2D will continue its trend to rely more on the graphics hardware acceleration. Swing's lead, Scott Violet, did work in 1.5 to reduce Swing's memory footprint somewhat. There are a bunch of creative discussions going on with members of the VM team on improving startup. I use a number of Swing applications daily on a three year old laptop and performance is just not a problem.

Now, one consistent and fair criticism is that it's harder than it should be to write a performant Swing app, which leads right to the issue currently burning holes in my laptop. How do we make Swing more tenable to a broader range of developers? We have to make it easier to approach and ensure developers can achieve better results with less effort. Swing is indeed broad and fine grained. This was intentional. We didn't want to limit the kinds of GUIs that could be developed in Java.

It took us awhile to realize that while we get twisted pleasure out of writing the threading code to load data into models asynchronously, 99% of the world does not. It's quite reasonable to simplify these common or difficult tasks by layering APIs (like JDNC), but we also need better tools and documentation.

One theory I'm still trying to prove is that our monstrous Javadoc is an issue. There are indeed more methods on JButton than there ought to be, yet we should be able to emphasize more clearly in tools and documentation the two or three that developers really need. Javadoc is the reference manual, yet I suspect it's also relied upon as a programmer's guide. I definitely use it that way - it annoys me when I also have to download a pdf spec to figure out how to use an API.

JDJ: As a corollary to the previous question, are the new technologies coming out of Sun prioritizing documentation and education? How much are they doing so, or are they focusing on the technology alone?
AF: Our priorities are clear: simplification and ease of development. Documentation and education are obviously large components of that, but it feels like we could do more of the latter. Our competition is very good at that.

JDJ: Will JDNC follow the JavaBeans component model?
AF: Yes. As much as possible, we're trying to make Swing functionality accessible through the beans patterns. For example, in our high-level table component, you'll be able to configure column rendering (colors, alignment, etc.) as bean properties without having to understand Swing's underlying CellRenderer mechanism.

JDJ: JavaBeans are used as a server-side component model, whereas they began life as a client-side tools API (with things like property editors and customizers). Are there any moves to embrace more server-side declaratives, or move toward the metadata model coming in 1.5?
AF: I believe that JSF has some facilities for managing beans in the Web tier. I recommend checking out the specification for details.

JDJ: As a corollary, how do the changes coming in 1.5 affect current designs?
AF: Version 1.5 is the most exciting Java release in some time. It's my personal misfortune that the current version of JDNC must run on 1.4.2, leaving me little time to play with 1.5 features directly. You all probably have more experience than I do in using 1.5's generics and autoboxing at this point! Unfair, but true.

In Swing, the new "Synth" look-and-feel will enable a whole new way to customize the look of an application without touching a line of code. This was part of the original vision of Swing - it just took us seven years to get to it. With 1.5, developers can skin applications without knowing anything about the pluggable look-and-feel (plaf) packages because the visual elements of the GUI can be configured in XML. Now we just need the tool that lets graphics designers, rather than engineers, create the skins.

For JDNC ,we're looking forward to leveraging Swing's new table printing, Java WebStart enhancements, the Xerces parser, and WebRowSet.

JDJ: How do you see Swing and SWT interoperating in the future?
AF: The AWT team made some changes in 1.5 to better support the hosting of Swing components within SWT (and Eclipse). It would be nice if they could be mixed and matched more freely; however, my understanding of the respective architectures is that this would be horrendously difficult without incompatible changes on one or both sides.

In light of Java's real and very mean competition (.NET and what's coming behind it), the last thing Java needs is a toolkit war. I've been there before - it's a complete waste of time. Our competitor gets great joy out of watching the infighting within the Unix community. Let's not go there with Java.

JDJ: With the LayoutManager2 interface the constraint object is passed as an argument to the container's add method. Why is the constraint not a property of java.awt.Component? Right now the only way to change a constraint is to add and remove the component.
AF: This does seem like an oversight that needs to be fixed. I'll plead the case with the AWT team.

JDJ: Are there any plans to make AWT and Swing interoperate better? If not, are there any plans to add Tree, Table, and TabFolder to AWT because this would go a long way toward satisfying the needs of people who want Swing's power coupled with native components?
AF: AWT and Swing interoperate fairly well as they share the same component model. We do have plans to make the heavyweight/lightweight clipping issue go away, hopefully, in the release subsequent to 1.5. We don't, however, currently have plans to build peer'd components for Tree, Table, etc. Look-and-feel fidelity is a big priority for us and we'll always be investigating ways to improve it, but likely in the context of the Swing components. However, the underlying platforms do evolve and we'll periodically reevaluate the best way to achieve fidelity.

JDJ: Do you find people at Sun have given up on Java on the client? You moved to JSF; is this because the focus went onto the server? Is the client coming back just hype or a reality?
AF: As with anything it's all a matter of perspective. You'll find a few people at Sun whose view is that Web clients are all that matter and Swing clients don't exist. Our team, on the other hand, gets daily requests to showcase Swing applications on Swing sightings and are noticing a boost in Swing development, which is backed up by a number of independent developer surveys. I moved to JSF primarily because I wanted to learn something new and I wanted to understand the EE world. I gained a fresh perspective from that experience, and it has helped drive my current fever to make rich Java clients easier to build. And I can spell X M L now too.

Who cares what I think, or what random Joe from org XYZ thinks. What matters is what the person in charge thinks. I can tell you that Jonathan Schwartz (Software EVP) "gets" that rich clients on the desktop are critical to Java's and Sun's long-term health. The client is definitely back and though Windows will likely remain the dominant desktop, we believe an increase of Linux and OSX desktops will make Java's cross-platform benefit even more relevant now than it was eight years ago.

We are looking out to where Java clients should be 3-4 years from now and plotting a steady course. There are big challenges and tremendous possibilities, given where graphics hardware is going. Resolution independence and better GUI/graphics integration are just a couple examples of crucial themes.

JDJ: There does not seem to be a "global API architect" over the entire Java API. Will Java APIs ever get a thorough review by such a person/committee? If so, when? If not, why not?
AF:There are definitely some very distinguished engineers in high places who are in charge of tracking, reviewing, and guiding our progress. You might see these guys giving the technical keynote at JavaOne. :-) The JCP plays a role here too - it's not just Sun, despite what the buzz on Javalobby says.

JDJ: You talked about the JCP and some of its good points and bad points - how are they addressed by the 2.6 release? And is JDNC going to be part of the JCP? (If it is already, what's the JSR number? If it isn't, why not?)
AF: JCP 2.6 introduces a number of changes that are a huge benefit to the public Java community, as well as the spec lead. First, the change that makes the first spec draft available to the public, rather than restricting it to the "JCP Community," will go a long way toward ensuring JSRs stay on track to meet the needs of the developers. Often expert groups are weighted on the geeky side, which doesn't always align with the practical priorities of the public. In addition, the change to encourage the first draft to go out with more "tbd" sections will enable expert groups to get to a first draft (and hence public feedback) much more quickly. Really really good from the perspective of an x-spec-lead - shrouding the JSR in secrecy felt like a burden to me.

JDNC is not currently being developed under the JCP. Once we get it out and in the hands of the development community and you tell us it's solving an important problem and should be standardized, then we'll definitely go there. But as I stated previously, I don't think the JCP is the place to do design from scratch. JSRs should be about taking something that exists in some form (however rough) and refining it for standardization. Rest assured, JSR or not, you all will have the opportunity to help shape JDNC because it won't succeed until it makes your development lives easier.

About Joseph Ottinger
I am a software evangelist for GigaSpaces technologies, as well as a writer and musician. I've been the editor-in-chief of Java Developer's Journal and TheServerSide.

GigaSpaces Technologies is a leading provider of a new generation of application platforms for Java and .Net environments that offer an alternative to traditional application-servers. The company's eXtreme Application Platform (XAP) is a high-end application server, designed to meet the most demanding business requirements in a cost-effective manner. It is the only product that provides a complete middleware solution on a single, scalable platform. XAP is trusted by Fortune 100 companies, which leverage it as a strategic solution that enhances efficiency and agility across the IT organization.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

http://www.sandrasf.com/sites

JDNC rocks and SwingX Rocks, and you can see samples above.
.V

There''s a new mailinglist over at Yahoo! Groups for Java Desktop Network Components (JDNC).

The charter reads as follows:

The Java Desktop Network Components (JDNC) Developers Group is a forum to ask questions or share tips and tricks about Sun''s Java Desktop Network Components project. You''re also more than welcome to announce your JDNC addon or JDNC powered application to the list.

If you''re interested in JDNC, you may wonna sign up and help the discussion get going.

More @ http://groups.yahoo.com/group/jdnc

I was glad to see an article that talked about using Java as more than a server-side technology. Ultimately the Java community will need a response to the work that Microsoft is doing on Longhorn to deploy Rich Internet Applications. Smart client-side components that can handle their own input-validation, data-fetching and the like are an obvious and necessary part of that. JNDC delivered as applets would appear to fulfill that role. The fact that the same components can also be used in standalone applications deployed using WebStart validates the approach further.

However IMHO neither of these really fulfill the requirements of a RIA. WebStart applications live very clearly outside the browser, and JNDC applets are really just very useful building blocks that can be assembled into an application. I would like to see a role for Java as a language for developing the applications themselves, applications that can be easily deployed over the web, applications that interface to the user through the browser.

The fact that this approach does not recieve much attention is probably because it is unlikely to work with all the major browsers. However this is not sufficient reason to discount it; Microsoft have a strategy that will initially deliver an enhanced experience only to those prepared to upgrade to XAML-capable browsers. If Sun is serious about JDS, or just Linux-based desktops in general, then surely there is a significant enough community for whom having Java work closely with the browser is a viable approach to RIA.

Considering the specific case of Mozilla, I think it sad that I have seen virtually nothing from Sun about making Java a viable language for developing Mozilla applications (although maybe Sun contributes to the Blackwood and JREX projects behind the scenes?). RIA would appear to be one place where the Java and open-source communities could really come together and make a big difference.

Please don''t feed the troll (Gerald Bauer) who is a well known NUT with OCD and hates everything and anything Sun. Just let him vent and move on.

There's no need to wait until Sun and Amy Fowler unveils Java Desktop Network Components (JDNC). You can use free, open source alternatives today such as Vexi, Luxor, SwiXml and so on. See the Open XUL Alliance online @ http://xul.sourceforge.net for more.

I think the JDNC is a great idea and I look forward to testing it out and providing feedback.

I have a request that has been echoed by others in the Java.NET forums: please make the _feel_ of these components more Windows-like or at least ensure it is easy to override the Java _feel_. Here''s an example of why this is important to me: I''m using Scott Violet''s (?) treetable3 in production in a limited MS Project-like timesheets application. When the CTO was testing my nice Java/JTreeTable and it didn''t select/edit like Excel would I received one of those condescending looks that says, "your software is crap". That hurts.
Maybe the Sun Swing _feel_ is smarter, better, more efficient, etc... but please consider mimicking the more familiar click/select/edit/drag&drop feel of Windows.
Thank you.

Amy makes an important point that for large APIs, javadocs are not easy to reference, and not easy to use as a learning reference. Something breaks down. There''s nothing wrong with a large API and I don''t think the solution is scaling down the API. The solution is a better reference. That was my goal when I built ashkelon.sourceforge.net. It is javadocs implemented as a web app on top of a relational database, which allows me to search javadocs, cross-reference javadocs. Furthermore, the color-coded, styled dhtml user interface makes for a clearer user interface that actually works for me.

when jndc will be out ?


Your Feedback
Vic wrote: http://www.sandrasf.com/sites JDNC rocks and SwingX Rocks, and you can see samples above. .V
John Leckey wrote: There''s a new mailinglist over at Yahoo! Groups for Java Desktop Network Components (JDNC). The charter reads as follows: The Java Desktop Network Components (JDNC) Developers Group is a forum to ask questions or share tips and tricks about Sun''s Java Desktop Network Components project. You''re also more than welcome to announce your JDNC addon or JDNC powered application to the list. If you''re interested in JDNC, you may wonna sign up and help the discussion get going. More @ http://groups.yahoo.com/group/jdnc
adrian cuthbert wrote: I was glad to see an article that talked about using Java as more than a server-side technology. Ultimately the Java community will need a response to the work that Microsoft is doing on Longhorn to deploy Rich Internet Applications. Smart client-side components that can handle their own input-validation, data-fetching and the like are an obvious and necessary part of that. JNDC delivered as applets would appear to fulfill that role. The fact that the same components can also be used in standalone applications deployed using WebStart validates the approach further. However IMHO neither of these really fulfill the requirements of a RIA. WebStart applications live very clearly outside the browser, and JNDC applets are really just very useful building blocks that can be assembled into an application. I would like to see a role for Java as a language for developing the applications the...
No Trolling wrote: Please don''t feed the troll (Gerald Bauer) who is a well known NUT with OCD and hates everything and anything Sun. Just let him vent and move on.
Gerald Bauer wrote: There's no need to wait until Sun and Amy Fowler unveils Java Desktop Network Components (JDNC). You can use free, open source alternatives today such as Vexi, Luxor, SwiXml and so on. See the Open XUL Alliance online @ http://xul.sourceforge.net for more.
Mark Swanson wrote: I think the JDNC is a great idea and I look forward to testing it out and providing feedback. I have a request that has been echoed by others in the Java.NET forums: please make the _feel_ of these components more Windows-like or at least ensure it is easy to override the Java _feel_. Here''s an example of why this is important to me: I''m using Scott Violet''s (?) treetable3 in production in a limited MS Project-like timesheets application. When the CTO was testing my nice Java/JTreeTable and it didn''t select/edit like Excel would I received one of those condescending looks that says, "your software is crap". That hurts. Maybe the Sun Swing _feel_ is smarter, better, more efficient, etc... but please consider mimicking the more familiar click/select/edit/drag&drop feel of Windows. Thank you.
Eitan Suez wrote: Amy makes an important point that for large APIs, javadocs are not easy to reference, and not easy to use as a learning reference. Something breaks down. There''s nothing wrong with a large API and I don''t think the solution is scaling down the API. The solution is a better reference. That was my goal when I built ashkelon.sourceforge.net. It is javadocs implemented as a web app on top of a relational database, which allows me to search javadocs, cross-reference javadocs. Furthermore, the color-coded, styled dhtml user interface makes for a clearer user interface that actually works for me.
vincent bellet wrote: when jndc will be out ?
SOA World Latest Stories
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will d...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus ...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one l...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastruct...
Adding public cloud resources to an existing application can be a daunting process. The tools that you currently use to manage the software and hardware outside the cloud aren’t always the best tools to efficiently grow into the cloud. All of the major configuration management tools ha...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, dep...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
ADS BY GOOGLE