adjust generated '*.cls' filenames

[Mark Evenson]

dmiles:

it be nice to eventually name the coerce-666.cls coerce_666.cls as the same name of the way classpaths think about them (they'd continue to work).. one argument agaist is our autoloader at least gets a better whack at finding them in the right context apart from classloader

[Douglas Miles]

coerce-666.cls -> coerce_666.class

I can only speculate the reasons for using .cls:

The use of .cls was maybe we were not sure if ABCL was going to do new stuff with the .class file format. - But it didn't.

The use of .cls keeps the (parent/system) classloaders from making assumptions that they can autoload these classes on their own (at the wrong time).

However I believe niether of the two issues would come up.

I have a special debugging plugin I use under eclipse that lets me inject and reinterpret and trace verify errors that is usefull in debugging/decompiling the .class files .. I had to extend this debugger to handle .cls files.. This is available to me as a hack.. But if I wasnt me, and was using Jode/JADClipse debugger plugins I would have issues.

Renaming the these to .class files has nothing to do with *just getting* a debugger working. But opens us up our autoload framework to leverage more types of compiler outputs and allows precompiler and bytecode loading systems from other types of JVMs on the right page to our class files.

[ehuelsmann]

On the other hand, I know we currently have users who want to control loading of non-java generated classes. Our .cls filenames allow that.

[Mark Evenson]

We could make the FASL ending settaable?

[ehuelsmann]

Impact of this change is - at this time - unclear, apart from the identified benefits above. (Jasper reports uses a non .class extension to its compiled reports too.)

[Mark Evenson]

Implementation from dmiles committed in r14002