Skip to content
This repository was archived by the owner on Nov 27, 2018. It is now read-only.

Use Scala reflection api instead of scalap (2.10) #23

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

clhodapp
Copy link

First, please read the commit message:

Note: Scala reflection in Scala 2.10 is NOT threadsafe. As a result,
we need to be very careful about how we do things. This means:

  • Continuing to use Manifests instead of TypeTags, lest TypeTag
    materialization at the client site create safety issues
  • Protecting our usage of the api internally with locks (doing this
    successfully requires that we use a reflective Universe that is
    not shared with the outside world)

That said, there are a number of reasons to prefer the Scala reflection api
over scalap for type analysis. Here are a few:

  • Not an internal api
  • No transitive dependency on scala-compiler.jar
  • More user-friendly (It's still pretty prickly, but, of the two, it's better)

Now some commentary:

This is a rather big change for jacks, so I'd expect there to be a bit
of discussion before it's decided whether to merge this. Please be
aware that I've also written another version of this idea that actually
updates JacksMapper to use TypeTags instead of Manifests and
doesn't use (jacks-side) locking or a separate reflective universe for
each ScalaModule. Unfortunately, that version depends on Scala
2.11 (which makes Scala reflection threadsafe through internal
locking), so I'd expect that it'd be less likely to be merged than this
(though parallel branches would obviously be possible). In any case,
look for another pull request with that version soon, though you
obviously don't want to merge both of them.

Note: Scala reflection in Scala 2.10 is NOT threadsafe. As a result,
we need to be very careful about how we do things. This means:

* Continuing to use Manifests instead of TypeTags, lest TypeTag
  materialization at the client site create safety issues
* Protecting our usage of the api internally with locks (doing this
  successfully requires that we use a reflective Universe that is
  not shared with the outside world)

That said, there are a number of reasons to prefer the Scala reflection api
over scalap for type analysis. Here are a few:

* Not an internal api
* No transitive dependency on scala-compiler.jar
* More user-friendly (It's still pretty prickly, but, of the two, it's better)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant