avatar
c*c
2
stupid BM, LOL

【在 xt 的大作中提到】
: Boolean.getBoolean("true")=false
avatar
m*t
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
avatar
t*t
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-)

avatar
xt
5

Nah, it is case insensitive. magicfat is right.

【在 t***t 的大作中提到】
: maybe IBM think only "TRUE" is true, else
: is false.

avatar
s*n
6
hehe, funny. the owner of this snippet must be veli stupid.

【在 xt 的大作中提到】
:
: Nah, it is case insensitive. magicfat is right.

avatar
F*n
7
It must be TERU, and VELI VELI FUNNY, i TINK.

【在 s*********n 的大作中提到】
: hehe, funny. the owner of this snippet must be veli stupid.
avatar
xt
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
avatar
c*t
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" );
: }

avatar
xt
10

OK. Define that method to static and try.

【在 c*****t 的大作中提到】
: Your posted code is impossible since compareFile is not a static
: function.

avatar
c*t
11
Maybe you had random function in there :P
Post your real code.

【在 xt 的大作中提到】
:
: OK. Define that method to static and try.

avatar
xt
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.

avatar
m*t
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

avatar
xt
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-)

avatar
xt
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-)

avatar
m*t
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 );

avatar
xt
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?

avatar
m*t
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.

avatar
xt
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");

avatar
st
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.

avatar
m*t
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.

avatar
v*e
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.

avatar
c*t
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.

avatar
xt
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.

avatar
xt
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?

avatar
c*t
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.

avatar
xt
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.

avatar
xt
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.

avatar
c*t
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 );

avatar
xt
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.

avatar
c*t
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.

avatar
x*n
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
avatar
e*g
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

avatar
m*t
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.

avatar
xt
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-)

avatar
x*n
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.

avatar
xt
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.
avatar
m*t
38
ft, what are you, a paleontologist? 8-)

【在 x***n 的大作中提到】
: Give us the code and we'll debug for u.
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。