I think you have a few options:
- Put a test in on a static final constant (e.g. a boolean), which conditionally executes the the visual interface code. The JVM will eliminate the dead code when you set the constant to "off", and your code will be fully optimised. The downside is, of course, that you can only switch this at compile time, but this may be fine if you actually want to build two copies of the library.
- Add an extra parameter to the function that determines whether the visual interface is called, and test this where necessary in your algorithm. This will add a small amount of runtime overhead, but may well be acceptable. I suggest you benchmark this, in my experience though such tests on a local variable are usually sufficiently cheap that you can get away with it (in CPU terms, will probably be just a register test which is likely to be even cheaper than the cost of a single memory access into an int[] array...)
- Use a higher level / meta-language to express the algorithms, and use code-generation techniques to generate the actual code you need (with or without). I've done stuff like this in Clojure, for example. It's also an option to generate bytecode directly with tools like ASM (if all you care about is execution, and don't need the Java source code).
- Use a textual pre-processor. It should work fine for Java code generation (as it does for C/C++), though it's not such a common approach and you may find it a bit fragile. You may need to do some clever stuff like generating different class names in the file system etc.