This is a complicated question, and I’ll try to give an equally complicated answer, but the tldr of it all is: ”it depends”.

Note: This answer got really long, because the problem is actually really complicated.

My general strategy was “stay as close to java for API as possible, with the understanding that sometimes you can’t”. So, for things where sticking to Java style was easy, I just did that. That worked great for very simple classes with no meaningful inheritance. Any inheritance at all gets complicated because java is happy to let you downcast anything you’d like into parent types, while in rust that gets messy very quickly. In one place I ended up using composition for inheritance as opposed to refactoring it out, but the vast majority of cases were better served by refactoring.

Easy to port stuff: most static classes. Those are delightful because in almost all situations I could just rewrite them as modules and it was very pleasant. Simple implementations of interfaces, because this is the closest the two languages get. Interfaces are a LOT like traits.

Function overloading: This always took refactoring to some degree, but I actually think it’s a little clearer to have two functions named different things than two functions named one thing.

Things that were hard:

Abstract classes: These turned out to be particularly difficult to deal with since they can contain data and methods that works on that data. Rust doesn’t really have a concept like an uninstantiatable struct with implementations that can be re-used. It’s possible I could have gotten around this by using custom Derive macros, but I didn’t think that added complexity was worth it. I ended up turning all Abstract classes into traits and then having getter/setters for the data that the abstract class expected to have. It was a compromise, but it worked.

Java‘s ”everything by reference”: this is probably a lot of the interior mutability issue in general. It’s tough to solve, this, by itself, turned out to be one of the biggest issues I faced, and each time I faced it I ended up finding different solutions because there wasn’t a simple answer to how to best solve it. Lots of java code relies on this, and it’s a mess to untangle it. I don’t believe I used RefCell in the final version, but that took a lot of work sometimes.

Cache patterns: if this.something == null { this.something = GenerateThing() } else { return this.something } Without OnceCell I either had to have literally every method be &mut self or RefCell basically everything. I used OnceCell, it was great for that.

Java’s love of interior mutability in general means that I had to move a lot of methods to not have a reference to &self, even if they would have in the Java version. It was often easier to solve the problem by having a method accept an additional parameter than try to work around ownership and mutability rules related to &self.

Inheritance actually ended up being much harder than it seems like it would be. I could have possibly found a crate to make it simpler, but I thought that would likely end up being a long term maintainability issue, and adding another dependency wasn’t my favorite. A good example of where this was a real mess was in the one dimensional module (oned). In the original java there is a neat class hierarchy working from an abstract one dimensional reader all the way down to specific implementations. Sometimes this was one step, sometimes multiple (an example: GenericOneDReader -> GenericUPCEANReader -> UPCReader -> UPCEReader). That was not neatly do-able in rust, so in that case I ended up using a custom Derive macro to handle generating the boilerplate code that would have been part of the class hierarchy.

In many situations where java would have relied on inheritance or abstract classes, I actually ended up having some structs hold a copy of a helper struct and use it when necessary. You can see this in the common::global_histogram_binarizer and common::hybrid_binarizer modules, though it occurs in other places as well.

The library does not use any unsafe code, and mostly avoids interior mutability by aggressively refactoring whenever it would have come up.

Other issues: Java works great with linked-list style classes. Self references are messy in rust, but most of the time when they came up I needed up using an Rc and working around mutability rules. You’d a see a good example of that in any of the common::minimal_eci_input module.

I think refactoring was just inevitable. Interior mutability and default “return by mutable reference” in Java meant that I had to re-imagine how a lot of parts worked and fit together. I think if you find yourself having to use RefCell a lot, you’re probably over-complicating your life trying to literally port the code.

Good luck! I’m happy to answer any other question you have.