KDE should strive for better java support to gain more developers.

[mitch]

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

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