Bot releases are hidden (Show)
Published by dondonz over 1 year ago
This is a special release with only one commit: reverting stricter parseValue
scalar coercion. It is a backport of https://github.com/graphql-java/graphql-java/pull/3186
We received feedback that the stricter coercion was difficult without a migration pathway. The next release will include an input interceptor to enable monitoring and/or custom modification of inputs.
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v20.2...v20.3
Published by dondonz over 1 year ago
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.
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v20.1...v20.2
Published by dondonz over 1 year ago
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.4...v19.5
Published by dondonz over 1 year ago
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v18.4...v18.5
Published by dondonz over 1 year ago
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v17.5...v17.6
Published by dondonz over 1 year ago
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!
This release includes a security fix #3112 which adds a limit to the depth of grammar rules, to prevent stack overflow.
#3095 improves resiliency to class loader problems with LambdaMetafactory
.
#3049 adds an extensions builder and merger.
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v20.0...v20.1
Published by dondonz over 1 year ago
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.
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.3...v19.4
Published by dondonz over 1 year ago
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v18.3...v18.4
Published by dondonz over 1 year ago
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
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v17.4...v17.5
Published by bbakerman almost 2 years ago
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.
parseValue
coercion with JS reference implementationWe 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.
parseValue
now requires input is of type String
. For example, a Number input 123
or a Boolean input true
will no longer be accepted.parseValue
now requires input is of type Boolean
. For example, a String input "true"
will no longer be accepted.parseValue
now requires input is of type Number
. For example, a String input "3.14"
will no longer be accepted.parseValue
now requires input is of type Number
. For example, a String input "42"
will no longer be accepted.String parseValue
changes: https://github.com/graphql-java/graphql-java/pull/3030
Boolean, Float, and Int parseValue
changes: https://github.com/graphql-java/graphql-java/pull/3042
JS reference implementation: https://github.com/graphql/graphql-js/blob/main/src/type/scalars.ts
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.
https://github.com/graphql-java/graphql-java/pull/2994
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.
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.
https://github.com/graphql-java/graphql-java/pull/2953
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.
https://github.com/graphql-java/graphql-java/pull/2981
https://github.com/graphql-java/graphql-java/pull/2980
https://github.com/graphql-java/graphql-java/pull/2979
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.
https://github.com/graphql-java/graphql-java/pull/2912
https://github.com/graphql-java/graphql-java/pull/2921
We have added extra builders on the GraphQLError
, ErrorClassification
and ExecutionResult
interfaces that make it easier to build instances of these common classes.
https://github.com/graphql-java/graphql-java/pull/2939
https://github.com/graphql-java/graphql-java/pull/3011
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.
https://github.com/graphql-java/graphql-java/pull/2923
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.1...v20.0
Published by bbakerman almost 2 years ago
The 19.3 bug fix release has been created
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.2...v19.3
Published by bbakerman about 2 years ago
The 19.2 bug fix release has been created
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.1...v19.2
Published by bbakerman about 2 years ago
This bug fix release was made to address a specific NullPointerException
problem if consumers are explicitly setting the ExecutionInput
to null
See https://github.com/graphql-java/graphql-java/pull/2908 for the code details.
The other fixes are included because they are... well... fixes and where ready at the time.
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v19.0...v19.1
Published by andimarek about 2 years ago
This is release 19.0 of GraphQL Java. It contains one breaking change.
It contains one security related bugfix hardening GraphQL Java more against malicious requests: #2892
GraphQL Java now shades Antlr runtime to prevent any further dependency conflicts. Antlr is used internally for parsing and validating of GraphQL requests and SDL. #2854
It includes some performance improvements (#2786, #2769, #2839) and several bugfixes and general improvements.
#2769 is an improvement to reduce object allocation. It can contain a breaking change if you would implement your own ChainedInstrumentation.
#2878 introduces i18n for validation error messages, and by default will set locale to the JVM default locale
#2799 changes the behaviour of the AST printer to use the shortest form available for query operation if possible. While semantically this is not a change, it might affect you.
#2892 Security bugfix to prevent DOS attacks
#2818 Fix silent thread leak for chained instrumentation
#2825 Fixup Introspection input field deprecation filterting
#2842 fix runtime exception for deep async queries
#2856 SchemaPrinter description bugfix
#2786 performance improvements for validation
#2854 Shade Antlr Runtime
#2896 Update DataLoader to 3.2.0
#2878 i18n for validation error messages
#2881 Improve SchemaPrinter
#2872 Improve AST compact printing
#2846 Subscription root field valiation
all PRs: https://github.com/graphql-java/graphql-java/milestone/38?closed=1
Published by andimarek about 2 years ago
This is a security bugfix release containing only one PR: https://github.com/graphql-java/graphql-java/pull/2897
GraphQL Java has a max token limit per request preventing DOS attacks. But in some circumstances it was not enough to prevent malicious requests. This release fixes this problem.
All details can be found here: https://github.com/graphql-java/graphql-java/pull/2892
Published by andimarek about 2 years ago
This is a security bugfix release containing only one PR: https://github.com/graphql-java/graphql-java/pull/2902
GraphQL Java has a max token limit per request preventing DOS attacks. But in some circumstances it was not enough to prevent malicious requests. This release fixes this problem.
All details can be found here: https://github.com/graphql-java/graphql-java/pull/2892
Published by dondonz over 2 years ago
This bug fix release fixes the double variable coercion problem identified in #2819, and introduces RawVariables
and CoercedVariables
to indicate whether variables have been coerced.
Note: This is a bug fix release. Only changes to fix #2819 have been cherry picked in this release. Other merged changes will be released separately as v19.
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v18.1...v18.2
Published by bbakerman over 2 years ago
This bug fix release contains an important fix
https://github.com/graphql-java/graphql-java/pull/2773
The latest 18.0 version of graphql-java changed the way raw values are resolved to canonical values.
However this revealed a bug in MaxQueryXXX instrumentation where invalid values (null being present for non nullable input values) caused an exception rather than generating a graphql error. This is not a behavior we intended.
The bug is only present if you use graphql.analysis.MaxQueryDepthInstrumentation
and graphql.analysis.MaxQueryDepthInstrumentation
TypeRuntimeWiring.enumValues()
error message by @martinbonnin in https://github.com/graphql-java/graphql-java/pull/2782
AstPrinter
to print field descriptions by @david-castaneda in https://github.com/graphql-java/graphql-java/pull/2808
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v18.0...v18.1
Published by bbakerman over 2 years ago
We are happy to announce v18.0 of graphql-java
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A18.0+is%3Aclosed
Graphql directives have two modes. They can be defined in a schema
directive @example on FIELD_DEFINITION | ARGUMENT_DEFINITION
and they can be applied to schema elements and query elements
type Query {
field(arg : String! ) @example
So we have a directive definition and cases where that directive is applied to an element.
However when the graphql.schema.GraphQLDirective
and graphql.schema.GraphQLArgument
classes was created, we modelled this badly. These classes should really represent a directive definition in schema only but we reused them to also be the representation of a directive and value arguments applied to another schema or query element.
This modelling is wrong. You can tell because we have javadoc comments like this in graphql.schema.GraphQLArgument
saying a certain property is only applicable in certain call contexts.
/**
* This is only used for applied directives, that is when this argument is on a {@link GraphQLDirective} applied to a schema or query element
*
* @return an input value with state for an applied directive
*
* @deprecated use {@link GraphQLAppliedDirectiveArgument} instead
*/
@Deprecated
public @NotNull InputValueWithState getArgumentValue() {
return value;
}
So we have decided to fix this bad class modelling in version 18. We have introduced new classes
graphql.schema.GraphQLAppliedDirective
graphql.schema.GraphQLAppliedDirectiveArgument
which represent an applied directive on a schema element and
graphql.execution.directives.QueryAppliedDirective
graphql.execution.directives.QueryAppliedDirectiveArgument
which represent an applied directive on a query element
For backwards compatibility reasons, the old graphql.schema.GraphQLDirective
objects are still created for applied
elements however the methods have all been deprecated and like for like getAppliedXXX
methods have been introduced.
You should migrate your code way from getting applied directives from the old methods and use the new more correctly modelled classes. This backwards compatibility will be removed in a future version.
Because of this backwards compatibility, there are a few gotchas to look out for. For example visitors will be called twice for the same applied element, eg one for the old style GraphQLDirective
object and one for the new GraphQLAppliedDirective
object. You should choose the new classes only as part of code migration. This should only affect code that does schema and query traversal (which is an advanced use case) and hence most consumers of graphql-java will not be affected.
There is one breaking change here. graphql.introspection.IntrospectionWithDirectivesSupport
and its predicate argument graphql.introspection.IntrospectionWithDirectivesSupport.DirectivePredicateEnvironment
have been changed to provide a directive name and not the appliedGraphQLDirective
directly. Again we think very few people will be affected by this breaking change.
https://github.com/graphql-java/graphql-java/pull/2186
The team at Twitter contributed a changed to the RulesVisitor
that is used to validate a query against the set of validation rules. For large queries this could be a performance drag.
This changes it to roughly linear complexity and shows a 5000% speedup when validating our large queries.
https://github.com/graphql-java/graphql-java/pull/2563
In extreme cases, a server may choose to skip certain validation rules. We don't recommend it, because results may become unpredictable and we won't support fixing issues caused by deactivated rules.
However it is now possible and may help trade validation for performance.
Predicate<Class<?>> predicate = new Predicate<Class<?>>() {
@Override
boolean test(Class<?> aClass) {
if (aClass == NoUnusedFragments.class) {
return false
}
return true
}
}
ExecutionInput.newExecutionInput(query)
.graphQLContext(["graphql.ParseAndValidate.Predicate": predicate])
.build()
https://github.com/graphql-java/graphql-java/pull/2598
The java data loader version has been upgrade to 3.1.2
which as some bug fixes and small improvements.
https://github.com/graphql-java/graphql-java/pull/2724
PreparsedDocumentProvider
changesThe graphql.execution.preparsed.PreparsedDocumentProvider
has been updated to use a CompletableFuture<PreparsedDocumentEntry> getDocumentAsync
method. This allows you to go to a remote cache in an asynchronous non blocking manner to get cached documents. This should have always been modelled in this manner.
However its an optional default interface method thats called the old deprecated synchronous method direct.
https://github.com/graphql-java/graphql-java/pull/2612/files
AstPrinter
performanceThe AST printer has been improved to stop unnecessary string allocation. For very large queries this slowed printing down dramatically.
https://github.com/graphql-java/graphql-java/pull/2729
The type resolvers now can get access to the local context object via the passed in graphql.TypeResolutionEnvironment
interface.
Similarly, the field sub selection graphql.schema.DataFetchingFieldSelectionSet
is also now available.
https://github.com/graphql-java/graphql-java/pull/2699
https://github.com/graphql-java/graphql-java/pull/2597
SchemaPrinter
. by @folone in https://github.com/graphql-java/graphql-java/pull/2575
Introspection.__DirectiveLocation
regression tests by @jord1e in https://github.com/graphql-java/graphql-java/pull/2703
SchemaPrinter
(\r\n -> \n
) by @jord1e in https://github.com/graphql-java/graphql-java/pull/2705
@Deprecated
to ExecutionStepInfo#getFieldContainer()
by @jord1e in https://github.com/graphql-java/graphql-java/pull/2712
Full Changelog: https://github.com/graphql-java/graphql-java/compare/v17.3...v18.0
Published by bbakerman about 3 years ago
This bug fix version of graphql-java provides new limits to help prevent Denial Of Service attacks induced by over parsing and validation.
Attackers can craft queries that consume lot of resources to parse and validate, which which ultimately invalid can deny real queries from being serviced.
https://github.com/graphql-java/graphql-java/pull/2549
https://github.com/graphql-java/graphql-java/pull/2553
There are new limits imposed by default. Parsing will be terminated after 1500 tokens and only 100 validation errors will be captured.
We chose to put in defaults so that people will get some amount of bad query parse and validate DOS protection out of the box.
There are JVM wide methods to change the default on these if that's problematic for your implementation.
There is also a small fix in the ValueResolver
https://github.com/graphql-java/graphql-java/commit/8530366f24ba316075a63402473cb2a38ca36ab3