Skip to content
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

Lombok in Java 9 makes Netbeans 9.0 go crazy #1617

Closed
victorwss opened this issue Mar 19, 2018 · 4 comments
Closed

Lombok in Java 9 makes Netbeans 9.0 go crazy #1617

victorwss opened this issue Mar 19, 2018 · 4 comments

Comments

@victorwss
Copy link
Contributor

victorwss commented Mar 19, 2018

I already reported this here sometime ago. [Edit: It was in #1435. It also relates to #985]

Trying to use lombok in Java 9 within a Netbeans 9.0 project makes the IDE go crazy spamming a lot of IllegalArgumentException: URI is not absolute exceptions making it unusable.

The cause of the issue is that Netbeans 9.0 uses javax.tools.JavaFileObject instances and calls toUri().toURL() on them. But this happens in code specific to handle modules, so it will only trigger in Java 9. To be precise, this happens in the org.netbeans.modules.java.source.parsing.PatchModuleFileManager.java class.

The toURL() method throws that exception when it is called in a URI that is not constructed as an absolute URI. This was never a problem until now, but now it is.

The JavaFileObject javadocs do not say anything about requiring or not that the URIs should be absolute. Jan Lahoda from the Netbeans project replied:

I believe the code in NetBeans expects that it will get JFOs which NetBeans
has constructed. Which apparently is not the case here. This is not a
completely wrong assumption: I am not aware about any API that would allow
to inject external JFOs into javac. I guess a solution here might be to
ignore unknown JFOs, which is what the standard file manager in javac is
doing, for better or worse.

After hacking around lombok, I determined that the offending JavaFileObject is an instance of lombok.javac.apt.EmptyLombokFileObject. The name which produces the bad URI is lombok.dummy.ForceNewRound0 and it is produced in the forceNewRound(String, JavacFiler) method of the lombok.javac.apt.LombokProcessor class.

A simple fix would be to rewrite the toUri() method of EmptyLombokFileObject. Instead of this:

	@Override public URI toUri() {
		return URI.create(name);
	}

Let's use this:

	@Override public URI toUri() {
		return URI.create("file://" + name);
	}

After that, I:

  1. Recompiled lombok with my changes.
  2. Closed Netbeans and obliterated its cache in the disk.
  3. Replaced the lombok.jar in my project with the one that I compiled.
  4. Restarted Netbeans and reopened my project.
  5. Profit!

And, it worked like a charm. A simple one-line fix!

Ok, to be fair, I had to twist some other things in order to make it able to compile in my Java 9 environment, but this is for some other issue. I don't think that this is really important here, but I should say it anyway in the case of somebody else failing to reproduce my fix.

Should I submit a PR on that?

Side note: Some people on Netbeans side are very angry about lombok due to unhappy past iteractions here. Surely, there are many things that we all could improve...

victorwss added a commit to victorwss/lombok that referenced this issue Mar 24, 2018
Signed-off-by: Victor Williams Stafusa da Silva <[email protected]>
@victorwss
Copy link
Contributor Author

Relevant PR: #1626

rzwitserloot added a commit that referenced this issue Apr 4, 2018
@rspilker
Copy link
Collaborator

rspilker commented Apr 9, 2018

Merged related pull request.

@rspilker rspilker closed this as completed Apr 9, 2018
@victorwss
Copy link
Contributor Author

@rspilker @rzwitserloot Can we have an edge release with this?

@rspilker
Copy link
Collaborator

rspilker commented Apr 9, 2018

The edge release is available.

tmurakam added a commit to tmurakam/lombok that referenced this issue Apr 16, 2018
…ontain authority part.

fix degrade of projectlombok#1617, the file URI must starts with 'file:///', not 'file://'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants