I cannot reproduce this issue with 1.0-milestone-3. Are you sure the version is correct?

Here's how I performed the tests (passing sys props from GRADLE_OPTS and explicitly from terminal). It worked fine regardless of --daemon

task printSys << {
  println "file.encoding sys property = " + System.properties["file.encoding"]
  println "foo env variable = " + System.getenv("foo")
}

Is this how you would expect the env/sys props are honored by gradle?

There's one gotcha with env. variables, though. Since the daemon process is long-living and you cannot change the env variables in java, you need to restart the daemon if you change the environment variable. At least that's the behavior at the moment (in theory we could fix it by restarting the process in case env variable has changed).

Hi Szczepan-

So, one of the confusing things about the file.encoding system property is that the JVM only checks this property once when it's starting up. Changing that system property at a later date doesn't effect the encoding used by code depending on the default encoding.

So, if you instead use this task:

task printSys <<

(If it doesn't come through, I used a UTF-8 character on the last println...)

What will happen is that even when GRADLE-OPTS is set to be "-Dfile.encoding=UTF-8", when the build is executed by the Daemon the special UTF-8 character won't print correctly, even though the file.encoding property will show up as "UTF-8".

Certain system properties like file.encoding need to be set on the command line when the java command is executed, not later.

Thanks for looking at this!

Thanks for info. We will try to address it. The simple solution would be to pass those 'special' system properties at process bootstrap. However, this will not solve the problem in case some wants to change the file.encoding when daemon is already running

We should probably come up with a general solution for jvm settings which can only be applied at startup. For example:

• java version
• memory settings
• certain system properties, such as file.encoding

When these value have changed since the daemon has started, we could:

• kill the existing daemon and start a new one with the new settings.
• start a new daemon, leaving the old one to expire some point in the future.
• run the build in the client process.

Option 2. is a good one, I think, provided we tweak the expiry algorithm to take into account things such as how many daemon are already running.

The daemon now properly respects file.encoding as an immutable property that needs to be correct on startup.

It has also for sometime correctly managed mutable system properties.

There may be other immutable properties like file.encoding, but as they are not known right now I'm going to close this off and we can open new tickets for them as needed.