This is a bugfix release to address mainly the following things:

#1102: This fixes mutation when used with the batched data loader instrumentation.
#1090: This fixes chained instrumentation.
#1072: Not consistent exception handling across strategies

The full list of changes can be found here:
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A9.1+is%3Aclosed

Data Loader performance has been greatly improved

The performance of graphql.execution.instrumentation.dataloader.DataLoaderDispatcherInstrumentation has been greatly improved. It now tracks which fields are outstanding and how many values are expected for that field. This allows it to optimise when it "dispatches" the underlying data loaders so that they retrieve as much data as possible in one call.

PR: https://github.com/graphql-java/graphql-java/pull/990

Directive Wiring Support

The new graphql.schema.idl.SchemaDirectiveWiring interface allows you to wire in new behaviour to the SDL built graphql schema via directives that are placed on SDL types and fields.

For example imagine a type such as the following

    directive @auth(role : String!) on FIELD_DEFINITION

    type Employee
        id : ID
        name : String!
        startDate : String!
        salary : Float @auth(role : "manager")
    }

You can now wire in data fetcher behaviours that enforce the authorisation access to those specific fields.

PR: https://github.com/graphql-java/graphql-java/pull/1001

Directives MUST be declared in the schema

If you use a directive in the schema, you now MUST declare it up front and on what places it can apply. This is required by the graphql specification. eg:

 directive @length(max: Int = -1) on FIELD_DEFINITION | INPUT_FIELD_DEFINITION

There is an boolean flag that allows you to use the old lenient behaviour but its off by default.

PR: https://github.com/graphql-java/graphql-java/pull/1006

PropertyDataFetcher has been optimised

The default and most called data fetcher graphql.schema.PropertyDataFetcher has been optimised to make it run faster. It now caches method look ups so that the costs of reflection is not paid over and over

PR: https://github.com/graphql-java/graphql-java/pull/1013

@Defer support is no longer experiemental

It is now considered a supported operation in graphql-java.

PR: https://github.com/graphql-java/graphql-java/pull/1035

New Traverser for analyzing queries:

QueryTraverser is a new traverser for Documents (or part of it) which tracks at the same time the type
informations of the Schema. It is intended to be used for advanced use-cases including libraries build on top of graphql-java.

PR: https://github.com/graphql-java/graphql-java/pull/1031

More

See the following Pull Requests for more information on other changes v9.0

• https://github.com/graphql-java/graphql-java/pulls?utf8=%E2%9C%93&q=+is%3Apr+milestone%3A9.0+

This release contains a number of fixes, enhancements and breaking changes.

The list of breaking changes can be found here

Extend all the SDL types

The graphql SDL specification has finally hit master at Facebook and graphql-java has reflected this.

https://github.com/facebook/graphql/blob/master/spec/Section%203%20--%20Type%20System.md

One new capability is that you can now extend all the different types not just Object types, which includes Interfaces, Unions, Enums, Scalars and Input Objects.

interface NamedEntity {
  name: String
}

interface ValuedEntity {
  value: Int
}

type Person implements NamedEntity {
  name: String
  age: Int
}

type Business implements NamedEntity & ValuedEntity {
  name: String
  value: Int
  employeeCount: Int
}

extend interface NamedEntity {
  nickname: String
}

extend type Person {
  nickname: String
}

extend type Business {
  nickname: String
}

See:

#933
#935
#941
#945

Directives on runtime types

You can specify directives during SDL type definition and these have now been captured and transferred to the graphql runtime types.

So for example given

type Person implements NamedEntity {
  name: String 
  age: Int
  wage : Int @security(role:"manager")
}

