Convert Properties to YML

Why Convert Properties to YML?

Converting Properties files to YML (the .yml extension for YAML) is the most practical path for modernizing Java application configuration. The .yml extension is the convention used by Spring Boot (application.yml), Docker Compose (docker-compose.yml), GitHub Actions, and GitLab CI. By converting to YML, your configuration speaks the same language as your entire deployment pipeline.

The .yml format dramatically reduces configuration file size by eliminating prefix repetition. A Properties file with 50 entries under spring.security.oauth2.client.registration.google. repeats that 47-character prefix on every line. In YML, the prefix appears once as indented hierarchy, reducing the file size and making the unique configuration values immediately visible.

Docker Compose is one of the most compelling reasons to adopt YML. Teams often maintain application.properties for their Spring Boot service alongside a docker-compose.yml for local development. Converting the Properties file to YML means developers work with one consistent format across application code and container orchestration, reducing context switching and configuration errors.

For CI/CD pipelines, YML is the universal configuration language. GitHub Actions workflows, GitLab CI/CD pipelines, CircleCI configs, and Travis CI all use .yml files. When your application configuration is also in YML format, your entire project from source code configuration to build pipeline to deployment manifests uses a single, consistent format that every team member understands.

Key Benefits of Converting Properties to YML:

• Industry Convention: .yml is the standard extension for Docker, CI/CD, and Spring Boot configs
• Smaller Files: Hierarchical structure eliminates 30-50% of redundant key prefixes
• Profile Consolidation: Combine multiple profile files into one .yml with --- separators
• Native Collections: YAML lists and maps replace comma-separated strings
• Pipeline Consistency: Match your CI/CD and Docker Compose configuration format
• Type Awareness: Automatic boolean, integer, and float detection
• DRY Config: Anchors and aliases enable shared configuration blocks

Practical Examples

Example 1: Docker-Ready Microservice Configuration

Input Properties file (application.properties):

# Service configuration
spring.application.name=inventory-service
server.port=8080

# Redis cache
spring.redis.host=redis
spring.redis.port=6379
spring.redis.timeout=2000

# RabbitMQ messaging
spring.rabbitmq.host=rabbitmq
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.virtual-host=/

Output YML file (application.yml):

# Service configuration
spring:
  application:
    name: inventory-service
  # Redis cache
  redis:
    host: redis
    port: 6379
    timeout: 2000
  # RabbitMQ messaging
  rabbitmq:
    host: rabbitmq
    port: 5672
    username: guest
    virtual-host: /

server:
  port: 8080

Example 2: CI/CD-Aligned Configuration

Input Properties file (build-config.properties):

build.java.version=17
build.gradle.wrapper=8.5
build.docker.registry=ghcr.io/myorg
build.docker.image.name=payment-api
build.docker.image.tag=latest
build.test.coverage.threshold=80
build.deploy.environments=dev,staging,production
build.deploy.strategy=rolling-update

Output YML file (build-config.yml):

build:
  java:
    version: 17
  gradle:
    wrapper: 8.5
  docker:
    registry: ghcr.io/myorg
    image:
      name: payment-api
      tag: latest
  test:
    coverage:
      threshold: 80
  deploy:
    environments:
      - dev
      - staging
      - production
    strategy: rolling-update

Example 3: Actuator and Monitoring Configuration

Input Properties file (monitoring.properties):

management.server.port=9090
management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.show-details=when-authorized
management.endpoint.health.probes.enabled=true
management.metrics.tags.application=order-service
management.metrics.tags.environment=production
management.metrics.export.prometheus.enabled=true

Output YML file (monitoring.yml):

management:
  server:
    port: 9090
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true
  metrics:
    tags:
      application: order-service
      environment: production
    export:
      prometheus:
        enabled: true

Frequently Asked Questions (FAQ)

Q: What is the difference between .yml and .yaml extensions?

A: There is no functional difference. Both .yml and .yaml use the identical YAML specification. The .yml extension became popular because early Windows systems had a three-character extension convention. Most DevOps tools (Docker Compose, GitHub Actions, GitLab CI) use .yml by convention, while the official YAML specification recommends .yaml.

Q: Does Spring Boot treat application.yml the same as application.properties?

A: Yes, Spring Boot processes both identically. The same property server.port=8080 in .properties maps to the same server: port: 8080 in .yml. If both files exist, application.properties values take precedence over application.yml values for the same keys.

Q: How does the converter handle Properties list values?

A: Comma-separated values like app.cors.origins=host1,host2,host3 are converted to YML sequences with each item on a separate line using the - prefix. Index-based list properties (e.g., app.servers[0]=host1) are also converted to proper YML array syntax.

Q: Can I use the YML output with Docker Compose?

A: The converter generates standard YAML/YML syntax that is compatible with Docker Compose and all other YML-based tools. However, Docker Compose has its own specific schema (services, networks, volumes). The converted output represents your application configuration data, which can be referenced from Docker Compose environment variables.

Q: How are multi-line property values converted to YML?

A: Properties files support line continuation with a trailing backslash. These are joined and converted to YML multi-line strings using the literal block scalar (|) or folded block scalar (>) syntax, preserving the original content while using proper YML formatting.

Q: Can I combine multiple Properties files into one YML file?

A: Yes, this is one of YML's key advantages. Multiple profile-specific Properties files (application-dev.properties, application-prod.properties) can be combined into a single application.yml using the --- multi-document separator with profile activation conditions.

Q: Does the converter preserve the order of properties?

A: The converter preserves property order while grouping related entries under common parent keys. Properties sharing the same prefix are placed together under their parent section in the YML hierarchy, which may reorder them compared to the original flat file but improves logical organization.

Q: Are there any Properties features not supported in YML?

A: All Properties features are supported in YML. The conversion handles Unicode escapes (\uXXXX), multi-byte characters, both = and : separators, line continuations, and comments. YML actually adds capabilities that Properties lack, including native types, arrays, and multi-document support.