[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE / CORBA / C++ a historical viewpoint
From:       Bavo De Ridder <bavo.deridder () cs ! kuleuven ! ac ! be>
Date:       1999-09-17 18:18:36
[Download RAW message or body]

On Fri, 17 Sep 1999, you wrote:
>Bavo, are you really suggesting we should all dump everything and switch
>to Java for KDE 2?
>
>If no, what's the point on arging this right now? :-)
>

Switching to Java for KDE 2 is indeed complete crap. As long as we don't have
gcj, Java is no option (although I will start my own freetime projects in Java
:-) )

The point of my mail. I just wanted to put everything in the right (IMHO)
perspective: no matter what you choose, CORBA or shared libs, you will always
have a very high degree of complexity and a lot of functionality not available
that should be available.

The complexity of writing components for the KDE should be in the component
itself, in the task it wants to accomplish. Not in the underlying library *and*
the component. The library should be simple. Everyone uses Java because it is
easy. A lot of people use Qt because it is easy. CORBA however has been here a
long time and still not a lot of people are using it. IMHO that's a sign....

KDE 2 will and should be written in C++. However, I have a strong feeling that
Java will take a lot of C++'s marketshare, both in closed source and open
source, when natively compiled Java becomes available.

The higher the version number in KDE, the harder it will be to keep writing
libraries everyone can use.


BDR

p.s. Try to imagine the complexity of KDE 3 when you will probably have a
distributed desktop, application server, .... how many opensource developers
will be able to contribute or will be able to just understand what is going on.
In Java I can easily transport an entire application over the network to put on
another desktop. Try to do that in KDE/C++/CORBA .... and I am afraid exactly
that will be the future ....

>On Fri, 17 Sep 1999, Bavo De Ridder wrote:
>
>> On Fri, 17 Sep 1999, Jo Dillon wrote:
>> >Bavo De Ridder (bavo.deridder@cs.kuleuven.ac.be) spake thusly:
>> >> Not when using native compiled Java.
>> >
>> >  That isn't a magic bullet. Compiled languages can be inefficient, and
>> >given Java's admittedly-groovy dynamic method invocation, compiled java
>> >is likely to be.
>> >
>> >-- 
>> 
>> Hmm, this is actually one of the points where Java is faster than C++ ....
>> 
>> C++ has mixed dynamic/static method invocation. Java only has dynamic method
>> invocation. If you have lot's of virtual functions in C++ (see Qt ...) than
>> Java will actually be faster than C++ ....
>> 
>> BTW (1): GCJ is a mixed compiled/interpreted system. The best of both worlds.
>> 
>> BTW (2): machinelanguage is faster than C which is faster than C++ ... you
>> always pay a price. However, I think a full blown KDE 2/3 in C++ + CORBA will
>> actually be slower and use more memory than KDE written in Java and compiled
>> with gcj.
>> 
>> My experience show that a non-gui Java program is as fast as a C++ program, the
>> memory usage is comparable (not counting the overhead of the VM which is static
>> and won't grow when the program grows). For instance: alllocating 1000
>> javax.mail.MailMessage's (this is not the exact name, but you now what kind of
>> class I mean; I actually tested this once), gave a memory increase of 150-200
>> Kb. Those MailMessage objects included configuration file support, multipart
>> messages, dynamicly pluggable backend (Internet, Lotus Notes, ....). 
>> 
>> A GUI  program is slow because the bytecode is interpreted. Compiled code
>> should improve dramatically on that.
>> 
>> 
>> BDR
>> 
>> 
>
> ("\''/").__..-''"`-. .         Roberto Alsina
> `9_ 9  )   `-. (    ).`-._.`)  ralsina@unl.edu.ar
> (_Y_.)' ._   ) `._`.  " -.-'   Centro de Telematica
>  _..`-'_..-_/ /-'_.'           Universidad Nacional del Litoral
>(l)-'' ((i).' ((!.'             Santa Fe - Argentina
>                                KDE Developer (MFCH)
>Not mad, but bound more than a madman is (Romeo and Juliet, Act I Scene II)

[prev in list] [next in list] [prev in thread] [next in thread]