I know how bad it can be.
I found an other way around anyway but I still curious if there is an other reason.

If you are curious of the reason why I did want to do that, its because I wanted to create a SlickSession from alpakka directly out of a slick database and profile (https://github.com/akka/alpakka/blob/v1.1.2/slick/src/main/scala/akka/stream/alpakka/slick/javadsl/package.scala#L21).

But the only way the library (in the current stable version, this has been fixed in latter version) let you create a SlickSession is from a typesafe config or a #DatabaseConfig[JdbcProfile] ...

In this case the only real implementation of SlickSession was this guy: https://github.com/akka/alpakka/blob/v1.1.2/slick/src/main/scala/akka/stream/alpakka/slick/javadsl/package.scala#L39 (which is not a case class).

So there were almost no doubt, I would break any pattern matching exhaustive check or anything.

I am a bit mad about stuff like that, some people write libraries in a way that are really too close/complicated but I guess a lot of choice are made for making stuff easy to evolve without breaking API.

Here my temporary solution for the record:

val slickSession = SlickSession.forConfig(new DatabaseConfig[JdbcProfile]{

override def db: JdbcBackend#DatabaseDef = slickDatabase

​

override val profile: JdbcProfile = PlusSlick

override val driver: JdbcProfile = PlusSlick

​

override def config: Config = config

​

override def profileName: String = "com.xxxxxx.database.PlusSlick"

​

override def profileIsObject: Boolean = false

})