JDesktop Network Components Project Debuts

Discussions

News: JDesktop Network Components Project Debuts

  1. JDesktop Network Components Project Debuts (18 messages)

    Sun has announced the debut of the JDesktop Network Components project. The project takes on the goal of simplifying development of data-centric Java desktop clients by providing shortcuts in the form of high level Swing components and an optional XML configuration language.

    The project has been launched on javadesktop.org.
    Over the years, we have consistently heard feedback about building desktop clients for the Java™ platform ("Java clients") that can be summed up in just one word: simplify. Skilled developers have been able to create all kinds of rich, responsive applications with the Java platform, however developers with less time to invest are often thwarted by the size and complexity of the interfaces they need to master. This situation is not peculiar to the Java platform; all of the platforms that provide comprehensive support for building desktop applications — such as GNOME, KDE, and Mac OS X — are necessarily complicated. However, what some of them have, and what the Java platform lacks, is a shortcut for developers who are building applications that match a small number of common archetypes. Database and web service front ends, forms-based workflow applications, and simple chart/graph information visualization clients are good examples of these common archetypes.

    Thus, we have initiated a new open source project on javadesktop.org, JDesktop Network Components (JDNC), which aims to provide the shortcuts required to construct these sorts of desktop applications in significantly less time by reducing the learning, design, and coding requirements. Additionally, JDNC has a specific goal to make these shortcuts accessible to a broader developer base. This ambition has led us to develop a high-level XML markup language for JDNC that makes the richness of the Java client platform, previously accessible primarily to developers comfortable with the Java language, amenable to markup developers as well! The goal to make Java desktop client development accessible to a wider audience is also driving our focus to make JDNC a natural companion for development tools, which is a critical requirement.
    Read the announcement entry: The JDNC project debuts

    Read the article that discusses JDesktop Network Components
  2. Sun Joins the XUL Bandwagon[ Go to top ]

    At last Sun tries to make Swing programming easier. If anyone is interested in alternative free open-source projects that use XML UI language formats to let you create rich clients using web-style techniques (that is, markup plus scripting) check out the XUL Alliance site online @ http://xul.sourceforge.net

    Let's hope Sun's JDNC initiative goes beyond Swing and will embrace scripting (e.g. Groovy, Beanshell, Javascript, etc.) and more popular XML formats for rich graphics or rich text instead of reinventing some Swing-only formats.

      - Gerald

    PS: I invite Sun to join the XUL Alliance or if they prefer the United XAML initiative. After all, open source is all about working together, isn't it?

    -------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  3. Just to let you now I've started a JDNC mailinglist over at Yahoo! Groups. If anyone is interested in JDNC I invite you to join the discussion and ask questions or share tips and tricks about Sun's new Java Desktop Network Components initiative.

    Find out more @ http://groups.yahoo.com/group/jdnc

     - Gerald

    -------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  4. Just to let you now I've started a JDNC mailinglist over at Yahoo! Groups.
    FYI, there's another JNDC mailing list @

    http://jdnc.dev.java.net/servlets/ProjectMailingListList
  5. Spring Rcp[ Go to top ]

    How this compares with Spring Rcp ?

    http://www.springframework.org/spring-rcp.html
  6. Spring Rcp[ Go to top ]

    How this compares with Spring Rcp ?http://www.springframework.org/spring-rcp.html
    Doing a quick read of the Spring RCP site, I think it could be used within the Framework at the JDNC Component or Swing Extension level. I don't readily see where Spring RCP provides "Data Aware" (hate to use that term) Network components.
  7. spring-rcp[ Go to top ]

    How this compares with Spring Rcp ?http://www.springframework.org/spring-rcp.html
    Doing a quick read of the Spring RCP site, I think it could be used within the Framework at the JDNC Component or Swing Extension level. I don't readily see where Spring RCP provides "Data Aware" (hate to use that term) Network components.
    The main focus and goal of Spring's rich client platform is similiar to that of JNDC; we want simplification, we want a framework with blue-prints for building standard, enteprise rich-client applications quickly.

    Stepping back a bit, Spring's focus in general is on providing an application framework for accelerating the development of real-world java/j2ee apps; we're taking that focus and the core services Spring already provides, leveraging it, and applying it to the rich client space.

    Today, the spring-rcp project has quite an sophisticated domain layer data-binding and validation framework which greatly simplifies taking form input entered by the user, converting it to the correct type, binding it to a backing model (be it a javabean, map, or form model buffer), reporting as-you-type validation results to the GUI using a declarative rules API, and committing validated updates to the middle-tier via a service interface (which may be backed by SOAP/Axis, EJB/RMI, direct JDBC, Hessian, Burlap; Spring has a nice remoting abstraction built on its AOP framework that integrates a number of lightweight web-services-style protocols, as well as EJB.)

    As this is a JNDC thread, I just want to say I am excited to see this! "Swing simplification" has been needed for such a long, long time; in fact, the whole reason I started Spring's rich client work was to address this need--Swing is a great widget toolkit, but way too low-level for building moderately involved rich client apps quickly. We need more options in the rich client framework space, and I am very much looking forward to reviewing the work of the JNDC group, and seeing how we can integrate the project with what we're doing with Spring's platform. I think we certainly can make java on the desktop a reality people embrace rather than run from!

    Very best regards,
    Keith

    Keith Donald
    http://www.jroller.com/page/kdonald
  8. spring-rcp[ Go to top ]

    Thanks for the clarification. I was only reporting on what I didn't see.

    I agree this needed too. And we need choices. I've been doing Java Rich Client for a while and my best choice has been my own "Framework" with serialized Java objects over HTTP. Ok, it was more a pattern and less a framework.

    Where can I find more info on Spring RCP? The main page doesn't say anything of "data binding" and I can find no other links to documentation.
  9. I've got a plan - we will make life easier for developers by modelling a gui using a STUPID ASCII DATA MODELLING format.

    The good techies don't need it. The bad/time challenged techies want to drag and drop and not wade through rubbish ascii formats.

    XML is NOT fit for every purpose. It is good for data, aimed at both machines and people. It crosses over and has become the defacto x-platform solution. But don't ever pretend it is a great way to represent a sharpe and simple gui.

    A bit disgruntled at another java arrow that's fired and misses.

    Jonathan
  10. I don't agree, I'm a "techie" and I would love an official XML format to describe Java GUIs. We've been using XML-based form and GUI definitions for years already within our company and there are so many examples where this way of building a GUI just fits perfectly.

    The most obvious disadvantage of the 2 systems you describe: a) GUI code written by a programmer b) GUI designed with some kind of design tool is the fact that both are static, once made you can't easily change them in a dynamic way. The code has to be written with the dynamics already in place and most GUI design tools don't allow any kind dynamic control to the GUIs they make.

    With an XML format (assuming it is well-designed of course) is becomes easy to store GUI definitions and read them, use them and re-use them when necessary. You can put parts together to make something new. You could generate a GUI on-the-fly and communicate the definition over the wire. The possibilities are endless (and most of them we probably haven't even begun to think about).
  11. JDNC ML is not for defining Java GUIs.

    But, not being fully persuaded, I think it would be good for those who want or need it for their to be some sort of standard. Shouldn't be tough. There are a couple of good OSS java ui MLs out there.
  12. I'm not sure if you are responding to the main post or are a little jaded do to Gerald's post.

    The main purpose of JDNC is NOT a new XML markup. Read their site and what they say it is for and how it is to be used. Yes, you as a senior Java developer might not. Then again you might. Even in what they posted here - " Additionally, JDNC has a specific goal to make these shortcuts accessible to a broader developer base. This ambition has led us to develop a high-level XML markup language for JDNC." See? Not the main purpose. They even say you can mix and match. You choose.

    They can't please everyone. But saying that, I think they have done a good job. Something for everyone. Except those who only want one thing. If it all works as well as they say it will, I think it is a bullseye.

    Want to use JDNC without coding java? Use the ML.
    Want to use JDNC without coding alot of Swing? Use the JDNC Components.
    Want to use JDNC just like you hand code Swing? Use the Swing Extensions.
    Want to use JDNC with a GUI builder? Use the JDNC Components or Swing Extensions.

    BTW, they are not trying to reinvent the wheel with JDNC ML. But they looked at what was available and figured it was faster to come out with their own ML. At least for the time being. They also say it is not for building generic Swing apps.

    I think - no cross that out, - I know Rich Client APIs like these are important to the survival of Java. Microsoft is pushing back to the desktop (See MSDN for info on SmartClient, Longhorn, ...) because they have to have people tied to Windows(and thus all their other stuff). Web apps give too much freedom of choice, at least on the serverside. And it isn't that tough to make most things cross browser so it goes for the desktop too. While some web techologies do a good job of emulating desktop apps, they just aren't the same. Having done both rich clients and Web apps (and mainframe apps :) ) there are other issues too.
  13. But, your pick list is typical of java land.

    What do you want to do? Hey, there is a solution, just spend a week or two reading up on them all, tracking the next major release of each, working out the version dependancies with 3rd party projects...etc.

    The aim of quick, powerful data access and maintenance apps is:
    Display a list (read only data list - table joins)
    Drill into the list (load the enties, for edit this time)
    Edit them, revert them, refresh them, store them.
      - deal with optimistic locking issues as appropriate.

    And do this to support single entity and groups of entity updates.

    This is what I want to achieve, and your first comment is learn a ML, or maybe xml or maybe swing, or maybe swing extensions.

    It's fine to create an xml widget set if thats what you think is sexy, it's fine to use such a widget set. But to make out that it will embrace my requirements above where TIME is my main challange is wrong minded.

    Jonathan
  14. I would say the picklist (with in JDNC) is NOT typical. That is what the "we want to use GUI/IDE to do everthing" people keep saying about Java. They say you can only do it one way. The hard way (I don't agree that that is true, but ...).
     
    Stop focusing on the XML part. You've said you don't like it. Then, with JDNC, you don't have to know or think about it or use it. There are those who need it/want it. Since everyone is so wowed by VS.Net and .Net (From experience - I don't know why) Java has no choice but to compete for the mind share of those who think quick is better.
    It's fine to create an xml widget set if thats what you think is sexy, it's fine to use such a widget set. But to make out that it will embrace my requirements above where TIME is my main challange is wrong minded.
    JDNC is NOT an xml widget set, if that is what you have been lead to believe. Is it? I know Gerald's comments have been focused on that.

    Unfortunately, there is never one right way. There is always something that makes another choice better. If you want single choice, then you know what you can use and do it how they want you to. Don't forget not to innovate, cause they will steal your market. I guess you could also choose a single Java vendor and use whatever they provide.
  15. I'm not sure if you are responding to the main post or are a little jaded do to Gerald's post. The main purpose of JDNC is NOT a new XML markup.
    Sure, Gerald is not entirely accurate to consider JDNC as a XUL. But Gerald's sentiment is correct in that JDNC is meant as a web challenge to HTML applications. JDNC isn't thin client. JDNC is yet another enhancement by Sun that hopes to make fat client attractive.
  16. I'm not sure if you are responding to the main post or are a little jaded do to Gerald's post. The main purpose of JDNC is NOT a new XML markup.
    Sure, Gerald is not entirely accurate to consider JDNC as a XUL. But Gerald's sentiment is correct in that JDNC is meant as a web challenge to HTML applications. JDNC isn't thin client. JDNC is yet another enhancement by Sun that hopes to make fat client attractive.
    I understand Gerald's sentiment in that regard. And in the regard of creating a new ML when a few exist. But I also understand why the JDNC group did what they did. They are saying that they could use or be used by an existing api. It is opensource. Any takers?

    Also, I would say it is rich client vs fat client. At least traditional fat client where all db drivers were installed on the client, etc. This is a necessary move by the Sun and thus the Java community because, at the very least, Micrsoft is doing the same (Making the "fat" client attractive).
  17. But I also understand why the JDNC group did what they did. They are saying that they could use or be used by an existing api.
    JDNC could be skinned and scripted with a XUL. They're complementary.
    This is a necessary move by the Sun and thus the Java community because, at the very least, Micrsoft is doing the same (Making the "fat" client attractive).
    As far as I can tell, Sun's Java is the quality leader of fat client platform. I don't see XAML, Avalon, and Longhorn changing that.
  18. As far as I can tell, Sun's Java is the quality leader of fat client platform. I don't see XAML, Avalon, and Longhorn changing that.
    Check out Microsofts push in the area of SmartClient. I wouldn't say MS is the quality leader - but they are pushing in to the rich client arena - they have to. (I do MS stuff too, so I have been reading about it)
  19. Hello,

      for some insight into the "why use XUL" debate allow me to quote Stephen D. Williams:

      XML-based UI interpreters are the way to go for the long term, although it will take a while to standardize. All native UI toolkits will likely be left in the dust, including my favorite: QT and/or KDE. Derived, IMHO, from TCL/TK, XUL and XAML along with a couple cool Java applets are showing how powerful this can be.

      This is essentially taking the idea of a web browser and semantically pivoting it to supporting XML+XSL+custom objects/methods/event handlers rather than, or possibly in addition to HTML. Very clever, clean, concise, user-modifiable/skinnable, and a big win overall for GUI programming. I haven't yet found a truly complete system however that supports arbitrary 2D or 3D graphics, which is something I need.

      Is Stephen D. Williams out of his mind? What's your take on it?

       - Gerald

    -------------
    Gerald Bauer
    United XAML | http://xaml.sourceforge.net