Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Betamax runtime exceptions don't seem to be compatible with java 7 #55

Closed
tomaslin opened this issue Jul 17, 2012 · 5 comments
Closed
Labels
Milestone

Comments

@tomaslin
Copy link

I have a tape that seems to be incompatible with Betamax.

This tape generates the following error in Java 6 -

| betamax.tape.TapeLoadException: Invalid tape
at betamax.tape.yaml.YamlTape.readFrom(YamlTape.groovy:34)
at betamax.tape.yaml.YamlTapeLoader.loadTape_closure1(YamlTapeLoader.groovy:37)

But in Java 7 it gives an incompatible runtime exception -

Failure: search returns correct information(com.kickscraper.ScrapeServiceSpec)
| java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.RuntimeException do not match. Expected 4 but got 5
at betamax.tape.yaml.YamlTape.readFrom(YamlTape.groovy:34)
at betamax.tape.yaml.YamlTapeLoader.loadTape_closure1(YamlTapeLoader.groovy:37)

See URL attached on issue 52 for url that is breaking

@erdi
Copy link
Contributor

erdi commented Jul 27, 2012

All you need to do to fix that is to write your exceptions in java - there was a new constructor added to Exception in JDK7 which currupts Groovy metadata about them. If you write them in java then groovy won't touch them and the problem will be solved.

@joesondow
Copy link

Does that mean it's no longer possible to write new exceptions in Groovy? Does anyone reading this know what version of Groovy will solve that problem?

@erdi
Copy link
Contributor

erdi commented Feb 15, 2013

You can write your exceptions in Groovy, the problem is that you cannot run Groovy exceptions compiled with JDK6 on JDK7 and you cannot run Groovy exceptions compiled with JDK7 on JDK6. It's pretty well explained why in my blog post. I have no idea why Groovy inspects the number of constructors on classes during compilation and checks if it is still the same during runtime and if/when this could change. You should probably raise that on Groovy user or dev mailing list.

@joesondow
Copy link

Agreed. My app needs to run in Java 6 and 7, and I don't want to make separate releases for them, so rewriting all my custom exceptions in Java seems like the best workaround for now. However, this limitation of Groovy seems like a significant problem, so hopefully a future version will address it. Thanks for your blog post on the subject.

@mahileeb
Copy link

mahileeb commented May 9, 2013

HandlerException.groovy and subclasses also need to be changed over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants