Slashdot Mirror
Sun Opens JDesktop Integration Components
Jahf writes "Sun has released the JDIC / JDesktop Integration Components API via the LGPL. The idea is to create a Java API that allows Java applications to better integrate with a modern desktop. It allows apps to embed a web browser component, access/launch desktop applications and associate filetypes. Documentation and demos are available and there is an incubator project (SaverBeans Screensaver) under way. Sun has been a proponent of developing desktop apps in Java, including a number of open source Java apps in the Java Desktop System and developing new ones for it as well (Java System Updater), and this appears to be a step towards making that goal a bit easier. I'm sure that every release of Java Desktop System (disclaimer: yes, I work on it) will continue to get the 'it has nothing to do with Java!' trolling since Sun is using GNOME as a desktop foundation (imagine what people would say if Sun created a 3rd environment in Java!) But those willing to step back and look at all facets (JDIC, Java Desktop System, Looking Glass previews, etc), hopefully others will see that Sun is getting more serious about making Java a platform for desktop developers."
OpenOffice.org
deep down, Sun loves us
OTOH GCJ is far from replacing Sun's java (at least in terms of speed). To compile java properly you have to do some funky runtime optimizations (which sometimes even require un-optimizations!), something that the gcc infrastructure doesn't really allow. That's why you get considerably better running speeds with Sun's or IBM's JITs (although you do get better startup speeds with gcj)
The Raven
Because it will not always be Linux underneath. Running the JDS just means you have a common set of apps, ui, libraries and java. It could soon be Solaris x86 underneath or a sparc version running on Sunrays (which I still think are cool).
_damnit_
It's my job to freeze you. -- Logan's Run
Take a few min and read
man java
and
man jar
if you have the main-class set correctly in the manifest you can do:
java -jar yourjar.jar
if not then just do
java -cp yourjar.jar org.my.Main
where org.my.Main is the main class of your app.
I'll go out on a limb here and suggest that any non-trivial platform you want to use is going to take some time to learn. The JSDK has a TON of docs that come with it. Put some effort into it and read them. Esply the part on the jar tool.
Had Java used native widgets, it might fit in better.
Java can use native widgets easily: IBM's SWT toolkit does just that.
Had Java used widgets that didn't look like a throwback to Motif it might have been slightly better.
Then don't use these widgets. Use any of hundreds of Swing look and feels, or use versions of SWT that use GTK, or Windows, or Aqua.
Instead Java UIs tend to be a usability nightmare.
There is nothing intrinsic about a Java UI that is a usability problem. With any Java GUI you can design your own buttons, add your own accelerators, menus, colours, tooltips. I think you are confusing the bad design of some particular applications with what is potentially possible using a GUI toolkit. Its like saying that GTK is bad in general because you have seen some badly designed GTK apps.
Even Eclipse, which is far and away the best app I've seen in Java has nowhere near the visual polish as its GNOME, KDE, Aqua, or Win32 equivalents.
This does not make sense: Eclipse uses GTK, aqua and Win32. It uses those native widgets! Eclipse is a native GUI program.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class -data-sharing.html
Java is not necessarily slow. Badly coded Java can be, but Java itself tends to be quite fast. I know companies that are writing essential services with 5 9s reliability in Java because it's fast enough and a lot easier to maintain.
b enchmar k.html
Benchmarks here:
http://www.idiom.com/~zilla/Computer/javaC