Instructions on how to add/import into Eclipse incomplete/incorrect

[just-Addict]

Description: I have tried to add/import the API as Gradle project into Eclipse and have been unsuccessful to say the least.

Steps to reproduce:

1. [Step 1] See README.MD, followed instructions in the section "Build From Source" to the letter. Pulled copy from Github

2. [Step 2] executed git submodule update --init (completed without issues)

3. [Step 3] executed gradlew.bat :library:build (completed without issues, found 4 JAR files in library/build/libs/)

4. [Step 4] added library/build/generated/source/proto/main/java to build path of top project.

Expected behavior: Should end up with 3 different projects (Library, Sample, PokeGoAPI-java) and using the installed Java Library on my system (Windows10, JDK1.8 build 121)

Actual behavior: Projects do get added but with "Problems" tab in Eclipse reporting 25K+(!) errors and looking for a Java library JRE 1.7 which is sooo old that it isn't even funny anymore.

Stacktrace (If it's a crash):

Version: Latest version pulled from Github.

[s7092910]

First off, Java 7 is fine. Specially since it is still required for Android development. And just so you know Java is backward compatible. So if you have Java 8 installed, it can still run Java 7 or Java 6 targeted programs.

Anyways, from the looks of it, gradle is pointing to a location on your computer where you don't have your JDK located.

[just-Addict]

It is, and JAVA_HOME environment variable is also set to the location of my JDK. I checked every setting to no avail.

[AbandonedCart]

Java 7 is not required for Android development, just the most common. The issue is Eclipse. The ADT plugin was deprecated and Eclipse likes to configure itself over letting the system configure it.

Open Eclipse Preferences and expand Java. Select the tab for Installed JREs and verify that the intended Java is checked and contains the right path. Eclipse will often ignore environment variables in favor of its own configuration. You can also use this option to select a lower installed version.

[s7092910]

@LoungeKatt Android runs Java 6 and Java 7. Android M does support some Java 8 features, tho at the moment if you want to support earlier Android versions with Java 8 features you need to use the Jack compiler which just frankly sucks and it quite the hassle to get up and running. Just so you know. That is why I said Java 7 is required to do Android development.

[AbandonedCart]

@s7092910 The version that Android runs and its relation to the version used to compile an application to run on it are only relevant when they are incompatible. Java 8 is just fine by setting the compiler to Java 7 compliance. Not sure why you are trying to force it to run Java 8, but that may be the confusion about Java 7 being required for development.

[s7092910]

@LoungeKatt I don't think you quite understand. While yes Java versions are backwards compatible. But features are not backwards compatible. For instance, you can't use Lambdas in Java 7. That is because it is a Java 8 feature.

So when you say something requires Java 7. It means it can only use the Java feature sets all the way up to Java 7. While it also means that the program needs at least Java 7 to run, because it uses features that are only in Java 7 and not in any lower version of Java.

So for Android, yes you can have Java 8 installed or even Java 9. It is just you can not use any Java 8 or 9 features. So you can not use Project Jigsaw with Android. You can't use Lambdas with Android unless you use the Jack Compiler.

When I said Java 7 is fine. I was commenting on this part of his bug report.

JRE 1.7 which is sooo old that it isn't even funny anymore

[AbandonedCart]

@s7092910 Why are you trying to give a lecture on Android development using irrelevant details? Who is trying to run Java 8 features on a Java 7 machine? Are you sure you read the whole report?

So for Android, yes you can have Java 8 installed or even Java 9. It is just you can not use any Java 8 or 9 features.

Exactly why I said you are not required to have Java 7, but must set the compliance level.

looking for a JRE 1.7 which is sooo old that it isn't even funny anymore

You missed the most important part. The "looking for" states that the build is trying to locate it, while

installed Java Library on my system (Windows10, JDK1.8 build 121)

states that it is Java 8 present on the system performing the build.

Your statements more or less suggest installing Java 7 because Java 8 will attempt to run some alternate code not included in the build on an incompatible version. That is not true. Before going into a whole speech about how the Android development process works, make sure you are answering the right question. Nobody is trying to build a Java 8 program and run it on Java 7.

More importantly, it is impossible that

gradle is pointing to a location on your computer where you don't have your JDK located

when running gradle

(completed without issues, found 4 JAR files in library/build/libs/)

but the issue does occur with

Eclipse reporting 25K+(!) errors and looking for a Java library JRE 1.7

pointing to it being an Eclipse problem, as per my original statement...

[AbandonedCart]

@just-Addict skipping over all the nonsense about Java, does setting the compliance level to match the project requirements in Eclipse fix the issue for you?

[just-Addict]

@LoungeKatt I would love to try, but even though the gradlew.bat file ran perfectly ok the first time, I can't for the life of me get it to finish now without a build fail when it comes to :library:generateProto.

The resulting commandline to protoc ends up being too long for my crap win10 .... and I am not experienced enough with all this stuff to do it all manually. Tried editing the bat file to see if there was a place where it called protoc, figuring if I moved it into my %path% somewhere I could get around it but don't see where that is called.

[AbandonedCart]

There was an issue with the length causing errors before. If you move the entire project to the root directory (C:/) it should resolve it. Sadly, some of the people there were too concerned with (overly) descriptive file names and end up using "CryptoFileToDecodeHash64InDecimal" when all it had to be was "DecodeHash" but they don't see an issue until one of them can't compile it.

Also, if you do use a subdirecty, try to make sure it uses short names with no whitespace. I compile mine from /Users/loungekatt/GitProjects but also have a Mac that is a bit more forgiving on length.

[just-Addict]

@LoungeKatt it's not the project folder where this happens, it's all the stuff it dumps into my C:\Users\Me\.gradle folder that ends up forming too long path names.

frankly, this is giving me more bother than it's worth

[just-Addict]

@LoungeKatt I have let this rest for a while and finally found out why it kept tripping. The error wasn't entirely correct. The problem was caused by the resulting arguments passed to the protoc executable forming a too long commandline, I could get around this by moving the whole folder structure to start at the root of the drive, but am still facing the problem of errors showing up in the Problems tab in Eclipse.

I checked the compliance setting you shown me, but it already defaults to 1.7 What is not clear to me is to which of the projects the source folder should be added to the build path. The readme.md only says right click the project folder... but is that to only the top folder, only the library folder, the sample folder or all three individually? I've tried each but it didn't make any difference as far as the Problems tab is concerned.