protocolbuffers / protocolbuffers/protobuf

Protobuf/Gradle Case Sensitivity Issue on macOS - class x is public should be declared in a file named x.java

Open
#14,555 1 comment 0 reactions 1 assignee View on GitHub

@zhangskz is already working on this.

Since Nov 3, 2023.

help wanted java platform related
Dominant language
C++
Stars
72k
Forks
16.3k
Avg merge
1d 17h
Merged PRs (30d)
140

Description

I encountered an issue with Protobuf and Gradle on macOS, which I believe may be related to case sensitivity of file names. When using two Protobuf message types, ChecklistItemMsg and CheckListItemMsg, where the only difference is the letter 'L' case, the Gradle build process fails on macOS but works fine on Linux.

message ChecklistItemMsg {
}
message CheckListItemMsg {
}

error: class ChecklistItemMsg is public, should be declared in a file named ChecklistItemMsg.java
public final class ChecklistItemMsg extends
^

Expected Behavior:
I expected that the Gradle build process would generate two Java files, one for each of the .proto files. Specifically, it should generate ChecklistItemMsg.java and CheckListItemMsg.java.

Actual Behavior:
However, on macOS, the build process only generates one of the expected files (e.g., CheckListItemMsg.java), while the other file (ChecklistItemMsg.java) is missing. This results in a build error because the missing file is referenced in the code.

Platform Information:

  • Laptop: Macbook Pro with M2 chip
  • Operating System: macOS [Version]
  • Development Environment: IntelliJ IDEA 2023.2.4
  • Java Version: OpenJDK 17
  • Protobuf Version: 3.x
  • Gradle: Embedded with the IDE

Additional Information:

  • I've verified that the issue is specific to macOS as the build process works as expected on a Linux system.
  • I had to change the name of one of the messages to resolve the issue, which is not an ideal solution.
  • It appears that the issue is related to the case sensitivity of file names in the macOS file system.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.