Open hrj opened 9 years ago
Not a lot we can do if you're htiting jvm size limits. It's because the size of the files roughly doubles when instrumenting.
If it's that big though must be a monster of a class.
On 14 February 2015 at 17:38, hrj notifications@github.com wrote:
I was trying out sbt-coverge on this project https://github.com/darkfrog26/powerscala, and it runs some of the tests fine, but trips up on this one:
[error] powerscala/core/src/main/scala/org/powerscala/Language.scala:17: Could not write class org/powerscala/Language$ because it exceeds JVM code size limits. Method scala/Predef$ArrowAssoc$'s code too large! [error] object Language extends Enumerated[Language] { [error] ^ [error] one error found error Compilation failed [error] Total time: 13 s, completed Feb 14, 2015 10:59:22 PM
That's an admittedly large class, though it compiles fine when coverage is not enabled.
Is this something that can be addressed by the plugin in the future, or is the only solution to break up the Language class into smaller ones?
— Reply to this email directly or view it on GitHub https://github.com/scoverage/sbt-scoverage/issues/92.
even this class may be excluded for scoverage, regular scala compile will fail when this class size doubles. This class should be classifed as "code smell" class and need to be addressed there.
czl
This class should be classifed as "code smell" class and need to be addressed there
For my specific instance, I replaced a database table of 1000 records with a map in the code. This signficantly improves the applications performance, reduces complexity, failure surface, increases type-safety. Why would I introduce the potential of a config or database file being invalid and the startup overhead when I can just hardcode the data into the app? Especially considering in docker it's easier to deploy the app than patch the database. No need to learn SQL, use liquibase or provide backwards compatible support when deploying to a loadbalanced environment?
But whatever, guess I'll just have to find another way around this.
I was trying out
sbt-coverge
on this project, and it runs some of the tests fine, but trips up on this one:That's an admittedly large class, though it compiles fine when
coverage
is not enabled.Is this something that can be addressed by the plugin in the future, or is the only solution to break up the
Language
class into smaller ones?