Open GoogleCodeExporter opened 8 years ago
Original comment by brice.du...@gmail.com
on 31 Oct 2010 at 10:19
This issue was closed by revision 966a8bc0e0.
Original comment by szcze...@gmail.com
on 31 Oct 2010 at 8:25
Original comment by brice.du...@gmail.com
on 1 Nov 2010 at 10:48
Original comment by brice.du...@gmail.com
on 3 Nov 2010 at 1:48
More on Javassist there :
http://www.csg.is.titech.ac.jp/~chiba/javassist/tutorial/tutorial.html
Original comment by brice.du...@gmail.com
on 16 Dec 2010 at 4:30
So.... this is now a serious bug that means no code under JDK7 will run -when-
compiled a JDK7 compile target.
Has any movement been done on switching to Javassist at all?
Original comment by m...@talios.com
on 27 Nov 2011 at 11:38
A movement has begun, but you don't switch that easily to another lib just like
that, especially since this project is mostly done on our free time which is
sparse.
Original comment by brice.du...@gmail.com
on 28 Nov 2011 at 8:56
Hmmm, are you saying Mockito does not work under java7?
Original comment by szcze...@gmail.com
on 6 Dec 2011 at 12:32
ASM 4.0 supports JDK7, and I've tried to update the sources under cglib-and-asm.
I rebuilt mockito, however this didn't solve the problem.
I'm still getting this:
Caused by: java.lang.VerifyError: Bad type on operand stack in aaload in method
...
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
at java.lang.Class.getDeclaredConstructors(Class.java:1853)
at org.mockito.internal.creation.jmock.ClassImposterizer.setConstructorsAccessible(ClassImposterizer.java:70)
at org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:65)
It seems the guys at jetbrains have solved a similar issue:
http://youtrack.jetbrains.net/issue/IDEA-71870
Just in case I'm attaching the updated cgi-lib/asm sources.
Original comment by idls...@gmail.com
on 9 Feb 2012 at 10:22
Attachments:
Hi,
Yeah we know about ASM 4, unfortunately, we are using CGLIB that is using ASM.
If CGLIB doesn't use ASM with new class format instruction then it won't work.
And CGLIB does seem to be a dead project. I definitely would like to spend more
time here, but right now I don't have this free time luxury.
Actually our best shot would be to try with Javassist. There might be actually
some progress on that matter.
Original comment by brice.du...@gmail.com
on 10 Feb 2012 at 8:45
Anyway thank you so much for your time investigating the problem and possible
solutions :)
Original comment by brice.du...@gmail.com
on 10 Feb 2012 at 8:47
But you're using the repackaged version of both cglib and asm. So I assumed
that replacing a repackaged asm 3.x with a repackaged asm 4.0 and subsequent
refactoring of the repackaged cglib would to the trick.
Unfortunately I was wrong, there is obviously some little detail missing.
Original comment by idls...@gmail.com
on 10 Feb 2012 at 2:20
At this point I'm guessing. ASM is pretty low level, if some *new* instructions
are not used to generate a correct bytecode for the JVM 7 then it won't solve
the issue. As ASM guys actually made a huge effort to keep the API of version 4
backward compatible. And as said for now that is CGLIB that issue these
instructions to ASM.
Original comment by brice.du...@gmail.com
on 10 Feb 2012 at 2:28
@idlsoft, we will gladly accept patch for the cglib-asm we ship mockito with if
it solves some problem and does not break existing functionality.
First things first, though. What problem we are trying to solve? Are you saying
that Mockito does not work with jvm7? If that's the case we need a separate
ticket to track it and let's start a discussion there.
Cheers!
Original comment by szcze...@gmail.com
on 11 Feb 2012 at 3:17
Hi. Seems that cglib resurrected. 3.0 was released yesterday:
http://sourceforge.net/news/?group_id=56933
Not yet in maven central.
Original comment by eduardo.macarron
on 26 May 2012 at 4:12
BTW regarding the license Javassist adopted the ASL 2.0 since 3.15.
Original comment by eduardo.macarron
on 27 May 2012 at 6:54
Thanks for the info. At the moment we're not actively pursuing replacing cglib.
There does not seem to be a huge benefit of doing this.
Users are welcome to try out javaassist (or other tools) via Mockito's
MockMaker interface. It is an extension point that enables using custom proxy
creation mechanism and avoid using current default (cglib).
Original comment by szcze...@gmail.com
on 27 May 2012 at 2:16
Thx for the update.
I took a look at what they changed, unfortunately it doesn't really help in our
case right now.
- They moved to ASM4
- They changed a few interfaces of their own
Most of the previous issues are still there, however this might be good news as
the project might see future works.
Original comment by brice.du...@gmail.com
on 29 May 2012 at 6:58
Hi Brice. Not sure if that is good news.
We at MyBatis were thinking about going javassist due to cglib inactivity. Now
there is not that inactivity! :) But I am not sure if this is a signal for
future improvements. The new version was not released by one of the regular
cblib devs and it is not yet in maven central and I do not know if it will be.
Original comment by eduardo.macarron
on 4 Jun 2012 at 2:48
[deleted comment]
I hope that javassist support will be available as optionally attachable
artifact (in maven terms) out-of-the-box. It seems that CGLIB mock maker
couldn't handler non-public super classes but Javassist version can.
I pulled out the initial source code but it wasn't compatible with latest
release. It also suffered from the fact that already proxied classes having
Proxy(Object) interface(es) already in them are not supported. It's quite easy
to get the first non javassist super class and gather interfaces that are left
behind on the way. Of course this will not work if the javassist proxies are in
the middle of the class hierarchy.
Original comment by TuomasKi...@gmail.com
on 8 Aug 2012 at 9:12
Hi Eduardo,
A few months / weeks ago I took the opportunity to try Javassist as the
bytecode engine, but I was a bit disappointed : some NPEs in generated bytecode
in some cases, some bridge method error on call site (some bridge methods were
not found when the JVM performed some late binding), plus unpractical stuff in
the API. However I'm talking about the proxy factory.
Still, I heard that the javassist transformers do seem to work well. Johan uses
them with Powermock.
In my opinion, a new bytecode engine, maybe on top of the good ASM4. By the way
this guy is crafting a fluent API over ASM4 : https://github.com/qmx/jitescript
Original comment by brice.du...@gmail.com
on 8 Aug 2012 at 9:22
@tuomas I'v stopped working on javassist, as I had to patch Javassist myself.
I've proposed a patch, but there's no movement on that front either. And there
is still NPEs in generated bytecode, that I didn't investigated.
And I would rather avoid important modifications on Javassist anyway, so we
updating the javassist code would be a no-brainer task.
Also I've seen movement on the CGLIB front, like CGLIB 3 (which appears to be
in a very young development state). Still the project site is a mess. I don't
know how the team is commited. (I understand this an opensource project, but a
better transparency would be very welcome). I don't know what their plan is.
They still use CVS. etc.
Original comment by brice.du...@gmail.com
on 8 Aug 2012 at 9:38
@brice Thanks for the info. CgLibMockMaker is a no-go for me due to '2. you are
trying to stub a final method, you naughty developer!' but luckily I got the
general idea from your code and I wrote a version that I could use. I hope that
it doesn't blow up in any of the situations where I'm using it. BTW:
ClassPathLoader doesn't work correctly under OSGi environment and hence I got
thrown back to default CgLibMockMaker implementation.
Original comment by TuomasKi...@gmail.com
on 16 Aug 2012 at 10:04
@tuomas Could you fill a bug, and even best if you have a fix or an
environement were we can reproduce, that would be awesome !
Original comment by brice.du...@gmail.com
on 16 Aug 2012 at 10:08
About spring : https://jira.springsource.org/browse/SPR-9669
They finally decided to keep CGLIB, and jarjar it as well. It seems they are
using CGLIB 3, which we must investigate the changes (Spring had problems with
this version it seems but they hotfixed it, see the issue link)
Original comment by brice.du...@gmail.com
on 4 Dec 2012 at 9:55
Original issue reported on code.google.com by
brice.du...@gmail.com
on 3 Sep 2010 at 4:02