xt
发帖数: 17532 | 1 Boolean.getBoolean("true")=false |
c*c
发帖数: 1 | 2 stupid BM, LOL
【在 xt 的大作中提到】
: Boolean.getBoolean("true")=false
|
m******t
发帖数: 2416 | 3
Either you actually have a system property called "true",
or you didn't read the javadoc for Boolean.getBoolean(). 8-)
(I agree it's a badly named API 8-)
【在 xt 的大作中提到】
: Boolean.getBoolean("true")=false
|
t***t
发帖数: 6066 | 4 maybe IBM think only "TRUE" is true, else
is false.
【在 m******t 的大作中提到】
:
: Either you actually have a system property called "true",
: or you didn't read the javadoc for Boolean.getBoolean(). 8-)
: (I agree it's a badly named API 8-)
|
xt
发帖数: 17532 | 5
Nah, it is case insensitive. magicfat is right.
【在 t***t 的大作中提到】
: maybe IBM think only "TRUE" is true, else
: is false.
|
s*********n
发帖数: 13 | 6 hehe, funny. the owner of this snippet must be veli stupid.
【在 xt 的大作中提到】
:
: Nah, it is case insensitive. magicfat is right.
|
F****n
发帖数: 3271 | 7 It must be TERU, and VELI VELI FUNNY, i TINK.
【在 s*********n 的大作中提到】
: hehe, funny. the owner of this snippet must be veli stupid.
|
xt
发帖数: 17532 | 8 class Util {
public boolean compareFile( File f1, File f2 )
{ // Read and compare content of file }
} // end class Util
class Test
{
...
if( !Util.compareFile( f1, f2 ) ) {
System.out.println( "Different" );
}
boolean same = Util.compareFile( f1, f2 );
if( same ) {
System.out.println( "Same" );
}
...
}
Use f1 and f2 pointing 2 identical files
Result:
Different
Same |
c*****t
发帖数: 1879 | 9 Your posted code is impossible since compareFile is not a static
function.
【在 xt 的大作中提到】
: class Util {
: public boolean compareFile( File f1, File f2 )
: { // Read and compare content of file }
: } // end class Util
: class Test
: {
: ...
: if( !Util.compareFile( f1, f2 ) ) {
: System.out.println( "Different" );
: }
|
xt
发帖数: 17532 | 10
OK. Define that method to static and try.
【在 c*****t 的大作中提到】
: Your posted code is impossible since compareFile is not a static
: function.
|
|
|
c*****t
发帖数: 1879 | 11 Maybe you had random function in there :P
Post your real code.
【在 xt 的大作中提到】
:
: OK. Define that method to static and try.
|
xt
发帖数: 17532 | 12
Technically I can't. I ran the debugger into it
and found the function returns true but that if( !...)
got in. So I extracted the return value to a variable
everything becomes normal.
IBM is rubbish
【在 c*****t 的大作中提到】
: Maybe you had random function in there :P
: Post your real code.
|
m******t
发帖数: 2416 | 13
Oh yeah, IBM is not only rubbish but also mind controlling, because evidently
everybody else who uses jikes and dares to write statements as complicated as
"if (!foo())" all got screwed up big time by this rubbish JVM, and yet they
just stayed silent all the time.
8-)
【在 xt 的大作中提到】
:
: Technically I can't. I ran the debugger into it
: and found the function returns true but that if( !...)
: got in. So I extracted the return value to a variable
: everything becomes normal.
: IBM is rubbish
|
xt
发帖数: 17532 | 14
evidently
as
IBM JVM is rubbish, no matter how they boast that they have the best compilers
in the world - which I very much doubt. Compared with IBM, Miscrosoft is much
better and should never be charged under antitrust law.
【在 m******t 的大作中提到】
:
: Oh yeah, IBM is not only rubbish but also mind controlling, because evidently
: everybody else who uses jikes and dares to write statements as complicated as
: "if (!foo())" all got screwed up big time by this rubbish JVM, and yet they
: just stayed silent all the time.
: 8-)
|
xt
发帖数: 17532 | 15
evidently
as
FYI, this is actually a known bug! I don't know if Sun JDK handles it right,
but IBM JDK, which came with my WebSphere, does not handle it right:
Class Util{
public static boolean check( File canonFile, String dirName)
throws SecurityException, IOException
{
File dir = new File( dirName );
if( !dir.isDirectory() ) throw new FileNotFoundException( dirName+ " is not
a directory");
// Find the most recent file in the directory
File[] files = dir.listFiles();
if( files==null || files.l
【在 m******t 的大作中提到】
:
: Oh yeah, IBM is not only rubbish but also mind controlling, because evidently
: everybody else who uses jikes and dares to write statements as complicated as
: "if (!foo())" all got screwed up big time by this rubbish JVM, and yet they
: just stayed silent all the time.
: 8-)
|
m******t
发帖数: 2416 | 16
I think I missed your point in the OP. What exactly is the known bug? Are
you saying jikes has side effects in their file reading methods?
【在 xt 的大作中提到】
:
: evidently
: as
: FYI, this is actually a known bug! I don't know if Sun JDK handles it right,
: but IBM JDK, which came with my WebSphere, does not handle it right:
: Class Util{
: public static boolean check( File canonFile, String dirName)
: throws SecurityException, IOException
: {
: File dir = new File( dirName );
|
xt
发帖数: 17532 | 17
right,
Nothing went wrong with file reading. I tracked with debugger. The bytes
from both files come out identical. In the method, the "return true;" was
reached. It is the complex boolean expression being evaluated wrong in
the if( !... ) line. Frankly after 2 years using the quality products
from IBM, I am still not enjoying any of them.
【在 m******t 的大作中提到】
:
: I think I missed your point in the OP. What exactly is the known bug? Are
: you saying jikes has side effects in their file reading methods?
|
m******t
发帖数: 2416 | 18
Well then I didn't miss your point. So can you reduce this to something like:
boolean foo() { return true; }
if (!foo()) System.out.println("false");
boolean fooRes = foo();
if (fooRes) System.out.println("true");
【在 xt 的大作中提到】
:
: right,
: Nothing went wrong with file reading. I tracked with debugger. The bytes
: from both files come out identical. In the method, the "return true;" was
: reached. It is the complex boolean expression being evaluated wrong in
: the if( !... ) line. Frankly after 2 years using the quality products
: from IBM, I am still not enjoying any of them.
|
xt
发帖数: 17532 | 19
like:
Nah, I don't think IBM is that silly. Actually it works fine on these.
For example, I have never had to use a boolean to store a Vector.isEmpty().
I just don't know why it failed in my case. Maybe it is just too complicated
for that compiler/interpreter to understand. I am also pretty sure
I did not turn on any optimisation, since I am using -g option.
【在 m******t 的大作中提到】
:
: Well then I didn't miss your point. So can you reduce this to something like:
: boolean foo() { return true; }
: if (!foo()) System.out.println("false");
: boolean fooRes = foo();
: if (fooRes) System.out.println("true");
|
st
发帖数: 1685 | 20 your "code" no sense, it has numerous errors...
【在 xt 的大作中提到】
:
: like:
: Nah, I don't think IBM is that silly. Actually it works fine on these.
: For example, I have never had to use a boolean to store a Vector.isEmpty().
: I just don't know why it failed in my case. Maybe it is just too complicated
: for that compiler/interpreter to understand. I am also pretty sure
: I did not turn on any optimisation, since I am using -g option.
|
|
|
m******t
发帖数: 2416 | 21
I thought you said it was a known bug? How can the complexity of the method
you are calling affect the evaluation of the if statement *after* the method
returns?
I'm still suspecting there is some side effects in your check() method. Did
you try swapping the two calls?
【在 xt 的大作中提到】
:
: like:
: Nah, I don't think IBM is that silly. Actually it works fine on these.
: For example, I have never had to use a boolean to store a Vector.isEmpty().
: I just don't know why it failed in my case. Maybe it is just too complicated
: for that compiler/interpreter to understand. I am also pretty sure
: I did not turn on any optimisation, since I am using -g option.
|
v******e
发帖数: 63 | 22 I don't like IBM, but I can't agree with you on this one. Looks like your
check() method is not idempotent. Check this :
boolean check1 = check(arg1, arg2);
boolean check2 = check(arg1, arg2);
System.out.println("check1:" + check1 + " check2:" + check2);
they
not
【在 xt 的大作中提到】
:
: like:
: Nah, I don't think IBM is that silly. Actually it works fine on these.
: For example, I have never had to use a boolean to store a Vector.isEmpty().
: I just don't know why it failed in my case. Maybe it is just too complicated
: for that compiler/interpreter to understand. I am also pretty sure
: I did not turn on any optimisation, since I am using -g option.
|
c*****t
发帖数: 1879 | 23 Jesus, the code doesn't even compile with so many syntax errors.
It also contains semantic errors (second parameter of check is
String, not File).
I guess that you'd better post some real code.
99.99999999% of the time, some bugs you claim that is compiler/JVM
bug, it is in fact of your own fault.
【在 xt 的大作中提到】
:
: like:
: Nah, I don't think IBM is that silly. Actually it works fine on these.
: For example, I have never had to use a boolean to store a Vector.isEmpty().
: I just don't know why it failed in my case. Maybe it is just too complicated
: for that compiler/interpreter to understand. I am also pretty sure
: I did not turn on any optimisation, since I am using -g option.
|
xt
发帖数: 17532 | 24
It is not the orginal source code. Why? The orginal source
code is about 1000 lines long with 2 classes! Also yu
won't be able to compile it anyway. It depends on a large
number of files in classpath.
This time, I am pretty sure it is the JVM that went wrong.
Otherwise how can you explain the fact that after I store
the return value with a variable, it becomes normal?
【在 c*****t 的大作中提到】
: Jesus, the code doesn't even compile with so many syntax errors.
: It also contains semantic errors (second parameter of check is
: String, not File).
: I guess that you'd better post some real code.
: 99.99999999% of the time, some bugs you claim that is compiler/JVM
: bug, it is in fact of your own fault.
|
xt
发帖数: 17532 | 25
I do not know. This is exactly what I have observed with debugger,
after numerous times of failurs for no good reason.
Again, it is IBM. I am not surprised of anything insensible
from them any more. Do you know if you add int with long on
IBM JVM, you are not guaranteed a correct result? Don't tell
me this has been fixed with C more than 20 years ago.
How? I am just giving an example. In my code I have only one line
to call it.
【在 m******t 的大作中提到】
:
: I thought you said it was a known bug? How can the complexity of the method
: you are calling affect the evaluation of the if statement *after* the method
: returns?
: I'm still suspecting there is some side effects in your check() method. Did
: you try swapping the two calls?
|
c*****t
发帖数: 1879 | 26 sigh, did you every get rid of the ! and run the program again?
Your check() maybe suspicious s.t running it again would return
a different result. Also, you may have to close the file.
【在 xt 的大作中提到】
:
: I do not know. This is exactly what I have observed with debugger,
: after numerous times of failurs for no good reason.
: Again, it is IBM. I am not surprised of anything insensible
: from them any more. Do you know if you add int with long on
: IBM JVM, you are not guaranteed a correct result? Don't tell
: me this has been fixed with C more than 20 years ago.
: How? I am just giving an example. In my code I have only one line
: to call it.
|
xt
发帖数: 17532 | 27
OH, I forgot to close the file. haha
Anyway, it is only a test program. I have to write about 5000 lines in 2
weeks. So what can you expect?
I am normally a very defensive programmer. Even my student say I am the
most picky programmer he ever met.
【在 c*****t 的大作中提到】
: sigh, did you every get rid of the ! and run the program again?
: Your check() maybe suspicious s.t running it again would return
: a different result. Also, you may have to close the file.
|
xt
发帖数: 17532 | 28
On 2nd though, I didn't. Here's the method "readFile":
public static byte[] readFile( String fileName ) throws
FileNotFoundException, IOException
{
byte[] buff=null;
// Read in the file content
InputStream in=null;
try{
in = new FileInputStream( fileName );
buff = new byte[in.available()];
in.read( buff );
} finally {
if( in!=null ) {
try{
in.close();
} catch ( Exception e ) {
// Ignore
}
}
}
return buff;
}
【在 c*****t 的大作中提到】
: sigh, did you every get rid of the ! and run the program again?
: Your check() maybe suspicious s.t running it again would return
: a different result. Also, you may have to close the file.
|
c*****t
发帖数: 1879 | 29
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This line could be a problem. in.available() may not necessarily
equal to the file size. You should use File.length() to obtain
the actual file size.
【在 xt 的大作中提到】
:
: On 2nd though, I didn't. Here's the method "readFile":
: public static byte[] readFile( String fileName ) throws
: FileNotFoundException, IOException
: {
: byte[] buff=null;
: // Read in the file content
: InputStream in=null;
: try{
: in = new FileInputStream( fileName );
|
xt
发帖数: 17532 | 30
Right. As long as it works temperarily, who cares. It's only for testing
not a product.
【在 c*****t 的大作中提到】
:
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: This line could be a problem. in.available() may not necessarily
: equal to the file size. You should use File.length() to obtain
: the actual file size.
|
|
|
c*****t
发帖数: 1879 | 31 The thing is that when your code not working, you blame IBM for the
problem, while on the other hand, you used codes don't have the documented
features. Those things just complicate the debugging process.
【在 xt 的大作中提到】
:
: Right. As long as it works temperarily, who cares. It's only for testing
: not a product.
|
x***n
发帖数: 39 | 32 /* Returns true if and only if the system property
* named by the argument exists and is equal to the string
* "true".
*/
the Boolean.getBoolean(String systemPropertyName) tests agains the system
property, not the string itself.
I especially don't appreciate your insulting a company without first check
if that's your own fault (misunderstanding, or ignorance, or the like).
Also, even if this is it's bug, you still need to test it against other JVMs
b
【在 xt 的大作中提到】
: Boolean.getBoolean("true")=false
|
e***g
发帖数: 158 | 33 haha.
but that one is indeed a very bad API. everybody was hit by it.
【在 x***n 的大作中提到】
: /* Returns true if and only if the system property
: * named by the argument exists and is equal to the string
: * "true".
: */
: the Boolean.getBoolean(String systemPropertyName) tests agains the system
: property, not the string itself.
: I especially don't appreciate your insulting a company without first check
: if that's your own fault (misunderstanding, or ignorance, or the like).
: Also, even if this is it's bug, you still need to test it against other JVMs
: b
|
m******t
发帖数: 2416 | 34
//nod I don't usually blame the language or the VM, but as far as this one
is concerned, I think Sun does deserve a few spanks. 8-)
【在 e***g 的大作中提到】
: haha.
: but that one is indeed a very bad API. everybody was hit by it.
|
xt
发帖数: 17532 | 35
So is IBM. Actually the more I use IBM products, the more
I dislike them.
【在 m******t 的大作中提到】
:
: //nod I don't usually blame the language or the VM, but as far as this one
: is concerned, I think Sun does deserve a few spanks. 8-)
|
x***n
发帖数: 39 | 36 Give us the code and we'll debug for u.
【在 xt 的大作中提到】
:
: So is IBM. Actually the more I use IBM products, the more
: I dislike them.
|
xt
发帖数: 17532 | 37
No can do. The related code has a few ten thousand
lines, and it is company property.
Also, my coworkers have once noticed with their
JSP's that IBM java went into both true and false
scopes. They had to literally do
if( isTrue ){}
if (!isTrue ) {}
【在 x***n 的大作中提到】
: Give us the code and we'll debug for u.
|
m******t
发帖数: 2416 | 38 ft, what are you, a paleontologist? 8-)
【在 x***n 的大作中提到】
: Give us the code and we'll debug for u.
|
