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."
That's a much better license than I was expecting. Of course, I don't know just what is being covered. It's important to know that before giving Sun too much credit. (Still, they haven't been slow about being viscious in public, so no reason for them to be subtle now.)
I think we've pushed this "anyone can grow up to be president" thing too far.
a Sun spokesperson says, "The future of JDesktop Integration Components is uncertain. We have no plans to make JDesktop Integration Components open source in the near future."
This can help the GCJ project to build their free CLASSPATH faster.
Soon [I hope] this free Java compiler/interpreter will be ready to replace the "closed" Sun's Java.
... shouldn't they have done this 4 or 5 years ago? Why now? We could all run Java based browsers and applications if those guys would have put their thinking caps on half a decade ago. Just my personal opinion - as usual, I could be wrong ;-)
Java -- liked it, thought it was the future, then it ran slow on the desktop so I stopped looking at it. I heard it's great on the server side, though. Then processors got faster and memory got cheaper so I thought hey, let's do Java on the desktop again!
Enter the debate of AWT, Swing, JFC, and all these other widget libraries. I tried the free Forte for Java and JBuilder to make me cutesy GUIs. I compiled and ran it on a Win98 box, transferred it over to a Linux box, and it worked spiffy except for a few font complaints. I had issues creating a jar file, though, and eventually got sidetracked away from the language altogether.
In the end, Java seems like an abusive friend -- I keep going back, and it keeps giving me pain. Haven't gotten around to running Eclipse and trying again. Not sure if it's safe to give this 'relationship' another shot.
Java's memory footprint is currently too large to allow numerous java programs of a moderate complexity (and size) to be running simultaneously on the desktop. Until Sun gets VM sharing going, we will not see Java attain a strong desktop presence. And, in the meantime, Microsoft will be cleaning Java's clock with .NET.
.NET/C# rule the desktop. Hope Sun proves me wrong.
I work in Java and would love to see Sun devote the effort required to make Java *truly* desktop ready. However, I fear that that is not a priority for Sun, and instead we'll see
The biggest problem in naming it the Java Desktop System is that you are making your product lines vague and ambiguous. Didn't you learn anything from watching the whole Microsoft .NET hilarity as that ensued.
Why not name it the Linux Desktop System, thereby keeping naming distinct between OS and development technologies? Sure, it's good to tie them together, but you need some focus and clarity among the things you are trying to push.
Now, somewhat more contraverial, is you also need to recognize the contributions of the many people who's code you are selling. It would seem a responsible thing for a member of the community to acknowledge their participation by helping promote the name (Linux, GNOME, whatever). I'm not trying to flame Sun, because they've done some nice things with ATK and OO.o, etc. However, as a Linux supporter, why should I go with Sun over IBM or Red Hat when both of those put forth more effort to evangalize open source?
-- Fighting mediocrity one bad post at a time.
Now if they could make it so you don't have to start up a separate VM for every application...because it takes too much memory AND too much time.
They've needed a process model for a long time. That's still the critical piece needed to make a "Java OS" a reality. (AFAIK it still is missing...)
Of course there is the copout that the interpreter ends up in shared memory anyway. But what about loaded classes? Are they shared between apps? I think not.
Of course, applications can be written to become threads in an existing VM rather than intended to start up on their own, but that generally isn't done. This way Sun can ignore security issues between apps within the sandbox by saying well, just start up a new sandbox for every application, and there is no way they can step on each other. Moore's law has had many cycles now since Java came out, and the cost of even one VM is still not negligible, let alone one per application.
Then there is the fact that Swing applications always look so unique, so volatile and unreliable, due to the fact that they paint slower, and you can sometimes see unpainted gray areas, at least temporarily. They make a bad impression, like old cars going down the road perpetually in primer, the "restoration" incomplete for years on end, making you want to ask "when are you ever going to use real paint!" They should instead work on fleshing out AWT to include the missing widgets, like trees (just implement their own native versions on the few OS's whose GUI toolkits don't have them), and screw pluggable look-n-feel. That should be a toolkit feature for the whole OS, not just for Swing applications. This approach is largely responsible for Swing apps looking and feeling so crappy.
In our projects we have found that the .NET winforms foot print is minium 11mb, but often is at least 20-30mb. So please stop spreading FUD
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
I've been developing in Java for close to 7-8 years now, and am a great advocate of Java - for those tasks that fit it. I think Java on the server-side is a very powerful thing, but that it just wasn't ready for the desktop up to and including v1.4. Try running 10 copies of Notepad - and then try running 10 Notepad-equivalents in Java, and see the difference. Having said that, v1.5 bringing virtual machine sharing should have a big impact on this, but I have not yet had the opportunity to evaluate how much of a difference this makes on the footprint. I recently had to demo an old application that we developed back in '98 for Java 1.1/1.2, on both Windows and Linux using Sun's 1.4 virtual machine. I was appalled to see that the application, which had very good performance on Windows, was unfortunately having quite dramatic performance issues when run on Linux (Tests were done on a dual-boot machine). Java on the desktop - yes, great. But up until 1.5, it wasn't the time. Maybe things will change now.
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.