Now thinking about it, I think it must by design since if we would include the inline fragments there is a risk they would conflict:
Example:

type QueryType {
    humanCharacter(id : String) : Character
}
interface Character {
    id: ID!
}
type Human implements Character {
    id: ID!
    homePlanet: String
}
type Droid implements Character {
    id: ID!
    homePlanet: String
    make: String
}

and query:

{ 
   humanCharacter(id: "1003") {    --> returns Leia who is a Human
        id
        __typename
        ... on Human {          
            homePlanet
        }
        ... on Droid {
            homePlanet
            make
        }
    }
}

the result of environment.getSelectionSet().get().keySet() would be:

["id",
"__typename",
"homePlanet",
"make"]

and this would be ambiguous? (as we would lose information about one of the two homePlanet fields)

@tinnou you are right: this is intentionally as we don't have a good way at the moment to really analyze the query statically (without executing it) to the desired level you describe.

The challenge are really Interfaces and Union as they are only "realized" when executed.
We are planning to add a new feature we call "normalized Query" (see #1731 for an outdated first version).

This normalized Query would tell you that:
(QueryType.humanCharacter) has two different children (Human.homePlanet) and (Droid.homePlanet) which are both "conditional" meaning it depends on the resolved value of "humanCharacter" if they are getting executed (or mabye even both if it would be inside a List)

And remember that now we have "branching" in the fields. That is you code would have to cope with "if its a Human it could be these fields and if its a Droid it could be these fields".

This is a much more complicated programming model than "these are the concrete fields" you can access.

@tinnou Please have a look at this test: https://github.com/graphql-java/graphql-java/pull/1963/files#diff-d9e663cf35993c9d4de118e0353dda5f to see how it will probably look like with NormalizedField:

@tinnou Please have a look at this test: https://github.com/graphql-java/graphql-java/pull/1963/files#diff-d9e663cf35993c9d4de118e0353dda5f to see how it will probably look like with NormalizedField:

Ok looking at the test you linked, that makes sense. So a NormalizedField from what I understand, represents a fused version of the language Field with schema aware properties (like GraphQLFieldDefinition, level in the selection set, and output type)

@tinnou we talked about it a bit more and we will probably incorporate the NormalizedFields into the DataFetchingFieldSelectionSet in a way. NormalizedFields will probably be more like a fundamental concept "wrapped" by DataFetchingFieldSelectionSet

This PR will be superseded by #2079
@bbakerman please have a look if you think copying this test here is worth it.