@samuelAndalon sorry for not getting back to you on this. Its been Easter and i have been away a fair bit.

I thought it might be a good addition to have a DataFetcherFactory with no DataFetcherFactoryEnvironment as argument

I think that PR adds exactly what you want (unless I dont understand what you want properly which is entirely likely)

public interface DataFetcherFactory<T> {

    /**
     * Returns a {@link graphql.schema.DataFetcher}
     *
     * @param environment the environment that needs the data fetcher
     *
     * @return a data fetcher
     *
     * @deprecated This method will go away at some point and {@link DataFetcherFactory#get(GraphQLFieldDefinition)} will be used
     */
    @Deprecated(since = "2024-11-26")
    DataFetcher<T> get(DataFetcherFactoryEnvironment environment);

    /**
     * Returns a {@link graphql.schema.DataFetcher} given the field definition
     * which is cheaper in object allocation terms.
     *
     * @param fieldDefinition the field that needs the data fetcher
     *
     * @return a data fetcher
     */

    default DataFetcher<T> get(GraphQLFieldDefinition fieldDefinition) {
        return null;
    }
}

The .get with GraphQLFieldDefinition gets called first in the code registry and then the older method

Let me look into this more because perhaps its not working in the way I think it is

I found a bug in the code and we do allocate DataFetcherFactoryEnvironment for simple properties.

#3942 fixes that and this should greatly reduce the object allocation needed

thanks @bbakerman, I didn't notice the new method of the factory that provides the field definition, that should be enough to avoid creating DataFetcherFactoryEnvironment, my question was more about making that change backwards compatible, to the version 22, I would appreciate if its possible.