Java 7 about rxandroid HOT 26 CLOSED

One data point: Eclipse ADT (as of ver. 23) has been requiring Java 7 for Lollipop-targeted builds: http://developer.android.com/tools/sdk/eclipse-adt.html

from rxandroid.

I think we should keep it at Java 6. API 18 and below still represent a significant market share, and if we start compiling against Java 7 we might easily include some bytecode that wasn't compatible on API 18.

I don't think there's much value-add by dropping support for Java 6. As long as we're diligent about using the right versions of other plugins that we're using, it should be fine.

That being said, I think we could deploy a final Java 6 supported version, include that in the Readme, and then encourage people that need to only support Java 6 to either use that or Retrolambda.

from rxandroid.

+1 to @ronshapiro comments

from rxandroid.

Ok agreed. Any suggestions how to test this before shipping? I would like
to prevent the scenario I described earlier to ever happen if we stick with
Java 6. There's not enough visibility around the Java tool chain right now
and Gradle seems to pick up whatever your shell's javac is?

from rxandroid.

I think the Jar's manifest should have the version, right? You could make
it a gradle task to check that before uploading. Not sure of a declarative
way of enforcing the compiler to be a particular version.
On Oct 22, 2014 11:21 AM, "Matthias Käppler" [email protected]
wrote:

Ok agreed. Any suggestions how to test this before shipping? I would like
to prevent the scenario I described earlier to ever happen if we stick with
Java 6. There's not enough visibility around the Java tool chain right now
and Gradle seems to pick up whatever your shell's javac is?

Reply to this email directly or view it on GitHub
#37 (comment).

from rxandroid.

@ronshapiro something like this?

allprojects {
sourceCompatibility = 1.6
targetCompatibility = 1.6
}

from rxandroid.

Java 7 (and Retrolambda) are compatible with all android versions, as long as the build tools are 19.0.0 or higher, with the single exception of try with resources which requires minSdkVersion 19!
Technically there is no harm in using it...
See the official documentation.

from rxandroid.

Eugenio, this is not an Android / DEX question, it's about the byte code
language level. Class files compiled with level 7 can not be linked to a
Java project using level 6. Compilation would fail before the dexer even
gets a chance to look at it.

from rxandroid.

Oh right, I didn't consider jars, but I assume that people wanting to use a new framework can always upgrade to Java 7? It should require very little to no modification in the sources.

from rxandroid.

It's not just about the app sources though. You have to upgrade your build
pipeline too, fix tests and legacy code, upgrade dependencies that don't
work with Java 7. It might depend on the project of course but it took us
several attempts spread out over several months with a final full day with
the entire team being all hands on deck to finish this migration. I thought
it was at least mildly painful (not upgrade-to-Gradle kind of painful, but
painful) and not everyone might see enough merit in diamonds or string
switching to go through that effort.

The reason I opened this was to get more insight into who of our users is
actually using JDK6. I mean are we just hypothesizing? Most people I spoke
to that use RxAndroid in production use Java 8! Is it generally safe to
assume for instance that adopters of something rather exotic as Rx are more
likely to be users of newer JDKs too?

I would like to see actual data points around this rather than speculating,
although I admit I'm not sure how to best do this other than simply ask
users that frequent the project website (which I assume most RxAndroid
users do?)

from rxandroid.

Yes, that is precisely my point :)
As you said, everyone that I know using RxJava right now is at least on Java 7 if not on Java 8 (like we are, in production!). Also, using Java 7 on RxAndroid also means the ability to use Retrolambda in the library at some point...

But you're right about finding actual statistics about this, I have no idea honestly.

from rxandroid.

I don't think this is a good forum to get insight on users of Rx. There are only 50 people watching the repo, and most of them probably aren't looking at the issues as they come in.

I'm not so familiar with the internals of Retrolambda, but it might be possible that if we use it on our end, then our outgoing jar would be Java 6 byte-code compatible. AFAIK it only translates Lambdas but not all language features (like try-with-resources). @orfjackal, could you help answer this one?

One issue with adopting Retrolambda internally be that contributors would need Java 8 to submit a PR for something even small. Not sure if this is actually a concern, just something to consider.

from rxandroid.

Yes, Retrolambda translates only lambdas and method references (experimental support for default methods is under development).

