quarkus:dev hot reload changes default charset?

[seseso]

Running a project with quarkus:dev, everything works fine. When triggering hot reload (changing some source), the behavior changes and Strings that exists in the code seems to be interpreted in a different charset.

I created a small project to reproduce this error: https://github.com/seseso/quarkus-hot-reload
Steps:

1. mvn clean install -DskipTests quarkus:dev
2. curl http://localhost:8085/hello/S%C3%A9rgio
3. Excpected output: hello Boss!
4. Change a source and save, triggering hot reload
5. curl http://localhost:8085/hello/S%C3%A9rgio
6. Excpected output: hello Boss! Actually, it returns Hello Sérgio

The rest endpoint is this one:

@GET
@Path("/{name}")
@Produces(MediaType.TEXT_PLAIN)
public String hello(@PathParam("name") String name) {
    
    if("Sérgio".equals(name)) {
        return "hello Boss!";
    }
    
    return "hello " + name;
}

So, after hot reload, the if does not matches.

Environment

• Output of uname -a or ver: Windows 10 PRO
• Output of java -version: openjdk version "1.8.0_212"
• GraalVM version (if different from Java): Not using
• Quarkus version or git rev: 0.20.0

If more information is needed, please let me know as I'll be glad to provide...

[gwenneg]

Hi @seseso! I just tried to reproduce this using your project on a MacBook but the curl call always returned hello Boss!. Could you please verify that the source file encoding is not changed when you edit it? That could also be a Windows specific issue.

You can check the file encoding using the file * command from the source directory if you're using Git bash from Windows.

[seseso]

I doubt that the save action do a change on charset as if I stop / start the project, everything works fine again.
I bet more on a Windows specific issue. Tested on a WSL Linux in my Windows machine and everything works fine also.

• Output of uname -a: Linux DESKTOP-4ICQ7FU 4.4.0-18362-Microsoft Switch to the Maven distributed copy of the SubstrateVM annotations #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 GNU/Linux

[gwenneg]

Yes I agree the charset change on save was very unlikely but since it can happen, I had to ask :)

Thanks for testing this with Linux!

[gwenneg]

I'm not sure this is related but during a hot reload, we're recompiling the changed sources here using a StandardJavaFileManager which relies on the platform default charset because we're not providing a specific charset (which does not look like a good idea at first glance).

I'll assign this issue to myself if I'm able to reproduce it on my mac.

[gwenneg]

I forced a wrong charset and obtained similar results during a hot reload with your project, but I couldn't exactly reproduce the issue since I don't have any Windows computer to test it right now.

@geoand: WDYT of the fix in the PR? I'm not sure it's ok to have a hardcoded charset in JavaCompilationProvider since the charset usually comes from the project.build.sourceEncoding Maven property or a Gradle equivalent for the initial compilation. I could try retrieving the charset from the Maven/Gradle plugins system properties if the hardcoded one is not ok.

[geoand]

@gwenneg I think that it would be OK to have UTF8 for now since that is by far the most common scenario.

[gwenneg]

Fixed in #3471 and #3487.