Develop Reference

Buffered Writer occasionally creates symbols rather than numbers

So I have a program that collects a bunch of data and continuously concatenates the data into a string with a single white space between each entry. During my close routine I print the String into a txt file using buffered writer. About 50% of the time the data shows up as (mostly) Chinese symbols. Is the VM doing some weird Unicode stuff? Why does this only occur sometimes?
I've looked around on other forums and have not seen other instances of this problem. None of the other CS majors I know understand what is happening.
EDIT : the data is all integer numbers ranging 0-1365;
UPDATE: upon further research I found this which makes me think a may need a PrintStream rather than a BufferedWriter can anyone speak to that? I tested the PrintStream and I will not be able to construct it with a FileWriter as I would a BufferedWriter which means I need more research to write to my txt.
UPDATE: printing to the console does not make this error occur. I will accept an answer that explains way Notepad (the program I am using to open the txt) sometimes displays numbers and sometimes displays symbols.
Here is the relevant code:
//fields
private static BufferedWriter out;
private File saveFile;
String data;
//inside constructor
this.saveFile = new File("C:\\Users\\HPlaptop\\Desktop\\MouseData.txt");
this.saveFile.delete();
try{this.saveFile.createNewFile();}
catch (IOException e ){System.out.println("File creation error");}
try {out = new BufferedWriter(new FileWriter("C:\\Users\\HPlaptop\\Desktop\\MouseData.txt"));}
catch (IOException e) {System.out.println("IO Error");}
this.control.addWindowListener(new WindowAdapter()
{
public void windowClosing(WindowEvent e)
{ //there is a method call here but the basics are below
out.write(data);
out.close();
System.exit(0);
}
});
Here is an example data set printed correctly:
1365 767 1365 767 1365 767 1364 767 1353 756 1268 692 1114 604 980 488 812 334 744 283 694 244 593 150 473 81 328 13 207 0 124 0 115 0 102 0 99 6 107 13 132 20 173 32 187 31 190 25 194 20 201 17 215 14 221 10 224 7 224 7 224 7 226 6 226 6 226 6 226 6 226 6 226 6 226 6
This data set was taken seconds later and is not what I want
㐀ㄹ㈠㤰㐠㔸㈠㈱㐠㠶㈠㐱㐠㘲㈠㘰㌠㠷ㄠ㔹㌠㌳ㄠ㌹㈠㘹㈠㄰㈠㠷㈠㜳㈠㐶㈠㐷㈠㐶㈠㔷㈠㌶㈠㔵㈠㐵㈠㠰㈠㤴ㄠ㔲㈠㤴㐠‶㐲‹㌱㈠㘴〠㈠㘴〠㈠㘴〠㈠㜴〠㈠㠴〠㈠㠴〠㈠㜴㠠㈠㔴ㄠ‶㐲‵㤱㈠㔴ㄠ‹㐲‵㠱㈠㜴ㄠ‶㐲‹ㄱ㈠〵ㄠ‰㔲‰〱

The BufferedWriter is not making an error and the code is correct except for
the redundancy of using
this.saveFile.delete();
try{this.saveFile.createNewFile();}
catch (IOException e ){System.out.println("File creation error");}
and
new FileWriter
The error in reading the data occurs when the file is opened. The depending on what program opens the data different results are displayed because of the way the software reads the data. Notepad was displaying symbols because it interpreted the numbers as ASCII. The console did not try to interpret the data and just displayed what was written to it. Using a program that does not try to interpret the numbers in the file will allow the data to be viewed correctly.

Since you did not provide and example of what data you write into the stream, you are probably experiencing the bush hid the facts phenomenon.

Are there any benchmarks comparing Java 8 Streams to Guava Iterables?

I'm happy enough with Guava on Java 8 - are there any performance benefits or pitfalls in migrating to Streams for sequential code?

