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

bugfix: Use classpath jar for defining run classpath #4868

Merged
merged 1 commit into from Jan 20, 2023

Conversation

tgodzik
Copy link
Contributor

@tgodzik tgodzik commented Jan 17, 2023

Previously, we would use the classpath as string which might be too long on some systems for example on Windows. Now, we define it using jar with the classpath defined inside its manifest. This also benefits other system since it makes the path shorter.

The jar will only be created once per classpath change and deleted on exit.

Fixes #4827

@tgodzik tgodzik force-pushed the fix-java-classpath branch 3 times, most recently from c8974e4 to b0d536e Compare January 18, 2023 20:44
@tgodzik
Copy link
Contributor Author

tgodzik commented Jan 19, 2023

Opinions? Should we always add the classpath jar or add a specific case when the classpath is too long? Having it always makes the commandline much shorter.

Copy link
Member

@ckipp01 ckipp01 left a comment

Choose a reason for hiding this comment

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

Hey! This make sense to me. Nice solution. Just a couple questions/nit.


val out = Files.newOutputStream(manifestJar.toNIO)

Using.resource(new jar.JarOutputStream(out, manifest)) { jol =>
Copy link
Member

Choose a reason for hiding this comment

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

Just ignore me if this doesn't make sense because in my head I was trying to think about what this looks like but was struggling with it. Since we're managing mutliple resources here should we maybe be using Using.Manager, or does that not fit here because of the jol == null check deciding what we call close() on. That's not 100% clear to me.

Copy link
Member

Choose a reason for hiding this comment

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

+1 for answers! :D

  1. Shouldn't JarOutputStream take care of closing out?
  2. can constructor of JarOutputStream return null?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. It does close out so it's safe to only run close one one.
  2. It can't, but it can throw.

I reworked it a bit and also wrapped it all in Try to be on the safe side.

Copy link
Member

@ckipp01 ckipp01 left a comment

Choose a reason for hiding this comment

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

LGTM!

Previously, we would use the classpath as string which might be too long on some systems for example on Windows. Now, we define it using jar with the classpath defined inside its manifest. This also benefits other system since it makes the path shorter.

The jar will only be created once per classpath change and deleted on exit.

Fixes scalameta#4827
@tgodzik tgodzik merged commit ee6eef4 into scalameta:main Jan 20, 2023
@tgodzik tgodzik deleted the fix-java-classpath branch January 20, 2023 19:25
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

Successfully merging this pull request may close these issues.

Metals won't run application due to length of classpath/command line on Windows
3 participants