KDE should strive for better java support to gain more developers.
mitch074 at gmail.com
Sun Apr 27 16:57:17 BST 2008
Peter Qusec a écrit :
> -------- Original-Nachricht --------
>> Datum: Sun, 27 Apr 2008 13:22:05 +0200
>> Von: mitch <mitch074 at gmail.com>
>> An: kde at mail.kde.org
>> Betreff: Re: [kde] 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.
Incidentally, that also brought Vista to the world.
>> 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
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.
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.
>> 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.
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
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)
- 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).
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde