Support Java Properties grammar.

[dscalzi]

A pain point for Java in VS Code is currently lack of in built-in highlighting for .properties files. This change allows Java projects to have highlighting out of the box when installing the standard extension pack.

If name changes are requested to the added files or folders, let me know. Thanks.

[rgrunber]

I think this would be a nice addition as it's not the first time there has been a request for the Java support to deal with this (See eclipse-jdtls/eclipse.jdt.ls#1676 )

If another extension has their own kind of ".properties" file they'd like to take control of, will this be annoying ? For vscode-quarkus, we have an option to update the language id programmatically (to quarkus-properties id for application.properties files), so at the very least extensions would have to do that going forward.

@angelozerr This seems pretty similar to https://github.com/redhat-developer/vscode-microprofile/blob/master/language-support/properties-support/java-properties.tmLanguage.json , although that also handles some unnecessary things like property references with ${...}. Are they pretty much the same ? I notice they both can't handle things like :

multiline = This line \
continues
oddKey = This is line one and\\\
# This is line two

but these are more corner cases.

[dscalzi]

Looks like the quarkus one is just extending the java-properties syntax from microprofile. The difference between the two grammars is that the one in this PR is pulled from TextMate, which is the typical source for most of the grammars in vs code. The one in microprofile appears to be a modification of the ini grammar.

Just from that I think the quarkus-properties and regular java-properties are probably the same format, so not sure we actually need to do some type of dynamic swapping? If I'm wrong about that, I would need some guidance as I'm not sure how that's achievable.

From a user perspective, when installing the Java language pack I'm often working with projects that contain .properties files. Those may be gradle.properties, application.properties with spring, or just custom .properties files that are read in using the JDK's provided utilities. Having the highlighting built-in eases set up and gives the appearance of a more polished experience for java development in the editor. Having to search for additional extensions on top of the standard extension pack is not ideal. I'm not aware of any other .properties uses that have a different syntax. If there are, one would think that you just disable the java extension in that project since it's likely not going to contain java sources anyway.

One more thing, having the grammar provided by this extension would allow extensions providing java specific themes to style the properties files with a semi-standard grammar. It's not ideal to target scopes from a separate extension and require users to install that on top of it. Also, providing the grammar as part of a theme somewhat exceeds the scope of a theming extension.

[datho7561]

I like how the key/value pairs use the correct textmate scopes in this PR, unlike the current MicroProfile one. Also @rgrunber it looks like it supports line continuations as long as there is at least one leading whitespace character on the new line.

I'm not aware of any other .properties uses that have a different syntax.

Just to comment on this; the microprofile properties file has a slightly different syntax from regular properties files, where you can use ${} to reference other properties in the property value. In order to allow vscode-microprofile to provide this extension to the grammar, I think we could use embedded languages. In order to support this, I think it would be a good idea to add a new textmate scope to match the "unquoted string" parts (excluding the \ when there is a line continuation) that has a more meaningful name, such as "meta.embedded.java-property-value".

[angelozerr]

@martinlippert @BoykoAlex I think this PR could interest you to colorize your Spring application.properties instead of maintaining your own TextMate grammar.

[dscalzi]

Most of the comments I'm seeing call for modifying the grammar. Should that be contributed to the textmate repo? It may not be accepted anytime soon.. even the main java grammar is missing the latest language keywords like record. As far as this PR is concerned, is there anything else needed?

[rzheng95]

Can we get this PR merged? It's very inconvenient to not have the support to be able to do ctrl + / to comment lines in .properties files. This would be very helpful.

[BoykoAlex]

Does anyone know how to re-use the java-properties grammar in a new language? Boot Tools introduce a language: spring-boot-properties as well as as the grammar for java-properties. I'd like to re-use the grammar from the java extension but keep the spring-boot-properties language. Is this doable? Or do I have to remove the spring-boot-properties and now deal with java-properties language? Thanks in advance!

[datho7561]

We re-use the java-properties for microprofile-properties in vscode-microprofile and then add additional scopes specific to MicroProfile: https://github.com/redhat-developer/vscode-microprofile/tree/master/language-support/properties-support (microprofile-properties.tmLanguage.json defines the language as extending java-properties, and microprofile-properties-injection.tmLanguage.json defines the extensions onto java-properties)

We also have another example in https://github.com/redhat-developer/vscode-quarkus/tree/master/language-support/properties-support, which extends the microprofile-properties language with Quarkus-specific features.

[BoykoAlex]

@datho7561 thanks very much!