Add Eclipse Collections as a dependency.

[itohiro73]

There are couple of open issues I want to consult with @gs-rezaem . Please kindly advise.

• In Add Eclipse Collections as a dependency. #30 , Moh suggested to try getting rid of GSC impl dependency, but there are too many dependencies for FastList/UnifiedSet/UnifiedMap as internal storage, so I left them as is for now.
• In Add Eclipse Collections as a dependency. #30, Moh suggested below for ByteArraySet, but this caused conflict in get(Object) and get(K), also signature conflict in collect(). So I didn't touch this class for now. Please advise how you want to handle this class.

For ByteArraySet, extend the EC UnifiedSetWithHS and implement GSC MutableMap.

• MithraFastList and AdhocFastList extend FastList. Please advise how you want to handle these classes.
• AbstractDatedCache.MatchAllAsOfDatesProcedureForMany#getResult() returns FastList. Please advise how you want to handle this.
• MasterSyncResult#getBuffers() returns FastList. Please advise how you want to handle this.
• MithraCompositeList#getLists() returns FastList. Please advise how you want to handle this.
• AsOfEqualityChecker#getMsiPool() returns UnifiedMap. Please advise how you want to handle this.
• ConcurrentIntObjectHashMap#parallelForEachValue() takes List<IntObjectProcedure<V>> in its signature. Introducing EC equivalent method would cause same erasure issue. Please advise how you want to handle this.
• ListFactory has couple of create() methods that return FixedSizeList. We can either have GSC version or EC version for this class. Making it EC version may cause wide impact as it's used widely in reladomo. Please advise how you want to handle this class.

[gs-rezaem]

I think replacing the internal usages is pretty important because it'll flush out some of the interactions with the pseudo-public methods (see below) that you're having trouble with.

For ByteArraySet, use the same solution as primitives: create a new one and deprecate the old. Use the com.gs.reladomo.util package for the new one.

The other methods you've listed is what I would call "pseudo-public". Convert all of them to EC.

[itohiro73]

Thanks @gs-rezaem for your comment! It is very helpful.

I've added a commit to replace GSC impl with EC impl. Now only 3 impl usages are left after the change. Because of these, we still cannot get rid of GSC lib dependency itself.

• ListAbstract.jsp for asGscList()
• AggregateList#getAttributeAsGscIntSet(String) that constructs IntHashSet in it
• Old ByteArraySet that implements GSC UnifiedSetWithHashingStrategy.

FYI, along with converting GSC impl to EC, I've optimized imports as well, so it may look more changes than necessary in imports.

Please let me know for further comments or suggestions.

[itohiro73]

Fixed issues in hiroshi_ito.dco commit.

• Fix file name typo: hiroshi_ito.cdo => hiroshi_ito.dco
• Fix missing replacement: <your name>.dco => hiroshi_ito.dco

[gs-rezaem]

asGscList is in the generated code and it's optional, so it's not a real dependency.
The other two are so rare in production, that I wonder if people would mind fixing a couple of places in their code when upgrading.
Can you put together a guide to changing a project over from GSC to EC? I can think of two steps:

• replace imports
• replace asGscList with asEcList

[itohiro73]

Sure, let me put together a guide.

As for two remaining GSC dependencies, do you want me to get rid of them or leave them as is for now?

[gs-rezaem]

Let's remove the two.

[itohiro73]

Now all GSC impl dependencies have been removed 👍.

I added a guide (GSC_TO_EC_MIGRATION_GUIDE.md) to migrate from GSC to EC, too. I'd assume there is going to be a link to this guide from CHANGELOG.md as part of 1.7.0 release.

Please let me know for any feedback.

[donraab]

I think this should be
Replace com.gs.collections.* imports with org.eclipse.collections.* in your code

[itohiro73]

@donraab Good catch! I'll fix it.

[itohiro73]

Fixed!

[gs-rezaem]

Merged with some minor changes. Thanks for this huge piece of work 😄