I have a project which is the code of an API.
In build.sbt the version of Scala is:
scalaVersion := "2.13.8"
In several Scala files I see imports using * instead of _ like this:
...
import sttp.tapir.*
...
How is that? It is my understanding that * can be used in Scala 3, but not in 2.1x ... I can't see any library (it's a big codebase) or something related to this ...
Why does it works instead of showing compiling errors?
To ease migration to Scala 3, some syntax of Scala 3 can be used in Scala 2.
See for instance the release note of Scala 2.13.7:
Align with Scala 3
...
Allow import x.{*, given} under -Xsource:3 (#9724 by #smarter)
...
(https://github.com/scala/scala/releases/tag/v2.13.7)
Though I'm not sure since when it is possible to use import X.* (in my understanding, this existed before 2.13.7).
Related
I have an interface:
trait MyInterface {
def doSomething(usefulName : Int) : Unit
}
I have a macro that iterates over the methods of the interface and does stuff with the method names and parameters. I access the method names by doing something like this:
val tpe = typeOf[MyInterface]
// Get lists of parameter names for each method
val listOfParamLists = tpe.decls
.filter(_.isMethod)
.map(_.asMethod.paramLists.head.map(sym => sym.asTerm.name))
If I print out the names for doSomething's parameters, usefulName has become x$1. Why is this happening and is there a way to preserve the original parameter names?
I am using scala version 2.11.8, macros paradise version 2.1.0, and the blackbox context.
The interface is actually java source in a separate sbt project that I control. I have tried compiling with:
javacOptions in (Compile, compile) ++= Seq("-target", "1.8", "-source", "1.8", "-parameters")
The parameters flag is supposed to preserve the names, but I still get the same result as before.
This has nothing to do with macros and everything to do with Scala's runtime reflection system. In a nutshell, Java 8 and Scala 2.11 both wanted to be able to look up parameter names and each implemented their reflection system to do it.
This works just fine if everything is Scala and you compile it together (duh!). Problems arise when you have a Java class that has to be compiled separately.
Observations and Problem
First thing to notice is that the -parameters flag is only since Java 8, which is about as old as Scala 2.11. So Scala 2.11 is probably not using this feature to lookup method names... Consider the following
MyInterface.java compiled with javac -parameters MyInterface.java
public interface MyInterface {
public int doSomething(int bar);
}
MyTrait.scala compiled with scalac MyTrait.scala
class MyTrait {
def doSomething(bar: Int): Int
}
Then, we can use MethodParameterSpy to inspect the parameter information name that the Java 8 -parameter flag is supposed to give us. Running it on the Java compiled interface, we get (and here I abbreviated some of the output)
public abstract int MyInterface.doSomething(int)
Parameter name: bar
but in the Scala compiled class, we only get
public abstract int MyTrait.doSomething(int)
Parameter name: arg0
Yet, Scala has no problem looking up its own parameter names. That tells us that Scala is actually not relying on this Java 8 feature at all - it constructs its own runtime system for keeping track of parameter names. Then, it comes as no surprise that this doesn't work for classes from Java sources. It generates the names x$1, x$2, ... as placeholders, the same way that Java 8 reflection generates the names arg0, arg1, ... as placeholders when we inspected a compiled Scala trait. (And if we had not passed -parameters, it would have generated those names even for MyInterface.java.)
Solution
The best solution (that works in 2.11) I can come up with to get the parameter names of a Java class is to use Java reflection from Scala. Something like
$ javac -parameters MyInterface.java
$ jar -cf MyInterface.jar MyInterface.class
$ scala -cp MyInterface.jar
scala> :pa
// Entering paste mode (ctrl-D to finish)
import java.lang.reflect._
Class.forName("MyInterface")
.getDeclaredMethods
.map(_.getParameters.map(_.getName))
// Exiting paste mode, now interpreting.
res: Array[Array[String]] = Array(Array(bar))
Of course, this will only work if you have the -parameter flag (else you get arg0).
I should probably also mention that if you don't know if your method was compiled from Java or from Scala, you can always call .isJava (For example: typeOf[MyInterface].decls.filter(_.isMethod).head.isJava) and then branch on that to either your initial solution or what I propose above.
Future
Mercifully, this is all a thing of the past in Scala 2.12. If I am correctly reading this ticket, that means that in 2.12 your code will work for Java classes compiled with -parameter and, my Java reflection hack will also work for Scala classes.
All's well that ends well?
I have code similar to below
import sqlCtx.implicits._
val items = sc.parallelize(List(i1, i2, i3))
items.toDF().registerTempTable("items")
When I hover over items I would like usual behaviour - displaying type information. Instead I get warnings Avoid wildcard imports and Imports should be grouped together. I can get rid of the first by importing specific function, like
import sqlCtx.implicits.rddToDataFrameHolder
but I can't put import on top of the file what IntelliJ expects of me since it imports from an object that is created with the code and not preexisting. How to workaround it?
I use IntelliJ IDEA v. 15.0.3 with the latest Scala plugin.
Assume you have two SBT projects, one called A and another called B
A has a subproject called macro, that follows the exact same pattern as showed here (http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Macro-Projects.html). In other words, A has a subproject macro with a package that exposes a macro (lets called it macrotools). Now both projects, A and B, use the macrotools package (and A and B are strictly separate projects, B uses A via dependancies in SBT, with A using publish-local)
Now, A using A's macrotools package is fine, everything works correctly. However when B uses A macrotools package, the following error happens
java.lang.IllegalAccessError: tried to access method com.monetise.waitress.types.Married$.<init>()V from class com.monetise.waitress.types.RelationshipStatus$
For those wondering, the macro is this one https://stackoverflow.com/a/13672520/1519631, so in other words, this macro is what is inside the macrotools package
This is also related to my earlier question Macro dependancy appearing in POM/JAR, except that I am now using SBT 0.13, and I am following the altered guide for SBT 0.13
The code being referred to above is, in this case, this is what is in B, and A is com.monetise.incredients.macros.tools (which is a dependency specified in build.sbt)
package com.monetise.waitress.types
import com.monetise.ingredients.macros.tools.SealedContents
sealed abstract class RelationshipStatus(val id:Long, val formattedName:String)
case object Married extends RelationshipStatus(0,"Married")
case object Single extends RelationshipStatus(1,"Single")
object RelationshipStatus {
// val all:Set[RelationshipStatus] = Set(
// Married,Single
// )
val all:Set[RelationshipStatus] = SealedContents.values[RelationshipStatus]
}
As you can see, when I use whats commented, the code works fine (the job of the macro is to fill the Set with all the case objects in an ADT). When I use the macro version, i.e. SealedContents.values[RelationshipStatus] is when I hit the java.lang.IllegalAccessError
EDIT
Here are the repos containing the projects
https://github.com/mdedetrich/projectacontainingmacro
https://github.com/mdedetrich/projectb
Note that I had to do some changes, which I forgot about earlier. Because the other project needs to depend on the macro as well, the following 2 lines to disable macro publishing have been commented out
publish := {},
publishLocal := {}
In the build.scala. Also note this is a runtime, not a compile time error
EDIT 2
Created a github issue here https://github.com/sbt/sbt/issues/874
This issue is unrelated to SBT. It looks like the macro from Iteration over a sealed trait in Scala? that you're using has a bug. Follow the link to see a fix.
This question already has answers here:
How do I get the Scala version from within Scala itself?
(4 answers)
Closed 1 year ago.
When trying to run some code in online interpreters or with IRC bots, I always wonder which version of Scala they support.
Is there a way to retrieve the version of Scala from within the interpreter?
For Scala 2, use scala.util.Properties.versionNumberString (or versionString):
scala> scala.util.Properties.versionString
val res0: String = version 2.13.6
scala> scala.util.Properties.versionNumberString
val res1: String = 2.13.6
For Scala 3, if you do the same thing, you may be surprised by the answer:
% scala3 -version
Scala code runner version 3.0.1 -- Copyright 2002-2021, LAMP/EPFL
% scala3
scala> scala.util.Properties.versionNumberString
val res0: String = 2.13.6
That's because Scala 3.0.x uses the Scala 2 standard library as-is, to aid migration, and makes only a small number of additions. (Eventually the standard libraries will no longer remain synchronized like this.)
Here's how to get the Scala 3 compiler version:
scala> dotty.tools.dotc.config.Properties.simpleVersionString
val res0: String = 3.0.1
This only works if the scala3-compiler JAR is on your classpath. (In the standard Scala 3 REPL, it is; in some other environments, it might not be.)
If the compiler isn't on your classpath and you want the full Scala 3 version string, see Dmitrii's answer.
If the compiler isn't on your classpath but you just want to find out at runtime whether you're on Scala 2 or 3, well... perhaps there's a cleaner/better way, you tell me, but one way that works is:
util.Try(Class.forName("scala.CanEqual")).isSuccess
Here, the choice of scala.CanEqual is arbitrary, it could be any of the small number of classes that are in scala3-library but not scala-library.
But if you are tempted to go that route, you might instead consider including version-specific source in your project, or passing the Scala version via sbt-buildinfo.
scala> scala.util.Properties.versionMsg
res: String = Scala library version 2.9.0.1 -- Copyright 2002-2011, LAMP/EPFL
Looks of course like the library version and not like the language version, but I think currently there won’t be a real difference in practice.
If you need just the version number without the "version" keyword you can use versionNumberString function.
scala> scala.util.Properties.versionNumberString
res1: String = 2.12.3
If you want to get the exact Scala 3 version, you can read it from the Manifest file
.../scala3-library_3-3.0.1.jar!/META-INF/MANIFEST.MF
import java.io.FileInputStream
import java.util.jar.JarInputStream
val scala3LibJar = classOf[CanEqual[_, _]].getProtectionDomain.getCodeSource.getLocation.toURI.getPath
val manifest = new JarInputStream(new FileInputStream(scala3LibJar)).getManifest
manifest.getMainAttributes.getValue("Implementation-Version")
Example in Scastie:
Someday, I'd like to learn Scala. What I see about the language from people who like it is very encouraging.
Today, though, is not that day. Today, I'd just like to make some changes to my team's build file. Unfortunately, this build file was put together with SBT, and is nearly incomprehensible.
My main issue is that it appears to me that SBT introduces some huge collection of new operators that do things with strings and lists to create some sort of sbt object. For example, in sbt:
"args4j" % "args4j" % "2.0.12"
Apparently is actually defined; however, I can't even tell what type it is at the scala repl, since at the repl I get the sensible error:
scala> val tstcrap = "args4j" % "args4j" % "2.0.12"
<console>:6: error: value % is not a member of java.lang.String
val tstcrap = "args4j" % "args4j" % "2.0.12"
I get this error even after setting up the classpath to include the sbt-launch.jar file and doing import sbt._.
Likewise, I'm dealing with stuff like this:
val jarSources = (descendents(classesOutput ##, "*") ---
assemblyExclude(classesOutput ##))
What's that ## operator, what's that --- doing, and more importantly what is the type of this expression? Are all these new operators documented somewhere, and is there some way to get a scala repl that's using the same language as is used in the sbt build files?
Looking at this sbt file reminds me of trying to decipher perl without ever reading any of the relevant man pages. (Not a recommended activity)
Update: After looking at the links in the answer below, and looking at other questions and answers tagged sbt, I've come across the major piece of scala knowledge that I was missing: scala allows one to define implicit conversions that will be invoked before methods are resolved. In this case, sbt defines inside the ManagedProject trait, an implicit conversion from String to the private class sbt.GroupID, so that
"a" % "b"
Is really something like
(new GroupID("a")) % "b"
I imagine the resolution order and other rules around implicit conversions must get very complicated; it almost reminds me of the nightmares you can introduce in C++ with operator overloading when done through non-member functions.
Since an SBT build file is a full-fledged Scala source file and relies on some libraries provided by SBT itself, it's difficult to cover SBT well without relying on some familiarity with Scala. I'm not aware of such a guide.
For the specific questions you raise, I think these wiki pages will help:
% operator for strings: http://code.google.com/p/simple-build-tool/wiki/LibraryManagement
## and --- operators: http://code.google.com/p/simple-build-tool/wiki/Paths
If you want to get a Scala REPL running with the SBT libraries available, try this:
$ sbt console-project
Some other useful commands are listed at http://code.google.com/p/simple-build-tool/wiki/RunningSbt .
Update 2016 (5 years later).
This is not a complete guide, but the article "Sbt heiroglyphs and multi-projects explained" from Divan Visagie can help starting to use sbt.
Plus, the sbt documentation is quite complete nowadays, and covers multiple projects in a single build.
The '---' operator is described in the PathFinder (since the 0.2 version).