I am learning one android project from youtube but that video is published 2 years ago. Now in order to use that code what changes i have to do in dependencies of libraries like room , Okhttp etcc and how can i update that project to latest verison easily?
If you add the dependencies as listed, they should still work - repositories keep the older versions, so projects built with a particular set of dependencies can pull those versions and build the same output no matter how old it is. Nothing has to update to a new version of a library - and many actively maintained projects will choose to stay on an older version of a dependency for lots of reasons!
That said, if you're creating a new project right now, some of the current Android framework libraries, plugins etc. might require certain versions of other dependencies - they might force you to meet some minimum version requirements, just because they're incompatible with older versions. You could either downgrade all the stuff that complains about needing a newer version of X, or you could upgrade your old dependencies, like you're asking about.
An easy way to do it is to open the Project Structure window in the File menu, and go to the Dependencies section. It'll show you all the dependencies in your project, identify which ones are out of date, and you can select an available version you want, or just update to the most recent version.
But if there is a compatibility issue, it might take some time to work out which versions are necessary, or even which versions are being pulled in by other libraries (e.g. a particular version of a library might internally have a dependency on a certain version of a library you're already using, and the most recent one is what your project ends up using). You can get some info about this from the output in the Build window, or maybe running the dependencies Gradle task if you want to explore that.
It wouldn't hurt to look at the project pages for your libraries and see what they say about installation and dependencies. Also, their method for adding them to a project might have changes, e.g. something that used the (now closed) JCenter repository might be using Jitpack now. Something to look at if you're having problems.
Also there's the issue that new versions of the libraries might have different APIs, or their behaviour might have changed. Even if fully updating everything goes smoothly, there might be stuff you need to fix in the code itself. Just a few things to keep in mind!
Related
I'm currently following this tutorial: https://openjfx.io/openjfx-docs/ (JavaFX and IntelliJ IDEA). I use Intellij 2021.3.2.
I have created a project (1. Create a JavaFX project), which worked out great and didn't need to 2. Set JDK 16 because it was already set to 17 (which I guess is fine).
But here begin the weird stuff (and I'm very new to programming so I'm sorry if it sounds silly). "You can also set the language level to 11 or greater." I don't have this option. Because it's "can" I felt like it wasn't a big deal but if someone can explain what this is all about? Just out of curiosity, because I'm at the very beginning of the tutorial and I kinda only understand half of it.
Then 3. Create a library, and I don't have what they have, and my stuff is red:
So when they said "add the JavaFX 17 SDK as a library to the project" I didn't know what to do. I also didn't know what to do to fix the red stuff.
And finally, they say "Warning: If you run now the project it will compile but you will get this error: ..." but if I click on this button
everything works! which you know i'm not complaining about but I would like to understand a bit more what is happening.
And then they suggest I should 4. Add VM options to fix the problem that I don't have. So I figured maybe my computer set the VM options correctly without me knowing it but there is currently no VM option (and it works). Should I add them nonetheless?
Thank you for your help, I'm very lost and feel like I don't really understand anything.
The current documentation in the openjfx tutorial for getting started with JavaFX using Idea is incorrect, at least for recent Idea releases (2021.3 +).
The tutorial is written as though a new Java project was created, rather than a new JavaFX project. Once a new JavaFX project has been created, most of the rest of the steps in the tutorial are either redundant or wrong.
Step 1, “Create a JavaFX project", does a lot more than just “Create a Java project”, which is why everything else is different from the tutorial.
A better tutorial for getting started with JavaFX with Idea, is the official Idea documentation:
Create a new JavaFX project.
Differences between creating a new Java project and creating a new JavaFX project
The new JavaFX project:
Provides a build script for Maven (pom.xml) or Gradle (build.gradle).
Adds the appropriate dependencies for JavaFX base, graphics, controls and fxml.
Provides an example application and controller code that you can run immediately.
The example project is modular and provides a module-info.java
Because the program is modular and dependencies are downloaded via maven and recognized by the IDE, you don’t need to manually configure VM runtime options for the module path and adding modules.
Idea will recognize the Maven or Gradle projects and automatically synchronize the initial transitive dependent libraries with the Idea project.
There are options in the Idea Maven tool window which will allow you to synchronize further changes to dependent libraries or javadoc and source code in libraries.
Selects a JDK and attaches it to the project, automatically downloading the selected JDK version if not already present.
Sets an appropriate language level for the project.
When you just use the create new Java Project option, it doesn’t do any of those things, so you need to do things manually instead, which is what the rest of that tutorial is about:
Manually download the JDK and configure it in the SDK.
Manually download the JavaFX SDK and add the libraries from it to your project.
Manually configure VM modular arguments.
Manually maintain any other dependencies.
Manually associate javadoc and source code.
Manually write the code for a basic application.
Manually set the project language level.
Doing all this stuff manually is more work and more error prone. The manual work usually leads to a worse outcome and a project that is more difficult to maintain for many people getting started with JavaFX, so I do not recommend it.
Versions
In terms of the versions to use, I recommend using the most recent stable (non-beta) releases of both JDK and JavaFX, regardless of what versions may be referenced in any tutorials you may be using.
You can set JavaFX versions in the Maven file generated by the new JavaFX project wizard, then press the button in the Maven Tool window to synchronize the Maven project with the Idea project.
Language level settings
These are important later on, but pretty irrelevant when just getting started.
The language level settings:
Tell the compiler what version of the java byte code to compile the application to.
Tell the IDE what language syntax rules to enforce and provide help with.
If you use Java 17 only features, the app won’t run on a Java 11 VM.
You can define the settings in Idea manually:
language setting level.
But it is better to set them in the compiler section of the maven project and synchronize the project with Idea, which will also configure the settings in the IDE.
IMO, set it to the most recent stable version and have a requirement that your application be run with that Java version as a minimum (you can enforce that by using jlink or jpackage to bundle the JRE version you choose with your packaged app).
Upgraded Android studio (stupid, right?). Now not only can I not hit alt-E, C to do a copy, but some older apps of mine, that I need to support, no longer run. These are apps that were put together with Android Studio 1.x.
First off, when I tried to compile, it demanded that I put "-keepattributes InnerClasses" in my proguard rules. Just including that in case it's some kind of hint.
The program compiles fine, but then it runs and quits instantly. Looking at Logcat, I see this:
2021-03-18 22:02:34.960 6147-6147/com.mycompany.myapp E/ycompany.myapp: No implementation found for java.lang.String com.mycompany.myapp.myappActivity.d() (tried Java_com_mycompany_myapp_myappActivity_d and Java_com_mycompany_myapp_myappActivity_d__)
Here's the weird part, though... in myactivity onCreate, I output a line of text. It gets there. That happens. It prints out ">>>>>CREATED APP<<<<<"
Can anyone explain what's happening? What do I need to do to fix this???
A lot has changed since ASs 1.x especially with the gradle / android gradle plugin. These are very finicky even after minor updates. Nevertheless you're more or less forced to update to a newer (not necessarily the newest) IDE version.
Not finding java.lang.String suggests some major incompatibility issue.
First you should check your JDK version (and ensure you have the full kit not just a JRE). Not all IDE versions work with all JDKs and again use an older one (10, 12) , not the absolute bleeding edge as the newest might not be supported (and android does not support newer java features anyway). I use JDK 12 and Ass 3.6.1.
Also check the gradle version you're using since gradle also has its incompatibilities. Remember to also inspect the contents of JAVA_HOME and GRADLE_HOME environment variables (if they exist and are used by your project) since they may override the build tool versions that are used.
Your safest bet would be to create a new empty project and copy all your sources in it. That might take less time then trying to clean the existing project, migrate the plugins, gradle and so on.
Until you fix the project setup you can disable proguard to get rid of one more hassle by setting
minifyEnabled false
in your app/ build.gradle # buildTypes # release. Note that proguard is usually disabled for debug builds.
How I can make maven to download only java 1.6 compatible libraries?
I have tomcat 6 and java 1.6.0_38. Or how I can find incompatible libs?
http://pastebin.com/WnwZL2RX list of dependencies.
If it's a one-time task which you have to run over the list your have provided then I would propose a manual approach described here:
What version of javac built my jar?
As for automatic check then you would have to implement your own maven plugin which will use similar approach to the one described above or drill into JAR manifest in order to get the Java version.
A very interesting question i hope to be able to check back for a more satisfying answer.
Maven is not able to perform such a task - and as faar as i know (i only checked back with a 5 minute websearch) there is no plugin available for this task.
In the end Maven supports with the dependency management by resolving dependencies of dependencies and has default approaches when it comes to versions of the same dependency ("the closest version wins") - regardless of this you will be in charge when it comes to compatibility between your own source and third party source.
Especially when talking about runtime incompatibility this could be a quite hard task to find out about issues.
I need to add some jars from JRE7 library to my Android project. But for example rt.jar is in conflict with android.jar from Adroid 2.2 SDK, so I get this error:
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
I know there have been several threads about it and things like JarJar, OneJar or FatJar might be good for me. But I don't know how to make any of them work and documentation doesn't really make it clear (for me). I guess they use Ant commands, but I have always used Eclipse built-in builder and now I have no idea how to use neither Ant nor any of mentioned above.
So my question is: how can I repack this rt.jar so I could compile it in my Android project?
Thank you!
EDIT:
Ok, so what I want to achieve is to create a .jar, which can be used during developing Android application (simplifies some functionalities, doesn't really matter). But I would also like to be able to add the very same .jar to standard Java project in order to use some functions there as well. It would look like this:
Whoever writes an application adds this .jar to his Java project -> it enables him to generate certain files (internet is needed to do it) -> these generated files are then added to Android project -> later on, when somebody uses this Android app, these files provide certain functionalities without using internet (off-line).
It would be ill-advised to do this in any project at all, even if it were possible. You would be opening yourself to a wealth of class incompatibility and loading problems. But in any case it doesn't even matter because the core Java libraries are loaded way before your archives are even touched, making any such attempt at overriding them moot.
Not to even talk about the fact that Android is using its own JVM implementation which is not fully compatible with JDK 6 (forget JDK 7). Also note that it may be a copyright violation to package the core Java libraries with your code and could change your licensing options (IANAL).
You need to find another way to resolve whatever issue you are having (which you failed to mention in your question).
There are many JARs that work nicely on both Android and on classic Java. None involve having Android developers pirate rt.jar. Stick to java.* and javax.* classes that exist in both the Android SDK and in whatever level of Java you are supporting, and your JAR will work fine in both environments.
You should ideally refrain from using such .jar files, but if you must, you can add them to build path. But this, at times results in a conflict, like the one that you are facing right now. What you need to do to resolve this kind of a conflict, is:
add the jar in the build path.
Check "referenced libraries". The jar file should appear under the same.
once it features under referenced libraries, check the "android dependencies" virtual directory. If you get to see that you have an instance of the same jar file there as well, you should delete the "android dependencies" folder altogether. (Trust me, this does not affect your project in any way).
having done that, you should be able to compile your code without any further conflicts.
Happy coding.. :)
I do mostly google app engine coding, and a little bit of android development, and don't understand why I wouldn't want my Eclipse ide to always be at the most recent release, or version. It seems like there are some plugins that wouldn't be compatible, but couldn't you just install the missing features from an old release of Eclipse into the newest release?
I'd say that always having the most up to date version of program x really isn't necessary. I think the most important thing is having a set of tools that you know how to use well. Upgrade those tools when there is a reason to do so, not just because there is a new version of them.
By far the predominant reason for not upgrading is lack of support for the new release from the plugins that you require. You cannot just install "missing features". Most of the time, the incompatibility is due to changes in the new version of an existing feature. Plugins that ship from eclipse.org are tested together in coordinated releases. While in some cases, it may be possible to down-version a plugin and have that plugin still work in the new version of Eclipse, it is not something that you can depend on working. In fact, the odds of this working without issues are so small, that I wouldn't bother trying.
Stick with whatever version of Eclipse your required plugins support until those plugins upgrade their support. If they aren't moving fast enough, consider pestering the provider about this issue. If nothing else, knowing how big of a chunk of the community cares about support for the latest version of Eclipse will help the plugin provider prioritize their work.
You can do that. If you want to compile against an older Eclipse version, this can be done very easily.
e.g. if you want to develop with Eclipse 3.6:
download Eclipse 3.5 and extract it (e.g. c:\development\targetplatforms\eclipse3.5).
start Eclipse 3.6, choose your workspace where you want to use the Target Platform.
open the Menu Window->Preferences, type target in the search field, and add a new Target Platform (Nothing: Start with an empty target definition -> Add -> Direcotry -> choose the unzipped Eclipse 3.5)
There are some advantages of using a target platform. You have the newest IDE Features. You can build your product against older Eclipse Versions without having to port it to your newses IDE version. You can add Plugins to your Target Platform without contaminating your ide or add Plugins to your IDE withoud contaminating your Target Platform. ...
You should bundle your Target Platform with your Project, so you don't have to download it again. We have a TargetPlatform Project in our SVN Repostory. Every Project has a small readme how to setup the Workspace (targetplatform, deployment, ....).
Why wouldn't I want to use the newest version of Eclipse?
Because IntelliJ IDEA provides a Community Edition. :)