Sun's JDIC And JDNC: A Cross-Platform ActiveX?
Espectr0 writes "eWeek is reporting that last week, Sun Microsystems Inc. licensed a pair of the underlying technologies of the Java Desktop System under the open-source LGPL (GNU Lesser General Public License). The two projects, JDNC (JDesktop Network Components) and JDIC (JDesktop Integration Components), are essentially to Java application developers what Microsoft's ActiveX and COM were to Windows developers--an architecture for creating easily configured application components and for integrating with the functionality of the local operating system and other applications."
java is still kickin: "Windows Loses Another Customer to Sun's JDS" http://www.eweek.com/article2/0,1759,1618125,00.as p
This quote is misleading:
The two projects, JDNC (JDesktop Network Components) and JDIC (JDesktop Integration Components), are essentially to Java application developers what Microsoft's ActiveX and COM were to Windows developers--an architecture for creating easily configured application components and for integrating with the functionality of the local operating system and other applications."
From the JDNC project page:
The goal of the JDesktop Network Components (JDNC) project is to significantly reduce the effort and expertise required to build rich, data-centric, Java desktop clients for J2EE-based network services. These clients are representative of what enterprise developers typically build, such as SQL database frontends, forms-based workflow, data visualization applications, and the like.
And then from the JDIC project page:
The JDesktop Integration Components (JDIC) project aims to make Java(TM) technology-based applications ("Java applications") first-class citizens of current desktop platforms without sacrificing platform independence.
The quote is misleading because it doesn't explain how ActiveX is similar to JDNC/JDIC. The similarity is platform lock-in: ActiveX and COM means you're stuck on Windows (albeit with a choice of programming languages). JDNC/JDIC means you're stuck on Java (but without real, viable choice on the language).
The fundamental problem (IMHO) is that desktop component integration is limited to a single desktop. Yes, I can have code reuse on Windows, and I can have code reuse on Gnome|KDE|Sun(tm)Java(r)Desktop(tm), but will I ever have (or need?) component integration across the three? It seems to me that developers have enough to handle getting the core functionality right.
This kind of thing seems like just so much... distraction.
Cross platform viruses, worms, spambots, and spyware? No thanks!
sulli
RTFJ.
Er no. This is Java. Unlike ActiveX, its designed not to do nasty things.
It may have a few platforms but ubiquitous it isn't.
It is like saying that Flash / Shockwave is cross platform just because there are a few players.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
>>Since windows is more widely used than Java, by your argument, it's even better to be stuck on Windows. Ugh.
No, Java devices (now verging on close to 14 Billion total) FAR outnumber Windows devices. Java is more than just computer desktops, as are these libs.
Remember guys, this is Amerika. Just because you have the most votes, doesn't mean you get to win.--Fox Mulder
Thing are getting interesting,
Sun is approaching java to desktop (hurray for them, it only took 5 years!).
Mac is publishing rendezvous for linux, win and others (after ten years of networking, will we finally get something like a 'zero' config system!?).
It seems that the non-windows side of the world is awakening!.
What's in a sig?
Which does not mean it's not possible to do nasty stuff anyway. Mobile phone worms anyone ? (yes, there are published and plausible proof-of-concepts and IIRC I read something recently that there are also a handful in the wild)
Which does not mean it's not possible to do nasty stuff anyway.
Nothing is ever impossible, but its very, very difficult, because of in-build security.
Mobile phone worms anyone?
The mobile phone worms are nothing to do with Java. The proof-of-concept was code that used the raw Symbian OS.
> JDIC also provides Java developers with a way to tap into the functionality of the client operating system they are run from. Sasaki said one of the first applications built with the JDIC project was a Java screen saver that runs on Windows, Linux and Mac OS X.
JDIC sounds like Sun has finally gave up "100% pure Java" principle and allows Java developers to access native functionality easily. For example, Swing has been burden because it has "Java only" implementation. It totally ignores all UI provided by client OS which means that text boxes and file dialogs never behave correctly in Swing. On the other hand this allows you to run "Windows themed Swing" under Gnome, but who wants that...
SWT and Eclipse league have wrapped native components and provided their own implementation only if native platform lacks the specific components. This is why SWT reacts 3x quicker than Swing, follows native GUI guidelines and is a pleasure to use compared to its Swing counterparts. Also, drilling through SWT to use native OS mechanisms like COM is easy. This is often required for compatibility reasons.
> For example, rather than using Java's own HTML-rendering capabilities, a developer could use a JDIC to integrate a Web browser running on the local operating system, such as Internet Explorer or Mozilla.
SWT had this from the beginning. For example, Eclipse on Windows use IE as help viewer by default.
JDIC sounds like Sun has finally gave up "100% pure Java" principle and allows Java developers to access native functionality easily.
You always have been able to do this. Its called JNI (Java Native Interface).
It totally ignores all UI provided by client OS
No it doesn't. You can cut and paste between Swing and the client OS. You can drag and drop between Swing and and client OS. You can access Client OS information, and Client OS Print Services. There are tools available that allow you to embed ActiveX components in Swing.
which means that text boxes and file dialogs never behave correctly in Swing.
Never behave correctly? I can enter text, cut, copy, paste, reformat, edit styled text and HTML.
The file dialogs allow me to search for files and directories, filter by file types, create new directories.
How is this not 'behaving correctly'?
This is why SWT reacts 3x quicker than Swing
Yes, SWT is a good product. However, the next release of Java (out September) allows Swing to be accelerated through the use of OpenGL. That should be fast.
Java becomes more like a usable programming language every day!
The functionality of mailcap, later cloned in win32, GNOME and KDE, is now available to Java as JDIC!
And JDNC provides powerful GUI functionality, including an XML format for describing GUIs, a la Glade, wxWidgets XML resource files, XUL , XAML. Of course, they are all completely incompatible. Also worth mentioning here is GNU Enterprise, which has seemingly similar aims to JDNC.
I don't know what all this has to do with ActiveX. For all I know, ActiveX was MicroSoft's intended replacement (or umrella) for Java and JavaScript. It has met with mixed success, having met with popelarity mostly as a malware target. JDIC and JDNC look like decent proposals to me. It's good to see Java maturing both in speed and functionality. The more choices, the merrier, after all.
Please correct me if I got my facts wrong.