When using different Google Java SDKs, you include the right version which is defined by, for instance, v2-rev292-1.21.0 for the latest BigQuery library version. I suppose the syntax is something like this : version-revision-some other version, but I can't seem to be able to find an explanation for the relationship between the three parts. This is problematic when you need to upgrade versions and finding out that updates give compilation errors without changing (what I thought) was a minor version.
Can somebody explain precisely the Google SDK versioning nomenclature? In particular, what does the second version mean?
Related
Disclamer
Sorry in advance if this is a stupid question, but my research to clarify this was not as successful as i needed it to be.
Problem description
I am working on a project using jdk 11 and in order get decent testcoverage, i added something to mock calls/answers to/from external services. So i included wiremock.
As suggested on their setup getting-started section, i included
testImplementation "com.github.tomakehurst:wiremock-jre8:2.34.0"
Even though everything works on my machine (and tests run fine on the pipeline), i don't know if this will potentially cause issues on other machines. The architect involved in the project also stated his concern that we do only use jre 11.
Therefore i need some more insight to either change things up or argue why this is not an issue.
Attempts so far
I expected there to be an higher version of wiremock on mavencentral, but ther were only two projects:
mvnrepository: wiremock - last updated Sep, 2020
mvnrepository: wiremock-jre8 - last updated Sep, 2022
To my surprise, wiremock-jre8 was the most recent version. I don't know what the older version was compiled with but i was using annotations that wouldn't work with the 2020 version either way. So it would be nice to not downgrade the current implementation to a less readable solution.
I should mention, that i only guess that wiremock-jre8 has been compiled with jdk8 from the naming. I did not find any evidence about what compiler did produce the bytecode for either of those dependencies or clues on how to interpret this.
When trying to figure out how back and forwards combability works with java, the compiler and the produced bytecode, i found this older post. In short it states:
Compatibility from the point of view of javac (as it is the part specific to the JDK), meaning that the bytecode generated can be run in future releases of the jvm (that is more related to the JRE, but also bundled in the JDK).
JDK's are (usually) forward compatible.
JRE's are (usually) backward compatible.
I do understand that in parts, but not fully concerning my issue. Especially the "usually" part.
So are there some more insights someone has to spare to enlighten me? :)
The Download and Installation section of their documentation contains this sentence:
Additionally, versions of these JARs are distributed for both Java 7 and Java 8+.
So if you are still running Java 1.7 you must use the version for Java 7.
For all later versions of Java there is the version for Java 8+ (the version that you use.)
Since this is an actively supported project any problems related to Java versions later than Java 8 will be properly addressed and resolved (see for example Build on & fully support JDK 17 which was resolved in "com.github.tomakehurst:wiremock-jre8:2.32.0").
I'm maintainer of an Open Source Java library.
I have no experience at all in Android development but I would like that my library could be used in an Android app as dependency. (at least I would avoid the main blocker issue)
It's not crystal clear to me but I understand there is several kind of Java Compatibility with Android :
API level
byte code compatibility
source code compatibility.
(Please to not hesitate to better explain this ☝ or correct me if I'm wrong)
I guess in my case I'm mainly concerned by the 2 first points.
Currently :
we check API level with animal-sniffer-maven-plugin. (api-level-19)
our releases are compiled against java7 with a openjdk7.
But I would like to upgrade to a more recent version of Java. (probably java8, but maybe java11)
Can I use those jdk versions (openjdk8, openjdk11) to compile a library which could be used in android project ?
My current research about this, but still not clear to me :
https://developer.android.com/studio/write/java8-support
https://jakewharton.com/androids-java-9-10-11-and-12-support/
https://developer.android.com/studio/releases/gradle-plugin?utm_source=android-studio-2020-3-1&utm_medium=studio-assistant-stable#java-11
I'm running an old version of appengine-api-1.0-sdk (1.9.54) and want to upgrade to a newer version (1.9.90), but I can't find any list of changes from one version to the next. I would have expected a release note or something in the download, but it just points me to a general Java page for Appengine: https://cloud.google.com/appengine/docs/java/release-notes. This doesn't tell me what has changed from one version of the SDK to the next.
Thanks
Tim
You can use BigQuery to select different points between 2 versions
https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=google_cloud_release_notes&t=release_notes&page=table&_ga=2.107183563.811335336.1632571946-1193389554.1631929347
I came upon this simple Library that someone wrote in java GetImageText.java for OCR in images so i tried compiling it on my Ubuntu via terminal but i get several error as shown below in this paste :
Compilation Errors
Can Someone help me with it , it is absolute necessity that i test this code , its explanation can be found here
I think the problem is that i do not have com.sun.image.code.jpeg in my system, although java is definitely installed. Although I am not sure how to import this package without using an IDE.
The problem is that the library you are trying to recompile depends on INTERNAL classes1. Portable libraries are not supposed to do that!
What has happened is that the class has been removed or replaced. This happens from time to time, and that is the reason that people are not supposed to write code that depends on INTERNAL classes.
Solutions:
Bug the authors of the library to fix the problem.
Figure out which version(s) of Java that the library supports, and stick with those.
Find an alternative library that supports the version(s) of Java that you need.
Non-solution: Compiling the library on an older version of Java and running on a newer one is likely to fail. The class needs to be present at runtime, as well as at compile time.
1 - Anything in the "com.sun" tree counts as INTERNAL. Sometimes people have no choice but to have such a dependency. However, they still needs to deal with the potential consequences for portability.
I am just learning about android app development and have created my first app which is a relatively simple app with a link to a gallery of images and some text pages. I created this using the 1.5 platform as it seemed sensible to make it backwards compatible. I've been testing it on 3.0 and it comes up tiny on the screen and I have since learnt I need to use supports-screens and other related commands to allow variable screen support which from what i read is only available in 1.6 and above. As a result I need to change the app platform to 1.6 or above and my questions are as follows:
1) Am I able to just go to project properties and change the platform version tickbox to a newer one (in this case 1.6)? As I tried this with the project but the supports-screens tag still gives an error (which it doesn't when I create a brand new project)?
2) What version should I be creating it in these days for ideal backwards compatibility but able to use most desirable features? I understand 1.6 includes a lot of the newer functionality but according to http://developer.android.com/resources/dashboard/platform-versions.html only about 4% of people are using less than 2.1 so is it better to just code using 2.1 (assuming I want to target mobiles and tablets)?
Thanks so much for your help as ever,
Dave
Take a look at this. It explains how you can go about changing your AndroidManifest.xml to specify which version of the SDK to use. You may also need to update default.properties to point the target to the proper api value.
This really depends on what you want to do. If you require something from 2.1 or 3.0, then I think you need to go with that. But if you can get by using just 1.6 and still have all the functionality that you need/want, then I would definitely recommend using 1.6.