google
compiler.jar size is 40% larger, includes copy of Apache Ant
According to the message at [1], future versions of Closure Compiler binaries will no longer distributed from https://dl.google.com/closure-compiler/ URLs. When comparing the last published version in that endpoint at [2], with the one from NPM there is a substantial 8.3MB->12MB (40%) increase in the compiler.jar size.
Compare with the following commands:
wget https://dl.google.com/closure-compiler/compiler-20200719.tar.gz
tar xvfz compiler-20200719.tar.gz
ls -lah closure-compiler-v20200719.jar # 8.3MB
whereas the NPM version
npm install --no-bin-links --only=prod google-closure-compiler
ls -lah node_modules/google-closure-compiler-java/compiler.jar # 12MB
Is this increase expected?
[1] https://github.com/google/closure-compiler/wiki/Binary-Downloads [2] https://dl.google.com/closure-compiler/compiler-20200719.zip
It appears you're comparing a release from July against a release from October, so some change is expected. It's possible a change in how @nreid260 made releases affects this.
Is this a problem for you?
If you wanted to help on this bug, you could try diffing the contents of the jar file and paste your findings here.
Is this a problem for you?
We are including compiler.jar as part of the Chromium repository at https://source.chromium.org/chromium/chromium/src/+/master:third_party/closure_compiler/compiler/compiler.jar, which is why I am interested. A larger compiler.jar has overhead on trybots/buildbots and individual developers workstations. It's not a problem in the sense that nobody I know has complained about this increase yet, but I think it is reasonable to investigate if this bump is expected (feature additions to Closure compiler), or just an artifact of how it is built and distributed. This concern is also captured at https://bugs.chromium.org/p/chromium/issues/detail?id=1137293#c3
The fact that this bump happened when the distribution method changed makes me suspect the latter.
If you wanted to help on this bug, you could try diffing the contents of the jar file and paste your findings here.
I'll look into how to diff jar files. Having said that, I was hoping that someone from the compiler team could follow up on this using the repro steps above.
Jar files are just zip files, so you can unzip them both. It's unlikely we'll investigate this ourselves anytime soon (sorry!).
It's unlikely we'll investigate this ourselves anytime soon (sorry!).
That's unfortunate.
Jar files are just zip files, so you can unzip them both
Done. There are about 2000 more files in the latest version (4709 vs 6782 files) which kind of explains the size difference. After a quick inspection an entire copy of Apache Ant seems to be included within the NPM compiler.jar file, taking up 7.2MB (uncompressed, see org/apache/tools/ant/ within the jar).
Hopefully that's enough to have someone on the Compiler team investigate further? Including Apache Ant as part of compiler.jar seems unnecessary and possibly an accident? Let me know if this bug has better luck if I file it internally.
Thanks for looking, that does seem wrong. We'll leave this bug open, but we are pretty stretched for resources, so it's at the end of a long list of other bugs (that we'd also like to fix someday...).
so it's at the end of a long list of other bugs (that we'd also like to fix someday...).
Ok. That sounds like a P3/WontFix unfortunately. Thanks for the honesty though. Trying to give this a positive spin, I take it as a signal that we should accelerate our efforts to migrate to TypeScript in the Chromium codebase.
Doesn't compiling TypeScript still require Closure Compiler if you want small output?
Doesn't compiling TypeScript still require Closure Compiler if you want small output?
It's a bit tangential to the discussion here, but the answer is not necessarily. We already don't use Closure Compiler for minification in the Chromium repository. We use other tools for minification (https://github.com/terser/terser) and only leverage the Closure compiler for type checking.
Having said that a possible migration to TypeScript would be a long term project, and even if we started working on it today, we would still depend on Closure Compiler for quite a while (order of years possibly).
This also affects us - since the JavaScript version of Closure Compiler (jscomp.js) was retired, we're looking in to getting our own JavaScript/WebAssembly port of Closure Compiler. The jar file is already bigger than the rest of our entire web app. A 40% increase is therefore significant and further increases the download/load time users will face when loading Closure Compiler in the browser.
It sounds like a build system was accidentally included in the .jar file itself - hopefully that's just an accident that straightforward to correct.
Congratulations, now we have renamed (shaded) the Ant files in the output so you won't see why the jar file size is growing into infinity due to dependency hell. Rules out some further creative closure compiler use-cases. Or did I miss something? 😉
