RuntimeModuleManager and RuntimeModelLoader delegation to runtime lookup from runtime API/SPI

[akberc]

EDITED: to include both RuntimeModuleManager and RuntimeModelLoader
There is a FIXME in RuntimeModelLoader.findModuleForClass:

// FIXME: perhaps we can have other one-classloader-to-one-module setups than jboss modules?

I think this should be fixed in 1.1 and the RuntimeModuleManager be loaded via the Ceylon runtime API/SPI from a given runtime implementation. A glimpse of that approach can be seen in Metamodel.loadModule which is called from com.redhat.ceylon.compiler.java.runtime.ide.Launcher -- which is due to be removed?

This would, hopefully,

• remove dependency of language on org.jboss.modules. Really ugly.
• remove need to instanceof JBoss classloaders to find the runtime
• shift some compiler loader stuff and Lazyxxx to the runtime extended API for packages and declarations, allowing separation of compiler loader stuff from compiler compiler stuff
• move CMR behind the runtime implementation at run time.
• still allow compiler and other tools can use the JBoss runtime loader and CMR directly
• as a result, separate the toolset from the bare minimum required at runtime.
• allows Ceylon modules to be run in any container that satisfies the runtime API.
• automatically slice bread, apply butter, and other benefits :) . . .

As a result, the language module -- which is rightly the only required dependency of any Ceylon module -- would be able to boot itself by looking up a Ceylon runtime, and then using Metamodel.loadModule to invoke the runtime API to load other modules from the looked-up runtime.

[akberc]

Related: #280 and #370

[FroMage]

We should do that yes, but what other container do you have in mind?

[akberc]

Thanks for the encouraging feedback. I was just querying if it is a viable direction.

[akberc]

Also linking to #348 as a possible long-term solution.

[FroMage]

Look, I agree we should make it possible to run Ceylon without the runtime dependency on:

• Maven (used by the CMR)
• Runtime/JBoss Modules (if using a flat classpath)

But that's a lot of work. We may even be able to remove the CMR somehow if we abstract some of its services (used in language/typechecker/compiler). We may even be able to abstract the model loader away from the compiler (I started that work a long time ago), and the model from the typechecker. I guess all three may make sense to move to ceylon-common, and so the language module would only depend on that one at runtime.

WDYT @gavinking?

In any case, this is not a change we can do for 1.1, so moving to 1.2

[akberc]

OK. If you can put together a simple API that language module can lookup
dependencies through service locator or other mechanism, I can take a stab
at implementing it, while it uses the current dependency mechanism for 1.1

On May 16, 2014 7:27 AM, "Stéphane Épardaud" notifications@github.com
wrote:

Look, I agree we should make it possible to run Ceylon without the runtime
dependency on:

• Maven (used by the CMR)
• Runtime/JBoss Modules (if using a flat classpath)

But that's a lot of work. We may even be able to remove the CMR somehow if
we abstract some of its services (used in language/typechecker/compiler).
We may even be able to abstract the model loader away from the compiler (I
started that work a long time ago), and the model from the typechecker. I
guess all three may make sense to move to ceylon-common, and so the
language module would only depend on that one at runtime.

WDYT @gavinking https://github.com/gavinking?

In any case, this is not a change we can do for 1.1, so moving to 1.2

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/385#issuecomment-43321403
.

[gavinking]

Well, yes, it would be desirable, surely.

[FroMage]

OK, opening ceylon/ceylon-common#41 for the refactoring in 1.2.

[akberc]

Thanks. This new issue will consolidate existing code in common so that it is available to all. It makes the runtime compact but not open.

If the language module can define an interface for runtime lookup of module resolver, loader and model loader -- that would make language independent. The default implementation would be provided by common but alternate containers would be possible.

--Edited to remove typo--

[FroMage]

Sure that's why there are two issues. But the more urgent one is the other one since it reduces the dependencies for runtime a lot. I don't think anyone is going to produce an alternate model loader soon. Module resolver is more likely.

[akberc]

Agreed. Sorry, I thought this issue was being closed.

Language should not need to use module resolver directly. It should look up the RuntimeModuleManager, which in turn should call its own module resolver if it doesn't have a module loaded.

Any API will have to be designed in a way that it strongly encourages modules to be Ceylon-ish and Herd-ish, but obviously it will not be able to enforce it.

We may not have independent implementations of the RuntimeModelManager in the near future, but by lookingi it up at runtime, we may more easily support multiple back-ends, multiple JVM compatibility in the future - multiple JVM versions and implementations - OpenJDK, IBM SDK etc. Just for reference, lnking to an old thread: https://groups.google.com/forum/#!msg/ceylon-dev/WnjPovpQ7YA/Wa1fqiFuWX4J