-------- Original-Nachricht --------
> Datum: Sun, 27 Apr 2008 17:57:17 +0200
> Von: mitch <mitch074@xxxxxxxxx>
> An: kde@xxxxxxxxxxxx
> Betreff: Re: KDE should strive for better java support to gain more developers.
> Peter Qusec a écrit :
> > -------- Original-Nachricht --------
> >
> >> Datum: Sun, 27 Apr 2008 13:22:05 +0200
> >> Von: mitch <mitch074@xxxxxxxxx>
> >> An: kde@xxxxxxxxxxxx
> >> Betreff: Re: KDE should strive for better java support to gain
> more developers.
> >>
> >
> >
> >> Corrected proposal: the KDE project should very well document how to
> >> access their applications with Java
> >>
> >> Lack of pointers and need for garbage collection go hand in hand: in
> >> C/C++, you clean up after yourself. You don't clean up, you get buried
> >> under crap. Java (and .Net/Mono C#) get away with garbage collection
> >> because 1- the virtual machine they run in has a small memory capacity,
> >>
> >
> >
> >> and 2- being virtual machines in nature, if they crash they don't bring
> >> other applications down with them.
> >> The price of this automatic memory management is incredible slowness
> >>
> > That might have been the case in the past, but that is certainly not
> true any more. Automatic memory management can even be more efficient than
> manual memory management because the VM can clean larger chunks of memory at a
> time which leads to less fragmentation.
> > From my personal experience I know that java is certainly not slow. In
> my group we are working on some large scale applications that keep gigabyte
> of data in main memory and that works just fine.
> >
> In MY own experience, Java seems fast on modern computers - not on
> hand-held. What it amounts to? A dozen times slower means that a C++
> application that runs fast on a 150 MHz ARM chip will look like molasse
> if ported to Java, on the same chip.
> So yes, current CPUs allow you to hide away that fact; it's been used by
> many companies to sell their next software version.
It might be true that interpreted Java is a dozen times slower c++, but thanks to the hot spot optimization Java code gets compiled to machine code on the fly in al the important spots. That really makes a huge difference. A few years ago I implemented the same data mining algorithm on c++ and java and while c++ was faster, it was so only by a factor of 2.
But you might be right about the ARM chip. Somebody told me once that the hot spot optimization could not be used these smaller processor. However, I can't exactly remember what that reason was.
> Incidentally, that also brought Vista to the world.
> >
> >> and
> >> difficulty of integration with the rest of the system;
> >>
> > I don't know about that, never tried it ;-)
> >
> Java runs in its own little world; it can manipulate elements outside of
> itself too, but then you don't have 'just' Java: you have Java moving
> other objects around (like a Gtk application, or a Qt application, or a
> Win32 application) that have hooks Javacan manipulate, and then yes,
> since Java doesn't need to draw the interface or handle interface
> elements and inputs or outputs, which have always be the most expensive
> elements in an application, it isn't as slowed down as if you whole app
> was written in Java - but then, every time you port the application, you
> have to port the whole 'outside of Java' part too.
> Your application may handle gigabytes of data, and use Java; rest
> assured though, that while Java may very well be the language used by
> the core part of your application, the actual heavy lifting is done by
> one database engine or another (or several), and the interface done
> through Gtk or Qt - and most of those are written in C or C++, which
> don't require more than gcc (and probably gcc-cpp) to compile.
> In that case, outside of small toys, there is no real interest in
> writing applications in Java for KDE
Actually, one of the first version of this application was written in a way that all the heavy computations would be performed as sql statements inside an oracle database. That, however, turned out to be far to slow which is why we reimplemented it completely in Java. We even copied the whole database to the Java heap space and performed all the computations purely in Java. And that works now really fast.
>
> Adding the possibility to do stuff in Java directly into KDE would mean
> one extra requirement for KDE-core: a Java VM. It's big enough as it is,
> and if you look at Gnome's example with Mono (C#), which doubles the
> size of a core install and its memory requirements, it's not exactly a
> completely good thing - especially considering how light KDE 4 finally
> got.
> >
> >> Sun tried for a
> >> Java OS for a long while, without success due to the humongous overhead
> >> entailed by such a system, and its relative lack of stability.
> >> Please note that GNOME already uses Mono for some apps (Tomboy,
> Beagle);
> >> browse the Intarweb for Tomboy and Beagle troubles: CPU hogging, memory
> >> use, crashes, etc. for the simple reason that while programming apps in
> >> VMs is easier than doing C on a real machine, programming the VM is
> >> another bucket of nails all in itself.
> >>
> > Well, I think that its unfair to infer from problems in Mono that Java
> will the same problems. While I don't know much about Mono I can't imagine
> that Mono is even nearly as mature as Java.
> >
> Oh, it's mature enough to run pretty much anything you'd run on Java.
> >
> >> Current compilers, automatic checks and CPU extensions like the NX bit
> >> are able to point out a lot of potential leaks and type corruptions: if
> >> you program without paying attention to your compiler output, yes,
> C/C++
> >> is trouble; if you program cleanly, it blows Java's socks off.
> >>
> >
> > The problem is, as a c++ you need to direct much of your attention to
> these problems instead of on the problem you are actually trying to solve
> with your program. In my opinion developer time is the most important resource
> in a software project much more so than memory or CPU usage.
> >
> Are you crazy?! If you thing memory or CPU usage are less important than
> rapidly pouring out code, they are hiring at Microsoft's! From my
> personal experience, ensuring your code is clean from the get go may
> seem slow at the time, but after that, code review and testing (which is
> supposed to represent at the very least 60% of your development time)
> gets so much faster, and debugging so easier, you end up SAVING time
> instead of wasting it! Not to talk about expanding said code: the better
> thought out, the simpler, the better, the more stable.
I specifically meant the memory and CPU overhead imposed by java. Of coarse its important to write clean code, think through the architecture of your software and chose the right algorithms for your problems. But there are a lot of bugs that one can cause in c++ that you can completely forego in Java. The worst ones I remember were those where you access an array outside its allocated area. Your program would just crash anywhere and you had to hunt that bug for days. Such things are just a waste of time.
>
> And a VM ain't simple, be it Java's or C#'s.
>
> You may not notice it when developing you application running on
> powerhouses, but if you craft your algorithms to run only once instead
> of a thousand of times a second, not only will you ensure that the
> 'ghost in the machine' won't have enough time to bite you on the butt,
> but it will also mean that it'll scale that much better.
Optimizing your algorithms has to be done independant of the language you are using. However the more technical details get into the way the harder it will be to focus on what the algorithm is actually doing.
> >
> >
> >> And, deal breaker, Java isn't fully licensed under the GPL - so it
> can't
> >> be distributed with KDE.
> >>
> >
> > Java is open source except for the sound engine and the SNMP code and
> Sun has promised to make that open sorce by the end of the year.
> >
> Yeah, well, it was supposed to be end of 2006... right now, there are
> two 'fully free' and quite feature complete Java VMs: IcedTea, and GCJ.
> IcedTea, which uses Free Sun code and a bunch of stubs, runs - barely
> (so there must be something missing), and GCJ, which, while passing the
> Java test suite, still can't run many Sun VM compiled bytecode
> flawlessly, when it's not compiled first.
I was talking about the OpenJDK project.
http://developers.slashdot.org/article.pl?sid=08/04/23/2037220
>
> Considering most Java programmers came to Java not to have to learn the
> intricacies of a compiler or a fully typed, memory mapped language, I'd
> like to see you try to make these programmers work on a platform where
> the Java version may change from one release to the other.
> > Also, my main point is that KDE should provide a straight forward way
> for Java developers to contribute to KDE. I believe that there are quite a
> few Java developers out there who would like to contribute to KDE but for
> whom its just not worth the hassle to switch to c++.
> >
> How may I put it... Nothing prevents these developers from creating a
> Java back-end for KDE, and code around it; I mean, geez, KDE is Free! If
> it hasn't been done in all that time (Java ain't brand new, KDE ain't,
> either), then maybe it was considered, weighted, attempted and finally
> rejected.
>
> In short, I understand your reasoning, but there are technical and
> licensing reasons why this hasn't happened, and many real life examples
> showing where it would byte (GNOME and Mono are one, Vista and .Net are
> another, and Sun's JavaOS wraps it up).
>
> Without going as far as a full OS, another example of Java integration
> in a complex C++ application can be found in OpenOffice.org 2: the
> original version had 30% of its features relying on Java; so, as long as
> there was no Java VM installed, it didn't quite work. What happened?
> Well, most Java-reliant features were little by little rewritten in C++,
> in order to solve:
> - dependency on Sun's VM (at least allow use of GCJ; cleanup brought
> some speedup and a lot of redundant Java code removal)
> - slooooowness
> - lack of portability (no Sun Java VM on the machine, no OOo)
> - memory footprint
> - instabilities (it crashed or hung pretty much whenever).
> In short: Java is fine for programming some tricky stuff rapidly, and
> create fully featured prototypes easily; it is also stable enough when
> you don't tax it or delegate UI-related work to native toolkits, in
> which case you won't really feel the x30 slowdown provoked by the VM. It
> is also well geared to support applications that are accessed by various
> systems reliably (such as servers accessed by clients of various types,
> architectures and endianness), and that is what it's being used for.
> However, performance- and durability-wise, it doesn't hold a candle to
> well-programmed C++, and Open Source code pretty much solves the problem
> of C++ not being platform agnostic (well-programmed code needs a
> recompile, that's it).
>
> Don't forget that KDE is a user-oriented project, where I/O timings are
> of the utmost importance, and the user's machine can't be controlled:
> you may find KDE on a PPC Mac, on a PPC Linux machine, on a Cell
> processor, on 32-bit and 64-bit x86, on ARM for a cell phone; the latter
> doesn't do any kind of predictive branching well, but handles interfaces
> fast; a Cell processor will crunch floating point data fast, but suck at
> pure integer computation; x86 is, well, x86.
> If you don't ensure your application can run well on all these, then you
> shut away loads of users; if you make it so your application can run on
> an underpowered ARM chip or on the odd specialized chip out there, you
> strike the motherlode. C and C++ allow that; it's tricky, but it works.
> Java doesn't (before you ask, yes, I know about Java Mobile; the simple
> fact that it's not a stripped down version of Java makes code management
> much more difficult).
>
>
> > Peter
> >
> Mitch
>
Peter
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
