Walsh graham

Greenhorn
+ Follow
since Apr 10, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Walsh graham

hi,

could anybody give me any pointers on how to do this;

I have a JTree with various nodes.Each node actually corresponds to a matrix ( N * N) of data. When the Jtree is initially visible the user will see just N1, N2, N3 eetc... *unexpanded*. However when they expand the node N1, N2 etc they will be displayed a table/matrix of data.

Could anybody let me know what I need to look at in JTree. Is JTree the right component here? As usual demo code is always very welcome.

thanks much and have a great day

Graham
12 years ago
I would agree with the reply from Ankit Garg. "Java Threads" by Scott Oaks and Henry Wong is quite good for threads. I reccommend it.

Have a nice day
yes. Object A, B and C exist. A is the caller. B and C contain methods syncB() and syncC() which are both synchronized. This it is possible for A to call syncB() and syncC(), holding locks for B and C at the same time.

G
you know, I might just do that
12 years ago
Hi Hi,

thanks for the reply. There's no real problem at all, I'm just toying with theory and curious to hear peoples opinions on ArrayCopy vs looping. All is actually good for a change!

have a nice day.

G
12 years ago
thanks for the reply. I could google it but if you know any good articles that outline the why and how about these 1.6 improvements, I'll definitely check them out.

thanks and have a nice day

Graham
12 years ago

Hi Hi,

the text below is from the following link;

http://java.sun.com/developer/technicalArticles/Programming/Performance/

"Native methods are really fast.
This sounds silly, but I had heard that the overhead of invoking a native method was so high that it might be the case that small Java methods would be faster. Not! In my test case, I implemented System.arraycopy in plain Java. I then compared this using arrays of different sizes against System.arraycopy . The native (original) method was about an order of magnitude faster, depending on the array size. The native-method overhead may be high, but they're still fast compared to interpreting byte code. If you can use native methods in the JDK, then you can remain 100% pure and have a faster implementation than if you used interpreted methods to accomplish the same thing. "


Ive tested this using some very basic java code, I have only used code like this to do timing;

long startTime = java.lang.System.currentTimeMillis();

so its not real CPU time (I'm on jdk 1.4 and so I don't have access to the new ThreadMXBean interface and features provided for measuring CPU time.


Anyways, I'm seeing that within the debugger there are significant differences (arrayCopy is about 15 times faster). Its under debugger control so this timing doesn't really count. I was encouraged however and went straight to the command line to test outside the debugger.

At the command line, the results show no differences. They both take more or less the same time.

So my questions are;

1) If I measure using real CPU time, can I expect to see greater performance with the System.ArrayCopy approach?
2) I'm compiling under eclipse and I'm not sure if debug versus non-debug mode differences are in place. I can't see where in eclipse I should specify "-g:non" when compiling. I understand eclipse uses its own internal javac compiler. Thus, I'd like to know how to specify a non-debug build (if that makes sense).

thanks for any input.

G

Outside



12 years ago
Hi,

Im about to put a GUI around some data we use. We're running jdk 1.4.

The data is a matrix of dates and doubles (its actually a volatility matrix). I need a control such that when clicked, the matrix is expacnded so the dates/values can be seen. By default the data is not visible ( a minus sign indicates that the data is not expanded). When clicked, the minus sign expands into the matrix (a little like directories when navigating windows).

could anybody tell me what control I should be using? Do I need to download some custom control or is it available in the swing toolbox? I had a look and can't see anything that stands out.

thanks for any info.

Graham
12 years ago
Hi,

Im writing a function thats returning a N dimensional array and I'm doing it wrong.. I know there's a better way to do it;

Here's what I'm doing now (and I know its filthy)

foo[][] getIt()
{

List fooList= new ArrayList();

// assume someOtherFooList is a list containing foo[]'s
// i.e. ita list of array's of foos
// And no, I cannot just create a foo[][] from the someOtherFooList, I've simplified the logic to
// get the right answer to my question

for (int i =0; i<someOtherFooList.size(); ++i)
{
fooList.add(someOtherFooList.get(i);
}

foo[][] retval = new foo[fooList.length];

for (int i2=0; i2 < fooList.length; ++i2)
{
foo[i2] = fooList.get(i2);
}

return retval;

}
12 years ago
Hi Hi,

nearly, but not quite. Remember we create Thread objects in various ways, one of them is via an implementation of the Runnable interface. Once created we call start() on the *Thread* object, not an implementation of the Runnable interface. If you remove the "start()" method from your code, the compiler will rightly complain.

You can check the threads created with something like this;

System.out.println("Thread: " + Thread.currentThread().getName());

hope this helps
Hi Asha,

I posted a reply to this earlier but it hasn't appeared, if you see two replies from me on this then its due to a delay somewhere along the line.

From what I can see you have 2 choices;

1) Does openSession return a value? If yes, test the return value and exit from your run method, thereby exiting the thread.

2) if 1) isn't possible then have openSession throw an exception. Catch the exception in your run method below and return from run(). For info, openSession sounds like it catches the CORBA exception but does nothing with it. Maybe rethrow the exception and catch it in the method below.

For info, 2) is probably the option you need here.

public void run() {
try {
// some code for getting the corba object
obj_ref.openSession(user, password); // This is where i am getting org.omg.CORBA.COMM_FAILURE
pingT = new pingTask(sessionRef, Thread.currentThread());
timer.schedule(pingT, 10000, 3*1000);

} catch (InterruptedException e){
log.warn( "Interrupted explicitly ..", e);
} catch (CORBAException ce)
{
logg.error ("CORBA connection problem: " + ce.ToString());
return;
} catch (Exception e){
log.error("Exception in run method", e);//
} finally {
timer.cancel();
// Some code here for cleanup
}

}
Hi Hi,

delighted your're up and running.


make that boolean flag volatile to be safe. You've nothing to lose except register storage and it could save you a lot of debugging in months to come if somebody modifies/misuses your code. If performance is a huge part of your applications requirements (and I mean HUGE ), then check before making it volatile.

have a nice day

Graham

Hi,

try putting the break statement in this try/catch. You're testing isInterrupted AFTER its been interrupted... I think...




try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
BREAK; // HERE

}


so by the time you get here...

//stop1();
if(Thread.interrupted())
{
System.out.println("Thread stoopped");
break;
}


you're no longer interrupted.

let me know if this helps

Naga Niranjan wrote:Komal,

Check my modifications to your code. I think it will solve your problem.



Thanks,
Niranjan

Hi Hi,

If youre relatively new to Java Threading but know java, then I reccommend Java Threads by Scott Oaks and Henry Wong (O Reilly publish it). I bought it last week. Its not going to get you writing NASA rocket mission critical threaded applications but it will definitely give you the basis you need and protect you from making classic threading gaffs.

They incorporate swing code into the examples which was a mistake, SWING is completly irrelevant to the principles of threading in Java (ok, swing code uses threads but after that there is no relevance to MT coding). Its easy reading and if you're at home with swing then you'll probably dig this book. I'd give it a 7/10 based on what I've read of it so far.

have a nice weekend