Re: [scala-user] Scala 2.9.0.RC1 erasing ParameterizedType details

[Maxime Lévesque]

Thanks Wille, that will be extremely valuable, it's too bad that we need to depend on scalap.jar, but OTOH sbt or maven does
compensate for this.
I'm replying to the list to let Dave W. that his nice contribution has been broken in 2.9.0-RC1, sorry for the bad news Dave ;( !

Keep up the nice work on Bowler !

2011/4/17 Wille Faler <wille...@gmail.com>

Hi,

So I've finally solved the dilemma with Parameterized types being erased, and I think I've also inadvertently solved your general issue with resolving default constructors.

Basically, I depend on the scalap.jar, which is easy enough to add to a sbt Project definition, and I retrofited some of the command-line tools to be more usable in an in-app context, to return a "ClassSignature" case class instead of printing to System.out.

These two classes are what you are probably interested in: https://github.com/wfaler/recursivity-commons/blob/master/src/main/scala/com/recursivity/commons/bean/scalap/ClassSignature.scala

..and: https://github.com/wfaler/recursivity-commons/blob/master/src/main/scala/com/recursivity/commons/bean/GenericTypeDefinition.scala

..the latter one was a pre-existing combinator-parser, the first one the new I created for this purpose.

I just finished this, so the code might still need a bit of cleaning up and prettifying, but for now, it seems to work and might give you an idea of how to solve some of your headaches.

Regards

Wille Faler

2011/4/10 Maxime Lévesque <maxime....@gmail.com>

Let me know if/when you find a solution, I'm interested !

2011/4/10 Wille Faler <wille...@gmail.com>

Thanks for all the input Paul, I might have found a solution that is workable, though at the cost of making scalap.jar a dependency of any project that wants to use this.

Basically, I looked at the Main.scala for the scalap.jar and tried to extract and slightly change the code where needed. I've got a rough gist of it here:

https://gist.github.com/912586 (and yes, it is basically Main.scala from scalap.jar slightly modified to be usable from within an application).

This is just a spike to see that it works, so might still be fragile, but from what I can see, it should work as a workaround - just get the signature, parse the resulting String and work out the generic types.

Not sure if this comes with a performance penalty, but time will tell..

Once I'm confident this will work, I'll put the code into my little Scala utilities library here: https://github.com/wfaler/recursivity-commons

Thanks again.

Wille Faler

2011/4/10 Paul Phillips <pa...@improving.org>

On 4/9/11 6:56 PM, Maxime Lévesque wrote:

Recently someone contributed a patch to "guess" the type inside the
Option, so the user only has to declare :

class Student(val name: String, val lastName: String, val age:
Option[Int], val gender: Int, val addressId: Option[Int])

Oh yeah, I just remembered that's how this works.

 https://github.com/paulp/optional

Anyway, you guys don't need to convince me that this sucks.  What you need to do is solve the problem better.  I'm not a magician, and if it's a choice between eclipse working and reflection conveniences working, eclipse is going to win.  I simply cannot table every other facet of the distribution to dive into this issue again.  You guys are enthusiastically encouraged to research the situation and assemble a convincing argument that the boxed types can be used without breaking things.

[David Whittaker]

Max,

Was this original thread from a mailing list?  If so, can you send me a link?  Is the issue that they are erasing the ParameterizedType info in 2.9.0?  That would be really troubling.  They'd basically be outputting invalid java byte code and I can't see how that would improve Eclipse support.

2011/4/18 Maxime Lévesque <maxime....@gmail.com>

[Maxime Lévesque]

This was the thread in the scala user list :

   https://groups.google.com/d/topic/scala-user/9B5Q2yupQ_E/discussion

The eclipse support will not suffer because building blocks for IDE functionality have been
introduced in the scala compiler jar. I haven't tries eclipse because IDEA has been good
for me, from what I hear eclipse support is now an order of magnitude better in 2.9

depending on scalap.jar will probably allow us to deduce Enumeration types, which I'm not sure
was possible using only reflection.

ML

[David Whittaker]

Ugh.  I don't like that at all.  I think that Enumerations were doable with the old method but without being able to get any information about AnyVal types the point is kind of moot.  I'll have to give this some thought.....

2011/4/18 Maxime Lévesque <maxime....@gmail.com>

[David Whittaker]

Ok, the bad news.... I get the feeling this is a done deal for 2.9 and we will definitely have to find another method (which is bound to be more complicated).

The good news..... I don't think we'll need to depend on scalap to get this done.  We already have a pretty nice bytecode library in ASM that comes along with CGLIB.  Hopefully I can read the information out of the class with that, parse it as Willie is doing, and properly deduce the type.  It may take me a little while to get it done, but I feel pretty confident that it's doable.

[Alec Wysoker]

Hi Folks,

I haven't followed this discussion very closely, but I had thought that 2.9 _fixed_ problems with type parameters being erased.  See http://lampsvn.epfl.ch/trac/scala/ticket/3897 .

I tried the following on a 2.9 nightly build from December, and found that the following worked and did not return None.

    val genericType = clazz.getDeclaredFields.apply(

0).getGenericType
    if (!genericType.isInstanceOf[ParameterizedType]) None
    else Some(genericType.asInstanceOf[ParameterizedType].getActualTypeArguments.apply(0))

Maybe I'm misunderstanding the current issue.

[David Whittaker]

Hi Alec,

The issue isn't that the signature doesn't exist, it's what it contains.  Java doesn't allow primitive types in generic signatures.  In the past if you defined val a: Option[scala.Int] you could extract the type parameter of the Option, but to make that possible the Scala compiler was outputting invalid byte code.  In 2.9 when a primitive is involved the the generic signature when you reflect on it you'll get Object instead which makes it impossible to deduce what is inside.  It's a pain, but I get why they did it.  As long as Scala exists on the JVM I'm afraid we're going to have to deal with these types of compromises.

[Alec Wysoker]

Grrrr.  Thanks for explaining.  Scala really needs a Scala-aware reflection API.

-Alec