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.
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.
neverind the trolling you'll get because GNOME is being implented in
That's right I say:
JDS = GNOME = Mono =
(imagine what people would say if Sun created a 3rd environment in Java!)
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.
-- Fighting mediocrity one bad post at a time.
I agree completely. They had their perfect cross-platform platform back then. They could have done so much, back when there was no real competition in that area (read desktop apps, such as browser, office, etc...), that every move they make now just look odd at best.
Write boring code, not shiny code!
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.
Looking glass is way cool, I am itching and burning to get my hands on a copy of that (and perhaps some ointment).
Java Desktop is gnome with a new theme. Seriously they didn't even do as good a job as Redhat with Bluecurve in pretending that it was anything more than that. I suppose the real benefit is the legitimacy that it lends Linux on the desktop to the PHBs of the world, but technically it appears to be nothing to get excited about.
But the demos I've seen for looking glass....damn. It looks like Apple's Expose on steroids.
Finkployd
As they add more features and functionality I fully expect them to encounter the same problems that Microsoft has. With tighter desktop integration the risk of bugs and malicious actvity also increases.
How long before we start seeing Java worms? It's only a matter of time. How will we blame Microsoft for them? They'll be cross platform worms. The only redeeming feature is that with the performance that Java provides, propogation of such worms will likely be a bit slower than the usual Windows type.
...and netbeans, though the license was the Sun Public License (like the Mozilla license), rather than the GPL.
...though I'm more an eclipse kinda guy, myself.
This is where the serious fun begins.
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
Five years ago the main GUI for Java apps was the AWT, which just didn't sit well with a lot of serious developers. Swing was in its infancy, was dog slow at the best of times and didn't play well with threads. If they had tried to do this then, or anytime before Swing became a lot more usable, then it would have died before anyone noticed. They probably could have done it a little sooner, but its possible that because they now ship Gnome instead of CDE they're rethinking some of they ways the deploy a GUI desktop, or are making it easier to create apps with Java across all installations for desktop oriented tasks so that more programmers realize what can be done with Java.
"I use a Mac because I'm just better than you are."
That's a step in the right direction, but it does not go far enough. As the blurb says, only 5 to 6 MB gets shared. I am running JDK 1.5 beta2 and to be honest, I haven't noticed much (if any) savings (this is on Linux 2.6.5, don't know about windows). I currenly have 3 Java progrmas running using 511MB, 288MB, and 276MB (the first one is eclipse) according to both gtop and ksysguard. They are easily the top 3 memory pigs of the 150 processes currently running on my desktop. It is possible that gtop and ksysguard are not telling the total truth, but I do know for a fact that the java programs are the ones with which I get the most bang for the buck when I have to start killing processes to free up memory.
I suspect that to make Java truly viable on the desktop it would be necessary to have true VM sharing. In this scenario, starting a Java program would result in it being executed in an already running VM. The VM would be capable of running multiple programs simultaneously while still providing the safety of the sandbox. And, of course, there would always be at most only one copy (or part thereof) of a given class in the VM, regardless of how many applications are making use of it.
I don't know how feasible this really is, but Java will not take off on the desktop without something like it.
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.
Is what you propose going to be in .NET. If so then I would want to avoid it at all cost. Just imagine if one of those classes has a bug, and it crashes the VM. Now Microsoft wouldn't develop any buggy classes would they?
.Net will "clean Java's clock" when it runs well, and is supported on all the platforms Java runs well on today. That should be about the time hell freezes over.
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 load off the system AND sharing some classes will be huge for most apps. Specifically things like a Java calculator, notepad, ping program, or other small programs.
Lastly, I will agree that C# and
The more I learn about science, the more my faith in God increases.
Very good question.
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?
I am quite happy to see so many innovation lately in the market in order to make Java to be more desktop friendy - I am a Eclipse fan and I think Sun is trying to dampen down the momentum being built up in the Eclipse RCP (Rich Client Platform http://dev.eclipse.org/viewcvs/index.cgi/platform- ui-home/rcp-proposal/rich_client_platform_faciliti es.html?rev=HEAD) camp.
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 been so much innovation coming out of them. As long as the source is there, it will all be good!
Actually I thought he was talking about something like this.
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.)
Karma: It's all a bunch of tree-huggin' hippy crap!
Can someone please explain something to me, as I feel I am being stupid.
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 got so bad that Linux developers insist on having everything pre-installed?
Is there some major lack of internet connections and/or CD-writers for 'enterprise Linux guys', so that they can't download the Java development kit at work and take it home? I mean, it only has to be done once....
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 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.
Java is currently a very good platform for server-side solutions.
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: releasing JDIC or whatever it is under the LGPL suggests that they are indeed interested in propagating desktop-side Java. So it would seem logical to get as many Java VM's out there as easily as possible; which would mean slightly less restrictive language about binary distribution. (Notice that I am not speaking here of open source.)
But then again: tight integration of a Linux desktop with a Java VM is one of the selling points of the JDS, so from the perspective of that division, it would not make sense to make Java VM's more easily distributable.
In short, I don't have the faintest idea of where Sun is going. And I suspect that they don't either. You cannot have both ubiquity and control, but Sun's business model is premised upon having both.
Google confirms: Ruby is the world's most beloved programm
Sun has simply figured out that it doesn't matter if they make some parts of the platform open source as long as they still control core portions of the platform.
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.