|
Hi,
some comments:
1.
you should implement error handling in your code; have a try-catch and log the exception.
2.
when an exception occurs, it gives the number of the offending line; that is where the problem shows itself, the actual cause may be somewhat sooner.
3.
when the exception occurs in a method call, check the documentation for that method to see what it has to say about the specific exception. That should tell you exactly what is wrong.
4.
Your searchForFile() method is a bit silly, it tells whether a file exists, but when it does, it does not tell you where it is. A better definition of it would return the path to the first occurence it finds as a string.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
What is the result of running the following? If it is exception then post the entire stack trace.
File file1=new File("C:\\");
System.out.println("exists=" + file1.exists());
|
|
|
|
|
This works for me.
As someone else has pointed out, file1.listFiles() may return null so you need to allow for that.
|
|
|
|
|
I am reduced to "someone else".
The best things in life are not things.
|
|
|
|
|
Hi all,
I am having one small doubt. If string is a immutable class then how come it is allow us change ? ex: String s1="abc"; s1="def"; Sop(s1); it gives op as :- def. does it mean we have made changes on string object ? please tell me.
Thanks
************ S G KORE *******************
|
|
|
|
|
"abc" and "def" are strings.
s1 is not a string, it is a variable holding a reference to a string. at first it refers to "abc", later on it refers to "def".
The string "abc" never got modified, it may still be alive (kept alive by another reference, as in the example below), or it is dead and garbage collectible.
string s1="abc";
string s2=s1;
s1="def";
Sop(s1);
Sop(s2);
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Thank you Luc Pattyn. Now I got clear picture .
************ S G KORE *******************
|
|
|
|
|
In addition to the above comment, what I suggest you is that try to draw a picture in a paper while you work on Object types & references so that you will always know what you are doing and have the right picture in your mind. It is very helpful, even in Arrays and Memory Allocations
|
|
|
|
|
I want to develope a desktop application in java which has TCP client on desktop.It connect to the server.And whenever TCP server sends message to this client,an alert(like balloon tip in windows) should appeared on my desktop where my application is running.This alert is timed alert.It should disappear after 3 seconds.
I am new to java so any help will be appreciated.
|
|
|
|
|
1. Learn basics of java
2. Learn GUI programming
3. Learn threads, including but not limited to timers.
4. Learn sockets programming
5. Create server
6. Create client.
|
|
|
|
|
Good answer.
The best things in life are not things.
|
|
|
|
|
yes, a fine, and precise answer.
But I'd like to give him a hint too: How to Make Dialogs @ oracle.com[^]. Combine this with the threads[^] that jschell talked about and you'll have your "Desktop notification".
...because we all started somehow & somewhere too.
regards
Torsten
I never finish anyth...
|
|
|
|
|
Hello guys,
I have to write an in-place version of Merge-Sort which works on doubly linked lists for university.
This wouldn't be the problem, but there are a few conditions to meet.
- the algo must work in-place (additional memory usage in O(log n))
- I cannot create new list elements or entire lists, just copies (ListElement left = new List Element() isn't possible but ListElement left = first is possible)
- the algo should be recursive, but this is not necessary
- each call of the algo must return a head pointer to the first element of the sub-list
- the merge part must also return a head pointer
public DoublyLinkedList mergesort(DoublyLinkedList in, int numOfElements) {
if (numOfElements > 1) {
DoublyLinkedList firstLeft = in;
DoublyLinkedList firstRight = in;
for ( int i = 0; i < numOfElements / 2; i++ ) {
firstRight.first = firstRight.first.next;
}
DoublyLinkedList left = mergesort ( firstLeft, (int)Math.floor(numOfElements / 2 ) );
DoublyLinkedList right = mergesort ( firstRight, (int)Math.ceil(numOfElements / 2 ) );
return merge ( left, right );
} else {
return in;
}
}
My problem is that I'm somehow stuck right at the beginning. The algo itself shouldn't be the problem, but the additional conditions make the whole thing quite difficult for me.
Of course I've already searched for useful algos or something, but I didn't find anything.
Thanks in advance for your help and best wishes,
Manfred
|
|
|
|
|
Coincidentally, I have to do the exact same thing. I believe recursion might be the most efficient, good thing you've already started it that way. The code you have looks simple/efficient. HOWEVER, it looks like you followed the algorithm given to you in the "Skriptum".
Through some searching without using the keyword "pseudocode", I came across this very descriptive page which I have yet to take the time to fully comprehend (http://www.chiark.greenend.org.uk/~sgtatham/algorithms/listsort.html)
|
|
|
|
|
In the meantime I wrote a fully working recursive implementation. However, I'm now working on an iterative version, because I'm not that fan of recursion for performance reasons.
|
|
|
|
|
I hope your iterative version has a less than linear auxiliary space requirement.
|
|
|
|
|
It has, but if I execute the program, I get an MAC error message "Segmentation fault".
I got this one time with the recursive version, but the next run finished without any errors?
Does anyone know what can cause this error, a simple Java program shouldn't do this.
|
|
|
|
|
This is really an interesting Assingment. Ive worked with MergeSort but I didnt have the Idea before that it could be effectivly implemented with DoublyLinked Lists. I would give this a try. I hope you guys will help me also
P.S. I want to implement this in C++ with Stack. I think Stack here can do a lot of work
do you have any pseudocode, so I start it easily.
|
|
|
|
|
I'm gonna write you down a few lines the next days, but at the moment I'm quite busy.
|
|
|
|
|
Indeed, a doubly linked list can make this easy, but I can already imagine it working with a singly linked list. Any idea if having a cyclical list would be of any advantage over an acyclical one?
|
|
|
|
|
In my opinion it's not an advantage for the algorithm. It can be an advantage when dealing with the data structure itself. However, if you split the list, you have to reconnect the first to the last element of the sub-list and vice versa. It's also not that easy to check whether you reached the last element, cause you need help pointers or something similar.
|
|
|
|
|
aghhh, I can't get it finished
I've been spending on it my whole day. Hey Manfr3d maybe you can help me with your version-code?
|
|
|
|
|
OK, here is a pseudo code version of my implementation.
DLL mergesort ( DLL in, int n ) {
check for special cases and handle them separately: in == null, n == 0; n == 1; n == 2 => rearrange if necessary
m = floor ( n / 2 )
get first and last elements of left and right sub-lists: f.e. with a for-loop then the left first is the element pointed at by the list head, the right last is the previous of this,
last left and first right are at position m and m+1
wrap around left and right sub-lists
mergesort ( in, m, first left )
first left = in.first
mergesort ( in, n-m, first right )
first right = in.first
merge ( first left, first right )
return in
}
mergesort ( DLL in, LE first, int n ) {
as the mergesort function above, except that the trivial case n == 1 must be handled, because this is the break condition for the recursion
if n == 1 => in.first = first
this function also calls the 3-argument version of mergesort
all list elements must be addressed via the first one, not via the head, the head is just needed for the trivial case to connect the single LE to it
recursive calls and merge as above
return
}
merge (DLL in, LE first left, LE first right, int n ) {
first decide if the first element is of the left or the right sub-list, connect it to the head and move one step fwd in the sub-list
finished = f
counter = 1
while ( counter < n && !finished ) {
if next element is of left sub-list and it is not the first one => connect it to the sorted list, move fwd one step
else if next element is of right sub-list => same for right sub-list
else if the beginning of one sub-list is reached again => connect the other one to the sorted list, finished = t
move one step fwd in sorted list so that you are at the current end
counter++
}
return
}
I know that this looks somehow quick and dirty, but if you have any questions feel free to ask.
|
|
|
|
|
I asked for little and you gave me a lot of help. I really have to thank you. Im gonna end this assigmend coz it has already spend a lot of my time. Ill give this Pseudocode a try and see what happens. I hope its functional.
So I immediatly have a question. Im a little confuzed here:
"
mergesort ( DLL in, LE first, int n ) { // in: head, first: first list element, n: number of elements
as the mergesort function above, except that the trivial case n == 1 must be handled, because this is the break condition for the recursion
if n == 1 => in.first = first // in.first means the first element of the list
this function also calls the 3-argument version of mergesort // the 2-argument version is just the entry point
all list elements must be addressed via the first one, not via the head, the head is just needed for the trivial case to connect the single LE to it
recursive calls and merge as above
return
}
"
This is very roughly written. I suerly need more explanation on this .Thnx again
|
|
|
|
|
This function is nearly the same as the above one. However, the 2-argument version (I will call it ms2 from now on, and the 3-argument version ms3) was just the, one could say, "standardized interface" that must be used. ms2 calls ms3 like it is the same function. You could also call ms3 just once within ms2, resulting in one more level on the call stack. The implementations of the functions are equal, except for the fact, that the head in ms3 is just used as a return value, which isn't returned at all, because it is accessible in the caller, even if modified. All copies, pointers and auxiliary LEs are assigned referring to the first element. This consumes less time, and is easier in my opinion, even though I wouldn't say that it's impossible without this additional parameter.
And of course the trivial case must be caught in ms3 to end the recursion, which isn't necessary in ms2.
|
|
|
|
|