Sun Opens JDesktop Integration Components 200
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."
Good step forward, but... (Score:4, Insightful)
Java footprint too large for ubiquitous usage (Score:4, Insightful)
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
Name mistake (Score:5, Insightful)
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?
Re:Still an abusive friend (Score:5, Insightful)
You realize that this is like saying "I has issues creating a
Haven't gotten around to running Eclipse and trying again
Last time I tried, it was really simple: Run the installer, double click on the
Another Desktop API? (Score:2, Insightful)
At first I was an oponnent of OSS Java, but now I'm not so sure. I am thinking anything is better than Java in the hands of Sun. Will someone please give Java to Apple.
Always The Outcast (Score:1, Insightful)
I took an interest in Java for desktop work a few years ago, but quickly realized that Java on the desktop is even worse than Java applets were. (And at the time they were both incredibly atrocious.)
Even with the increases in processor power, storage, and memory, Java is still atrocious, even compared to interpreted languages like Perl or Python. Even the simplest applications leave even powerful systems swapping like mad. Java consumes memory like the unholy offspring of Rush Limbaugh and Courtney Love would consume drugs at a pharmacy warehouse. Java brings in a large memory footprint that makes it completely unsuitable for many applications.
And don't get me started about Swing and the other Java UI classes. The last thing we need is another UI toolkit. Had Java used native widgets, it might fit in better. Had Java used widgets that didn't look like a throwback to Motif it might have been slightly better. Instead Java UIs tend to be a usability nightmare. 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.
The fact is that if Java is to succeed in the desktop it needs to be made much faster, memory footprint needs to be reduced, and it needs to get a consistant and usable set of Human Interface Guidelines. Unfortunately for Sun, I tend to think that the Java developers would be better suited to inventing a time machine and traveling back to 1996 when such improvements may have made a difference.
Java has a nice niche as an enterprise-level web applications language, but as a desktop programming language Java isn't neither well-regarded nor particularly useful. Now that you have other languages like Python (which beats Java for RAD tasks hands down) or .NET (which has the advantage of both Windows.Forms and Gtk# as well as an extensive class library), whatever Sun does to make Java a desktop programming language is probably too little, too late.
Startup time (Score:5, Insightful)
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.
What the hell can I even write in the subject line (Score:4, Insightful)
I'm also going to follow an age-old trend of mankind and blame the victim. Really, Sun; with all of the incomprehensible noise that's been coming out of official and semi-official channels, who can blame me? The Kremlin during Brezhnev's dotage was more on-message than you these days. Clearly you were asking for it.
But anyways, if this doesn't include a less-restrictive license on the JRE such that it could go into Fedora, Debian, free-as-in-beer SuSE and other non-commercial distros, who gives a fuck? I don't even mean GPL - even a patches-only Minix-style source license; hell, even just free binary redistribution without selling your firstborn to Scott McNealy would do it.
Yes, yes, I know; those aren't enterprise Linux. But they are what enterprise Linux guys run at home.
If Sun really wants Java to be the platform of the future, they've got to make it possible to install as part of a platform, rather than an afterthought added in after you've already got kernel, services, gui, and browser application running.
Re:Java footprint too large for ubiquitous usage (Score:5, Insightful)
By default the 1.4 JVM allows a default maximum (note 'maximum' of 64MB per application, but there is no reason why an app needs to use anything near that. The full Swing GUI demo (a pretty complex app with memory-hogging features) from Java 1.4 runs comfortably in 32MB.
New machines are purchased with around 512MB of memory. That is enough to run more than 10 copies of this app.
If you use something like SWT; a portable GUI library with native code bindings you can run Java apps GUI with memory requirements a lot smaller (Swing is a memory pig). You can run many more GUI apps. If you don't require a GUI, Java apps can require memory requirements of the order of single figures of megabytes, including the VM for each app.
How many Java apps do you want to run - 10, 20, 30, 40?
Microsoft will be cleaning Java's clock with
Why? For now
If Java starts to grow on the desktop as well,
Where is the security? (Score:1, Insightful)
What is to stop a malicious java applet from registering an action that is executed via
Is JDIC restricted to applets running on the local machine, or could any old web page host an applet that could launch documents for you?
Re:Always The Outcast (Score:3, Insightful)
I took an interest in Java for desktop work a few years ago, but quickly realized that Java on the desktop is even worse than Java applets were. (And at the time they were both incredibly atrocious.)
So we already know where this is coming from. Someone who saw how bad it was in the past and hasn't kept up with the improvements: "Perl was pretty crap in version 1.0, therefore Perl still sucks today."
Even with the increases in processor power, storage, and memory, Java is still atrocious, even compared to interpreted languages like Perl or Python.
We know this is a lie, because Java outbenched Python in benchmarks last year (it almost outbenched C, and would have if it weren't for the atrocious trigonometric performance.)
Even the simplest applications leave even powerful systems swapping like mad. Java consumes memory like the unholy offspring of Rush Limbaugh and Courtney Love would consume drugs at a pharmacy warehouse. Java brings in a large memory footprint that makes it completely unsuitable for many applications.
It brings about 8MB on top of the base application size. I don't know about you, but I have 512MB RAM in my system.
Of course by "it", I mean the Sun JVM. The Sun JVM is one of half a dozen that I know of, and some of those half a dozen are specifically written to conserve memory. Therefore bitching about Sun JVM's memory usage is akin to bitching about glibc's size wastage on a device where you should be using dietlibc.
And don't get me started about Swing and the other Java UI classes. The last thing we need is another UI toolkit. Had Java used native widgets, it might fit in better.
(... well it did in AWT, the problem was more that it didn't look modern enough...)
Had Java used widgets that didn't look like a throwback to Motif it might have been slightly better.
"The default GTK theme sucks, therefore GTK on the whole sucks."
Instead Java UIs tend to be a usability nightmare. 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.
... not that anyone has ever really seen an "equivalent" to Eclipse. I don't like Eclipse much myself (would use IDEA if I could afford it), but I've never seen any other application even competing in the same space. KDevelop looks like it might put up a fight, but it sure as hell doesn't at present, and is far from what I would call "polished."
In fact the main problem with Eclipse is that it's based on the shittiest GUI toolkit in existence: SWT. If it had been based on Swing like IDEA is, it would probably run smoother, look better, and generally be easier to use.
The fact is that if Java is to succeed in the desktop it needs to be made much faster,
... I'd love to see how it could get much faster, since it's already faster than C in many areas. Hey, perhaps C should get much faster too...
... again, property of the VM, not Java...
Yeah, because that really made GTK and Qt apps so consistent. The only desktop environment with a set of HIG that anyone gives a fuck about is OSX. Every other platform has them, and even Java has them, but the developers have to care! And of course, you can't force developers to care.
Unfortunately for Sun, I tend to think that the Java developers would be better suited to inventing a time machine and traveling back to 1996 when such improvements may have made a difference.
Well I would just go back with a copy of J2SE 1.5, to save all the waiting time for that. :-)
Java has a nice niche as an enterprise-level web applications language, but as a desktop programming language Java isn't neither well
Re:interesting (Score:2, Insightful)
Re:Java worms soon to come. (Score:4, Insightful)
Re:What the hell can I even write in the subject l (Score:3, Insightful)
Oh come on. This is just silly. If I download GCC, I get huge amounts of things I don't want, like cross-compiling for ARM processors. Where is the option to disable these?
Nothing else in my system works that way so I can't understand why Java does.
There is a very simple and easy to understand reason why Java does this. Java is a standard set of libraries and functions. Java includes things like Swing because that is part of what other developer's Java programs expect to be on your machine.
What is the point of installing a system called 'Java' if you can't download java programs and run them?
Re:Good step forward, but... (Score:1, Insightful)
There's where you're wrong!! Since it's your opinion, you really can't be wrong. It's an opinion!