UnsupportedClassVersionError when trying to render Scalate content

[virtualeyes]

Anyone ever hit this?

I have no idea why, but am getting the following errors:
"org/scalatra/servlet/ServletContextWrapper : Unsupported major.minor
version 51.0"
"java.lang.UnsupportedClassVersionError: org/scalatra/servlet/
ServletApplicationContext"

when trying to render Scalate content.

Have had a perfectly working setup for weeks on end and then this show
stopper comes up. 5 hours and counting down the tubes.

Sending "foo" directly to the response works just fine; the error
occurs when attempting to templateEngine.layout(), but debug log shows
that Scalate in fact finds the target layout and view. Normally at
this point content is rendered to the browser.

I have seen posts on the net re: these errors related to compiling
with one java version and running with another. I have made no
changes: java home is the same; "which java" is the same;
"alternatives --display java", the same; eclipse jdk points to java
home; everything compiles just fine in both eclipse and sbt, but when
trying to run against jetty instance in web browser, I get the above
errors. WTF is going on here ;-)

Running jdk 1.6.0_22 with SBT 0.11.2. build.sbt dependencies:
"org.scalatra" % "scalatra" % "2.1.0-SNAPSHOT",
"org.scalatra" % "scalatra-scalate" % "2.1.0-SNAPSHOT",
"org.scalatra" % "scalatra-lift-json" % "2.1.0-SNAPSHOT",
"org.scalatra" % "scalatra-anti-xml" % "2.1.0-SNAPSHOT",
"org.scalatra" % "scalatra-fileupload" % "2.1.0-SNAPSHOT",
"org.scalatra" % "scalatra-specs2" % "2.1.0-SNAPSHOT" % "test",
"org.eclipse.jetty" % "jetty-webapp" % "8.1.0.RC5" %
"test;container;provided",
"javax.servlet" % "javax.servlet-api" % "3.0.1" % "provided",
"ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
"org.clapper" %% "grizzled-slf4j" % "0.6.8"


Ideas much appreciated! btw, have blown away .ivy2, .m2, sbt clean
update reload, eclipse project clean, no change, I'm really at a loss
here...

[Ivan Porto Carerro]

oh, I need to set the java version to java 6. The default java version
on that server has changed.

sorry about that

[Massimiliano Mazzarolo]

It seems that scalatra-user itself has been compiled with java7.

Massimiliano

[virtualeyes]

you rascal! ;-)

well, I guess I learned a few things along the way, was probably going
to hit this at some point anyway (new to JVM)

So, by "The default java version on that server has changed", I assume
you mean Jetty 8.1.0.RC5 is running Java 7?

If so, for Scala users (who write little Java), is there any real
benefit to switching to 1.7? I'm all for it if it enhances the
developer experience, but if it's YAGNI, I'll stay on 1.6.

Glad I posted, could have been a long weekend of groping in the dark.

Let me know when you can get the change in place and I'll give it a
test.

Thanks!

[Ivan Porto Carrero]

I meant the default java version on the build server responsible for publishing the scalatra snapshots has changed from java 6 to java 7 because we, as a company switched to java 7 :).  Chef just did a good job I suppose. 

I've configured the scalatra builds to use java 6 instead and new jars have been published to sonatype.  

[Ross A. Baker]

On Fri, Apr 27, 2012 at 3:05 PM, virtualeyes <sit...@gmail.com> wrote:
> If so, for Scala users (who write little Java), is there any real
> benefit to switching to 1.7? I'm all for it if it enhances the
> developer experience, but if it's YAGNI, I'll stay on 1.6.

You might get a little bit better performance and some new APIs which
you're unlikely to depend on as a Scala developer. However, Java 6
reaches EOL in November 2012. That means that you'll stop getting
security updates, and you'll find more libraries dropping support for
Java 6 in the coming months. We still support 6 because Scala
supports 6 and we don't need anything introduced in 7.

A Java upgrade is not nearly as troublesome as a Scala upgrade. Java
7 should be backward compatible with Java 6, both source and binary.
So it's low risk for a low immediate payoff, but expect that rest of
the world is going to push you toward Java 7 later this year, and plan
accordingly.

--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA

[virtualeyes]

Ah, ok that makes sense, the build server compiles class files to java
7, thus the unsupported class error when trying to run my java 6 web-
app via sbt-jetty. Now I get it, was not clear before what the source
was, thought nothing had changed.

Cleaned project and voila, it works again ;-) yes!

Thanks for getting that in place, Ivan

[virtualeyes]

Sure, Java 7 performance bump, why not. Already running latest &
greatest of CentOS/Scalatra/Jetty/MySQL/Redis, bleeding edge is fine
with me.

I'll grab Java 7 and give it a go.

Now, another matter is, will Scalatra 2.10 work with upcoming Scala
2.10? Hope so ;-)



On Apr 27, 10:39 pm, "Ross A. Baker" <ba...@alumni.indiana.edu> wrote:

[Ross A. Baker]

On Fri, Apr 27, 2012 at 5:31 PM, virtualeyes <sit...@gmail.com> wrote:
> Now, another matter is, will Scalatra 2.10 work with upcoming Scala
> 2.10? Hope so ;-)

Some version of Scalatra will support Scala 2.10, but the version
number is to be determined. Like many others, we have abandoned the
cross build conventions of SBT <= 0.11 starting with Scalatra 2.1.
Scalatra 2.1 supports all Scala 2.9.x.

SBT 0.12 offers a simpler convention. If widely adopted, we'll follow
it. If not, then Scalatra for Scala 2.10 will get its own version
number. But one way or another, we will support Scala 2.10.

[virtualeyes]

Ross,

great, there is some Scala 2.10 goodness I'd like to integrate into
Scalatra projects, most notably the new scala-based reflection
(apparently reflection is "bad", but I'd sure like to be able to peer
into my case classes at runtime and generate, for example, a form to
create a new Foo without having a Foo case class instance)

Switching to the JVM and Scala is the single best decision I have ever
made as a programmer ;-)

Thanks to you guys for such a great project!


On Apr 28, 2:07 am, "Ross A. Baker" <ba...@alumni.indiana.edu> wrote: