Please don't use 16.0, but rather 16.2
After a very lengthy time between releases, we are happy to announce that v16.0 of graphql-java is now available.
It adds new capabilities based on updated graphql specification and as usual a mix of bug fixes and performance improvements.
#2015 Repeatable directives support
The graphql specification now allows repeated directives on an element. This adds support for this. The is a breaking change because now there can be more than 1 directives for a given name and this was not true prior to this release.
#2079 Support in DataFetchingFieldSelectionSet for Unions and Interfaces
We have revamped the DataFetchingFieldSelectionSet so that it can handle non concrete types such as Unions. This is a breaking change but it significantly increases the ability to look ahead at all "possible" field selections and hence allow you to
do your own data retrieval optimisations even better.
#2093 Makes a default data fetcher exception handler possible
It is now easier to customise the data fetcher exception handler, without requiring you to instantiate your own execution strategies.
More schema validation
The validation code that ensures the schema conforms to specification has been improved. We have more SDL based validation and also we have post schema building validation to ensure types are specification compliant.
#2013 Persistent query support
We have added more code to help better support persistent queries. This includes basic implementations of the Apollo pattern for nominating persistent queries via query input extensions.
#2086 Use Immutable collections to avoid memory copying
As we worked towards releasing v16.0 we decided to attack the immutability of the objects
used in the code base. We reasoned that Immutable data structures would be more reliable
and they MAY be faster as less list / map copying needs to happen in order to pass
data around.
One thing that graphql-java does a lot of is pass a lot of lists and maps around. A graphql
engine is by specification a giant list and map generator.
We reasoned that because Immutable collections can do tricks when copying data (if its already immutable it can just no-op the copy)
then this may favour our code base.
List<Foo> fooList = ImmutableList.of("a","b","c");
//
// no actual copying takes place in this classes because
// the list is an immutable collection already
//
List<Foo> copiedFooList = ImmutableList.copyOf(fooList);
Benchmarks of the code confirmed this to be faster and also reduce memory pressure..
Performance improvements and memory pressure improvements
We have a lot of performance improvements in this release. Some of them are significant improvements for systems at high scale.
#2008 changed the error holder class
#2019 Faster Property fetching with derived classes
#2020 pre-sizing internal data structures
#2067 Support for Streams and Iterators
#2074 avoiding allocations in FieldCollectorParameters and MergedField
#2086 Use Immutable collections to avoid memory copying
#2023 ExecutionStepInfo optimisations to make it more performant