JDriven Blog

Helidon SE Helpings: Default Configuration Sources

Posted on by  
Hubert Klein Ikkink

When we use Helidon SE we can use the Config class to pass configuration properties to our application. The static method create() creates a default configuration. The Config class is then configured to support different input sources. This configuration reads configuration properties from the following sources in order:

  • Java system properties,

  • system environment variables,

  • a file on the classpath that has the name application.properties (based on default config parser that is part of the artifact helidon-config).

The last input source behaves differently based on which classes that can parse a configuration file are on the classpath of our application. If we use the helidon-config artifact on the classpath then the configuration file read is application.properties. To read a JSON formatted configuration file we must add the helidon-config-hocon artifact to the classpath. The file that is read is application.json. With the same artifact we can read a HOCON formatted configuration file that is named application.conf. Finally if we add the helidon-config-yaml artifact to the classpath we can read a YAML formatted configuration file that is named application.yaml or application.yml. Helidon SE will only read one configuration file from the classpath with the following order of preference:

  • application.yaml or application.yml,

  • application.conf,

  • application.json,

  • application.properties.

Continue reading →

Structurizr for Maintainable architecture

Posted on by  
Johan Kragt

Simon Brown’s C4 Model for architecting your software solutions provides a clean and structured way of modeling software. Structurizr is not a new tool, but with some new "Solution Architecture" responsibilities flowing my way I was looking for a way to create maintainable models. I found Structurizr extremely useful for creating easy to maintain models to use and change(!) during discussions with architects and developers alike.

Continue reading →

Write your own mock

Posted on by  
Ronald Koster

We all know mocking libraries like Mockito or Mockk to mock classes in our unit tests. They can be convenient to mock I/O with external systems by replacing the boundary classes (aka. DAO = Data Access Objects) with mock objects. That way we do not require a full-blown simulator of that external system. However, mocking using these libraries also has some drawbacks. One way to avoid these drawbacks is to write your own mocks.

Continue reading →

Vrijheid en Uniformiteit in Softwareontwikkeling; Hoe draagt een Enablement Team hier aan bij

Posted on by  
Willem Cheizoo

Binnen softwareontwikkeling worden teams vaak geconfronteerd met een spanningsveld tussen keuzevrijheid en standaardisatie. Aan de ene kant zorgt keuzevrijheid ervoor dat teams tools en technologieën kunnen kiezen die het beste aansluiten bij hun specifieke behoeften en hun persoonlijke voorkeuren. Aan de andere kant kan standaardisatie juist helpen om uniformiteit en stabiliteit binnen een organisatie te waarborgen. De sleutel tot het vinden van een gezonde balans ligt in het ondersteunen van beide doelen, mogelijk door het introduceren van een Enablement team. Ik leg graag uit waarom.

Continue reading →

Spring Boot Sweets: Using Duration Type With Configuration Properties

Posted on by  
Hubert Klein Ikkink

With @ConfigurationProperties in Spring Boot we can bind configuration properties to Java classes. The class annotated with @ConfigurationProperties can be injected into other classes and used in our code. We can use the type Duration to configure properties that express a duration. When we set the value of the property we can use:

  • a long value with the unit to express milliseconds,

  • a value following the ISO-8601 duration format,

  • a special format supported by Spring Boot with the value and unit.

Continue reading →

Java Joy: Using JShell With Standard Input

Posted on by  
Hubert Klein Ikkink

The Java Development Kit (JDK) includes a tool called jshell that can be used to interactively test Java code. Normally we run jshell and type Java code to be executed from an interactive shell. But we can also use jshell as a tool on the command line to accept standard input containing Java code to be executed. The output of the code can be used as input for another tool on the command line. We run jshell - to run jshell and accept standard input. The simplest way to pass Java code to jshell is to use echo to print the Java code to standard output and pipe it to jshell.

Continue reading →

InnerSource: Open Source mindset through Tech Culture

Posted on by  
Erik Pronk

In our day to day work we are always striving to innovate and deliver high-quality software. One technique that could help you be more successful in achieving these goals is inner source. Inner source refers to applying open source principles within an organization. It is about adopting the collaborative, transparent, and decentralized approach commonly seen in open source projects and applying it to the organization’s internal software development.

Continue reading →

shadow-left