Don't scan contents of every file in a Jar to determine if a classfile is a Scala one
Deciding if a classfile is Scala is expensive: it requires unzipping and parsing the classfile. The way the Aspect is designed forces us to take the decision very early (when a package is open), and the classfile might never be open or needed. We should cache this information per jar file.
This is particularly expensive if jars come from a network drive.
In scala-ide:492a546df849aa75d316bb8c95ee9c8b981f998d Cache info about jar files that might contain Scala classifies.
Deciding wether a class file is produced by Scala is expensive (it entails
parsing the binary). Instead, we cache the information per package fragment,
assuming that a jar contains Scala-only or Java-only classifies. For
mixed Java/Scala jars, behaviour depends on the first classfile that is
accessed. It might lead to using the Java icon/classfile editor for
Scala classfiles.
A more fine-grained strategy could be used (caching per package, instead
of jar file), but this patch has been running at a customer and solved
the issue, so we go for the tried-solution.
Fixes #1001999
In scala-ide:e02f826519c3b8e13fd949489a1eb2ae02a35e60 Cache info about jar files that might contain Scala classifies.
Deciding wether a class file is produced by Scala is expensive (it entails
parsing the binary). Instead, we cache the information per package fragment,
assuming that a jar contains Scala-only or Java-only classifies. For
mixed Java/Scala jars, behaviour depends on the first classfile that is
accessed. It might lead to using the Java icon/classfile editor for
Scala classfiles.
A more fine-grained strategy could be used (caching per package, instead
of jar file), but this patch has been running at a customer and solved
the issue, so we go for the tried-solution.
Fixes #1001999
(cherry picked from commit 492a546df849aa75d316bb8c95ee9c8b981f998d)
Conflicts:
org.scala-ide.sdt.core/src/scala/tools/eclipse/javaelements/ScalaClassFileProvider.scala