Skip to content

Releases: graphql-java/graphql-java

19.5

30 Mar 23:40
7a4b8de
Compare
Choose a tag to compare

This is a security bugfix release containing only one PR: #3158

This adds a limit to the number of characters used in an operation.

Full details can be found here: #3148

What's Changed

  • This is the backport of the max characters in a parse to the 19.x branch by @bbakerman in #3158

Full Changelog: v19.4...v19.5

18.5

30 Mar 23:39
fac642c
Compare
Choose a tag to compare

This is a security bugfix release containing only one PR: #3159

This adds a limit to the number of characters used in an operation.

Full details can be found here: #3148

What's Changed

Full Changelog: v18.4...v18.5

17.6

30 Mar 23:39
c3a1662
Compare
Choose a tag to compare

This is a security bugfix release containing only one PR: #3160

This adds a limit to the number of characters used in an operation.

Full details can be found here: #3148

What's Changed

Full Changelog: v17.5...v17.6

20.2

30 Mar 23:42
fabc3e0
Compare
Choose a tag to compare

This is a security bugfix release containing #3148, which adds a limit to the number of characters used in an operation.

There are no breaking changes in this release.

What's Changed

Full Changelog: v20.1...v20.2

18.4

22 Mar 03:09
3e2ccea
Compare
Choose a tag to compare

This is a security bugfix release containing only one PR: #3144

This adds a limit to the depth of grammar rules, to prevent stack overflow.

Full details can be found here: #3112

What's Changed

Full Changelog: v18.3...v18.4

17.5

22 Mar 02:58
354bcc3
Compare
Choose a tag to compare

This is a security bugfix release containing only one PR: #3139

This adds a limit to the depth of grammar rules, to prevent stack overflow.

Full details can be found here: #3112

What's Changed

Full Changelog: v17.4...v17.5

20.1

22 Mar 03:32
4aedac7
Compare
Choose a tag to compare

This is a feature and bugfix release. There are no breaking changes in this release. This release continues to use Java 8.

Thanks to everyone in the community for helping us with this release. Thanks for your PRs, issues, and discussions!

Security fix

This release includes a security fix #3112 which adds a limit to the depth of grammar rules, to prevent stack overflow.

Highlights

#3095 improves resiliency to class loader problems with LambdaMetafactory.

#3049 adds an extensions builder and merger.

Release policy

We have formalised our release schedule to give the community a better idea of when to expect releases, what will be contained within them, and when important fixes will be backported. See the full details at https://www.graphql-java.com/blog/release-policy

