use Tatoo's compiler as front end of javac

[Jonathan Gibbons]

Rémi,

With regards to the issues regarding ServiceLoader, don't we just
have to step back one level, and have the service loader return
a trivial object providing just one method to create the real object
we want, created the way we want to create it.  In other words,
instead of tweaking ServiceLoader, we can tweak the way we
instantiate the objects.

For example, for any class C that wishes to be accessed via a Context,
it could use this template:

public class C {
    public interface Factory {
        C create(Context context);
    }

    public static C instance(Context context) {
        C instance = context.get(C.class);
        if (instance == null) {
            Iterator<C.Factory> iter = 
ServiceLoader.load(C.Factory.class).iterator();
            instance = (iter.hasNext() ? iter.next().create(context) : 
new C(context));
        }
        return instance;
    }

    // etc
}

The old mildly icky thing about this proposal is that if C is ParserFactory,
we end up with ParserFactory.Factory !!  Suggestions for better names
are welcome.

-- Jon


Rémi Forax wrote:
> Jonathan Gibbons a écrit :
>> Rémi,
>>
>> Thanks for the suggested patch. I'm thinking it might be worth
>> investigating this one step further, and see if we can leverage the
>> JDK ServiceLoader mechanism to come up with a more general
>> mechanism that would apply to any object that might be found via
>> the javac Context.
> ServiceLoader requires an empty constructor and
> objects store in a Content are constructed with that context.
>
> I don't see how to use it without modifications of 
> java.util.ServiceLoader.
>>
>> I can see 3 possibilities:
>>
>> Early: as soon as the context is created, populate it with any
>> objects found via the service loader.
>>
>> Later: after the command line options have been read, populate
>> the context with any objects found via the service loader. This
>> will allow the ability to select objects via hidden command line
>> options.
>>
>> Latest: on an instance by instance basis, check the service loader
>> before creating each default object for the context. This is the
>> most expensive option, since it requires checking the service
>> loader on an object by object basis; the previous two options
>> would just require one access to the service loader, for any/all
>> objects to put in the context.
> In my opinion, this should be done in instance(),
> (your latest solution), Context is already a cache
> but again there is no way to get the service class from a ServiceLoader.
>
>>
>> We could also go for a radically different dependency injection
>> framework, but I'd prefer to go for a small/lightweight change,
>> and not any major refactoring at this time.
> yes, we could :)
>>
>> -- Jon
> Rémi