Treating an integer as a boolean in Java

I'm working on updating an old Java application to work on modern operating systems and I've run into an error that I can't figure out. I don't have much experience with Java but from what I've read, you can't store boolean values in an integer (1 or 0) like in C++.

Here's the bit of code where the error is:

  public static double a(cr paramcr, int paramInt) {
    double d = 0.0D;
    int i = ++b;
    if (b <= l.length()) {
      if (paramInt < 0) {
        int j = b; // <----------- defined again as an integer.
        d = e();
        if (e == true && d >= h && d + f - g >= 1.0D && d + f - g <= d) {
          String str1 = String.valueOf((int)d);
          d = d + f - g;
          String str2 = String.valueOf((int)d);
          l = a(j, l, str1, str2, i);
        } else if (j == false) { // <---------------------------- error
          if (((d < 1.0D || d > d) ? false : true) == false)
            c = 7; 
        }

With error message:

The operator == is undefined for the argument type(s) int, boolean

The variable j is defined as a static boolean at the top of the program, but later redefined as an integer inside of this 'a' class. I notice that there are other integer variables being used to compare to true and false statements in this class, but they are all being compared to some condition in order to get a true or false result. That's obviously not the case here, and my problem is that I can't think of a way that this program would have ever functioned in the past if this is how it was written. Any ideas as to why this could be or suggestions on my next move?

It doesn't help that none of this has any documentation or intuitive variable names.

In Java you cannot treat an int as a boolean. Period.

> I was sent some files that I was told contained the source code. It did not. I was then told to decompile it.

What you are apparently looking at is some code that has been decompiled from a ".class" file. Decompilation is NOT guaranteed to produce valid (compilable) Java source code. And in this case, it appears that it hasn't. Indeed, there are clues in that code that imply that the original bytecodes were obfuscated ... to deliberately make it hard for the decompiler to generate readable / valid Java source code.

(The problem is that the same bytecodes are used dealing with boolean and integer types up to int. In this case, the decompiler has assumed that the local variable is an int, and not been able to figure out that its assumption was incorrect. A better decompiler might be able to figure it out ...)

So what you will need to do is figure out how to modify that (not-really-Java) code to make it 1) compilable, and 2) do the correct thing¹.

> It doesn't help that none of this has any documentation or intuitive variable names.

Well ... that what happens when you try to use decompiled code. All local variable names and comments (including javadocs) are discarded by the compiler, and the decompiler has no way to reconstruct them.

The alternative is to go back to the people who were supposed to give you the source code and ask them to provide it to you ... for real!

^{1 - This assumes that you can figure out what this method is really supposed to be doing. I don't think we can help you with that. For a start, it would probably be necessary to read the disassembled bytecodes to figure out what the code really does.}

"updating an old Java application to work on modern operating systems" already is nonsense. The operating system of a JAVA application is JAVA. "Platform independence" is core functionality of JAVA applications. I would refuse the task already at this point.

I really hate it when you can't use int like bool but it's not rocket science to replace "==false" by "==0" and "==true" by "!=0".