Performance on today's desktop

Discussion in 'Java' started by gerrards8 @yahoo.com, Sep 26, 2005.

  1. With today's *average* personal/business desktop computing power, do you
    consider Java based client applications to be slow? (to remain pure,
    let's just concentrate on Swing based apps)

    If so, at what point (in time and/or JVM release) did this performance
    issue become a non-issue?

    If not, is it the application architecture or the JVM (and its libs,
    i.e., Swing) that's behind this lag in performance?

    Please base you reply on desktop computers that can be purchased in your
    market today, clean of all the infestations of unnecessary memory
    resident and background processes that are normally pre-installed on
    commodity type Win systems.
     
    gerrards8 @yahoo.com, Sep 26, 2005
    #1
    1. Advertising

  2. That was very bad!

    Please _revise_ question to:

    With today's personal/business desktop computing power, do you consider
    the performance of Java based client applications to be satisfactory?
    (to remain pure, let's just concentrate on Swing based apps)

    If so, at what point (in time and/or JVM release) did this performance
    issue become a non-issue?

    If not, is it the application architecture or the JVM that's behind this
    lag in performance?

    Please base you reply on desktop computers that can be purchased today,
    clean of all the infestations of unnecessary memory resident and
    background processes that are normally pre-installed on commodity type
    Win systems.


    Sorry for the confustion..
     
    gerrards8 @yahoo.com, Sep 26, 2005
    #2
    1. Advertising

  3. On 2005-09-26, gerrards8 @yahoo.com penned:
    > With today's *average* personal/business desktop computing power, do
    > you consider Java based client applications to be slow? (to remain
    > pure, let's just concentrate on Swing based apps)


    They're not blazingly fast, but they're not slow. I guess it depends
    on what you mean by slow. Slower than native? User would say that
    it's slow?

    > If so, at what point (in time and/or JVM release) did this
    > performance issue become a non-issue?


    I think it had less to do with the JVM than with improvements in
    hardware over tmie.

    > If not, is it the application architecture or the JVM (and its libs,
    > i.e., Swing) that's behind this lag in performance?
    >
    > Please base you reply on desktop computers that can be purchased in
    > your market today, clean of all the infestations of unnecessary
    > memory resident and background processes that are normally
    > pre-installed on commodity type Win systems.


    Why? That's not a realistic expectation of a user machine. User
    machines were probably purchased a few years ago and are almost
    certainly infested.

    --
    monique

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Monique Y. Mudama, Sep 26, 2005
    #3
  4. gerrards8 @yahoo.com

    elektrophyte Guest

    gerrards8 @yahoo.com wrote:
    > With today's *average* personal/business desktop computing power, do you
    > consider Java based client applications to be slow? (to remain pure,
    > let's just concentrate on Swing based apps)
    >
    > If so, at what point (in time and/or JVM release) did this performance
    > issue become a non-issue?
    >
    > If not, is it the application architecture or the JVM (and its libs,
    > i.e., Swing) that's behind this lag in performance?


    I've been using the IntelliJ IDEA Java development environment, a Swing
    app, for about two years and it's fine on average to high end PCs. At
    first it seemed a little slower than native GUI applications, but
    definitely useable. I never had any problem with it's speed. Since
    about a year ago, the difference has not been noticable; there's been
    no "lag".

    > Please base you reply on desktop computers that can be purchased in your
    > market today, clean of all the infestations of unnecessary memory
    > resident and background processes that are normally pre-installed on
    > commodity type Win systems.


    Most computers I work with are loaded with lots of background
    processes. Actually, one of the guys has noticed that it doesn't play
    well with the Novell Groupwise client for Windows, come to think of it.
    But I never noticed that problem.

    In general, my sense is that with today's machines, and improvements to
    Java, Swing application performance is acceptible. You could easily try
    it out for yourself by trying some of the apps found here:

    http://java.sun.com/products/jfc/tsc/sightings/

    E
     
    elektrophyte, Sep 26, 2005
    #4
  5. gerrards8 @yahoo.com

    Oliver Wong Guest

    "gerrards8 @yahoo.com" <seeName@noSpam> wrote in message
    news:7_WZe.2242$...
    > With today's *average* personal/business desktop computing power, do you
    > consider Java based client applications to be slow? (to remain pure,
    > let's just concentrate on Swing based apps)


    The two Java applications I think of when I think of "Slow Java
    Applications" are Eclipse and JEdit, and occasionally Azureus.

    The only native program that I know of that does something of similar
    complexity to Azureus is eMule, and they're about the same speed. That is to
    say, the bottleneck is probably not CPU power but rather disk I/O and
    network I/O.

    The only native program that I know of that does something of similar
    complexity to Eclipse is Visual Studio. Actually, Visual Studio does far
    less "real time code analysis" (e.g. detecting errors as you type,
    quickfixes, intellisense, etc.) The two are of comparable speed, with
    Eclipse being a bit faster while actually "running" (might be an illusion
    from it continuously pre-compiling, as opposed to VS's "compile when the
    user says to compiler"), but Eclipse takes longer to load and quit.

    The only native program that I know of that does something of similar
    complexity to JEdit is TextPad. TextPad does quite a deal less than JEdit,
    but TextPad is blazing fast compared to JEdit. So here's a situation where
    Java might actually lose out due to performance; whether a user prefers
    JEdit or TextPad would depend on whether they are willing to wait longer in
    exchange for more features or not. Maybe someone should optimize JEdit (be
    sure to profile first!), or write a clone of TextPad in Java, with all the
    extra features in JEdit stripped out for performance?

    For every other Java application I've used, speed was not an issue. As a
    specific example, JDiskReport (http://www.jgoodies.com/freeware/index.html)
    shows you free disk space on your harddrive. The equivalent native program
    is DiskSpacePlus (http://www.softwhile.com/product_dsp.html). I find
    JDiskReport actually "feels" faster, but this probably due to JDiskReport
    using a seperate thread to scan the disk drive than the one drawing the UI,
    while the DiskSpacePlus application seems to be using the same thread for
    both (i.e. while scanning the disk, it does not repaint the window or
    responds to mouse clicks).

    So, IMHO, Java is "fast enough" except in the domain of plain text
    editors.

    > If so, at what point (in time and/or JVM release) did this performance
    > issue become a non-issue?


    Maybe I was a late adopter, but I've never encountered a Java program
    that was slow for which there existed a noticeably faster native program
    (except for the JEdit vs TextPad situation mentioned above). I'm told there
    was a point in history during which Java was dog slow. I guess back then,
    people didn't bother releasing many Java applications because it was so
    slow, which is why I never really encountered any such applications. When
    Java sped up, more applications were released which were written in Java,
    and so when I encountered them, I never experienced this "slowness" that
    some people claim to be a property of Java.

    > Please base you reply on desktop computers that can be purchased in your
    > market today, clean of all the infestations of unnecessary memory resident
    > and background processes that are normally pre-installed on commodity type
    > Win systems.


    I'm basinc my reply on my own experiences, which is composed mostly of
    my own personal computer.

    - Oliver
     
    Oliver Wong, Sep 26, 2005
    #5
  6. Oliver Wong wrote:
    > "gerrards8 @yahoo.com" <seeName@noSpam> wrote in message
    > news:7_WZe.2242$...
    >
    >>With today's *average* personal/business desktop computing power, do you
    >>consider Java based client applications to be slow? (to remain pure,
    >>let's just concentrate on Swing based apps)

    >
    >
    > The two Java applications I think of when I think of "Slow Java
    > Applications" are Eclipse and JEdit, and occasionally Azureus.


    Eclipse is not a Swing app.

    JEdit is incredibly badly written and is slow because of its
    "optimisations" (what else would you expect from a GPL program</troll>).

    When I think slow application, I think Thunderbird, Firebird, Opera and
    gedit.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Sep 26, 2005
    #6
  7. gerrards8 @yahoo.com

    elektrophyte Guest

    Oliver Wong wrote:
    > I'm told there
    > was a point in history during which Java was dog slow.


    I think that's true. When I started programming in Java in 2000 I tried
    to use Sun's "Forte" IDE which was written in Java. On a 550 mHz PC
    with 256 MB or RAM it was indeed miserably slow.

    > I never experienced this "slowness" that
    > some people claim to be a property of Java.


    I can think of reasons someone would choose not to develop a desktop
    app in Java. However, the slowness issue has been pretty much resolved.
    It's too bad the Java platform can't shake the reputation of being
    slow, even though it isn't anymore.

    E
     
    elektrophyte, Sep 26, 2005
    #7
  8. Oliver Wong wrote:
    > Maybe I was a late adopter, but I've never encountered a Java program
    > that was slow for which there existed a noticeably faster native program
    > (except for the JEdit vs TextPad situation mentioned above).



    You bring up great examples, and I totally agree with them.

    But, let's look at similar examples from the other side.

    What about office type applications (Word, Excel, Power Point)? Only
    one I can think of is ThinkFree (not sure if they include an API to
    integrate with their product). Perhaps there is only one choice of a
    decent HTML or PDF renderer in the market, and the price is way up!
    Very few Email and SQL clients (dbVisualizer rocks!). Hardly a fully
    functional reporting tool that would meet Crystal Reports or MS Access'
    reporting features plus ease/speed of report design, and the list goes
    on...

    I do believe the speed has been a non-issue, even with Swing, for 2 to 3
    years now but don't understand why desktop Apps (free or for $) are very
    rare, specially the kind that can integrate and enrich other Java
    desktop Apps.
     
    gerrards8 @yahoo.com, Sep 26, 2005
    #8
  9. gerrards8 @yahoo.com

    Roedy Green Guest

    On Mon, 26 Sep 2005 22:17:58 +0100, Thomas Hawtin
    <> wrote or quoted :

    >When I think slow application, I think Thunderbird, Firebird, Opera and
    >gedit.


    Why are browsers slow?

    1. because servers are slow

    2. because transmission is slow

    3. because of errors causing retransmissions?

    4. because of having to parse unclean markup and make sense of it
    anyway.

    5. because HTML is so designed that you need the entire document
    before you can completely nail down the layout.

    6. something else.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 27, 2005
    #9
  10. gerrards8 @yahoo.com

    Roedy Green Guest

    On Mon, 26 Sep 2005 18:19:04 -0400, "gerrards8 @yahoo.com"
    <seeName@noSpam> wrote or quoted :

    >I do believe the speed has been a non-issue, even with Swing, for 2 to 3
    >years now but don't understand why desktop Apps (free or for $) are very
    >rare, specially the kind that can integrate and enrich other Java
    >desktop Apps.


    Same reason you don't see non-java such apps. To compete you have a
    lot of catching up to do. The other reason is Java is very easy to
    decompile. Companies like to keep they code obscure.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 27, 2005
    #10
  11. gerrards8 @yahoo.com

    Chris Smith Guest

    I'm wandering into the middle of this, but...

    Roedy Green <> wrote:
    > Why are browsers slow?
    >
    > 1. because servers are slow
    > 2. because transmission is slow
    > 3. because of errors causing retransmissions?
    > 4. because of having to parse unclean markup and make sense of it
    > anyway.
    > 5. because HTML is so designed that you need the entire document
    > before you can completely nail down the layout.
    > 6. something else.


    It varies. 1, 2, and 5 are common. I'd never dream of 3 or 4 making
    any difference at all.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Sep 27, 2005
    #11
  12. Roedy Green wrote:
    > On Mon, 26 Sep 2005 22:17:58 +0100, Thomas Hawtin
    > <> wrote or quoted :
    >
    >
    >>When I think slow application, I think Thunderbird, Firebird, Opera and

    I mean Firefox (sorry Borland)^^^^^^^^
    >>gedit.

    >
    >
    > Why are browsers slow?
    >
    > 1. because servers are slow


    Rarely.

    > 2. because transmission is slow


    I don't need to use my 33.6 kbps modem anymore, since digital has become
    available across this densely populated country.

    > 3. because of errors causing retransmissions?


    Hope not.

    > 4. because of having to parse unclean markup and make sense of it
    > anyway.


    I don't think that's really a problem, although it can't help with
    maintenance.

    > 5. because HTML is so designed that you need the entire document
    > before you can completely nail down the layout.


    That hasn't really been a problem since 1997.

    Kind of related is overly long HTML. I believe display times tend to
    dominate, but pages with loads of stuff going on appear to be a bit
    slow. http://bugs.sun.com/bugdatabase/index.jsp as an example. Sites
    using JavaScript to animate are just evil (particularly if you have a
    large number of tabs open).

    > 6. something else.


    Mostly it's down to the GUI responsiveness. I used Firefox briefly after
    Mozilla until Opera came to my rescue (which isn't half as bad). Firefox
    is truly amazing. Open a new page and it locks up for a while. Any
    operation and goes into vegetive mode for a while. Back on Mozilla I
    once timed opening the history window taking one and three quarter minutes.

    For Opera the RSS reader is really irritating. Okay, some of the
    irritation is feeds that don't actually include the article inline. Take
    ages to move from one article to the next. Above 140 ms (or thereabouts)
    response time user interfaces become disconcerting.

    For long pages, which have their visible portions displayed perfectly
    accurately it inhibits progress by giving a busy cursor. Everything is
    in fact ready to go, but Opera is putting up stop signs.

    Also the usability of the search impacts on actual performance. I
    haven't noticed any incremental search, so finding keywords becomes an
    arduous task.

    It could do better switching between tabs isn't particularly clever.
    Okay, updating the page may take some time, but that's no excuse not to
    update the tabs.

    And they swap massively, but what doesn't.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Sep 27, 2005
    #12
  13. gerrards8 @yahoo.com

    Guest

    Roedy Green wrote:
    > Same reason you don't see non-java such apps. To compete you have a
    > lot of catching up to do. The other reason is Java is very easy to
    > decompile. Companies like to keep they code obscure.


    OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
    where MS has every government branch in hand. The state of
    Massachusetts is dumping MS Office in favor of OpenOffice due to its
    support for OASIS' OpenDocument as its default format (XML, but the
    right way!); and that's an Open Source software, whether the free
    version or the commercial one (StarOffice).

    Last I heard, Novell is also working on porting Evolution to Windows –
    Yet another “in your face” competition to Microsoft, and again,
    open-source (at least partially, not sure of its release 2).

    JetBrains (IntelliJ), Borland, Sun, Oracle, IBM and many others have
    done well selling Java based commerical software despite the risk of
    decompilation. They're threatened by free software, not open source.
     
    , Sep 27, 2005
    #13
  14. In article <F92_e.6552$>,
    "" <> wrote:

    > Roedy Green wrote:
    > > Same reason you don't see non-java such apps. To compete you have a
    > > lot of catching up to do. The other reason is Java is very easy to
    > > decompile. Companies like to keep they code obscure.

    >
    > OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
    > where MS has every government branch in hand. The state of
    > Massachusetts is dumping MS Office in favor of OpenOffice due to its
    > support for OASIS' OpenDocument as its default format (XML, but the
    > right way!); and that's an Open Source software, whether the free
    > version or the commercial one (StarOffice).


    Java is not a perfect fit for the desktop, which means that developers
    have to do more legwork to generate an application that 'fits in' than
    they would if they used the platform native tools. I find that
    additional work is not all that rough, usually, but if it is not done,
    then the app stands out as a turkey.

    It is the failure to do that final fit and finish pass that makes most
    Java application kinda bite. Those that have had that done seem to work
    pretty well. (I speak both of the commercial ones, and the custom apps
    that our group writes.)

    One good litmus test for whether the company 'gets it' is whether they
    produce a Mac version. A linux version is also a decent predictor, but
    the platform is close enough to Windows in look that it is not as clear.
    While engineering their Mac release, they usually find a lot of 'well
    how does Windows do it' problems, that then get addressed early in the
    product life cycle.

    OpenOffice has made the classic mistake - waiting until their app is
    mostly done before considering a Mac build. Thus, any problems will be
    found too late in the development cycle for them to consider fixing.

    NetBeans, on the other hand, has done a fairly good job of looking at
    what it will take to make their IDE Mac-like. They still have a ways to
    go, but they are making appropriate changes.

    IDEA has been doing this for a while, and is correspondingly far ahead
    on that score.

    Producing a Mac version will not insure good quality at the other end,
    but it will mean that you question your platform specific assumptions
    early in the process, and figure out your growth path.

    Scott

    --
    Scott Ellsworth

    Java and database consulting for the life sciences
     
    Scott Ellsworth, Sep 27, 2005
    #14
  15. gerrards8 @yahoo.com

    Guest

    Scott Ellsworth wrote:
    > In article <F92_e.6552$>,
    > "" <> wrote:
    >
    >
    >>Roedy Green wrote:
    >>
    >>>Same reason you don't see non-java such apps. To compete you have a
    >>>lot of catching up to do. The other reason is Java is very easy to
    >>>decompile. Companies like to keep they code obscure.

    >>
    >>OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
    >>where MS has every government branch in hand. The state of
    >>Massachusetts is dumping MS Office in favor of OpenOffice due to its
    >>support for OASIS' OpenDocument as its default format (XML, but the
    >>right way!); and that's an Open Source software, whether the free
    >>version or the commercial one (StarOffice).

    >
    >
    > Java is not a perfect fit for the desktop, which means that developers
    > have to do more legwork to generate an application that 'fits in' than
    > they would if they used the platform native tools. I find that
    > additional work is not all that rough, usually, but if it is not done,
    > then the app stands out as a turkey.


    Personally, I don't subscribe to the “fit in” notion as long as the App
    behaves in a generally accepted manner (UI). However, I would admit
    that I'd be a lot happier if my App does “fit in” without doing any
    platform specific coding, nor relying on third party libraries for that
    (IOW, JRE's responsibility).

    However, the question I wish to ask is that how many end users (home or
    business) out there make their software purchase decision based on the
    “fit in” criteria? I'm confident that if Adobe were to offer their
    Photoshop or even PDF viewer in, say Java/Swing straight up (it's a
    hypothesis), they would still be the market leader of such product
    segment, and that's due to the overall quality and value of their product.

    In the case of Mac, Apple would benefit greatly if Java desktop Apps
    would boom, just like they're benefiting from free Unix/Linux based
    software out there. IBM is constantly knocking on developers' doors to
    market Java solutions on IBM high end servers; perhaps Apple has better
    plans.
     
    , Sep 28, 2005
    #15
  16. gerrards8 @yahoo.com

    steve Guest

    On Wed, 28 Sep 2005 23:13:22 +0800, wrote
    (in article <Hoy_e.8511$>):

    > Scott Ellsworth wrote:
    >> In article <F92_e.6552$>,
    >> "" <> wrote:
    >>
    >>
    >>> Roedy Green wrote:
    >>>
    >>>> Same reason you don't see non-java such apps. To compete you have a
    >>>> lot of catching up to do. The other reason is Java is very easy to
    >>>> decompile. Companies like to keep they code obscure.
    >>>
    >>> OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
    >>> where MS has every government branch in hand. The state of
    >>> Massachusetts is dumping MS Office in favor of OpenOffice due to its
    >>> support for OASIS' OpenDocument as its default format (XML, but the
    >>> right way!); and that's an Open Source software, whether the free
    >>> version or the commercial one (StarOffice).

    >>
    >>
    >> Java is not a perfect fit for the desktop, which means that developers
    >> have to do more legwork to generate an application that 'fits in' than
    >> they would if they used the platform native tools. I find that
    >> additional work is not all that rough, usually, but if it is not done,
    >> then the app stands out as a turkey.

    >
    > Personally, I don't subscribe to the “fit in” notion as long as the App
    > behaves in a generally accepted manner (UI). However, I would admit
    > that I'd be a lot happier if my App does “fit in” without doing any
    > platform specific coding, nor relying on third party libraries for that
    > (IOW, JRE's responsibility).
    >
    > However, the question I wish to ask is that how many end users (home or
    > business) out there make their software purchase decision based on the
    > “fit in” criteria? I'm confident that if Adobe were to offer their
    > Photoshop or even PDF viewer in, say Java/Swing straight up (it's a
    > hypothesis), they would still be the market leader of such product
    > segment, and that's due to the overall quality and value of their product.
    >
    > In the case of Mac, Apple would benefit greatly if Java desktop Apps
    > would boom, just like they're benefiting from free Unix/Linux based
    > software out there. IBM is constantly knocking on developers' doors to
    > market Java solutions on IBM high end servers; perhaps Apple has better
    > plans.


    apple never gave a shit for java, and they still do not.
    anyone using os9 could see that , long before osx was released, 1.1.8 was the
    de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x
    same on osx now. with this built in java crap, we lag by several major
    revisions.
    I'm working with apple now on a bug that stops you printing ANY documents
    from java , if you send more than 1 document. it is reproducible only on osx
    and on all JVMS including 1.5.
    They fixed it on their high-end machines,(>900mhz) but not on the "low end
    stuff" and it's now been over 3 months. ( its being "verified", same as my
    other bugs in their java implementation, being verified for over 2 years"
    (sounds like sun))

    not to mention their shitty implementation of the java tool box.

    When printing documents using:
    PrintServiceAttributeSet printServiceAttributeSet = new
    HashPrintServiceAttributeSet();

    // aset.add(MediaSizeName.ISO_A4); //does not
    work crashes or hides printers

    // aset.add(new Copies(numberOfCopies)); does not
    work

    does not EVEN have the code implemented for setting number of copies page
    size etc. despite it being in the 1.4.x spec.

    yes i still have to loop to print multiple copies, and hope my printer has
    the correct size stock.
    Apples answer is "duplicate bug- previously reported", no shit , you mean i'm
    not the only person trying to print documents.


    Even me telling you this means i can be butt fucked under their
    non-disclosure agreement.


    Steve
     
    steve, Sep 28, 2005
    #16
  17. In article <>, steve <>
    wrote:

    > apple never gave a shit for java, and they still do not.
    > anyone using os9 could see that , long before osx was released, 1.1.8 was the
    > de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x
    > same on osx now. with this built in java crap, we lag by several major
    > revisions.


    I beg to differ.

    I have met the people involved, and they do care. They do not, however,
    have unlimited resources, and the resources they get are based on what
    the developer community and sales force demands. There was not
    sufficient call for an OS 9 1.2 VM to justify the rather amazing amount
    of work, given that OS X was their future. Had they failed to move to
    X, they would have ceased to exist.

    Outsiders could do a Java port, were they interested, but from what I
    have heard, Sun does not give a damn about the platform, and it is not
    clear whether Apache's project is going to produce a working JVM.

    Scott

    --
    Scott Ellsworth

    Java and database consulting for the life sciences
     
    Scott Ellsworth, Sep 30, 2005
    #17
  18. gerrards8 @yahoo.com

    steve Guest

    On Fri, 30 Sep 2005 08:05:55 +0800, Scott Ellsworth wrote
    (in article <>):

    > In article <>, steve <>
    > wrote:
    >
    >> apple never gave a shit for java, and they still do not.
    >> anyone using os9 could see that , long before osx was released, 1.1.8 was
    >> the
    >> de-facto standard on apples os9 for 2 years , whilst everyone else was on
    >> 2.x
    >> same on osx now. with this built in java crap, we lag by several major
    >> revisions.

    >
    > I beg to differ.
    >
    > I have met the people involved, and they do care. They do not, however,
    > have unlimited resources, and the resources they get are based on what
    > the developer community and sales force demands. There was not
    > sufficient call for an OS 9 1.2 VM to justify the rather amazing amount
    > of work, given that OS X was their future. Had they failed to move to
    > X, they would have ceased to exist.
    >
    > Outsiders could do a Java port, were they interested, but from what I
    > have heard, Sun does not give a damn about the platform, and it is not
    > clear whether Apache's project is going to produce a working JVM.
    >
    > Scott
    >
    >


    We are not talking about resources to develop some mickey mouse project
    needed by 50 people, we are talking about making sure the basics work.

    you consider printing is not basic enough?
    how about correct language support?
     
    steve, Oct 1, 2005
    #18
  19. In article <>, steve <> wrote:

    > On Fri, 30 Sep 2005 08:05:55 +0800, Scott Ellsworth wrote
    > (in article <>):
    >
    > > In article <>, steve <>
    > > wrote:
    > >
    > >> apple never gave a shit for java, and they still do not.
    > >> anyone using os9 could see that , long before osx was released, 1.1.8 was
    > >> the
    > >> de-facto standard on apples os9 for 2 years , whilst everyone else was on
    > >> 2.x
    > >> same on osx now. with this built in java crap, we lag by several major
    > >> revisions.

    > >
    > > I beg to differ.
    > >
    > > I have met the people involved, and they do care. They do not, however,
    > > have unlimited resources, and the resources they get are based on what
    > > the developer community and sales force demands. There was not
    > > sufficient call for an OS 9 1.2 VM to justify the rather amazing amount
    > > of work, given that OS X was their future. Had they failed to move to
    > > X, they would have ceased to exist.
    > >
    > > Outsiders could do a Java port, were they interested, but from what I
    > > have heard, Sun does not give a damn about the platform, and it is not
    > > clear whether Apache's project is going to produce a working JVM.

    >
    > We are not talking about resources to develop some mickey mouse project
    > needed by 50 people, we are talking about making sure the basics work.


    I am not pretending that their implementation is perfect. I am saying
    that 'Apple does not give a shit for Java' is in direct opposition to a
    team of over a dozen people paid to write it, with two new hires
    recently, and an open job req. The team is bigger than the Core Data
    group was through most of Tiger development, IIRC. Heck, the shared
    archive feature of Apple's 1.4 VM got moved into Sun's 1.5
    implementation, so they are doing real and original work. This is money
    being spent, and thus Apple clearly does care.

    The test of whether the 'basics work' is the JCK. You cannot ship if
    you fail to pass, so if something is missing, bug Sun to add it to the
    JCK.

    As far as my earlier argument about missing Mac libraries on the Java
    side, let me rephrase. Apple's resources are not unlimited, and thus
    they have to be allocated. If you want an API to have a Java
    implementation, you have to convince Apple that it is worth spending the
    time and treasure. That convincing comes through the developer
    community and through what sales reports to them. I find sales awfully
    powerful in that discussion, given that the java team is funded from the
    same $129 OS sales that drive Cocoa and the core OS.

    > you consider printing is not basic enough?


    Apparently Sun did not, as it did not make the JCK.

    I just read your earlier post again, and the release notes. Given that
    they did fix some printing bugs, they obviously tested printing. Given
    that your bug is still there, they did not test it well enough. I would
    be surprised if your bug was a known one on ship day, as it did not make
    the release notes.

    > how about correct language support?


    Correct language support? If, by this and 'we lag by several major
    revisions', you meant that we have 1.5_02 when 1.5_05 just shipped,
    well, they do have a preview of 1.5_04 out now. Or would you rather
    they held back for another few weeks to ship _05? (I, personally,
    wanted _04, so I could get the NetBeans folks to bring up their profiler
    now.)

    Sun could always ship a VM for the Mac, but we saw how that worked last
    time. Maybe the Apache group will succeed at making a better VM than
    Apple, but again, I am not so sure that will work.

    Scott

    --
    Scott Ellsworth

    Java and database consulting for the life sciences
     
    Scott Ellsworth, Oct 3, 2005
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page