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

[Mitch]

Peter Qusec a écrit :
>> Yes, SQL can be REAL slow.
>>     
> Yes, it really was. I mean we've used Oracle, prepared statements and even tried to give optimization hints. Nothing helped and worse, it was a complete mess. Maybe there was a trick to make it faster, but we havn't found it.
>   
Oracle is strong and stable; speed-wise, however, my last use of it 
showed it to be slow (it was version 9i, quite old); at least slower 
than MySQL (which, I know, I know, may not be the best database to use 
in those cases where Oracle shines). For sure, it's better to do 
'simple' database extracts and sortings, and hack the data in any other 
language you can get (Java, thanks to JDBC, is very well geared for 
that, and you do use it where it makes sense).
>  
>   
> No. If you access an array outside its range, Java will throw an IndexOutOfBoundException and you know exactly what happend and where it happend. Sure, checking the boundaries costs efficiency, but you gain a lot of stability and security. Buffer overflows are just a nightmare.
>   
True; I haven't used Java in quite a while now, I don't remember how it 
reacts in such case.

No kidding... Still, I've always seen Java's (and other languages) 
garbage collector as a 'sweep under the rug' shortcut, and I don't like 
the idea of letting something mission critical run on a piece of 
software that, although it is proven and true, gives me no real control.

As an aside, you'll easily guess what I think about Microsof't's Jscript 
engine :p...

You can't beat full manual memory management for control granularity.
> No, you don't use an array instead of a hash table just because your programing language supports it better. Searching through an array in linear time where a single hash lookup would have done it just doesn't make sense.
>   
Yes, yes - what I meant was (as an example) that some languages are so 
slow with arrays that using hash tables is always a big win, but with 
others it may be easier to use arrays in some cases, the hit in 
execution speed not being big enough to bother with a hash table which 
can be tricky to implement.
>   
>> if you want maximum 
>> performance, however, remember that in Java, code needs to be in effect 
>> compiled twice.
>>     
> Yes, but in Eclipse the first compilation happens while you type in your program. It even shows you interactively the compile errors in your program and usually offers you a menu with a number of choices to solve the problem. 
>   
I think Eclipse can do that with C, too - it's a very complete 
programming environment, so you may want to try C/C++ development under 
Eclipse, just to be sure that some of the advantages you perceive as 
stemming from Java don't actually come from Eclipse as an IDE...
> Well yes, you optimize your code following the language's strenghts but to understand and optimize an algorithm its important to get as many technical and implementation details out of the way as possiple. That's why scientific publications usually describe algorithms in pseudo code and not in any programming language. Sure you don't always have to go all the way and write the algorithm in pseudo code first, but abstraction really helps to understand an algorithm.
>   
Yes, the pseudocode step is important, and a programmer's role is to 
know how best to convert pseudocode in real code. Still, even then, it's 
best to know not only a language's strength, but also a compiler's 
quirks (eg. a C compiler may deal better with a kind of loop than 
another C compiler, and it adds up; Java's advantage here is that since 
one mostly uses Sun's compiler, quirks are far less obvious).
>
> I think you should really try it out yourself. Just download Eclipse and the JDK and write a small programm in it. I mean I have used KDevelop and C++ myself for years, but when I was forced to make the switch to Java, it really opened my eyes. There are so many techniques and features that make software development so much easier under Java. Like design by contract. You specifiy in javadoc the contract for every method (what it expects, what it has to return) and verify it with asserts. Or the toString method that can be added to every class and which will be shown in the debugger. 
>   
I won't deny the power of Eclipse (I used it too) and I do know Java has 
a role; however, I don't think a platform-agnostic desktop is the best 
place to use Java, as it adds a consequent core dependancy . As said in 
another message on that thread, there are hooks for Java in KDE, but 
they are not used because nobody seems interested in using Java here.
> 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.