I've started a project on GitHub to play with this.
Initial results are surprisingly positive for Streams - for an identity map over strings, Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) on 2014 MacBookAir 1.7Ghz i7, code version https://github.com/dmcg/iterables-v-streams#ea8498ee0627fc59834001a837fa92fba4bcf47ebcf47e
Experiment selection:
Benchmark Methods: [guava, iterate, streams]
Instruments: [allocation, runtime]
User parameters: {}
Virtual machines: [default]
Selection type: Full cartesian product
This selection yields 6 experiments.
Trial Report (1 of 6):
Experiment {instrument=allocation, benchmarkMethod=iterate, vm=default, parameters={}}
Results:
bytes(B): min=4072.00, 1st qu.=4072.00, median=4072.00, mean=4072.00, 3rd qu.=4072.00, max=4072.00
objects: min=3.00, 1st qu.=3.00, median=3.00, mean=3.00, 3rd qu.=3.00, max=3.00
Trial Report (2 of 6):
Experiment {instrument=allocation, benchmarkMethod=guava, vm=default, parameters={}}
Results:
bytes(B): min=15104.00, 1st qu.=15104.00, median=15104.00, mean=15104.00, 3rd qu.=15104.00, max=15104.00
objects: min=17.00, 1st qu.=17.00, median=17.00, mean=17.00, 3rd qu.=17.00, max=17.00
Trial Report (3 of 6):
Experiment {instrument=allocation, benchmarkMethod=streams, vm=default, parameters={}}
Results:
bytes(B): min=15272.00, 1st qu.=15272.00, median=15272.00, mean=15527.64, 3rd qu.=15432.00, max=17252.80
objects: min=20.00, 1st qu.=20.00, median=20.00, mean=25.00, 3rd qu.=26.00, max=53.00
Trial Report (4 of 6):
Experiment {instrument=runtime, benchmarkMethod=guava, vm=default, parameters={}}
Results:
runtime(ns): min=13365.32, 1st qu.=13660.61, median=13802.51, mean=13961.91, 3rd qu.=14445.46, max=14715.34
Trial Report (5 of 6):
Experiment {instrument=runtime, benchmarkMethod=iterate, vm=default, parameters={}}
Results:
runtime(ns): min=9952.47, 1st qu.=10892.64, median=11372.35, mean=11243.07, 3rd qu.=11785.48, max=12024.76
Trial Report (6 of 6):
Experiment {instrument=runtime, benchmarkMethod=streams, vm=default, parameters={}}
Results:
runtime(ns): min=10527.26, 1st qu.=11051.70, median=11747.29, mean=11631.15, 3rd qu.=12205.97, max=12581.39
Collected 81 measurements from:
2 instrument(s)
2 virtual machine(s)
3 benchmark(s)
Execution complete: 1.188 min.
Results have been uploaded. View them at: https://microbenchmarks.appspot.com/runs/d2c7f83b-2cfa-4217-ab0b-e8d506eaa85c
I'm still getting my head around Google calipers, but it seems to suggest that Streams are faster than Guava, and not much slower than a straight for loop.

java profile tool without gui

Is there a java profile tool that works without a GUI in Linux, just like top? I don't have the permission to use tools like jprofile and jvisualvm to work in remote model.

Try this: http://java.sun.com/developer/technicalArticles/Programming/HPROF.html You can query heap and cpu details.

You can use HPROF.
Command used: javac -J-agentlib:hprof=cpu=samples Hello.java
CPU SAMPLES BEGIN (total = 126) Fri Oct 22 12:12:14 2004
rank self accum count trace method
1 53.17% 53.17% 67 300027 java.util.zip.ZipFile.getEntry
2 17.46% 70.63% 22 300135 java.util.zip.ZipFile.getNextEntry
3 5.56% 76.19% 7 300111 java.lang.ClassLoader.defineClass2
4 3.97% 80.16% 5 300140 java.io.UnixFileSystem.list
5 2.38% 82.54% 3 300149 java.lang.Shutdown.halt0
6 1.59% 84.13% 2 300136 java.util.zip.ZipEntry.initFields
7 1.59% 85.71% 2 300138 java.lang.String.substring
8 1.59% 87.30% 2 300026 java.util.zip.ZipFile.open
9 0.79% 88.10% 1 300118 com.sun.tools.javac.code.Type$ErrorType.<init>
10 0.79% 88.89% 1 300134 java.util.zip.ZipFile.ensureOpen

How to analyze the performance of a Java Class without actually running it?

We need to implement an application for evaluating results of an online programming challenge. The users will implement the programming challenge and compile their source through a web interface. We are supposed to compile the submitted sources on the fly and present some statistics of the program like expected memory consumption and possible performance indicators of the sources. Does anybody know how can we gather memory consumption and performance indicators of the program statically from the sources?

While you could possibly do static analysis of the source to infer performance characteristics, I suspect it would be far simpler to just run a JUnit test suite over the code.
If you can present your challenge as a code stub or interface, you should be able to create a suitable JUnit suite which validates correctness and tests performance.
Granted, JUnit may not be the best way of running performance tests but you can likely bend it to the task. Alternatively you could look at JMeter or something similar.

