diff --git a/app/views/libraryIdentification.scala.html b/app/views/libraryIdentification.scala.html
index b9baf0b..3a20e09 100644
--- a/app/views/libraryIdentification.scala.html
+++ b/app/views/libraryIdentification.scala.html
@@ -1,6 +1,15 @@
 @(dep: GroupedDependency, suppressionXmlIdOption: Option[String => String] = None, addLink: Boolean = true, addButtons: Boolean = true)
 @import com.ysoft.odc.Confidence
-@import scala.math.Ordered.orderingToOrdered
+@implicitOrdering = @{
+    // This implicit should not be theoretically needed, but missing this used to cause somehow non-deterministic scalac behavior:
+    // The first ….sortBy expression used to pass, while the second one used to fail sometimes. Even though both expressions are essentially the same.
+    // When these expressions are swapped, still the first (after swapping) one passes and the second one fails, no matter which one is the first and
+    // which is the second. So, it looks like some compiler bug related to mutable state.
+    // It also seems to be related to some compiler cache. It is somehow possible to compile it by incremental compilation and some code changes, but
+    // clean build deterministically fails at the second expression.
+    // So, making the implicit explicit is a workaround for this issue.
+    Ordering.Tuple4[Confidence.Value, String, String, String]
+}
 
 @if(!dep.identifiers.exists(_.confidence >= Confidence.High)){
     <span class="badge">file: @dep.fileNames.toSeq.sorted.mkString(", ")@if(addButtons){<span class="btn-xs library-identification-badge-hack">&nbsp;</span>}</span>