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

Micro places compiled Java programs into incorrect directory when auto-compiling #3412

Open
ItzARubix opened this issue Aug 1, 2024 · 2 comments

Comments

@ItzARubix
Copy link

ItzARubix commented Aug 1, 2024

Description of the problem or steps to reproduce

Upon saving any Java program that throws no compiler errors, Micro will automatically compile and save a .class file with the same name as the .java file that was saved. However, when certain .java programs are saved as part of a package, Micro will place the compiled file in the wrong directory.

To reproduce:

  1. Create a directory to serve as your project source. I'm using ~/Documents/JavaProjects/ProjectSource, but you can use anything, and I'll just refer to this as src from now on.
  2. Create a folder such as src/MyPackage.
  3. Navigate to src/MyPackage and, using Micro, create a file such as src/MyPackage/PackagedClass.java. The class should include package MyPackage; as the first line, and the contents can probably be anything, as long as the result is a valid Java class. Upon saving, notice that Micro has taken the liberty of creating a new directory, src/MyPackage/MyPackage, and within this new directory, the compiled .class file can be found, src/MyPackage/MyPackage/PackagedClass.class. This is the crux of the issue. When correctly compiled, the resulting compiled class should be found in the same directory as the original .java file. (The reason this is an issue is because a developer may wish to structure their .java files in accordance with their package structure, and so having Micro create the compiled .class files in the wrong directory creates hassle and confusion).

I've also been able to create situations where a .java file in the default package causes the same issue on a much larger scale. For example, I had a situation where I had a file in /home/[User]/Documents/JavaProjects/TestCore/Test.java that, when saved after being edited with Micro, created a class in /home/[User]/Documents/JavaProjects/TestCore/home/[User]/Documents/JavaProjects/TestCore/Test.class, and I have... no idea how or why this happens. I'm not able to consistently reproduce it, with some projects it happens and with some it doesn't

I apologize if I have made any errors in my explanation, and please let me know if there is anything I should clarify or change.

Specifications

Commit hash: 68d88b5
OS: Linux
Terminal: Konsole (KDE's Terminal Emulator)

@ItzARubix ItzARubix changed the title Micro incorrectly compiles Java programs when auto-compiling Micro places compiled Java programs into incorrect directory when auto-compiling Aug 1, 2024
@Andriamanitra
Copy link
Contributor

Andriamanitra commented Aug 2, 2024

The reason this happens is that you have the built-in linter plugin enabled, and that calls javac -d CURRENTDIRECTORY CURRENTFILE to get diagnostics. This means that if your working directory is src/MyPackage/ instead of src/ it will create a new directory. I'm not sure why it's even doing full compilation instead of just checking for errors like it does for other languages (maybe javac can't do that?).

Anyway it seems you can work around the issue by adding this to your ~/.config/micro/init.lua to override the default linter for java:

function init()
    linter.removeLinter("javac")
    linter.makeLinter("javac", "java", "javac", {"%f"}, "%f:%l: error: %m")
end

I'm hesitant to make a pull request to change the default as I don't know java or how javac works – maybe there was a good reason to explicitly specify the output dir?

@ItzARubix
Copy link
Author

Thank you for the quick response. Removing the -d flag from the javac call in the linter plugin would probably fix the issue, but you bring up a good point about how there might be some reason behind setting it up the way that it currently is that would break if changed. I also appreciate the workaround that you provided. Thank you so much for your help.

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