This code badly needs a piece of documentation outlining:
* how it differs from Google Guava Collections,
* what are the tradeoffs and performance/memory characteristics of the collection types.
I couldn't find an answer to the question "why would I use this?" — and I am actually looking for collections with certain properties (for Clojure, but it doesn't matter much in my case).
This is old news, it was posted on HN when it was actually released and IIRC at least one comment compared it to Guava, pretty unfavorably from what I recall (too lazy to search for the link atm).
I have no idea whether this code is any good or not (I'm a PM by trade) but in Investment Banking, GS has very much a "build rather than buy" mentality, and I get the impression that techies are treated with more respect than some places.
I have heard from people that have worked there, that one of their main sources of competitive advantage is their bespoke settlements system, Sec DB. Apparently, it models every instrument as an object, and adding new derivatives and instruments is relatively straightforward.
A bunch of senior managers from GS took over the tech organisation of a different bank I was involved with, and one of the first things they did was to start creating a new settlements and trading system, even down to the level of creating their own RDBMS as existing ones didn't do what they wanted.
In most banks, you could get laughed out of the office if you said you needed to write a new RDBMS from scratch.
Show me one large organization that does project automation well. I'm literally not permitted to build my projects with Maven at work (this does seem to be Maven-ized), and I suspect I'm far from the only Java developer in that boat.
Thats scary, so you build the production files out of an IDE? What happens if some developer has a slightly different IDE config? Or the IDE has cached some compiled file that no longer actually compiles due to a change?
Personally I build all my test/stage/production releases on single Jenkins box that does a full clean before building (actually it auto builds off a github hook).
It's okay, because someone else is building the production artifacts and they're using a different tool.
</sarcasm>
I have a Jenkins install on a "found" server (belonged to a project that no longer exists, never gave the server back to infra) so I know my tests pass and my Ant scripts produce good artifacts. Still, it would be nice to step away from Ant and use something requiring less effort (and, could automatically resolve my dependencies, which by the way are a whole other battle).
gs-collections / collections / src / main / java / com / gs / collections / impl / map / strategy / immutable / ImmutableHashingStrategyMapFactoryImpl.java
Never mind...