Unable to convert the placeholder <some value> in a valid argument - NOT FIXED in 2.3.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the Unit test in Intellij

What is the expected output? What do you see instead?
1. I upgraded to 2.3.1 as I was getting "Unable to convert the placeholder" 
issue randomly in 2.2 version. Now I am getting this issue consistently even on 
Unit test.

What version of the product are you using? On what operating system?
1. Version 2.3.1 of Lambdaj in Windows 7.

Please provide any additional information below.
We are already using Lambdaj extensively in our project and we need a fix for 
this at the earliest.

Thanks,
Venkatesh Nannan
ThoughtWorks.

Original issue reported on code.google.com by nvenky on 1 Oct 2010 at 1:35

Attachments:

• LambdaJTest.java

[GoogleCodeExporter]

We found that changing the RatingType enum in the test class to a class fixes 
it. So problem might be related to handling the enums. 

Original comment by nvenky on 1 Oct 2010 at 1:38

[GoogleCodeExporter]

I am sorry, but there is no way I can fix this. As you can read here:

http://code.google.com/p/lambdaj/wiki/KnownLimitations

this is a well known limitation of lambdaj. Unfortunately in Java final classes 
are by definition not extensible and then not proxable. And enum are final by 
definition as well. That's why you experienced that you "fixed" the problem by 
converting the enum in a normal class. For the same reason I can say I am sure 
this particular use case never worked in any lambdaj version. If you found it 
sometimes worked it cannot be no more than a lucky coincidence.

Original comment by mario.fu...@gmail.com on 1 Oct 2010 at 9:47

• Changed state: WontFix

[GoogleCodeExporter]

Thanks for your response and that explains few things.

But, when I looked on the net for "Unable to convert the placeholder" it takes 
me to Defect #33, which was related to race condition and we have faced the 
same issue in our project as well. Upgrading Lambdaj to 2.3.1 actually fixed 
it. When I encountered this issue again, I immediately thought this is one of 
such cases that was not handled.

It will be great if we could get detailed error message on this case so that 
others don't get misguided as I did.

Thanks,
Venky.

Original comment by nvenky on 1 Oct 2010 at 11:16

[GoogleCodeExporter]

Sorry again, but I am afraid that also to give a more detailed error message is 
not feasible. Let me explain why quickly. When you invoke the on() method on a 
given class a proxy extending that class (or implementing that interface) is 
created. Then every time you invoke a method on that proxy, the invocation is 
registered and another proxy, with the same characteristic of the former one, 
but implementing the type returned by the invoked method is created. This chain 
of proxy get broken when you hit a final class (or an enum as in your example) 
because I cannot create a proxy for it (damn Java). In that case a plain 
instance of that class is returned and it acts as a placeholder that I can bind 
to the invocations sequence. But this instance, not being a proxy, is totally 
outside my control, so if you invoke another method on it, the result is 
completely not deterministic under my point of view. In other words this last 
invocation must be avoided but I have no way enforce that, so it is up to the 
lambdaj user to avoid it. In the end, what you experienced is that lambdaj 
cannot convert that placeholder (the object returned by the method invoked on 
the enum) in an invocations sequence and this is the only type of error I can 
report.

I hope this makes sense, but if you have any further doubt about it feel free 
to email me. The same applies if you have any suggestion to improve the 
lambdaj's behavior in this particular case.

P.S.: if you or your colleagues are using lambdaj and you find it useful, it 
should be great if you could leave a couple of sentences about your experience 
here:

http://code.google.com/p/lambdaj/wiki/WhoIsUsingLambdaj

Original comment by mario.fu...@gmail.com on 2 Oct 2010 at 1:20