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

Jar almost 50MB large as it bundles Scala language #586

Open
JanWittler opened this issue Aug 11, 2022 · 4 comments
Open

Jar almost 50MB large as it bundles Scala language #586

JanWittler opened this issue Aug 11, 2022 · 4 comments
Labels
enhancement Issue/PR that involves features, improvements and other changes

Comments

@JanWittler
Copy link
Contributor

The JPlag Jar is currently 46.8 MB large which appears unnecessary high to me. If unpacked, you can see that this is mainly due to bundling the entire Scala language which unpacked is 77 MB.
This is not a critical issue but we should think about how we can reduce the memory footprint of the Jar.
Options I currently see are to use a different Scala language module parser or to somehow dynamically poll language modules instead of always bundling all.

@JanWittler JanWittler added the enhancement Issue/PR that involves features, improvements and other changes label Aug 11, 2022
@tsaglam tsaglam added this to the v4.0.0 milestone Aug 11, 2022
@dfuchss
Copy link
Member

dfuchss commented Aug 11, 2022

The positive thing is that as soon as we clean up the dependencies.
Only the packaged CLI will has this large size. (And of course, everyone who uses scala)

@tsaglam tsaglam removed this from the v4.0.0 milestone Sep 13, 2022
@tsaglam
Copy link
Member

tsaglam commented Feb 9, 2023

In the future, we may release two versions of JPlag (and thus two Jars):

  • Slim: Only the main programming languages
  • Full: All programming languages, modeling languages and text

@alberth
Copy link
Contributor

alberth commented Mar 6, 2023

Currently there is a need for @MetaInfServices(de.jplag.Language.class) in a language (unless that is old information).

Can't that be used to make an empty JPlag framework jar, and a bunch of jars (one for each language) so the user can download the parts they want and combine them locally?

@tsaglam
Copy link
Member

tsaglam commented Mar 7, 2023

Currently there is a need for @MetaInfServices(de.jplag.Language.class) in a language (unless that is old information).

Yes, the languages are currently located by the service loader.

Can't that be used to make an empty JPlag framework jar, and a bunch of jars (one for each language) so the user can download the parts they want and combine them locally?

Yes, that would be possible. Each language could be an additional jar; running them locally would require them to be in the same directory, afaik. We currently, however, favor a solution where we have two versions of JPlag to download. A base version with the most commonly used languages that has a small size. And then an extended version including the larger language modules and more exotic languages like the EMF modeling language module. However, this decision is not final so there is still room for discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issue/PR that involves features, improvements and other changes
Projects
None yet
Development

No branches or pull requests

4 participants