What's Changed

  • docs: update badges for v20 release by @setchy in #3047
  • Update FieldValidationInstrumentation.java by @kfwerf in #3066
  • Update vulnerability reporting instructions by @dondonz in #3070
  • Fix extend schema directives ANTLR rule by @dondonz in #3071
  • Allow users to disable MultiSourceReader trackData through ParserOptions by @AntaresS in #3062
  • Add missing getter and fix name consistency by @gnawf in #3073
  • use toolchain to specify the java version by @andimarek in #3075
  • Fix isNameChanged by @gnawf in #3076
  • Update instrumentation example in documentation by @dondonz in #3078
  • Reuse ExecutionStrategyInstrumentationContext.NOOP in DataLoaderDispatcherInstrumentation by @dfa1 in #3068
  • Add missing this keyword for readability by @cookieMr in #3067
  • defaulting the deprecated methods in Coercing by @bbakerman in #3063
  • Add missing detail by @gnawf in #3079
  • Updating the JavaDoc http links by @bbakerman in #3083
  • An Extensions Builder by @bbakerman in #3049
  • Use ImmutableList.builderWithExpectedSize in ImmutableKit.mapAndDropNulls too by @dfa1 in #3081
  • Resolve TypeReferences in schema applied directives by @kaqqao in #3054
  • Remove sun.misc.* from MANIFEST.MF by @dondonz in #3091
  • Replace javax nullable annotations with JetBrains equivalent by @dondonz in #3093
  • Ensured that the MANIFEST.MF files is the first entry in the JAR File by @schaefa in #3097
  • Fix type change and directive deletion problems in schema diffing by @gnawf in #3102
  • Handle enum value rename by @gnawf in #3103
  • Bugfix: do not use default operation name types if not included in schema definition block by @dondonz in #3088
  • Adding ExtensionsBuilder in the graphql context by default by @bbakerman in #3085
  • Meta Lambda failures - make the code more resilient to class loader challenges by @bbakerman in #3095
  • Gracefully returning null in cases of UnresolvedTypeException by @ahmadizm in #3122
  • Add dependabot configuration by @yeikel in #3115
  • Bump org.jetbrains:annotations from 23.0.0 to 24.0.1 by @dependabot in #3125
  • Remove unused dependencies by @dondonz in #3132
  • Bump actions/checkout from 1 to 3 by @dependabot in #3126
  • Bump google-github-actions/auth from 0.4.0 to 1.0.0 by @dependabot in #3129
  • Bump org.codehaus.groovy:groovy from 3.0.9 to 3.0.16 by @dependabot in #3131
  • Add manual stop on schema diffing algorithm by @gnawf in #3119
  • Preventing stack overflow exceptions via limiting the depth of the parser rules by @bbakerman in #3112
  • UniqueObjectFieldName validation rule (#1806) by @ashatch in #3094

New Contributors

Full Changelog: v20.0...v20.1

19.4

22 Mar 03:18
1f905d8
Compare
Choose a tag to compare

This is a security bugfix release containing PR #3133. This adds a limit to the depth of grammar rules, to prevent stack overflow. See the full details on the original PR: #3112.

This release also includes backported fixes to ensure MANIFEST.MF is the first entry in the JAR file and removes sun.misc from Import-Package header. See the full details on the original PRs: #3091 and #3097.

What's Changed

Full Changelog: v19.3...v19.4

20.0

06 Dec 23:49
557ad5d
Compare
Choose a tag to compare

We are pleased to announce the release of graphql-java 20.0. Special thanks to each of the 200+ contributors over the years, who have made this milestone possible.

Breaking changes

Aligning parseValue coercion with JS reference implementation

We have made changes to String, Boolean, Float, and Int parseValue coercion, to be consistent with the reference JS implementation. The key change is parseValue is now stricter on accepted inputs.

  • String parseValue now requires input is of type String. For example, a Number input 123 or a Boolean input true will no longer be accepted.
  • Boolean parseValue now requires input is of type Boolean. For example, a String input "true" will no longer be accepted.
  • Float parseValue now requires input is of type Number. For example, a String input "3.14" will no longer be accepted.
  • Int parseValue now requires input is of type Number. For example, a String input "42" will no longer be accepted.

String parseValue changes: #3030
Boolean, Float, and Int parseValue changes: #3042
JS reference implementation: https://github.com/graphql/graphql-js/blob/main/src/type/scalars.ts

Notable Changes

Record Like Property Fetching Support

We have now added the ability to find properties via "Record like" naming. We call it "Record like" based on Java 14 record classes but in fact any class with a method named directly as the graphql field is named will work.

If you had this graphql object type declared

type Person {
   name : String
   address : String
}

then this Java record would be supported for fetching values via the method names name() and address()

public record Person (String name, String address)

and equally a non record class like this would also work

public class Person {
   public String name() { return "Harry Potter"; }
   public String address() { return "4 Privet Drive, Little Whinging"; }
}

We still have Java Bean (aka POJO) getter naming support like public String getName() however now the "record like" name() method will be used in preference and then the getName() methods will be used if that's not present.

This means there is a new behavior if you had weird POJOs likes this

public class WeirdPerson {
   public String name() { return "Harry Potter"; }
   public String getName() { return "Tom Riddle"; }
}

A property fetch for name will now return Harry Potter and not Tom Riddle as it previously would have.

This is a behavioral breaking change but on balance we think this behavior is the most correct going forward.

#2994

Improved Data Fetching

The PropertyDataFetcher class is the most common data fetcher used in graphql-java. It uses Java reflection to get field values from objects based on field name.

This was logically the following

Method method = findMethod(fieldname);
method.invoke(object);

with the method lookup cached for performance reasons.

However there is mechanism in the JVM that provides even faster object reflective access.

See

https://wttech.blog/blog/2020/method-handles-and-lambda-metafactory/
https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html

java.lang.invoke.LambdaMetafactory#metafactory is an arcane mechanism that can be used to create virtual method lambdas that give fast access to call object methods. It turns out to be significantly faster that Java reflection and only marginally slower that directly invoking a method.

If you use PropertyDataFetcher a lot (and chances are you do) then this should give improved performance.

The raw benchmarks are as follows

Java 8

Benchmark                                       Mode  Cnt         Score         Error  Units
GetterAccessBenchmark.measureDirectAccess      thrpt   15  81199548.105 ± 2717206.756  ops/s 0% slower (baseline)
GetterAccessBenchmark.measureLambdaAccess      thrpt   15  79622345.446 ± 1183553.379  ops/s 2% slower
GetterAccessBenchmark.measureReflectionAccess  thrpt   15  46102664.133 ± 4091595.318  ops/s 50% slower

Java 17


Benchmark                                       Mode  Cnt          Score          Error  Units
GetterAccessBenchmark.measureDirectAccess      thrpt   15  458411420.717 ± 34329506.990  ops/s 0%
GetterAccessBenchmark.measureLambdaAccess      thrpt   15  334158880.091 ± 10666070.698  ops/s 27% slower
GetterAccessBenchmark.measureReflectionAccess  thrpt   15   63181868.566 ±  3887367.970  ops/s  86% slower

It's worth noting that while the headline numbers here look impressive, the property fetching represents a smaller portion of what happens during graphql engine execution.

It probably won't be enough to keep Elon Musk happy but all performance improvements help and at scale they help the most.

Lightweight Data Fetchers

A DataFetcher gets invoked with a calling environment context object called graphql.schema.DataFetchingEnvironment. This is quite a rich object that contains all sorts of useful information.

However simple (aka trivial) data fetchers like PropertyDataFetcher they don't need access to such a rich object. They just need the source object, the field name and the field type

To marginally help performance, we have introduced a graphql.schema.LightDataFetcher for this use case

public interface LightDataFetcher<T> extends TrivialDataFetcher<T> {

    
    T get(GraphQLFieldDefinition fieldDefinition, Object sourceObject, Supplier<DataFetchingEnvironment> environmentSupplier) throws Exception;
}

PropertyDataFetcher implements this and hence this lowers the object allocation at scale (which reduces memory pressure) and will make the system marginally faster to fetch data.

#2953

Performance Improvements by avoid object allocations

We are always trying to wring out the most performance we can in graphql-java and so we reviewed our object allocations and found places where we can make savings.

These won't make dramatic performance savings but at scale all these things add up, reducing memory pressure and improving throughput marginally.

#2981
#2980
#2979

Locale is now available in Coercing and Parsing

The graphql.schema.Coercing interface used by scalars can now receive a Locale object that indicates the calling Locale. The same is true for the parsing code via graphql.parser.ParserEnvironment#getLocale

A custom scalar implementation could use the locale to decide how to coerce values.

#2912
#2921

Easier ways to build common objects

We have added extra builders on the GraphQLError, ErrorClassification and ExecutionResult interfaces that make it easier to build instances of these common classes.

#2939
#3011

The deprecated NextGen engine has been removed

The NextGen engine was an experimental feature that explored what it might take to build a new graphql engine. In many ways it was a success as it taught us a bunch of about graph algorithms and what works and what does not.

While it had some value, on balance it was not going to become production ready and so we deprecated it a while back and it has finally been removed.

#2923

What's Changed

19.3

02 Dec 03:56
8045928
Compare
Choose a tag to compare

The 19.3 bug fix release has been created

What's Changed

Full Changelog: v19.2...v19.3