IIRC, at the bytecode level Java 7 added only the invokedynamic instruction and made stackmap frames required. The try-with-resources basically works in Java 6, except for the generated calls to Throwable.addSuppressed. That would cause a NoSuchMethodError if the try-with-resources block throws an exception and also the close() method of one of the resources throws an exception, but in the happy case the code would work. (I think that the try-with-resources' dependence on AutoCloseable happens only at the compiler level and should not matter in the bytecode.)

It would be quite easy to implement try-with-resources support in Retrolambda. It could replace calls to Throwable.addSuppressed with a call to Throwable.printStackTrace or just silently swallow the exception. Please create a feature request at https://github.com/orfjackal/retrolambda/issues if you want that.

from rxandroid.

One issue with adopting Retrolambda internally be that contributors would need Java 8 to submit a PR for something even small. Not sure if this is actually a concern, just something to consider.

It would be good to run all tests under Java 6, just to make sure that no Java 7+ APIs are used. So they would need both Java 8 and 6, and they would need to tell the build tool their install locations so that it can choose between them (e.g. by setting environment variables JAVA8_HOME and JAVA6_HOME).

Though alternatively you could configure the project to by default use only the current JDK (i.e. Java 8) and have a separate profile for running tests on Java 6. In that case Java 6 would be needed only on CI or when making a release.

from rxandroid.

Java 6 is EOL. dx has supported translation of Java 7 bytecode for over a year. You don't need to compile with Java 6 to verify no 7-only APIs are used. That's easily accomplished with static analysis tools like animal sniffer.

from rxandroid.

@JakeWharton maybe I'm missing something, but last time I tried linking a JAR compiled with language level 7 in a project targeting language level 6, then regardless of whether Java 7 specific APIs are used, the compiler will refuse to compile that project. That's because the byte code version is different, so this goes beyond language library APIs.

http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#binary

What could work, I believe, is to use a Java 7 compiler, but set source and target API level in RxAndroid to 6. Then it should generate class files that are compatible with Java 6 projects. That sort of defeats the purpose though? It would make switching compilers redundant though, so that could be a big win.

It just means we wouldn't be able to actually use any Java 7 syntax or APIs in RxAndroid.

from rxandroid.

Definitely Java 7. It would be a mistake to have the project held back even minimally to make it work for that few extra few percent of scenarios.

from rxandroid.

We use Java 7 for all new projects, but we have one legacy RxJava projects that we could not upgrade (cannot recall why but it didn't work and the project is in support so there is no incentive to update).

from rxandroid.

Sounds like people are quite torn about it.

How about this: we'll continue to support Java 6 for all pre-release versions of RxAndroid (i.e. 0.x releases), with the goal to switch to Java 7 before the stable release? That should give folks enough time to update.

Let me know what you think.

from rxandroid.

I might suggest having one last official 1.0-jdk6 release just so its clear
that we are expressing our confidence to the outside world, but effectively
it's the same thing.
On Nov 11, 2014 5:05 AM, "Matthias Käppler" [email protected]
wrote:

Sounds like people are quite torn about it.

How about this: we'll continue to support Java 6 for all pre-release
versions of RxAndroid (i.e. 0.x releases), with the goal to switch to Java
7 before the stable release? That should give folks enough time to update.

Let me know what you think.

Reply to this email directly or view it on GitHub
#37 (comment).

from rxandroid.

Fine by me.

from rxandroid.

Another data point: JDK 7 is about to EOL.

Also this project won't see 1.0 for some time... #ShowMeTheDiamondOperator

from rxandroid.

Do we still need to wait? JDK 6 was EOL'd 2 years ago and the tools have been supporting this for about two years. JDK 7 has been EOL'd as well so you really shouldn't even be using that anymore. There's absolutely not reason not to be using JDK 8 as your build JDK. Now, as the to Java version you are targeting, if you are not using 7 (or 8 w/retrolambda for the bold) then why?

from rxandroid.

Fine by me.
On Jul 1, 2015 03:41, "Jake Wharton" [email protected] wrote:

Do we still need to wait? JDK 6 was EOL'd 2 years ago and the tools have
been supporting this for about two years. JDK 7 has been EOL'd as well so
you really shouldn't even be using that anymore. There's absolutely not
reason not to be using JDK 8 as your build JDK. Now, as the to Java version
you are targeting, if you are not using 7 (or 8 w/retrolambda for the bold)
then why?

—
Reply to this email directly or view it on GitHub
#37 (comment).

from rxandroid.

👍 to bumping the version.

from rxandroid.

Fixed by #194.

from rxandroid.