Welcome To Nirmalya!×
Feel Free to Contact us
Skip to main content

Java, a widely used programming language, offers various literals for creating values. However, wouldn't it be great if we could have even more options? Currently, Java supports literals for integers, floating-point numbers, strings, characters, booleans, and null values. Nevertheless, there are other data types, such as dates, regular expressions, and URIs, that would greatly benefit from having their own literals.

Current literals

Let's take a quick look at the literals that can be used in Java today:

  • Integer: 123, 12s, 1234L, 0xB8E817, 077, 0b1011_1010
  • Floating-point numbers: 45.6f, 56.7d, 7.656e6
  • String: "Hello world"
  • Character: 'a'
  • Boolean: true, false
  • Null: null
     

User-defined literals

In an ideal future version of Java, it would be fantastic to see support for user-defined literals. This would enable developers to convert sequences of characters into instances of their own classes by providing a mechanism within the class itself. Let's explore some examples using a possible syntax, denoted by backticks:

Currency currency = `GBP`;

LocalDate date = `2019-03-29`;

Pattern pattern = `strata\.\w+`;

URI uri = `https://blog.joda.org/`;

To enable this feature, several semantic features would be required: type inference, raw processing, and compile-time validation.

Type inference

Type inference is crucial for literals, and it would need to function similarly to existing literals in Java. However, a minor adjustment would be required to handle the new var keyword. In other words, these two versions would be equivalent:

LocalDate date = `2019-03-29`;

var date = LocalDate`2019-03-29`;

Type inference would also extend to methods, yielding a compile error if ambiguous:

boolean inferior = isShortMonth(`2019-04-12`);

public boolean isShortMonth(LocalDate date) {

  return date.lengthOfMonth() < 31;

}

Raw processing

Currently, Java's escape mechanisms can limit the processing of literals. However, user-defined literals should have access to the raw strings without these limitations. This would be especially beneficial for regular expressions and file paths on Windows. Consider the following examples:

// User-defined literals

var pattern = Pattern`strata\.\w+`;

// Today

var pattern = Pattern.compile("strata\\.\\w+");

In the above code, one can notice that the use of \ needs to be escaped, making the regular expression more difficult to read. If user-defined literals were supported, this drawback could be eliminated. Although there might be rare cases where this approach may pose problems, they would likely be rare edge cases.

Validated at compile-time

One of the key advantages of literals is that they are validated at compile-time. For example, using an integer literal to create an int would result in a compile-time error if the value is larger than the maximum allowed integer (2^31). Similarly, user-defined literals should also be parsed and validated at compile-time. Consider the following code that would fail to compile:

LocalDate date = `2019-02-31`;

Since most types that would benefit from literals only accept specific input formats, being able to check this at compile-time would be highly advantageous.

Implementation considerations

While there are various possible approaches to implementing user-defined literals in Java, it is ultimately up to those who control the JVM and the language to make the decision. onetheless, some aspects appear crucial. Firstly, there should be some form of factory method on the user class that performs the parse. This method could then be invoked by the compiler. Additionally, ideally, the results of the parse would be stored in the constant pool rather than having to be re-parsed at runtime.
 

It is worth noting that user-defined literals might eventually become a requirement to make value types more usable. Therefore, it is likely that Java will move in this direction in the future.


The addition of user-defined literals in Java would significantly expand the possibilities for developers. With the ability to create literals for various data types, such as dates, regular expressions, and URIs, Java would become more expressive and user-friendly. This feature would also improve type inference, enable raw processing, and provide compile-time validation for user-defined literals. While the specific implementation details remain to be determined, user-defined literals would undoubtedly enhance the Java programming experience.

Integrate People, Process and Technology