Should be able to process directly from a jar file into an output jar file

[pfn]

This is actually a problem of processing proguarded jars on a case-insensitive filesystem (OSX, Windows, etc) and working with android

Typical build process that I do on android when using retrolambda:

1. compile classes
2. unpack all jars into retrolambda processing directory
3. run retrolambda
4. pack into a new jar
5. hand off to dex

The problem is at step 2, when one or more of the input jars is processed by proguard, it does name obfuscation in such a way that there might be class com.example.a and com.example.A (for example see crashlytics which has a com.crashlytics.android.a and com.crashlytics.android.A). When the jars are unpacked, the a and A classes become a single file which are now improperly named.

This happens whether with unpacking all jars, or running retrolambda after running proguard. This seems to be a pretty difficult problem to solve without having retrolambda process directly into output jar files to bypass filesystem case insensitivity issues.

[pfn]

A workaround would be to not run retrolambda against 3rd party jars, but that's kind of a hack. What if libraries I want to use (or write) make use of lambdas?

[pfn]

I have this workaround currently, and it works ok for now.

scala-android/sbt-android@1668579

[243826]

+1

My use case is really simple. I have a 3rd party project compiled for java 8. I want a java 7 version of it. I should be able to point retrolambda to the jar file (or better yet just specify that jar as a special dependency) and be able to get a new jar.

[akuma8]

Hi,
Do I need JDK 1.8 to be able to compile my code? I'm on JDK 1.7, I added the pluggin in my pom.xml but can't compile. The main issue is that my IDE (IntelliJ) do not authorized lambda as it's preconfigured with JDK 1.7. I tried Streamsupport library and it works perfectly but Stream without lambdas is annoying. Thanks...

[luontola]

Yes, you must compile with JDK 8.