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."
LGPL! (Score:5, Interesting)
LGPL for pieces doesn't matter (Score:4, Interesting)
And Sun does: not only is there no complete open source implementation of crucial components like Swing (although the SWT-Swing effort may be changing that), even if people should manage to make a credible and complete open source Java 2 implementation, Sun's licensing restrictions on the Java specifications and their Java-related patents would probably let them shut down or control any such implementation should it become a threat to their dominance.
In other news... (Score:5, Funny)
That's good news (Score:4, Interesting)
Soon [I hope] this free Java compiler/interpreter will be ready to replace the "closed" Sun's Java.
Misinformed (Score:4, Informative)
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)
Re:Misinformed (Score:2)
This is on an Athlon XP2400+ machine running Fedora Core 2 (kernel 2.6.5).
This is obviously a lot slower than a C program (no surprise there) but it's still fast enough to give you an "instantaneous feeling" when running an application.
Re:Misinformed (Score:2)
Are you running 2.4?
Good step forward, but... (Score:4, Insightful)
Re:Good step forward, but... (Score:5, Interesting)
Re:Good step forward, but... (Score:2)
I'll have some of what you're smoking!
Re:Good step forward, but... (Score:2)
That's why. I'm not smoking anything. Maybe I should.
Re:Good step forward, but... (Score:4, Interesting)
Re:Good step forward, but... (Score:2, Informative)
I could see (and agree with) the point about noticeablely slow app response times in 1998.
But now Joe Schmoe can get a 2.0+ GHz CPU with 256-512 MB of RAM with nearly 3 GB/s of usable memory bandwidth. Unless there are some really serious performance problems with a particular runtime environment, there is no reason for a Java app to run noticeably slower than an precompiled machine binary app in the language of your choice (barring serious number crunchers, of course...
Re:Good step forward, but... (Score:2)
http://www.espial.com/
Re:Good step forward, but... (Score:3, Informative)
Benchmarks here:
http://www.idiom.com/~zilla/Computer/javaC
Re:Good step forward, but... (Score:2)
Trolling? JDS = GNOME = Mono = .NET on Linux (Score:2, Interesting)
neverind the trolling you'll get because GNOME is being implented in .Net/Mono instead of Java.... :)
.NET on Linux
That's right I say:
JDS = GNOME = Mono =
Re:Trolling? JDS = GNOME = Mono = .NET on Linux (Score:3, Informative)
That's right I say: .NET on Linux
JDS = GNOME = Mono =
Almost: .net on multiple platforms)
(JDS = GNOME) != (Mono =
GNOME is written in C (C++?), Mono is an open implementation of .net that runs on multiple platforms (including GNOME, KDE, Solaris, Windows, etc, etc) One's a language, the other's a technology (virtual machine, languageS, etc)
...and, to be honest, JDS is like most distros: it's not just the Window Manager. But hey! Why let "facts" get in the way of a good troll!
I think (Score:2)
Re:Trolling? JDS = GNOME = Mono = .NET on Linux (Score:3, Interesting)
Key fact:
Mono is an open implementation of a subset of
Arghhh... brain overload! (Score:2, Interesting)
Man, that was uncalled for. My head is spinning with comments. Must not read Slashdot thread for other's jokes.
Seriously folks, lets keep this on topic and confine these things to a single thread that is easily ignorable. Replying to this would be a good start.
Still an abusive friend (Score:4, Interesting)
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.
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
Re:Still an abusive friend (Score:2)
Re:Still an abusive friend (Score:2)
Hmm, interesting. I don't actually think the effort to learn Java is that big. But of coure I already know it, so I am biaised...
As for the jar file, I ended up creating one but wasn't able to launch it from the command line. Something about explicitly pointing to the main class or whatnot.
So a jar file is nothing else but a zip of a bunch of
Re:Still an abusive friend (Score:3, Informative)
Java is about as intuitive to learn as MSVC... while the core language is simple, making a nifty little GUI work is not. It's easy to make a "hello world" jar that runs from the command line, but making an actual graphical applet that runs that way is quite a bit different.
-WS
Re:Still an abusive friend (Score:2)
I totally agree with that point of view. It's actually not the fault of the language/libraries at all (IMO) but for the lack of a decent GUI builder. I haven't tried JBuilder & others in a while, but the last time I tried, it was really ugly (As compared to other nice GUI builders for other languages).
Of course, it is a weaknes of Java to lack such a nice builder.
Re:Still an abusive friend (Score:3, Informative)
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.
Re:Still an abusive friend (Score:2)
Comment removed (Score:4, Interesting)
Re:My impressions (Score:4, Funny)
yes it does.
-Instead of a nice pretty background, you get a pinkish, zit-covered background.
-Way more bulk than any prgram needs... quickly turns to bloat if you stop running it.
-Violent mood swings lead to the termination of all the puny shell scripts.
-To pass a performace test it will try to load foreign components, specifically, C code.
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
Your wish shall be granted. :-) (Score:5, Informative)
Re:Your wish shall be granted. :-) (Score:2, Interesting)
Re:Your wish shall be granted. :-) (Score:2)
I doubt that's the real problem. I think the bigger problem is just the super-object nature of it causes things to be large, especially since "everything is an object".
Re:Your wish shall be granted. :-) (Score:2)
They are primitives just like they are in Java. If they weren't, you'd be able to have two variables ponting to the name number, and then change it using (setf). You can't do this.
Re:Your wish shall be granted. :-) (Score:2)
There could be a lot of shared memory there, you really can't tell wether that happens using only the tools you mentioned.
IIRC Solaris has a command called pmap which can be used to see this. My Linux box seems to have that command too but it doesn't seem to do anything.
Re:Your wish shall be granted. :-) (Score:3, Interesting)
Sun or anyone for that matter has to be very very careful on how they do this. IYour example "Eclipes", isn't a good true world test. How much memory does visual studio take up? IDE's have always been hogs. On some systems Outlook takes over 300MB to load. Getting the initial VM lo
Re:Your wish shall be granted. :-) (Score:2)
The basic usage of the Java 1.4 VM isn't huge - its around 8 MB.
Re:Your wish shall be granted. :-) (Score:2)
I presume you mean something like this?
No, I think he meant something more in the lines of Dynamically Loaded Classes as Shared Libraries: An approach to Virtual Engine Scalability [sun.com]. Open called "JVM Sharing", try searching javalobby.com [javalobby.com].
This is first o
Re:Your wish shall be granted. :-) (Score:3, Interesting)
Actually I thought he was talking about something like this. [mac.com]
The thing which was added in 1.5 improves startup time, but each JVM you run still takes the same amount of space, unless they say otherwise on a different web page. JShell, on the other hand, solves the memory issue. (I wonder why this couldn't be worked into a core feature.)
Re:Your wish shall be granted. :-) (Score:2)
Actually, the J2SE 1.5 New Features [sun.com] clearly state that footprint is in fact reduced.
,NET footprint same OR LARGER than java (Score:5, Interesting)
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,
Re:Java footprint too large for ubiquitous usage (Score:2)
Re:Java footprint too large for ubiquitous usage (Score:2)
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.
True. Version 1.6 of java is suppose to finally solve this issue. There are serious concerns that have to be addressed: namely security and stability. If I have two apps running on the same VM it is possible that they could one could crash both or look into the other ones memory space. Kinda icky.
Fully supported by RIAA (Score:3, Funny)
try {
toDownloadMusic();
}
catch (GrandmaAnd12YrdOldViolators you) {
fineAndMakeYouAppearInCommerical();
}
finally {
try {
payMusicians();
}
catch(MoneyNotFoundException haha) {
}
}
private void payMusicians() throws MoneyNotFoundException
{
if(true) {
throw new MoneyNotFoundException("Sorry, get all of it because we like it that way");
}
}
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?
Not just Linux (Score:5, Informative)
Re:Not just Linux (Score:2)
For all of the above, in a pretty short timescale, I've heard.
Re: (Score:2)
Not much worse, really. (Score:2)
Re:Not much worse, really. (Score:2)
Snicker. (Score:2)
Another Desktop API? (Score:2, Insightful)
A
Re:Another Desktop API? (Score:2)
I agree somewhat with the last part: what Sun should d
Re:Another Desktop API? (Score:2)
Firstly, its 3. JDesktop/Sun is not a separate GUI toolkit - it uses Swing. You are confusing 'Desktop' with 'GUI'.
Its not fragmented, because (1) noone uses J++ anymore, (2) Swing and SWT can now be used together - you don't have to make a choice.
Re:Another Desktop API? (Score:2)
Why? Sun have kept the core of Java and the bytecode stable while opening up parts of the spec so that other companies have been able to offer a variety of APIs. What is your problem? You don't have to use any of these APIs if you don't want to. You can write as many Swing or SWT apps as you like. You can even combine them into one program. If you have an issue with what Sun has done, you can write your own alternative.
Re:Another Desktop API? (Score:2)
The only half-decent SWT implementation is in GTK (I say half decent because it is slow as fuck, and isn't Qt).
The JDS, which is built on GNOME, which is also built on GTK.
So SWT apps would not only work, they would style just like any other GTK apps running on that GNOME desktop.
Re:Another Desktop API? (Score:2)
This is all wrong. Its an API to integrate with system services. Its completely compatible with SWT and Swing: you can use the desktop components under Swing or SWT. So what if it uses GNOME? Do you need Sun to provide everything for you?
It makes Java a more unified platform by providing a new API that gives portable access to some useful syste
Oh the irony... (Score:2)
Re:Oh the irony... (Score:2)
Well this is probably just a thought, but if the integration API is open, then we can surely implement the API to work on vanilla GNOME and KDE. We would just use the KdeJava and JavaGnome projects to provide whatever tinkering we need to do, right?
I guess it could be something to play with. I've been missing an officially-supported way to interact with the desktop for a while now... starting from the basics of the system tray icon and working on up.
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.
Re:Startup time (Score:3, Informative)
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class -data-sharing.html [sun.com]
Re:Startup time (Score:2)
If you look at WebSphere, you'll notice there's support for "shared libraries", which allow "applications" to use certain sets of classes isolated from other applications.
The "Java OS", at least from a server perspective, is really an application server.
I'd agree that this functionality is missing on the desktop, however.
>They should instead work on f
Re:Startup time (Score:2, Interesting)
They have. You can.
and you can sometimes see unpainted gray areas, at least temporarily. They make a bad impression.
That has not been the case for years. If you see it, its bad coding by the developer.
They should instead work on fleshing out AWT to include the missing widgets,
IBM have done exactly that. Its called SWT.
Re:process model (Score:2, Informative)
It's called isolates, and it's supposed to be in Java 1.6: http://www.bitser.net/isolate-interest/
There's a proof of concept in KaffeOS.
Re:Startup time (Score:2, Informative)
I'm using Java 1.5 for several months now, and besides the new language feature goodies it also has shared [sun.com] memory between applications.
Now I can't say how much better swing has gotten since 1.4 because a dont' remember how good it used to be
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:What the hell can I even write in the subject l (Score:3, Interesting)
When some Linux developers are so keen and eager to download all kinds of software, do they complain so much about downloading a free Java development environment from Sun? Its free to download, free to use, and you can freely distribute the run-time with your apps.
I remember when, years ago, Linux people did not like to have pre-installed systems, and preferred to have the freedom to set things up for themselves. Have things really
Re:What the hell can I even write in the subject l (Score:2)
Then, as you mentioned, there's the whole freedom to set things up idea. I have to download and install things like Swing even if I don't want them. Nothing else in my system works that way so I can't understand why Java does.
It just seems the
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
Re:What the hell can I even write in the subject l (Score:3, Interesting)
It is not currently an ideal platform for desktop-side solutions. There are a number of reasons for this. One of them, and the most easily remedied of them, is that the current licensing scheme places restrictions on the distribution of binary JRE's.
It may be that Sun is content with the status quo; after all, there's more and safer money on the server. In which case greater ubiquity for the JRE would be of no concern to them.
But: releas
All for Java, but it still needs time... (Score:5, Interesting)
No JVM sharing in 1.5 (Score:2)
I posted this earlier, but I don't believe 1.5 has JVM Sharing, someone correct me if I'm wrong.
1.5 has a Class Data Sharing [sun.com] startup optimization. That's not quite JVM Sharing, which is described in Dynamically Loaded Classes as Shared Libraries: An approach to Virtual Engine Scalability [sun.com]
Sun is feeling the heat........ (Score:2, Interesting)
Anyway I am not particularly worry about splitting the community - the best will wins in the long run - look at GNOME and KDE - there has be
Re:Sun is feeling the heat........ (Score:2)
What kind of innovations are you referring to? Cloning Appl/M$ already existing UI?
proponents of proprietary platforms (Score:2)
Yes, and Microsoft has been a proponent of developing desktop apps in Windows. That's because it is valuable for a company to popularize a platform that they control. Since Sun can't get a lot of commercial developers of desktop software for Java, they do the next best thing--they try to sweet-talk open source deve
Re:Sun actually GPL'ing something?!!? (Score:3, Informative)
deep down, Sun loves us
Re:Sun actually GPL'ing something?!!? (Score:3, Interesting)
...and netbeans [netbeans.org], though the license was the Sun Public License (like the Mozilla license), rather than the GPL.
...though I'm more an eclipse [eclipse.org] kinda guy, myself.
Re:Sun's Take (Score:2)
Re:Sun's Take (Score:2)
You're absolutely right, there. The problem is that there are good Swing developers and there are shit Swing developers. It's just that unfortunately, the shit developers, who seem to be unaware of Swing's single-threaded application model, seem to be the majority at the moment, so you get all kinds of applications which pause during rendering because they're performing some other work from the wrong thread.
But certainly comparing the two competing APIs using an app written with each by the same develope
Re:Sun's Take (Score:2)
It doesn't.
It hasn't run slow for years, since reasonable JIT/hotspot acceleration arrived in Java 1.3 many years ago.
To quote from "Performance of Java vs C++" by J.P.Lewis:
"Java is now nearly equal to C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."
The paper then goes on to investigate why the myth of Java slow speed persists.
Re:Java-less Servers (Score:2)
Java is getting much better on the desktop (FINALLY), but it is most definitely at its best on the server.
wx4j: Native widgets via wxWidgets (Score:2, Informative)
Heck, you can even compile the whole thing natively [wx4j.org].
Re:Always The Outcast (Score:5, Informative)
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.
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
Re:Java worms soon to come. (Score:2)
Re:Java worms soon to come. (Score:3, Informative)
Nonsensical FUD.
Java has security manager features that have been tested and refined over a decade. Java was designed from the core to protect against such problems - every memory access and every class loaded is validated.
The only redeeming feature is that with the performance that Java provides, propogation of such worms will likely be a bit slower than the us
Re:Java worms soon to come. (Score:2)
Unless you use Swing, which is a critical component for writing desktop apps unless you resort to non-standard libraries.
Sun, swallow your pride for just a second and deprecate Swing (yes, ALL of it!). Then adopt SWT instead and you'll be doing the community a huge service. It's no surprise that the only usable desktop Java apps I'm aware of use SWT. In addition to Eclipse which most here are probably aware of, take a look at Azureus [sourceforge.net] for e
Re:Java worms soon to come. (Score:2)
Why can't slashdotters be up to date?
SWT is good, but sometimes its useful to have a consistent look and feel across all platforms (saves on user guides, for example).
Swing isn't slow anymore. It was really dreadful and unusable years ago, but there were major performance enhancements under Java 1.4, and Under 1.5 the native code for your apps is cached on disk. Next time you start,
Re:Java worms soon to come. (Score:4, Insightful)
Re:Java worms soon to come. (Score:2, Interesting)
Re:Java worms soon to come. (Score:2)
You have to keep up-to-date in the IT industry. What was true a couple of years ago is now out-of-date.
Re:Java worms soon to come. (Score:2)
My criticism stems from significant experience developing GUIs with Swing under v1.4, which is the latest non-beta release. And sorry, Swing is still dog slow for anything but trivial GUI stuff (e.g. menus and dialogs).
Maybe it's "good enough" in 1.5 but I doubt it. The problem is one of poor design choices (e.g. object-creation-happy apis), and all the kludges in the world (e.g. caching compiled native code) are unlikely to change that.
Re:I just (Score:2)
Re:Where is the security? (Score:2, Interesting)
Launching an executable from Java requires either access to a native library, or the Runtime.exec() method. By default, web applets can't do either, so they probably couldn't use this functionality at all. (Which is how it should be.) But I can't verify this without looking at the internal workings of the library.
Which brings me to my question: Where's the source code?? The download page only shows binary packages. Did I miss something?
Re:Where is the security? (Score:2)
Re:interesting (Score:2)
It is as fast as C/C++. The two limiting factors are startup time (gotta start the VM, gotta let hotspot spot the hot spots) and memory footprint (GC issue, mostly).
But for runtime, it is as fast.
Re:interesting (Score:2, Insightful)