gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] inverting gump classloading control could lead to *massive* potentials
Date Wed, 23 Apr 2003 11:00:31 GMT
on 4/22/03 6:08 PM Nicola Ken Barozzi wrote:

> Sam Ruby wrote, On 22/04/2003 17.31:
>>Nicola Ken Barozzi wrote:
>>> urllib.urlopen(repo+project+'-'+version+'.jar')
>>>shoud work.
>>>Is this what you are aiming at?
>>Another way to look at what I am asking... what is the feasiblity of a 
> Good suggestion.
> You are aiming at not using Java at all, right? It makes sense.
> Someone privately asked me why use Ruper in Gump at all for normal 
> builds, since we could just make Gump ingnore any jars it would have to 
> supply and make Ant, Centipede, Maven or whatever take care of that.
> The problm remains though with the gump-Gump usage, ie setting all the 
> classpath beforehand.
> Ok, this is what I'll do: I'll start using with the assumptions 
> I did before. It would be very simple. If-when we will need more, we can 
> always eventually call the Java Ruper from it. In fact the idea could be 
> to use the the Java Ruper only if Java is not there or it's not 
> requested by the user or the build is of type "Gump".
> But let's not put the cart before the horse, it's just for now.

Let me throw in a few stones in the lake.

Let's take a step back: java has *awesome* classloading capabilities and
*terrible* classpath problems generated by the fact that some braindead
guy designed javac without even understanding *how* a real java compiler
should work: fetching dependencies from the classloader *NOT* the classpath.

I was told this dates back to the days of "oak" when they had to show
that "oak" was cool by writing a compiler for it using the language
itself. Fair enough. Too bad this underlying problem remained even after
almost 10 years.

Fast forward to now: entering Eclipse JDT compiler. piecewise
incremental, syntax fault tollerant, much more warning capable and,
joyfull joyfull, entirely based on class dependency loading thru

Now: let me ask you: instead of using javac for gump, couldn't we use
Eclipse JTD and instead of setting up *massive* classpaths, work with
the control inverted?

Why the control inverted?

Gump is, in fact, a huge classloader, but it works its way thru
pre-generating the classpath-equivalences of the class dependency checkings.

Looking it with javac eyes it's pretty cool because it does all the
shitty job for you.

Looking it with Eclipse JTD eyes, it's a terrible hack.

While I totally share Sam's concerns in making gump the thinnest
possible, let's ask ourselves if it's good to sacrifice architectural
elegance of more modern code compilation just because it requires gump
to have a few hundred lines of java code that wrap around Eclipse JTD.

Also note that with control inverted, gump could *explore* dependencies
at compilation time, providing the information that is required to
understand if a project is *really* a friend of gump or not.

Why? because an IoC-based dynamic classloading gump could provide
automatic-backtracing!!!!! Look:

1) I need to compile
2) depends on
3) gump is the classloader and the compiler asks for an instance of
4) it performs compilation and fails.
5) gump receives the warning and restarts the compilation
6) gump fetches yesterday's version of the class

I've been thinking about this a lot and I think this is the only way we
can have enough information to determine if a project is a friend of
gump or not.

Also, we'll be able to blame not only the project, but the single
developer since we will know:

 1) the class failing
 2) the day the problem happened
 3) and from CVS, we an get the user ID of the person who did the commit

and nag him/her publicly :-)

Sam, you told us you want the Eclipse guys to use gump: isn't this a
*great* possibility to cross-pollinate them?


View raw message