Re: [Rails-devel] New ClassLoader

[Brett L. <wak...@gm...>]

On Thu, 2007-08-02 at 21:30 +0200, Erik Vos wrote:
> > I've just committed some fairly big changes.
> > 
> > I've pulled in the custom Class Loader from Colossus, and then tweaked
> > it a bunch.
> > 
> > This begins to clear up a bunch of problems I've been having getting
> > Rails to run under JNLP. These problems are mainly our depending on
> > using the local file system. While I'm not quite done yet, this is
> > certainly a step in the right direction.
> > 
> > Additionally, I've deprecated the Util.getStreamFromFile() method.
> > Please use ResourceLoader.getInputStream() instead.
> 
> Just a question: does this also allow reading from the Rails.jar?
>  


Yes, it does.  Over the last week, I've had a bit of a crash course in
how Java locates data.

The whole idea is that Java wants you to avoid using anything specific
to the underlying machine until the last possible moment. So, everything
that requires data from external resources (i.e. data files, images,
etc.) needs to use a class loader to search for those resources. It's
the class loader's job to figure out what resources are available, and
where they are using generic path identifiers.

At first I was considering writing a whole new class loader for us, but
as I was reviewing a few different projects, the Colossus class loader
looked very close to what we needed, so I used it as a base.


> > For now, I've updated the relevant areas to use the new 
> > method signature
> > so that things still compile and function. Next, I'll be removing some
> > of the redundancy this new class creates.
> > 
> > Lastly, thanks to the addition of the game.properties file, 
> > I've removed
> > reading the local file system to build the game list.
> 
> The old version would not have shown a game listed in games.properties,
> if the related directory did not actually exist. Now I'm getting
> several Exceptions on the console if such a non-existing entry is chosen.
> No big deal, but IMO some check should be in place.
> 


Yes, this is a necessity unfortunately. 

The big limitation to being platform agnostic is that we can't really
say "scan this location for stuff I need".  So, it was really fortunate
that you had just added in the game.properties file. It's the perfect
substitute for directory scanning, and simplifies the code quite a bit.

The downside is now the game.properties file must be kept synchronized
with the data/ directory entries.



> One real gripe though: you have also changed the stand-alone utilities
> ConvertTilesXML and MakeGameTileSets.
> These classes are not really part of the game. 
> Running these development aids now requires adding log4j.jar to the
> classpath,
> and standing the resulting warnings about not having configured log4j
> appenders.
> 

Oops. I didn't notice that. I just updated them to use the new
interface. I didn't really think about the additional import statements
that ResourceLoader uses.


> I think these utilities do not belong in package rails.util at all.

Agreed.

> In fact I vaguely remember that I had them originally in a separate 
> tools package. I'm going to put the original versions back there.
> If you don't want them there, I can keep these versions local.
> 
> Erik.

That's fine.

 ---Brett.


Excellent day for putting Slinkies on an escalator.