Found something very useful. I am not sure if this is what I am looking for. I am yet to analyse the results. But this is quite interesting.
We can gather some performance statistics using the HPROF profiler agent shipped with the JDK release. The good thing is that it can be run during the compilation to produce some interesting statistics on the code beign compiled. Following are some samples. More details can be found at http://download.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/tooldescr.html#gbluz
$ javac -J-agentlib:hprof=heap=sites Hello.java
SITES BEGIN (ordered by live bytes) Wed Oct 4 13:13:42 2006
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
1 44.13% 44.13% 1117360 13967 1117360 13967 301926 java.util.zip.ZipEntry
2 8.83% 52.95% 223472 13967 223472 13967 301927 com.sun.tools.javac.util.List
3 5.18% 58.13% 131088 1 131088 1 300996 byte[]
4 5.18% 63.31% 131088 1 131088 1 300995 com.sun.tools.javac.util.Name[]
$ javac -J-agentlib:hprof=heap=dump Hello.java
HEAP DUMP BEGIN (39793 objects, 2628264 bytes) Wed Oct 4 13:54:03 2006
ROOT 50000114 (kind=<thread>, id=200002, trace=300000)
ROOT 50000006 (kind=<JNI global ref>, id=8, trace=300000)
ROOT 50008c6f (kind=<Java stack>, thread=200000, frame=5)
:
CLS 50000006 (name=java.lang.annotation.Annotation, trace=300000)
loader 90000001
OBJ 50000114 (sz=96, trace=300001, class=java.lang.Thread#50000106)
name 50000116
group 50008c6c
contextClassLoader 50008c53
inheritedAccessControlContext 50008c79
blockerLock 50000115
OBJ 50008c6c (sz=48, trace=300000, class=java.lang.ThreadGroup#50000068)
name 50008c7d
threads 50008c7c
groups 50008c7b
ARR 50008c6f (sz=16, trace=300000, nelems=1,
elem type=java.lang.String[]#5000008e)
[0] 500007a5
CLS 5000008e (name=java.lang.String[], trace=300000)
super 50000012
loader 90000001
:
HEAP DUMP END
$ javac -J-agentlib:hprof=cpu=times Hello.java
CPU TIME (ms) BEGIN (total = 2082665289) Wed oct 4 13:43:42 2006
rank self accum count trace method
1 3.70% 3.70% 1 311243 com.sun.tools.javac.Main.compile
2 3.64% 7.34% 1 311242 com.sun.tools.javac.main.Main.compile
3 3.64% 10.97% 1 311241 com.sun.tools.javac.main.Main.compile
4 3.11% 14.08% 1 311173 com.sun.tools.javac.main.JavaCompiler.compile
5 2.54% 16.62% 8 306183 com.sun.tools.javac.jvm.ClassReader.listAll
6 2.53% 19.15% 36 306182 com.sun.tools.javac.jvm.ClassReader.list
7 2.03% 21.18% 1 307195 com.sun.tools.javac.comp.Enter.main
8 2.03% 23.21% 1 307194 com.sun.tools.javac.comp.Enter.complete
9 1.68% 24.90% 1 306392 com.sun.tools.javac.comp.Enter.classEnter
10 1.68% 26.58% 1 306388 com.sun.tools.javac.comp.Enter.classEnter
...
CPU TIME (ms) END

Binary files differ but not to JVM?

I'm having an issue where org.apache.commons.io.FileUtils.copyFile(File, File) is producing slightly different files. When I compare these files with bsdiff or in an editor, I can tell they're different. Certain bytes are being copied as question marks. For example 0200 (octal) is being copied as ? (077 octal).
So, I create a test case to include in a bug report. I make a copy of the executable, and then compare using FileUtils.checksumCRC32(File). Unexpectedly, the files have the same checksum. I then compare them by iterating through a FileInputStream of each file. This also asserts that the files are the same.
The files certainly differ. One runs, the other doesn't. bsdiff produces a diff of the two files. I can tell that certain bytes are being copied wrong by inspecting the files with my eyes.
However, to the JVM these files are the same. Any ideas of why I'm observing this behavior?
System info:
Windows 7, 64 bit; JVM 1.6.0_22, 32 bit

Eh, sorry everyone. Maven was 'filtering' the executable, which changed the encoding before copying it to maven's 'target' directory. Then FileUtils was correctly copying the messed up executable from 'target' to the destination. I was comparing the version in my source directory to the one in the destination.

This program writes every possible byte and reads them back in again. If the files were being corrupted how would Java turn those bytes back into their original values. i.e. how could it tell that 077 is 0200 and not 077.
byte[] bytes = new byte[256];
for(int i=0;i<256;i++)
bytes[i] = (byte) i;
FileUtils.writeByteArrayToFile(new File("tmp.dat"), bytes);
byte[] bytes2 = FileUtils.readFileToByteArray(new File("tmp.dat"));
System.out.println("equals "+Arrays.equals(bytes, bytes2));
a dump of the file shows.
od -x tmp.dat
0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000020 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
0000040 2120 2322 2524 2726 2928 2b2a 2d2c 2f2e
0000060 3130 3332 3534 3736 3938 3b3a 3d3c 3f3e
0000100 4140 4342 4544 4746 4948 4b4a 4d4c 4f4e
0000120 5150 5352 5554 5756 5958 5b5a 5d5c 5f5e
0000140 6160 6362 6564 6766 6968 6b6a 6d6c 6f6e
0000160 7170 7372 7574 7776 7978 7b7a 7d7c 7f7e
0000200 8180 8382 8584 8786 8988 8b8a 8d8c 8f8e
0000220 9190 9392 9594 9796 9998 9b9a 9d9c 9f9e
0000240 a1a0 a3a2 a5a4 a7a6 a9a8 abaa adac afae
0000260 b1b0 b3b2 b5b4 b7b6 b9b8 bbba bdbc bfbe
0000300 c1c0 c3c2 c5c4 c7c6 c9c8 cbca cdcc cfce
0000320 d1d0 d3d2 d5d4 d7d6 d9d8 dbda dddc dfde
0000340 e1e0 e3e2 e5e4 e7e6 e9e8 ebea edec efee
0000360 f1f0 f3f2 f5f4 f7f6 f9f8 fbfa fdfc fffe