UnsupportedClassVersionError in BCrypt when updating from lift 3.0-M6 to lift 3.0 or lift 3.0.1

31 views
Skip to first unread message

Robert Freytag

unread,
Jul 3, 2017, 8:27:54 AM7/3/17
to Lift
Hey there,

after updating my project from lift 3.0-M6 to lift 3.0 I get an Exception because of incompatible class files. 
In Boot I am creating default user accounts. This fails, because of the following error:

[WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@7dfcb28: java.lang.UnsupportedClassVersionError: net/liftweb/util/BCrypt : Unsupported major.minor version 52.0

java.lang.UnsupportedClassVersionError: net/liftweb/util/BCrypt : Unsupported major.minor version 52.0

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:800)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)

at java.net.URLClassLoader.access$100(URLClassLoader.java:71)

at java.net.URLClassLoader$1.run(URLClassLoader.java:361)

at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:421)

at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:383)

at net.liftweb.mapper.MappedPassword$$anonfun$4.apply(MappedPassword.scala:115)

at net.liftweb.mapper.MappedPassword$$anonfun$4.apply(MappedPassword.scala:115)

at net.liftweb.common.EmptyBox.openOr(Box.scala:862)

at net.liftweb.mapper.MappedPassword.real_i_set_$bang(MappedPassword.scala:115)

at net.liftweb.mapper.MappedPassword.real_i_set_$bang(MappedPassword.scala:43)

at net.liftweb.mapper.MappedField$class.i_set_$bang(MappedField.scala:517)

at net.liftweb.mapper.MappedPassword.i_set_$bang(MappedPassword.scala:43)


It seems like the util package was compiled against Java8 at build time? 

My Project is set up to run on Java 6 (maven compile target is set to that as well). 

I am basically compiling and running the same project, same settings, only upgraded the lift dependency.
I am running Scala Version 2.11.6.
java -version leads

java version "1.7.0_75"

Java(TM) SE Runtime Environment (build 1.7.0_75-b13)

Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)


The webserver is jetty 8.1.16.v20140903, which is compatible with Java 6.

I could fix this issue by updating to lift 3.1.0. 

I am not sure if I can move the codebase up to lift 3.1.0 like this. 

For people like me, who want to gradually update, it would be nice if you guys could look into rebuilding the sources for the 3.0 and 3.0.1 packages, so that the java classes are compatible for the expected version.

Regards

Robert - Big fan of Lift!

Robert Freytag

unread,
Jul 3, 2017, 8:37:33 AM7/3/17
to Lift
I have to correct myself, I see the same issue when updating to lift 3.1.0

Feels like this makes a lot of the newer lift 3 builds unusable for people like me, who still have to upgrade certain dependencies for a move to Java8

Matt Farmer

unread,
Jul 3, 2017, 9:19:19 AM7/3/17
to Lift
Hey Robert,

Sorry you ran into this, but yes we require Java 8 support as of Lift 3. This move was one of the many breaking changes that we saw as a part of the 2->3 major version bump.

This move was made as a result of requiring Java 8 to build for Scala 2.12 and maintaining Java < 8 compatibility in our build environment only for the Scala 2.11.x build being annoying. In addition to the fact that Oracle ended support for Java 6 many moons ago.

I tried to provide a link to some of the conversations about this on the ML but I'm currently on an iPad and Google Groups isn't playing nice. Feel free to search for "Java 6" and some of them should pop up.

If your organization has a local artifact repository set up, you should be able to build Lift 3.x for Java 6 with Scala 2.11.x, but this isn't really a supported configuration from our point of view. Aside from that, I'd encourage you to start the process of migrating now. Lift 2.6.x is still receiving critical security updates, so as we hear about issues in that realm we'll continue to patch them for awhile longer. Unfortunately, we're entirely volunteer driven and adding the complexity of building correctly on Java 6 _and_ Java 8 to our build process _and_ supporting that is a big ask on the volunteered time of the committers.

Robert Freytag

unread,
Jul 3, 2017, 9:31:41 AM7/3/17
to Lift
Thank you Matt. I will take your advice into consideration moving forward with our codebase. One comment though:

The hard Java 8 requirement for Lift 3 is something I did not really see documented anywhere (I have to say I am not reading up on EVERY posting happening in the lift community).

My main source for information is the changelog, which only states the scala version supported

With that information, my expectations towards dependencies go like this:
-> Which Scala Version is required by Lift 3.0 -> Either 2.11. or 2.12.
Okay take 2.11. -> Which java version do I require -> Java 6 

Having said all of that, I can understand your move towards Java 8 (I want to go there as well), so no need to post more thoughts on that. If you get the chance, maybe the version-dependencies towards java and scala can be made more explicit in the changelog. 

Regards and thanks for the fast reply

Robert

Matt Farmer

unread,
Jul 3, 2017, 9:39:53 AM7/3/17
to Lift
You expectations toward dependencies are understandable.

For what its worth, this was mentioned in the release notes for 3.0.0-M8: https://github.com/lift/framework/releases/tag/3.0-M8-release

Those release notes actually mentioned dropping Java 7, so perhaps we dropped Java 6 earlier than that. In any event, that wouldn't have been a change for 3.1.0 so it wouldn't have been mentioned in the release notes. But you've got a valid critique. We've been working on nailing down our communication strategy around releases so that it's clearer. The 3.1.0 release notes is the first where we summarize all the changes from the component milestones and I think we'll do that going forward for clarity.

I also just noticed that our README doesn't make any mention of the fact that we require Java 8. I'll get that fixed real fast.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

j...@joescii.com

unread,
Jul 3, 2017, 5:44:17 PM7/3/17
to Lift
I'm laughing at myself a bit because I spent last week migrating a Lift 2.6 app to 3.1 and had completely forgotten that Java 8 is a pre-requisite. Fortunately, we were already running 8 so it was no problem.

I don't know I'll have time to lead the charge, but I'd definitely be willing to help chip in things I learned to go towards writing a 2.x => 3.x migration guide.

Joe

Antonio Salazar Cardozo

unread,
Jul 6, 2017, 4:30:56 PM7/6/17
to Lift
Regarding migration documentation, there are a few entries on migration already at
https://github.com/lift/framework/tree/master/docs/migration . More are definitely welcome.

Another thing we could do here is to simply list the supported versions for Scala and Java
at the end of the release notes for all final releases as a matter of course. Since that information
is relatively stable, that could be a fairly easy change?
Thanks,
Antonio

Matt Farmer

unread,
Jul 10, 2017, 12:59:52 PM7/10/17
to Lift
Yeah, that could become a part of our regular release template.
Reply all
Reply to author
Forward
0 new messages