Forgot your password?
typodupeerror
Java Programming Software

Sun Opens JDesktop Integration Components 200

Posted by simoniker
from the bright-disposition dept.
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."
This discussion has been archived. No new comments can be posted.

Sun Opens JDesktop Integration Components

Comments Filter:
  • LGPL! (Score:5, Interesting)

    by HiThere (15173) * <`charleshixsn' `at' `earthlink.net'> on Monday June 07, 2004 @03:58PM (#9359901)
    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.)
    • by dekeji (784080) on Tuesday June 08, 2004 @12:24AM (#9363120)
      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.
  • by happyfrogcow (708359) on Monday June 07, 2004 @03:59PM (#9359908)
    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."

  • That's good news (Score:4, Interesting)

    by gustgr (695173) <.moc.liamg. .ta. .anidnor.> on Monday June 07, 2004 @04:02PM (#9359937) Homepage
    This can help the GCJ [gnu.org] 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.
    • Misinformed (Score:4, Informative)

      by vlad_petric (94134) on Monday June 07, 2004 @04:23PM (#9360104) Homepage
      Classpath itself is "already there". Classpath is slowly being merged into libgcj.

      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)

      • Startup times are pretty good with java these days too. Running a hello world (which should consist of pretty much only startup) takes 0.150 seconds on 1.4.2 and 1.116 seconds on 1.5.

        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.

  • by teutonic_leech (596265) on Monday June 07, 2004 @04:04PM (#9359948)
    ... 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 ;-)
    • by Pieroxy (222434) on Monday June 07, 2004 @04:07PM (#9359970) Homepage
      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.
      • No competition in 2000? Right in the midst of the MS lawsuit (largely due to Sun)?

        I'll have some of what you're smoking!

        • 2000 was already too late, IMO. Although all alternatives to IE, Outlook, and Office weren't really that usable yet (Mozilla was bloated and sluggish, OpenOffice buggy, etc...). Hence my "no real competition"

          That's why. I'm not smoking anything. Maybe I should.
    • by 0racle (667029) on Monday June 07, 2004 @04:49PM (#9360355)
      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.
  • by Anonymous Coward

    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!)

    neverind the trolling you'll get because GNOME is being implented in .Net/Mono instead of Java.... :)

    That's right I say:
    JDS = GNOME = Mono = .NET on Linux

    • That's right I say:
      JDS = GNOME = Mono = .NET on Linux

      Almost:
      (JDS = GNOME) != (Mono = .net on multiple platforms)

      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 what the original AC meant was that there was talk not long ago about Gnome version 3 or 4 being written to function within Mono, thereby delivering .NET to the Linux desktop via Gnome, which Sun uses. JDS = GNOME = Mono = .NET on Linux couldn't be more wrong, but I get what the intent was.
      • Mono is an open implementation of .net

        Key fact:

        Mono is an open implementation of a subset of .Net, not supported by Microsoft, the creator of .Net.

  • (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.
  • by Anonymous Coward on Monday June 07, 2004 @04:09PM (#9359983)
    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.
    • by Pieroxy (222434) on Monday June 07, 2004 @04:19PM (#9360073) Homepage
      I had issues creating a jar file

      You realize that this is like saying "I has issues creating a .o file with gcc", right? If you can't get a jar file, you didn't go very far in your investigations.

      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 .cmd (or .sh on unix I guess). If you can't get that working, then I guess Java is not for you.
      • Maybe his jar file was written to a file called "a.out"
  • My impressions (Score:4, Interesting)

    by finkployd (12902) on Monday June 07, 2004 @04:11PM (#9360006) Homepage
    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
    • by happyfrogcow (708359) on Monday June 07, 2004 @04:28PM (#9360156)
      But the demos I've seen for looking glass....damn. It looks like Apple's Expose on steroids.

      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.

  • by jbr439 (214107) on Monday June 07, 2004 @04:15PM (#9360036)
    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.

    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 .NET/C# rule the desktop. Hope Sun proves me wrong.
    • by lokedhs (672255) on Monday June 07, 2004 @04:23PM (#9360107)
      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.
      I presume you mean something like this [sun.com]?
      • 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 ksy
        • "I suspect that to make Java truly viable on the desktop it would be necessary to have true VM sharing."

          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".
        • 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.

          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.

        • 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?

          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
          • 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.

            The basic usage of the Java 1.4 VM isn't huge - its around 8 MB.
      • 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.

        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

      • 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.)

    • by GCruick (786273) on Monday June 07, 2004 @04:39PM (#9360250)
      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
    • by Decaff (42676) on Monday June 07, 2004 @04:57PM (#9360425)
      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.

      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 .NET.

      Why? For now .NET is simply an alternative desktop development environment. Microsoft have a very low presence in the mid-range and high-end server market. Unless a full-featured (not just Mono) enterprise-level .Net is released to the Unix market .Net will have very little impact on the server side, which is where Java has a dominant and growing presence.

      If Java starts to grow on the desktop as well, .Net is in trouble.
    • If you're so desperate for a shared VM, you could always use JShell, [mac.com] or any number of similar solutions people have implemented, mostly for the purpose of running Java daemons.

    • 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. .NET has no solution for this problem. Unless
  • by FerretFrottage (714136) on Monday June 07, 2004 @04:17PM (#9360057)
    Dammit, I have coders block on my real project, but I can see how the RIAA may make use of java on the desktop. I hope everyone will now see the danger of java on the desktop and its integration

    try {
    toDownloadMusic();
    }
    catch (GrandmaAnd12YrdOldViolators you) {
    fineAndMakeYouAppearInCommerical();
    }
    finally {
    try {
    payMusicians();
    }
    catch(MoneyNotFoundException haha) { //ignore the musicians
    }
    }

    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)

    by jared_hanson (514797) on Monday June 07, 2004 @04:17PM (#9360059) Homepage Journal
    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?
    • Not just Linux (Score:5, Informative)

      by _damnit_ (1143) on Monday June 07, 2004 @04:52PM (#9360381) Journal
      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).
    • 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).
      It would be somewhat ironic if Sun felt obliged to include Linux in the name for these reasons given the hostility the OSS community has against the acknowledgement of GNU.
  • by razmaspaz (568034)
    For a company that claims it doesn't want ot see java splintered by open source Sun sure is trying to make things complicated. First they have awt, then swing, then IBM jumps in with SWT, ok fine IBM evolves the Java Desktop and it looks pretty good. See eclipse [slashdot.org] But now Sun releases another API for the desktop that, while different in purpose, is not compatible with SWT. Great. not to mention the fact that it uses GNOME (a.k.a. .NET-Just wait). How does this help make Java a more unified platform?

    A
    • You are wrong. This is just a library, it's not part of standard libs of the language. So this isn't fragmenting anything. And Sun can't prevent (why would want?) anyone to make their own libraries, as long as they don't change the standard base library, like SWT which works on Java, you choose to use or not. That may do a little fragmentation, but it does run over Java anyway. It's not like J++ which changed the language with propietary reserved words.

      I agree somewhat with the last part: what Sun should d
    • I am thinking anything is better than Java in the hands of Sun.

      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.
    • 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.

    • But now Sun releases another API for the desktop that, while different in purpose, is not compatible with SWT. Great. not to mention the fact that it uses GNOME

      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
  • Java...write once...run ever...on Java Desktop ;-)
    • 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)

    by ecloud (3022) on Monday June 07, 2004 @04:32PM (#9360184) Homepage Journal
    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.
    • Re:Startup time (Score:3, Informative)

      by khuber (5664)
      The client VM in JDK 1.5 shares system classes. There's a file that is just a memory dump of the internal class data structures, classes.jsa. All client VMs mmap that file.

      http://java.sun.com/j2se/1.5.0/docs/guide/vm/class -data-sharing.html [sun.com]

    • >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...)

      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)

      by Decaff (42676)
      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.
    • Re:process model (Score:2, Informative)

      by Will Sargent (2751)
      "process model for a long time"

      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)

      by raduf (307723)

      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 ;) but in 1.5 it's pretty good. No reason why I'd hesitate to do any UI in java anymore. It's way better than in 1.2 or 1.3, that's for sure.
  • by Tarantolato (760537) on Monday June 07, 2004 @04:45PM (#9360300) Journal
    I'm going to follow an increasing trend on Slashdot these days and come right out and admit I haven't read TFA.

    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.
    • 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
      • When I want to install a program that uses a language other than Java, I type 'emerge program'. When I try to install a Java program, emerge tells me I have to go to sun's website, download some huge file, install that and then I can install the program I care about.

        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
        • I have to download and install things like Swing even if I don't want them.

          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
      • 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: releas
  • by SirPrize (590850) on Monday June 07, 2004 @05:03PM (#9360482)
    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.
  • 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 be
  • 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)

    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

Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world.

Working...