Re: [kde] KDE should strive for better java support to gain more developers.


-------- Original-Nachricht --------
Datum: Sun, 27 Apr 2008 17:57:17 +0200
Von: mitch <mitch074@xxxxxxxxx>
An: kde@xxxxxxxxxxxx
Betreff: Re: [kde] 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] 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 ***,
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.

Quantcast