github-actions[bot]
commented
1 year ago Test Results
93 files 93 suites 46s :stopwatch: 263 tests 263 :heavy_check_mark: 0 :zzz: 0 :x: 268 runs 268 :heavy_check_mark: 0 :zzz: 0 :x:
Results for commit 11c60674.
:recycle: This comment has been updated with latest results.
sonarcloud[bot]
This PR contains the following updates:
19.3->20.0Release Notes
graphql-java/graphql-java
### [`v20.0`](https://togithub.com/graphql-java/graphql-java/releases/tag/v20.0): 20.0 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: [https://github.com/graphql-java/graphql-java/pull/3030](https://togithub.com/graphql-java/graphql-java/pull/3030) Boolean, Float, and Int `parseValue` changes: [https://github.com/graphql-java/graphql-java/pull/3042](https://togithub.com/graphql-java/graphql-java/pull/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 ```graphql type Person { name : String address : String } ``` then this Java `record` would be supported for fetching values via the method names `name()` and `address()` ```java public record Person (String name, String address) ``` and equally a non record class like this would also work ```java 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 ```java 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](https://togithub.com/graphql-java/graphql-java/pull/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 ```java 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 ```java public interface LightDataFetcherConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.