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

There isn't any real problem installing sun java on linux and then running
java apps from kde. It used to be that they looked a bit yuck but not any
more.

My biggest beef in that direction is Konqueror. Obviously the best browser
available and it uses an obscure java that just can't keep up. There is no
obvious ways of updating it either. Also failing to update Konq means many
people finish up running 3 or 4 browsers. This spoils the KDE experience.

I'm on 3.5.7 64bit now folks and wondering about a couple of things. Has kmail
got a bug. A mail didn't get to some one when the address was put into the CC
field. I looked at the source of another and the name was there but not the
actual email address.

Also K Beagle. Thought that was neat to start off with but got sick to death
of my disc banging about. I'd stuck 8gig of old data on my desktop. Does it
crawl for ever? I put up with it for 2 or more days. It's an interesting
area. 1st time I used find file on suse 9.? it took ages as an index was
built. There after it was very quick. Along came suse 10 and finds always
took a while. Now we have Beagle. Me wonders if it's being done at the right
level and really aught to be a part of Linux a la windoze.

Suse 10.3 is interesting too. I have some avi's kicking about. Following
installation they played. Following a few soft ware updates of other things
they stopped playing - no codecs.

John

On Sunday 27 April 2008 14:17:46 Peter Qusec wrote:
-------- 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.

and
difficulty of integration with the rest of the system;

I don't know about that, never tried it ;-)

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.

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.

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.

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

Peter

End of story.

Mitch

Peter Qusec a écrit :
Proposal: The kde project could get access to a huge pool of developers

by integrating java into kde and allowing java applications to become
part of the kde distribution.

According to the TIOBE Programming Community Index

(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) java
has about twice the mindshare as c++.

One reason for that is that java is in many ways far more sophisticated

than c++. Features like garbage collection, avoidance of pointers,
automatic refactoring, not having to duplicate class signatures in header
files, easier handling of threads and many more, allow java developers to
completely avoid a large array of bugs that c++ developers frequently
make (or at least that I did). In my experience I would guess that a java
developer is at least twice as effective as a c++ developer meaning (s)he
can implement at least twice the functionality in the same time as a c++
developer can.

So far the ugliest part that I've encountered in java is swing, but
that

should be no problem since it could be replaced by jambi.

One important obstacle for java so far was that it wasn't open source

but sun has changed that during the last year.

Therefore I would welcome a better support for java in kde because that

would allow me to contribute the kde project.

Best regards,
Peter

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


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

Relevant Pages