Sev Zaslavsky

Greenhorn
+ Follow
since Nov 19, 2008
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 Sev Zaslavsky

I'm considering writing an application that will potentially have hundreds of threads instantiated, although only a handful of them will be runnable/running at any moment.

Can anyone comment on the performance impact of having many many threads that are sleeping?
Seems like there are at least 3 approaches:

1. Call "tar" using one of the flavors of java.lang.Runtime.exec() . Note that this might not be portable. Joe Ess alluded how to get a "tar" that runs on windows
2. Find a tar library written in java and code against it. Here is something I found on Google search that alludes to such a library http://bugs.gentoo.org/show_bug.cgi?id=75343
3. Instear of tar, use jar for which java has built-in support. zip/unzip utilities are tiny in size in relation to the archives that you'll be making. This might be the path of least effort.

Which do you like best?
[ November 26, 2008: Message edited by: Sev Zaslavsky ]
12 years ago
The problem is here - you're calling in.read(b) twice



try this code I fixed up a little, but don't forget to change ip address

12 years ago
Vijay, what do you mean by "in use"? Is it the same as "cannot be written?" java.io.File class has some methods for determining the status of files.
12 years ago
Rob, you're suggesting that Amir change his code to redirect System.setOut and System.setErr to a file on disk?

Amir, it seems you are looking for a way to echo the IDE console output to a file? In that case you're looking for some kind of setting in Netbeans or Eclipse?
12 years ago
Agree with Rob, you need the flush() and a close()on the client.

But I think the problem might be on the server. It appears you are detecting an EOF by looking for an exception at "in.read(b)" - it might be better to check for return value -1. Maybe the exception is causing some non-deterministic or simply unexpected behavior.
12 years ago
All along it has been hammered into my head that in java, characters are Unicode and they occupy 2 bytes, but it seems as if FileWriter does not fully agree.

So I tried something basic - I wrote the little program below to write a character and read it back. Based on the output of the "dir" command in Vista, it seems that it's writing one byte, not two as I expected. I even tried using the PrintWriter instead and I get the same result. Also any characters beyond \u007F seem to be written and read back as Ascii 63.

Can anyone explain whats going on here?

import java.io.*;
class Writer2 {
public static void main(String [] args) {
char[] in = new char[50]; // to store input
int size = 0;
try {
File file = new File( "fileWrite2.txt");
FileWriter fw = new FileWriter(file);
fw.write('\u0100');
fw.flush();
fw.close();
FileReader fr = new FileReader(file);
size = fr.read(in);
System.out.print(size + " "); // how many bytes read
for(char c : in) // print the array
{
System.out.println(c + "<->" + Integer.toString(c));
}
fr.close(); // again, always close
} catch(IOException e) { }
}
}
12 years ago