The special directive security will be made available on the wage field.

 GraphQLDirective securityDirective = personType.getField("wage).getDirective("security")

See

#924
#923

Instrumentation

The graphql.execution.instrumentation.Instrumentation SPI has been significantly changed. graphql-java uses an asynchronous model to execute a query and Instrumentation and InstrumentationContext has been changed to reflect that.

The signature of the methods have been changed to reflect that instrumentation callbacks now happen in two phases. The first is when the engine first dispatches an operation step and then again when it asynchronously completes.

public interface InstrumentationContext<T> {
    /**
     * This is invoked when the instrumentation step is initially dispatched
     *
     * @param result the result of the step as a completable future
     */
    void onDispatched(CompletableFuture<T> result);

    /**
     * This is invoked when the instrumentation step is fully completed
     *
     * @param result the result of the step (which may be null)
     * @param t      this exception will be non null if an exception was thrown during the step
     */
    void onCompleted(T result, Throwable t);
}

This is a breaking change to code that has implemented Instrumentation. You will have to change the code to implement this double callback pattern.

See #894

@fetch directive has been added to SDL

You can now specify an alternative name to fetch property values from during SDL type declaration

type Invoice {
          id : ID
          invoiceDate : String @fetch(from:"whenInvoiced")
 }

This allows indirection between the names you want to use in a graphql schema and the backing Java data
without having to write this mapping logic into all your data fetchers.

Experimental support for deferred execution

You can now support a deferred execution of parts of a query via @defer directive.
(This is an experimental feature, it is currently not part of the official spec.)

https://github.com/graphql-java/graphql-java/pull/967

The ability to have more than one error per field

The graphql spec is not super clear on whether multiple errors are allowed per field during execution. The previous code took the approach that they are not. However a re-interpretation of the specification reveals that is only true for null field checks.

So the restriction has been lifted and you can have multiple errors per field (except for null checks during execution)

See
#895

Performance improvements during type look up

Our friends from Intuit have contributed a series fo fix to help with the performance of the graphql-java engine during schema type look up, which happens a lot during the execution of a query.

See #898

graphql.execution.batched.BatchedExecutionStrategy has been deprecated

graphql.execution.batched.BatchedExecutionStrategy has been deprecated as an execution strategy.

It does not follow the graphql specification correctly and it has challenges on deeply nested queries with stack overflows being possible. While it remains in the code base, it may be removed at a later time.

See : #965

Other changes and fixes

The rest of the PRs for 8.0 can be found by following this link

https://github.com/graphql-java/graphql-java/pulls?utf8=%E2%9C%93&q=is%3Apr+milestone%3A8.0+

This release contains a number of fixes and enhancements

The schema diff now reports additions

This will report not just API breaking changes but additions (new fields / arguments etc..) as well

See #870

The root object of the subscription is correctly returned

The original subscription support didn't not send back the top level field which was contrary to the graphql specification. This is now fixed

See #850

Input types can now have field visibility

You can now used field visibility to decide what fields are available on input types as well as output types

see #854

Other changes

• #847
• #851
• #853
• #854
• #855
• #857
• #859
• #862
• #864
• #866
• #863
• #867
• #869
• #872
• #883

This release includes several improvements and bug fixes.

Subscription support

The big ticket item of 6.0 is support for graphql subscriptions. A subscription is a stream of results sent out by applying a graphql query over changing results.

This explains more : http://graphql.org/blog/subscriptions-in-graphql-and-relay/ in a general sense.

The graphql-java support is based on returning a reactive stream of ExecutionResult. Each time something changes on the subscription a new ExecutionResult is sent down to the Subscriber.

Systems like RxJava have support for the http://www.reactive-streams.org/ interfaces and with Java 9 you can write trivial adaptors to turn reactive stream Subscribers into Java 9 Flow.Subscriberss

See #754

Performance of Data Loader

The efficiency of data loader has be improved. Before it was too eager is calling dispatch which meant that lists of data cause early dispatches. The code has improved to handle this and the data loader batching is delayed into the last possible moment, greatly increasing the batching efficiency

See #764

Validation problems are now errors not exceptions

In line with the reference graphql-js implementation, validation and coercion problems are reported as errors and not exceptions.

See #789

Tracing Support now has parsing and validation timings

The Apollo Tracing spec was updated to include timings for parsing and validation and this is now reflected correctly.

See #784

API enhancements

A small API enhancement to make it easier to use the TypeResolution class as well as the ability to override the exceptions from the query complexity checkers.

There is also more data available via the TypeResolutionEnvironment class.

There is also a new AsyncDataFetcher to help compose asynchronous data fetchers.

See #774
See #778
See #795
See #798

Other fixes include

• #765
• #762
• #788
• #805

This release includes several bugfixes and improvements.

Dataloader support

The most important strategic change is #704: We now include java-dataloader as a direct dependency to make it as easy as possible to tackle performance issues during complex queries.

This also means java-dataloader is now a first class citizen in the graphql java world and will be maintained and improved on the same level as graphql-java.

Breaking change

We also reverted an older change to be graphql specification compliant again regarding InputObjects variables: #750. We expect that some users may have a problem with that. Please open an Issue if that is the case and we will find a solution.

Other improvements

Other notable changes are:

#690: pluggable field validation
#735: DataFetcher factories to allow for better IoC support of data fetchers
#745: diff two schemas
#747: Fix validation of non-null Interface member
#738: more logging of query execution
#708: allow different directives on the same field
#678, #696, #697 : Batched ExecutionStrategy fixes
#681: Support for primitive arrays as a return value for Lists
#679: Support for Iterables for as a return value for Lists

For a full list of issus/PR see here.

This is bugfix release containing these changes:

https://github.com/graphql-java/graphql-java/milestone/8?closed=1

This release is a bugfix release for 4.0 with one single PR:

#666: the new QueryTraversal class didn't work with mutations or subscriptions.

Please see here for the full 4.0 release notes: https://github.com/graphql-java/graphql-java/releases/tag/v4.0

Note: 4.2 is the newest 4.x version

Thanks a lot to all contributors for reporting bugs, giving feedback, fixing bugs, adding new features and more!

Major New features:

#590
This is the biggest enhancement to come to graphql-java in a long time. Query execution is now performed in a fully asynchronous manner. A DataFetcher is now able to return a CompletionStage<Object> background promise to data and the graphql-java engine will ensure that when it completes it will be placed into the correct place in the query results.

This allows you to use facilities like java 8's CompletableFuture.supplyAsync() to run many data fetchers in parallel, which should improve the speed of your system by fully utilizing all your available CPUs.

All of the provided ExecutionStrategy implementations now support fully asynchronous results. Note if you have your own derived ExecutionStrategy then the method signatures have been modified and are described below in the breaking changes section.

#577
New TracingInstrumentation has been added that tracks how long each field takes to execute. This is reported back on the ExecutionResult extensions field and gives you insight into how you graphql-java server is performing.

This tracing support follows the proposed Apollo Tracing specification https://github.com/apollographql/apollo-tracing which can then be viewed via their Optics performance monitoring tooling : https://www.apollodata.com/optics/

#641
You can now control the visibility of selected fields in the schema. A GraphqlFieldVisibility implementation can be attached to a schema that decide on what fields will be made visible to queries and introspection. This allows you to say restrict the view of the schema for different classes of users say.

#625
java.util.Optional is now supported as a return value from data fetchers and will be collapsed into either an object or the null value in graphql terms.

#618 #575 #560
Instrumentation was enhanced significantly to with an extra method when an ExecutionStrategy is entered and exited. It also allows you to intercept DataFetchers and results and hence inject new behaviour into the running system.

#616
The error messages for argument validation have been improved and better tells you went wrong and in more detail.

#650
You can now store extra meta data on GraphqlError objects that can be sent back to your client code

#552
The ExecutionResult object now has a toSpecification() method that gives you back and object that 100% complies with the graphql specification.

#449
There is now "path" support when running queries. Errors contain the path to which field was in error in a structured specified by the graphql specification and DataFetchers also get this path information.

#467 #470 #468
Schema IDL has been improved. Any additional types defined in schema IDL are now included into the build GraphqSchema object as expected, deprecation is now supported via IDL files and the build runtime type objects contain the original AST definitions.

List of breaking changes:

#593:

• The Instrumentation callback is now one method (with two parameters) instead of two methods.

#590 #380 #542 #487:

• ExecutionStrategy has been refactored by several PRs but it affects only custom strategies.
  Main changes are cleaned up parameters and support of CompletableFuture.

#550:

• ExecutionStrategy.handleDataFetchingException is removed: Instead a delegate DataFetcherExceptionHandler is used to handle Exceptions.

#211 #456 :

• An explicit root Object is added which is available to DataFetchers and is the source for the first level DataFetcher. Before that context was used for that purpose. Note: GraphQL.execute(String query, Object context) is still compatible to avoid unexpected bugs.

• The arguments objects for the Instrumentation are renamed to make them more clear: E.g. DataFetchParameters -> InstrumentationDataFetchParameters

#455:

• The overall scalar error logic was changed a bit. See this PR for details.

#427:

• By supporting the null literal the result of not providing an argument to a field was changed: not providing an arguments results in a arguments Map (for the DataFetcher) with no key in it and providing the null literal results in a Java null values.

#660:

• removes the deprecated methods for the Relay support.

Full List of changes:

See here for the full list of all changes.

This is our biggest release yet, with exciting new features, but also with breaking changes.

A big thanks to all contributors! A lot of them are not directly mentioned here, but every comment or Issue makes this project better.

The most fundamental change is that graphql-java requires now Java 8. Java 6 or Java 7 is no longer supported. (#359)

The biggest new feature is that we now offer a second way to define a schema (#386).

Breaking Changes

• #395: TypeResolver:
  The TypeResolver Interface was changed from getType(Object object) to getType(TypeResolutionEnvironment environment). The object previously directly passed is now available as TypeResolutionEnvironment.getObject().

• #398: GraphQLSchema:
  GraphQLSchema.getDictionary() was renamed to getAdditonalTypes()

• #400: Type References:
  GraphQLObject.reference(), GraphQLInterfaceType.reference() and GraphQLInputObjectType.reference() has been removed: Instead instantiate a new GraphQLTypeReference().

• #401 FieldCollector:
  The FieldCollector class is now clearly marked as an internal class and was changed. It is very unlikely that you used this class. If you did: please open an Issue to adress your use case.

Changes:

• #353 fix null error handling (by @bbakerman)
• #359 Change to Java 8
• #358 Support for user defined subscription type (by @vaant)
• #360 type param and misc. for relay types (by @Jimexist)
• #368 TypeReferences resolved for interfaces and unions (by @kaqqao)
• #361 use java 8 base64 features (by @Jimexist)
• #370 retain comments in the parsed document (by @bbakerman)
• #371 link a runtime object back to its possible definition (by @bbakerman)
• #378 too many tokens are allowed as valid (by @bbakerman)
• #386 Adds the ability to compile and build executable schemas (by @bbakerman)
• #387 Allow ExecutionStrategy to specify dataFetchingExceptionHandler (by @corydolphin)
• #388 ast printer support (by @bbakerman)
• #391 Fix handling of UnknownFragment (by @corydolphin )
• #392 Add fragment definitions and execution id to DataFetchingEnvironment (by @apottere)
• #395 Improved TypeResolver (by @kaqqao)
• #401 have the ability to know and capture all fields in a data fetcher (by @bbakerman)
• #411 make it more clear what internal vs public API is
• #418 do not overwrite top level schema definition during type registry merge (by @kaseyreed)
• #422 Add environment to field instrumentation. (by @apottere)
• #429 Improve wrong type exception (by @dh94)

Changes:

• #149 PropertyDataFetcher supports AutoValue style classes by @iancw
• #249 Passing input object as a resolved class doesn't work by @yrashk
• #261 GraphQL Java should use generics where possible by @bbakerman
• #266 Allow customized Relay cursor prefix by @Jimexist
• #267 Extract relay classes to interfaces and implementations by @Jimexist
• #270 Add instrumentation to the execution of the graphql query by @bbakerman
• #273 GraphQL object should use Builder pattern like the schema objects by @bbakerman
• #276 Use builder pattern in GraphQL top level object by @bbakerman
• #279 Add unique query idenitifer by @bbakerman
• #287 Spec allows for 'extensions' map in result but graphql-java does not by @sean-brandt
• #293 Allows an ExecutionProvider to be provided by the caller by @bbakerman
• #301 DataFetchingEnvironment as an interface by @bbakerman
• #311 More fluent description of the schema by @bbakerman
• #315 Lenient numerical scalars by @bbakerman
• #318 Coercing should be Coercing<I, O> by @dminkovsky
• #322 Validation for lone anonymous operation by @exbe
• #323 Validate name field matches current spec's conventions by @deruf
• #326, #327 Increasing test coverage by @delki8
• #341 PropertyDataFetcherTest throwing exception by @goodav
• #347 Make property and field data fetcher generic by @bbakerman
• #349 Mutations are optional and errors should come back if they are missing by @bbakerman
• #354 Get message returns the error's message rather then toString() by @guy120494

Big thanks to all contributors!

Info: This is last release supporting Java 6. The next release will require Java 8 and will probably contain other breaking changes. (Version 3)

Release highlights

• #172 Allow TypeReference as InputType with check for non-circular references by @kaqqao
• #225 Removed ANTLR compile dependency from POM by @IamCornholio (with help from @foragerr)
• #238 4. parses as FloatValue by @pcarrier
• #156 ValuesResolver fixes for input object literals and variable values by @trevor-morris
• #244 Support for integer-valued ID fields @dminkovsky (reported by @warbit)
• #190 Directive argument name check against directive instead of field by @p-guldbaek-elsevier
• #263 Make execution context thread safe by @bbakerman
• #243 Initial take on adding GraphQL Schema parsing by @brimworks
• #274 Fixed directive introspection by @trevor-morris
• #275 Fixed type conditionals in grammar by @trevor-morris
• #277 Ensure that keywords can be used as names by @dminkovsky
• #240 Allow specification of mutation strategy

This release also includes a test improvement (#196) and documentation fix (#246).

Big thanks to all contributors!

Release highlights

• #159 Simplify schema definition interface by @IamCornholio
• #213 Fix bug in grammar by @dminkovsky
• #222 Fix stack overflow during validation by @herojan
• #217 Allow serialization of any Iterable as a GraphQLList by @iancw and @adw45

This release also includes code cleanup (#201, #234, #216) and documentation (#228).

Release highlights

• #123 "Recursive types not being resolved" from alexkrebiehl
• #187 "Added introspection query to codebase" from aschrijver
• #164 "Adds support for Boolean property accessors with 'get' prefix in PropertyDataFetcher" from ayhanap
• #168 "Parse escaped characters in strings" from ntkoopman
• #161 "Remove generated antlr code. Add build task dependency" from IamCornholio
• #178 "Add overload of GraphQLEnumType.Builder.value() with deprecationReason" from aschrijver
• #151 "Make BatchedExecutionStrategy return values in consistent order" from arlampin
• #145 "Ensure build with Java 6 runtime" from andimarek
• #140 "Adding scalars for BigInteger, BigDecimal, Byte, Short, Char" from danielkwinsor
• #136 "Support for directive.locations in introspection query" from aschrijver
• #127 "ExecutionContextBuilder bug fix" from dminkovsky
• #129 "Union types must have at least 1 member, and members can be only of Object types, not scalars" from danielkwinsor
• #99 "Throwable instead of Exception" from okorz001
• #103 "PropertyDataFetcher can fetch fields" from tuukka
• #113 "Support parsing IntValue literals into GraphQLFloat" from Macroz
• #102 "Fail on redefinitions" from tuukka

This release also includes code cleanup (#191, #185, #141, #121, #117, #120), documentation (#119, #158, #131) and test improvements (#133).

This is version 2.0.0 of graphql-java:

• Beginning with this version (2.0.0) graphql-java follows Semantic Versioning
• It is Java 1.6. compatible instead Java 1.7 (thanks @pt-achang)
• There is a Batched Execution Strategy for better performance (thanks @cardinalraven)
• GraphQLFloat was changed to return Java double values instead of Java float values in order to comply with the spec.
• Smaller bugfixes, improvements and refactorings

Thanks a lot to all contributors, who created a PR/Issue!

mainly bugfixes and a first very basic relay support

This release contains:

• Som minor breaking changes to comply with the spec (for example some renaming in the ExecutionResults)
• the groupId is now com.graphql-java to comply with maven-central requirements
• Bugfixes
• Improved Error Messages and more validations
• a lot of internal improvements and refactorings

This is the first release of graphql-java.