为什么变量的范围有问题？

Question

Can someone please help identify what is the issue with the below code... and why is there a problem in compiling for the variable "i$"

Below is the code....

private void handlePendingFilesForPreviousCheckpoints(Map<Long, List<String>> pendingFilesPerCheckpoint) {
        LOG.debug("Moving pending files to final location on restore.");
        Set<Long> pastCheckpointIds = pendingFilesPerCheckpoint.keySet();
        Iterator i$ = pastCheckpointIds.iterator();

        while(i$.hasNext()) {
            Long pastCheckpointId = (Long)i$.next();
            Iterator i$ = ((List)pendingFilesPerCheckpoint.get(pastCheckpointId)).iterator();

            while(i$.hasNext()) {
                String filename = (String)i$.next();
                Path finalPath = new Path(filename);
                Path pendingPath = this.getPendingPathFor(finalPath);

                try {
                    if(this.fs.exists(pendingPath)) {
                        LOG.debug("Restoring BucketingSink State: Moving pending file {} to final location after complete checkpoint {}.", pendingPath, pastCheckpointId);
                        this.fs.rename(pendingPath, finalPath);
                    }
                } catch (IOException var10) {
                    LOG.error("Restoring BucketingSink State: Error while renaming pending file {} to final path {}: {}", new Object[]{pendingPath, finalPath, var10});
                    throw new RuntimeException("Error while renaming pending file " + pendingPath + " to final path " + finalPath, var10);
                }
            }
        }

    }

Even though the i$ is defined inside curly braces second time... it says, the variable i$ is already defined in the scope....

Can someone please help me fix this... and understand what is wrong with the variable i$ in the above code.

Thanks a lot.

Answer 1

The scope of a variable is the (entire) block in which it's defined, which of course includes all sub-blocks within the declaring block.

To fix the problem, use different variable names.

Answer 2

You commented this:

but wondering, why this is creating problem... as i copied this method from other class and that is working fine... but mine is creating problem.... can you please explain

OK what you actually did is that you decompiled a class and copied the decompiled code into your source code.

That approach often doesn't work. And yours is an example where it hasn't worked.

The design goals for a typical Java decompiler is to translate compiled code into something that a programmer can read . The decompiled code above satisfies this. A typical Java programmer reading the above will understand what the original code was trying to do.

However there are a couple of non-goals for a decompiler:

1. It is NOT a goal to reproduce the original source code. (It is mathematically impossible to do that!)

2. It is NOT a goal to produce code that is "best practice" in style. That is impractical for a number of reasons. (For a start, people can't agree on what best practice is!)

3. In is NOT a goal to produce code that is always compilable. It might be possible for bytecodes that haven't been obfuscated, but:

   • it is really hard to cover the edge cases,
   • it is impossible to prove that you have covered all of the edge cases
   • and the set of compilers whose code you need to support is growing all of the time.

---

What does this mean in practice?

In practice code that is generated by a decompiler is generally ¹ readable, and may be compilable, but:

• you may need to correct compilation errors
• the code is not as maintainable as the original source code ²
• the code is not suitable for use as an example of how to program.

---

^{1 - However, if the bytecodes have been obfuscated, all bets are off. The purpose of obfuscation is to make it difficult to decompile code and / or understand the decompiled code.}

^{2 - For a start, when you compile code, the compiler discards all source code comments and (typically) the names of local variables. Then it transforms various constructs such as enhanced loops, inner classes and lambdas into simpler forms that the JVM supports. These transformations are not reversible.}

Answer 3

A simple (but possibly not the best) solution is to just call the inner iterator something else like ir or something.

Ex. Change this line: Iterator i$ = ((List)pendingFilesPerCheckpoint.get(pastCheckpointId)).iterator();

to something like this: Iterator ir = ((List)pendingFilesPerCheckpoint.get(pastCheckpointId)).iterator();