Convert Anything to dot.case

dot.case Converter,Convert Text to dot.case

In JVM ecosystems and configuration hierarchies, dot.case gives each word its own segment. Java package names follow it (com.example.app), configuration file keys use it (server.port, spring.datasource.url), and Maven artifact IDs adopt it for group and package identifiers.

Yet dot.case does not appear in file system paths (that is path/case) or CSS (that is kebab-case). Its domain is configuration hierarchies and JVM ecosystem conventions. That keeps package and config names readable across nested layers.

Where dot.case is used

Java uses dot.case for package names, following the Java Language Specification convention of reversed domain plus package path: com.example.auth.¹ Spring Boot and other Java frameworks use dot-separated keys in application.properties: spring.datasource.url, server.servlet.context-path.² Maven and Gradle use it for group IDs: org.springframework.boot, io.micronaut.³ Furthermore, JavaScript config files like .npmrc and Webpack treat dot-separated keys as nested property paths. In the .NET ecosystem, namespace names follow dot.case: System.Collections.Generic, Microsoft.Extensions.Logging.⁴ Environment variable names in some Windows contexts use dot-separated hierarchies, though this is less common than underscores. Logging frameworks across languages (Log4j, Serilog, NLog) use dot-separated logger names that mirror the class hierarchy,⁵ making dot.case the standard for log configuration. The convention appears anywhere a hierarchical namespace needs a flat string representation that remains human-readable while preserving the nesting structure of the underlying system.

Edge cases: numbers, slashes, and existing dots

Numbers follow the same boundary rule as other case formats: "version2Release" becomes "version.2.release". Slashes and backslashes (present in file paths) are also treated as word boundaries and replaced with dots. Consequently, a filesystem path "com/example/auth" converts to "com.example.auth" correctly. Existing dots in the input are treated as separators rather than preserved as-is, which means re-converting an already dot.case string produces the same result. Windows-style backslash paths like "com\example\auth" convert identically to forward-slash paths, producing "com.example.auth" in both cases. Consecutive separators of any type (multiple dots, multiple slashes, or a mix) collapse to a single dot, so "com..example...auth" normalizes to "com.example.auth" without empty segments. CamelCase input within dot-separated segments, like "spring.data.mongodbUri", splits the camelCase portion and produces "spring.data.mongodb.uri". Handling all of these edge cases in a single pass is what makes the converter reliable when you are migrating a mixed-format configuration base to a consistent dot.case convention.

Workflow: converting a directory path to a Java package name

Building on this, here is the common workflow: you have a directory structure src/main/java/com/example/auth/service and want the package declaration. Paste the path segment "auth/service" or "com/example/auth/service" into the converter, and the dot.case output is your package name. The tool handles every segment of the path in one pass, so you get the fully qualified package name without manually replacing each separator character.

Package declarations from service paths

When you create a new Java package from an existing directory structure, the directory hierarchy becomes the package name with dots as separators. "auth/service" becomes "auth.service", and "com/example/auth/service" becomes "com.example.auth.service". Every subdirectory under the source root maps to a segment in the fully qualified package name, which means a deeply nested service class carries its entire ancestry in its package declaration. CapyToolkit processes each line independently, so converting multiple service paths in one pass produces a list of package names ready to use in import statements without manual renaming at each level.

The ancestry in the package name pays off when you read the code later. A developer scanning an import can tell exactly where a class lives in the source tree without opening the file. You can produce those import names in CapyToolkit by pasting your service paths and converting them, then copying the dot.case output straight into your Java files so the package and the directory agree.

Spring Boot application.properties key structure and dot.case conventions

Spring Boot's externalized configuration system reads application.properties files using dot-separated hierarchical keys. The key hierarchy mirrors Java package naming: spring.datasource.url, server.port, management.endpoints.web.exposure.include. When you add a new configuration property, choosing the correct dot.case key before writing it prevents refactoring later. Each layer of the hierarchy maps to a segment in the dot-separated key, so a deeply nested property like the health check endpoint path reads as a natural extension of the package structure it belongs to.

Spring's relaxed binding accepts underscores and hyphens as alternatives to dots in some contexts, but the canonical form in application.properties uses dots.² The Spring documentation lists all standard properties in dot.case, so matching that format makes it easier to search for the property in the documentation. Paste camelCase or snake_case property identifiers from your Java code in to get a Spring property key right before it reaches the application.properties file.

Converting Spring configuration keys between formats

Spring Boot applications frequently need the same configuration value in multiple formats across different layers of the application, and keeping those values synchronized by hand is a common source of deployment errors. A DATABASE_URL environment variable maps to spring.datasource.url in application.properties and to @Value("${spring.datasource.url}") in Java code. Converting between these three formats manually is error-prone because each layer expects a different separator convention. Paste the environment variable name, convert to dot.case, and use the output as both the application.properties key and the Spring @Value expression without any additional transformation. CapyToolkit processes each line independently, so converting a full set of database, cache, and queue configuration properties takes one paste.

Java logging framework configuration keys in dot.case

Java logging frameworks (Log4j 2, Logback, SLF4J) use dot-separated logger names derived from class names. Logger names follow the fully-qualified class name format: com.example.auth.UserService.⁵ Understanding this convention matters when configuring per-package log levels in logback.xml or log4j2.xml. The dot-separated hierarchy mirrors the Java package structure, so a logger configured at the com.example level applies to every class in that package and all its subpackages without needing individual entries for each class.

Logger configuration in Logback uses the name attribute on <logger> elements: <logger name="com.example.auth" level="DEBUG" />. This name must use dot.case matching the Java package structure. If your package is com.example.auth but you configure the logger as com-example-auth, the configuration is silently ignored and the logger falls through to the root level. Paste your Java package names into this converter to verify the dot.case format before writing logger configuration.

Logback XML configuration and logger naming

Logback's logback.xml supports package-hierarchy logger configuration: setting com.example to WARN suppresses debug output from all classes under that package. Adding a finer-grained com.example.auth logger at DEBUG re-enables debug logs for that specific package without affecting others. Getting the dot.case package name exactly right in the name attribute determines which classes the rule applies to, because a mismatched separator causes the configuration to be silently ignored. CapyToolkit converts each line independently, so converting an entire list of package names for a multi-module application takes one paste.

When to use this

Use this when writing Java package names from directory paths, generating Spring Boot property keys from camelCase method names, or formatting Maven artifact identifiers.

Examples

authService
userRepository
paymentGateway

auth.service
user.repository
payment.gateway

server_port
spring_datasource_url
app_jwt_secret

server.port
spring.datasource.url
app.jwt.secret