don't create classes with same name but different case

[scabug]

This should not be done. Something has to be renamed.

for f in /scala/inst/210/lib/*.jar ; do jar tf $f |grep -i timeout ; done
scala/actors/StashingActor$ActorContext$$anonfun$receiveTimeout$1.class
scala/actors/Timeout$.class
scala/actors/Timeout.class
scala/actors/AskTimeoutException.class
scala/actors/TIMEOUT$.class
scala/actors/TIMEOUT.class
scala/actors/threadpool/TimeoutException.class

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-6315?orig=1
Reporter: @paulp
Other Milestones: 2.11.0-M1

[scabug]

@paulp said:
Marking as 2.10 blocker.

[scabug]

@vjovanov said:
The TIMEOUT.class is located in the scala-actors.jar and Timeout.class is located in the scala-actors-migration.jar. Is this still the problem?

If yes, the TIMEOUT is used in Scala actors so it can not be renamed. The Timeout is part of the actor migration and should be called Timeout so the users could smoothly move to Akka.

However, Timeout is rarely used through the public interface so we can do all accesses to Timeout through the Timeout object and then rename the Timeout class to something else (e.g. AkkaTimeout). This should not affect the migration much since it would be used through the Timeout object methods.

[scabug]

@paulp said:
This is still the problem, yes. It doesn't matter that they're in separate jars; they are both on the standard classpath. If you explode the jars they will ovewrite one another on a case-insensitive filesystem. The are numerous situations where this has a chance of biting people; there's no reason to do it. In fact splitting the package across multiple jars breaks OSGI, as someone noted elsewhere.

[scabug]

@retronym said:
Invoking the Boy Scout Rule: The fix for this bug should also include a test case to prevent the same category of bug from occurring in the future.

[scabug]

@vjovanov said:
Good to know, I will move the Actor Migration Kit to the 'scala.actors.migration' package and close the bug.

Separately from this bug I will make the test that checks for future occurrences of this problem in the build. IMO it is not clean to write this test within the partest suite. I would rather include it into the ant tasks pipeline as a script or a plugin.

The script/plugin would explode all jars from the distro and check if two files residing in the same folder have different capitalization. This will be achieved by converting all entries in the distro jars to lowercase and checking if there are duplicates. Then it will do an equi-join on the package path of each jar's entries with all other jars in the distro and check that there are no results.

What would be the preferred way to do the test? Java as an ant plugin or python/bash in the ./tools invoked from the ant?

Where should the script reside in the ant pipeline and should I hook it in Jenkins?

[scabug]

@paulp said:
I don't think you need to work that hard. I can manage it from the repl.

% scala210 -nobootcp
Welcome to Scala version 2.10.0-20120910-085856-19e783b655 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_06).
Type in expressions to have them evaluated.
Type :help for more information.

scala> ( (sys.props("java.class.path") split ':').toList
    flatMap (p => new scala.tools.nsc.io.Jar(p).iterator)
    map (_.getName) 
    filter (_ endsWith ".class")
    groupBy (_.toLowerCase)
    collect { case (k, vs) if vs.size > 1 => f"$k%30s -> $vs" }
    foreach println
)

   scala/actors/timeout$.class -> List(scala/actors/Timeout$.class, scala/actors/TIMEOUT$.class)
    scala/actors/timeout.class -> List(scala/actors/Timeout.class, scala/actors/TIMEOUT.class)

scala> 

[scabug]

@vjovanov said (edited on Sep 12, 2012 12:40:24 PM UTC):
Here is the second part. One day we can put it into the build workflow.

val jars = (sys.props("java.class.path") split ':').toList

val jarPackages = jars.map(j => j.toString.drop(j.toString.lastIndexOf("/") + 1)).
  zip(jars.map(p =>
    new scala.tools.nsc.io.Jar(p).iterator.
    map(_.toString).
    filter(_.endsWith(".class")).
    map(s => s.take(s.lastIndexOf("/"))).toSet)
  ).toSet

jarPackages.foreach {case (n1, j) => 
  j foreach {p =>
    jarPackages filterNot(_._2 == j) foreach { case (n2, jj) =>
      if (jj.contains(p)) println(s"($p from $n1) duplicated in $n2")
    }
  }
}

Output is:
(scala/tools/nsc/io from scala-compiler.jar) duplicated in scala-reflect.jar

Don't know if this is a problem for OSGI?

[scabug]

@retronym said:
Can't you just pop this into a run test in partest? I don't think it's such an abuse of the facility?

[scabug]

@vjovanov said:
Makes sense for our use case.

Shall I put "(scala/tools/nsc/io from scala-compiler.jar) duplicated in scala-reflect.jar" into the check file?

[scabug]

@paulp said:
Partest doesn't have all the jars on the classpath; at least, the one you guys are using doesn't. (Mine does.) it is a problem/bug that scala.tools.nsc.io is split across jars, one I raised already: it's #6305.

[scabug]

@vjovanov said:
I see, than we have to include it into the build. However, this is not critical for this release so I will open a new ticket under the enhancement category. The code is there it just needs to be added to the build.

[scabug]

@gkossakowski said:
Fixed in scala/scala#1291.