关于Eclipse中可变Java变量的警告

Question

I'm interested in moving toward more functional constructs in Java, and was wondering if there was a way in Eclipse to have it warn if I have mutable local variables, parameters, class members, etc. That way, I could gently migrate code as I'm refactoring, and be nudged in that direction as I write new code as well.

I realize that's not all there is to FP, but would at least be a start.

Thanks.

Answer 1

In my experience, you can get fairly far with the final declaration, regardless of your IDE.

public class ImmutableThing {
  private final int someInt;
  private final String aString;
}

The idea here is that you set these once in the constructor, say, and then never touch them again. (You could provide setter methods, which are more clear, but convey the unwanted notion that this object is mutable.) Eclipse, IntelliJ, etc. should notice the final declaration and naturally tell you when you have code trying to muck with these things when it shouldn't. (I forget whether they will tell you if you've declared a final instance variable and provided no way to set it.)

One curveball to watch out for will of course be objects whose fields can be changed without changing the value of the field in your ImmutableThing :

    private final List<String> strs; // Hmm.

You can set up the strs in the constructor as above, but that List 's contents can of course be changed, so that's no good. In general, any mutable object inside an object you want to be immutable will have this problem. You can get around this in the case of Collections (probably the most common mutable objects) by using unmodifiable collections:

    strs = Collections.unmodifiableList<String>(initList);

or by using third-party versions, such as from Guava:

    strs = ImmutableList<String>.of ("x", "y", "z");

Other objects might provide immutability features; they might not. This feature availability will likely shape how far you get with this paradigm. Generally speaking, you can get pretty far with immutable data objects, and not very far with innately stateful things like streams and connection pools.

Answer 2

Got a wild hair over Xmas vacation, and decided to play with a parser, to be able to get a list of places that could benefit from final . Found javaparser.org, and got the following code running as a simple start, that I hope to build on, going forward:

import java.io.File;
import java.io.FileNotFoundException;

import org.apache.commons.io.FileUtils;
import org.apache.commons.io.filefilter.DirectoryFileFilter;
import org.apache.commons.io.filefilter.RegexFileFilter;

import com.github.javaparser.JavaParser;
import com.github.javaparser.ast.CompilationUnit;
import com.github.javaparser.ast.Modifier;
import com.github.javaparser.ast.body.FieldDeclaration;

public class JavaFPMain {

    public static void main(String[] args) throws Exception {
        JavaFPMain fpApp = new JavaFPMain();
        fpApp.run();
    }

    private void run() throws Exception {
        File projectDir = new File(...);
        FileUtils.listFiles(projectDir, new RegexFileFilter(".*.java"), DirectoryFileFilter.DIRECTORY)
            .stream()
            .forEach(this::parseFile);

        System.out.println("done");
    }

    private void parseFile(final File fi) {
        try {
            CompilationUnit compilationUnit = JavaParser.parse(fi);

            String AUTOWIRED = "Autowired";
            compilationUnit.getNodesByType(FieldDeclaration.class).stream()
                .filter(f -> !f.getModifiers().contains(Modifier.FINAL) &&
                             !containsAnnotation(f, AUTOWIRED))
                .forEach(f -> System.out.println("missing final: " + fi.getAbsolutePath() + "(" + f.getBegin().get().line + ") " + f.getVariable(0).getNameAsString()));
        } catch (FileNotFoundException ex) {
            throw new RuntimeException(ex);
        }
    }

    private boolean containsAnnotation(FieldDeclaration f, String name) {
        return f.getAnnotations()
                .stream()
                .anyMatch(a -> a.getNameAsString().equals(name));
    }

}

And yes, I get just short of 6,000 lines of output from this, which means that I have my work cut out for me, should I choose to pursue this. And that's not including parameters that should be made final , objects that are still modifiable, etc. But again, it's a place to start.