Great question! Naming conventions for JMS destinations (Topics and Queues) are one of those things that seem trivial at first, but can cause real headaches if you don’t get consistent with them. Let’s break this down step by step.

Is there an official standard? #

First things first: The JMS specification itself doesn’t mandate a specific separator (slash vs. dot). The spec only requires that destination names are valid strings adhering to basic character rules (no control characters, etc.). That said, most JMS providers and enterprise teams have settled on de facto conventions based on tooling, compatibility, and team habits.

Does the convention matter? #

Absolutely—here’s why:

• Team consistency: Nothing slows down a team more than having half the topics named masterdata.customer and the other half masterdata/customer. New devs won’t know which to use, and you’ll end up with duplicate or misnamed destinations.
• Tooling compatibility: Many JMS management consoles, monitoring tools, and broker admin UIs treat separators as hierarchical markers. For example, slashes might trigger folder-like grouping in ActiveMQ’s console, while dots might be parsed like Java package names in some enterprise tools. Using a consistent format ensures your tools work as expected.
• Vendor-specific behavior: Some brokers (like ActiveMQ or RabbitMQ’s JMS adapter) use path-style naming with slashes to enable granular permissions—you can grant access to all masterdata/* destinations at once instead of each one individually. Dots, on the other hand, might align better with legacy systems like IBM MQ, which has long used dot-separated naming for queues.

Choosing between masterdata.customer and masterdata/customer #

Let’s weigh the pros of each approach to help you decide:

Dot-separated (masterdata.customer) #

• Familiarity for Java teams: If your team works primarily with Java, this aligns perfectly with package naming conventions (e.g., com.company.masterdata.customer). It feels intuitive and reduces cognitive load.
• Legacy system alignment: Traditional enterprise JMS providers (like IBM MQ or WebSphere MQ) have used dot-separated names for decades. If you’re integrating with older systems, this is the safer bet to avoid compatibility issues.
• Namespace clarity: Dots naturally segment names into logical domains (business area → entity), making it easy to scan and categorize destinations at a glance.

Slash-separated (masterdata/customer) #

• Hierarchical organization: Like a file system, slashes create a visual hierarchy that shines when you have dozens or hundreds of destinations. Tools will often fold these into expandable folders, making it way easier to navigate in admin consoles.
• Granular permissions: Modern brokers support path-based authorization. For example, you can give a service access to all masterdata/* topics without having to list each one individually—this is a huge win for security and maintainability in large systems.
• Cloud-native fit: Most cloud message services (even if they’re not pure JMS, like AWS SQS/SNS or Azure Service Bus) use slash-separated paths. If you’re building a cloud-native system, this convention will feel right at home.

Final Recommendation #

Pick one convention and enforce it across your entire stack. There’s no "right" answer, but consistency is everything.

• Go with dot-separated if you’re in a Java-heavy enterprise environment with legacy JMS integrations.
• Go with slash-separated if you’re using modern brokers, cloud services, or need hierarchical organization for a large number of destinations.

Avoid mixing the two at all costs—it’ll lead to confusion, tooling bugs, and unnecessary maintenance work down the line.

内容的提问来源于stack exchange，提问作者dleerob