[Kde-java] KProgressTest program

[Richard Dale]

On Friday 01 March 2002 10:21 am, Kevin Krammer wrote:
> Richard Dale wrote:
> > string concatenation really - can't see the point. Perhaps the best
> > thing is to remove KProcess from the bindings, as there doesn't seem
> > to be anything particularly KDE-specific about starting a process. Is
> > there a Java System.exec() or similar that could be used instead?
>
> There is such a method in java.lang.Runtime
> http://java.sun.com/products/jdk/1.2/docs/api/index.html
>
> Runtime rt = Runtime.getRuntime();
> Process proc = rt.exec(commandString);
Thanks! What I like about Java is that you feel you know it before you've 
written any code. I can guess there'll be something called 'blah blah.exec()' 
somewhere - and sure enough you java experts point out the above example of 
exec(). Which to me looks pretty neat - easier to use than KProcess?

On Friday 01 March 2002 9:50 am, KJ P wrote:
> >particularly KDE-specific about starting a process. Is there a Java
> >System.exec() or similar that could be used instead?
>
> Yes I agree.  What I liked about KProcess was that you could start a
> process and block or not block.  The signals for when a process is finished
> I thought was good as well.  The System.exec() will work of course.
Perhaps we can put some kind of KDE api layer on top of Runtime.exec() with 
slot/signal notification and blocking/unblocking, rather than adapt the C++ 
specific KProcess class.

> >Yes, the Qt examples are a good test for the bindings - I've fixed quite a
> >lot
> >of bugs.
>
> I can tell.  I will be trying them out this weekend.
Good - the more testing the better.. I've got drag and drop working now, so 
KScribble should drag and drop, I think that was the only thing that wasn't 
working properly.

>
> I know it probably means nothing at all but while looking at the code of
> JavaSlot.cpp I thought that instead of testing the index <
> sizeof(javaToQtTypeSignatureMap)/sizeof(*javaToQtTypeSignatureMap) each and
> every time would it not be better to assign the length of the table to a
> variable and test against the variable instead of calculating every time as
> in the following:
>
> const char *
> JavaSlot::javaToQtSlotType(const char * javaTypeSignature, const char *
> signalString)
> {
>    int lenghtOfTable =
> sizeof(javaToQtTypeSignatureMap)/sizeof(*javaToQtTypeSignatureMap)
>
>         for (   unsigned int index = 0;
>                         index < lengthOfTable;
>                         index++ )
>         {
>                 if (    strcmp(javaTypeSignature,
> javaToQtTypeSignatureMap[index][0]) == 0
>                                 && (    signalString == 0
>
> QObject::checkConnectArgs(signalString, (const QObject *) 0,
> javaToQtTypeSignatureMap[index][1]) ) )
>                 {
>                         return javaToQtTypeSignatureMap[index][1];
>                 }
>         }
>
>         // If no matching C++ type signature is found, then just return the
> java one
>         return javaTypeSignature;
> }
>
> I am not taking pot shots at the code it is just something that popped out
> at me while looking.  In c++ maybe it does not mean anything, it is just
> something I try to do in java programs to save some cpu cycles.  As the
> table grows in length this might help.
Pot shots are most welcome - keep reviewing the code!. 

This is an interesting difference between C++ and java arrays. In the C++ 
example 'sizeof(javaToQtTypeSignatureMap)/sizeof(*javaToQtTypeSignatureMap)', 
sizeof() is a compile time thing. So the expression should be evaluated at 
compile time by gcc, and just map onto a constant (maybe I'm wrong and it 
isn't..). In java, array sizes are a runtime thing, which allows it to check 
array bounds at runtime.

On the other hand, I don't believe in optimization without measurement. So to 
justify any change to a working method, I think we should profile the code to 
see if a significant time was spent in JavaSlot::javaToQtSlotType().

-- Richard