Skip to content

Fix occasional ClassCastException when parsing Maven pom.xml files #8460

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Achal1607
Copy link
Collaborator

@Achal1607 Achal1607 commented Apr 26, 2025

When you open any Maven project, when Netbeans tries to parse pom.xml sometimes it shows the class cast exception as seen in issue oracle/javavscode#378 and oracle/javavscode#185. The root cause is if some of the modules are not included like org.netbeans.modules.editor.structure and org.netbeans.modules.editor.deprecated.pre65formatting, then LspMavenErrorProvider class sends document as FilterDocument instead of NbEditorDocument which causes this class cast exception. Since, FilterDocument extends StyledDocument and not LineDocument which is required by the BaseDocument.

This PR addresses above mentioned issue by introducing a new utility method that accepts a Document and ensures it is returned as a BaseDocument. If the given Document is already an instance of BaseDocument, it is returned as-is; otherwise, it is converted accordingly.
This approach ensures that the implementation remains agnostic to the available modules, providing a consistent and reliable way to work with BaseDocument regardless of the module configuration.

@Achal1607 Achal1607 added Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) Maven [ci] enable "build tools" tests labels Apr 26, 2025
@Achal1607 Achal1607 requested review from mbien, dbalek and lahodaj April 26, 2025 11:57
Copy link
Member

@mbien mbien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feel free to force push right away since the changeset is small.

@Achal1607 Achal1607 added the VSCode Extension [ci] enable VSCode Extension tests label Apr 28, 2025
@Achal1607 Achal1607 force-pushed the class-cast-exception branch from 97f4e99 to 7e4b75e Compare April 28, 2025 05:25
@Achal1607 Achal1607 requested a review from mbien April 28, 2025 05:25
@Achal1607 Achal1607 closed this Apr 28, 2025
@Achal1607 Achal1607 force-pushed the class-cast-exception branch from 7e4b75e to 92eb77d Compare April 28, 2025 08:25
@Achal1607
Copy link
Collaborator Author

Hey @mbien, Can you please review the PR?

@lahodaj
Copy link
Contributor

lahodaj commented May 5, 2025

The comment on line 79 talks about a possible deadlock, referring to this issue:
https://bz.apache.org/netbeans/show_bug.cgi?id=236116

It is not completely clear if the deadlock can still happen. But some care is probably needed here.

I wonder if the requirement for BaseDocument still applies - what would break if simply an ordinary Document would be used to create the ModelSource?

Alternatively, if the BaseDocument is really needed by the users of ModelSource, maybe the Document can be wrapped to BaseDocument in Utilities.createModelSource around line 187 using the approach from Utilities.getDocument? (Although the code to create the BaseDocument out of thin air in Utilities.getDocument seems dubious to me.) Possibly factor the BaseDocument creation out of the getDocument method, or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) Maven [ci] enable "build tools" tests VSCode Extension [ci] enable VSCode Extension tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants