# JavaParserDefinition v. LanguageSyntaxDefinition

**URL:** <https://platform.jetbrains.com/t/javaparserdefinition-v-languagesyntaxdefinition/2669>\
**Category:** IntelliJ Platform\
**Created:** [September 4, 2025, 1:46am UTC](https://platform.jetbrains.com/t/javaparserdefinition-v-languagesyntaxdefinition/2669 "2025-09-04T01:46:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rsmckinney](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/rsmckinney/32/506_2.png) [@rsmckinney](https://platform.jetbrains.com/u/rsmckinney)\
**Post date:** [September 4, 2025, 1:46am UTC](https://platform.jetbrains.com/t/javaparserdefinition-v-languagesyntaxdefinition/2669/1 "2025-09-04T01:46:28Z")

</div>

The IJ platform provides nice APIs for working with template languages. For instance, `MultiplePsiFilesPerDocumentFileViewProvider` and other components of the API make it straightforward to combine multiple languages within a single document/editor.

I’ve been using a derived Java language as the embedded scripting language within my template plugin successfully for many years. But now that the Java parser has migrated to the “syntax” API, I’m running into gaps such as `JavaParserDefinition` v. `LanguageSyntaxDefinition`. I’m trying to align my LanguageSyntaxDefinition impl with code that expects JavaParserDefinition and it’s not working out well.

Is there some way to bridge these two worlds, or a plan to provide one?

---

<div class="post-metadata">

**Author:** ![yuriy.artamonov](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/yuriy.artamonov/32/48_2.png) [@yuriy.artamonov](https://platform.jetbrains.com/u/yuriy.artamonov)\
**Post date:** [September 4, 2025, 6:18am UTC](https://platform.jetbrains.com/t/javaparserdefinition-v-languagesyntaxdefinition/2669/2 "2025-09-04T06:18:38Z")

</div>

It is unlikely that we have anything like that if we have no such features/needs in the codebase

---

<div class="post-metadata">

**Author:** ![rsmckinney](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/rsmckinney/32/506_2.png) [@rsmckinney](https://platform.jetbrains.com/u/rsmckinney)\
**Post date:** [September 5, 2025, 5:25pm UTC](https://platform.jetbrains.com/t/javaparserdefinition-v-languagesyntaxdefinition/2669/3 "2025-09-05T17:25:37Z")

</div>

It turns out my dependency on the old Java parser can still work as-is.

The manifold template engine uses Java as a scripting language - editor support frozen at JDK 24/25 isn’t a big deal, since compiler and runtime will continue to be compatible with the latest JDK compiler.

The only concern I have now is that the IJ platform does not deprecate the old parser API for removal. I suppose if that happens, I can still maintain a copy of it for my own use.

I am still a bit surprised, though, that support for the Java language is now completely separate from custom languages; IJ has two language systems now: one based on `ParserDefinition` and one based on `LanguageSyntaxDefinition`. Where the former is compatible with all other existing platform APIs, and the latter not so much.