Memo(English) - JavaDayTokyo - JDT62 - "goldman sucks approach for Java(ゴールドマンサックスのJavaへの取り組み)"

I attended Java day tokyo 2015.
and this time i would like to share short report for
JDT62 - "goldman sucks approach for Java(ゴールドマンサックスのJavaへの取り組み)".

you can see slide from here(Japanese)

Agenda is mainly separated 3 part.
2.GS Collection.
(will try to use GS collection later.)


What kind of system they created?

  • trading
  • accounting
  • platform
  • infrastructure


  • Build solutions to complex problems
  • Self-manufacture.


  • What is the percentage of engineer in the GS?
    • 25%(higher than expected!!)
  • focused on development department

Goldman Sucks <-> Java

  • 1998 Start internal evaluation(社内評価)
  • 2000 Start to use java for internal tools.
  • 2004 Create their own library(old product of GS collection)
  • 2012
    • Become JCP executive committee
    • Publish GS collection as a open source.
  • 2013
    • Selected OCA
    • Start to contribute OpenJDK

JSR contributed by Goldman Sucks.

  • JSR-107:JCACHE
  • JSR-335:Lambda
  • JSR-351:Java Identity API

Scale of Goldman Sucks development.


  • over 3,000 in global.
  • 24/7 development
  • 125,000 process / hour
  • huge application(heap size is over 150GB)
  • opensoruce-nization/contribution
  • use OpenJDK


Why they use OpenJDK?

  • Can access source code.
  • Modify problem and find problem cause by own.
  • Judge the improvement point earlier.
  • Security issue
  • Confirm development process of JDK
  • Bug database

Usage of OpenJDK

  • Trouble shooting(Could modify source code)
  • Research newly function in OpenJDK


  • Their Open Source framework.(2004~)
  • One of biggest their own library for improving java collection implementation.
  • Already supported Java8!!

※ more detail of GS-collections will write another entry.

GS-Collections kata

  • For learning usage of GS-Collections.
  • Pass test code one by one.
  • Over 1,500 Java engineer in GS use this training project.

My Feed Back


  • GS's engineer(of course not all of member) may learn core technology of Java.
  • They have pride for "speed"(e.g) Memory usage of Unified set)
  • They maybe have team for assessing new feature/technology
  • They have sense of ownership for resolving problem.(One of the biggest example is they are using OpenJDK)
  • I'm surprised that GS-collections already supported Java8(Lambda).
    • Internal library support latest version is really important for keeping good development environment.


  • Once created core-library(GS-collection) and they already use this library for many applications.
    • Thats why they must use this library continuously.
    • Compared to Java collections, GS-collections always must be better.
    • Because huge cost is need for abolish GS-collections(but its not problem, its one of their high level challenge).
  • Definitely GS-collections is useful. even though it, it is little bit difficult to use this library in large company(individual is no problem).
    • Learning cost is high, i guess. and if java8's stream statement and GS-collections statement is mixed in one application,its obviously not good code. use GS-Collections in all of collections implementation, this library make huge benefit.
    • But GS is good working place for creating such kind of library by their own.


  • Create internal training shikumi such kind of GS-Collections kata.
  • Internal library should support latest version(e.g.Java8).