How to add the library

[senchoi]

the instruction seems in need of update.
can you just provide jar file?

[xxxajk]

To build with ant on Linux (Sorry, don't use anything else, pretty sure it is a requirement anyway)
You do not need to build for ART or newer JDK, or use any of the android studio tools or the horrible gradle junk.
You will need ibm-java80-jdk, and apache-ant

cd ~/PATH_TO/PhysicaloidLibrary/PhysicaloidLibrary
JAVA_HOME=/usr/lib/jvm/ibm-java80-jdk-x86_64 ant debug

Let me know if that works out for you.

[senchoi]

I got it to work on Android Studio eventually.
By updating deprecated commands to suggested ones and following https://youtu.be/DG7OYSTxPUA partially.

i’m more curious about how you contribute in this library. What’s the relation to the original Physicaloid? Can we expect any future bug fixes from you?

[xxxajk]

Yes, basically the original person disappeared, got bored and abandoned it, or something worse happened.
So I basically adopted the project, and I do accept PR's.

I don't use studio, it's bloated trash, and always changes too much, forcing a re-learning every time.
Apache-ant is very JVM and build agnostic, and no IDE or network is required to build/use it. Everything else (from my experience) always delays by grabbing new package lists, and other stuff, even if you don't need any of it, then breaking your build because something was changed by someone.

I've been (slowly, in my limited spare time) working on android project plugins for Netbeans instead. It still has a few warts, but is slowly getting there. Soon as everything works, I'll put it up on github, but it's usability is pretty horrible right now, especially since I have to support all Android versions that I have and have to support for my clients.

What I suggest is that you make your PR in such a way that it does not affect the current build process using ant (if possible) and the older JDK, since some of us actually depend on it to use "obsolete" devices and repurpose them, cutting down on e-waste.

I can create a new branch for this in case that is too difficult or impractical, and then you can commit that to the new branch. What I need to know is what android target causes the problem, so we can name the branch properly.

That said...
Deprecation isn't an error, either, it's more of a warning that something could go away. The problem with that is it ends up killing the entire idea of java's backwards compatibility, but nothing stops you from making a branch that handles the changes, which is unfortunately the only way to work around this other than some way of building a wrapper.

Rant...
The OpenJDK people should have been smarter, and added a wrapper that can simulate SUN's old code, and not break anything. I'm surprised that nobody has a drop-in replacement.
Then to make matters worse, Android drops stuff all the time, which is hugely annoying, and a big fail there too IMHO.
These fails combined together, makes supporting different versions of everything a total nightmare.