Barzilai Spinak schrieb: [...]

I think recompilation is off by default, so it should use the .class file. But the above is clearly an error, because the .grovoy file is the fall back for a non existing .class file, which means groovy can't find the .class file as well here. You are sure it was there?

[...]

I agree partially... even if it recompiles, there should be no problem with the charset name.... would be nice of you to post a bigger trace for this (run groovy with -d)

I don't think it is the fault of groovyc or groovyStarter.

I think we should more ask how file.encoding does take effect. It effects the default encoding used by the java api for reader and inputstreams. And of course the groovy compilers uses this api. But should it really affect the compiler? Normally the compiler should use the encoding given to him, but since file.encoding takes effect it means that there are places where the compiler does not use an explicit encoding, therefor the configuration we gave in with the --encoding option is naturally ignored.

I see a suspicous line in GroovyClassLoader:

su = unit.addSource(codeSource.getName(), codeSource.getInputStream());

getInputStream is implemented as:

public InputStream getInputStream() { try { if (file!=null) return new FileInputStream(file); } catch (FileNotFoundException fnfe) {} return inputStream; }

so if file is not null, we will create a new FileInputStream *using the default encoding*. A big bug!

This does of course not explain the problem with not calling a .class file, but it exaplains the prolem with the encoing.

bye blackdrag