Case sensitivity with J2CL cache

[jhickman]

I recently came across an issue with a project dependency that is in the process of making their package names lowercase, thus having in the jar duplicates for classes, but in different packages only differing by case:

com.Foo.SomeClass
com.foo.SomeClass

This works in Linux, but in Windows and Mac, getting exceptions such as:

[ERROR] Exception executing task org.example:example:1.0.0-SNAPSHOT/unpack
java.nio.file.FileAlreadyExistsException: /Users/myproject/target/gwt3BuildCache/0.20/org.example-example-1.0.0-SNAPSHOT/9724fbf0f3f00a5e8d345d6be5c5ec5c-unpack/results/org/example/example/com/Foo/SomeClass.java
    at sun.nio.fs.UnixException.translateToIOException (UnixException.java:94)
    at sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:106)
    at sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:111)
    at sun.nio.fs.UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:218)
    at java.nio.file.spi.FileSystemProvider.newOutputStream (FileSystemProvider.java:484)
    at java.nio.file.Files.newOutputStream (Files.java:228)
    at java.nio.file.Files.copy (Files.java:3161)
    at com.vertispan.j2cl.build.UnpackJarTaskFactory.lambda$resolve$0 (UnpackJarTaskFactory.java:49)
    at com.vertispan.j2cl.build.TaskScheduler$2.executeTask (TaskScheduler.java:214)
    at com.vertispan.j2cl.build.TaskScheduler$2.lambda$onReady$0 (TaskScheduler.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:304)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1136)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635)
    at java.lang.Thread.run (Thread.java:833)
java.lang.RuntimeException
    at com.vertispan.j2cl.build.DiskCache.markFailed(DiskCache.java:542)
    at com.vertispan.j2cl.build.DiskCache$CacheResult.markFailure(DiskCache.java:62)
    at com.vertispan.j2cl.build.TaskScheduler$2.executeTask(TaskScheduler.java:235)
    at com.vertispan.j2cl.build.TaskScheduler$2.lambda$onReady$0(TaskScheduler.java:266)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)

[niloc132]

A few mitigations we can try:

• The log output is bad, though accurate - the OS says that the file already exists, and we're configured to fail if a file already exists, but in this case there are two files that have the same path if case is ignored. Perhaps we can add a specific check for "does the existing file match the new file only if you ignore case" and log a custom error message to handle this?
• Keep contents in jars, and write new output into jars, so that output doesn't collide. We've previously discussed other benefits of doing this (can't find an issue right now), letting each task output live in its own zip FileSystem, for smaller on-disk output, potentially faster IO, and capability of using something like jimfs instead of actually putting intermediate work on disk