Collections name conflict with standard library about functionaljava

[tonymorris]

Why would anyone use standard java collections? What is the use-case for such a thing?

[MikhailGolubtsov]

Given a real world project with a modestly big codebase there are tons of usages of standard java collections. It's not easy to turn them all in fj structures in one step. And even if it is possible there are certain APIs with standard collections usage that cannot be changed but should be implemented. So I wish FJ were more friendly in its naming.

[techtangents]

Yeah, standard java collections are mutable, therefore impractical. Many
of us come to fj realising this and trying to improve things. So, fj
code will mix with java collections frequently.

I don't use fj in my main project, but have developed a very similar
library. List is the big one. We called it ConsList. I've also used a
prefix of Im for Immutable in other structures.

I fully understand your pain, but I really don't think it's practical to
rename classes in fj. It would break pretty much all fj users.

That leaves a few options:

1. In your code, try and only use either java.util collections or fj
   collections within the one class.
2. Qualified imports. Pick which will be qualified (fj or java.util) and
   try to be consistent throughout your project.
3. Tweak your IDE settings so that fj collections will be imported, but
   java.util ones won't
4. Push hard to refactor your code to the fj collections.
5. Fork fj.

If only java had type aliases - you could import a module of aliases and
use those names instead.

[MikhailGolubtsov]

@techtangents Thank you for your advice. Refactoring all the things seems too hard for me. Also it would not be nice to bother my team with additional restrictions. I'd rather fork fj.

[mperry]

Unfortunately the names class with the Java standard library. This puts up artificial barriers to using the library for new users.

Personally, I'd like to rename all the classes that clash (in particular List, Set, Stream, HashMap, HashSet, TreeMap, Writer, Class) but I don't think we should force people using the library to handle the change.

I am supportive of a fork or branch that does this, but fear that it won't be maintained.