In answers to this question, I learned that it is not possible to invoke the Java Compiler in javax.tools from a GAE app.
Does this limitation still apply?
If so, what are my options for compiling Java source code into loadable class files "on the fly"?
No, javax.tools is still not on the Appengine's JRE Class Whitelist.
The options you have are:
Compile somewhere else and than transfer and load .class files on appengine.
Try using one of embeddable Java compilers: Janino, JDT.
If you can live without Java, than you might try using BeanShell for Appengine.
Related
Im new to app development and was wondering if it would be possible to include another jdk. For example java 17 and run a jar that needs to be run in this exact version? I think termux has an api that you may use for these purposes but is there another possibility? These jars are only console based and without any gui.
I first tried to use the jar as a android library inside the app, which did not work since it was compiled in java version 17. I tried decompiling the jar and recompiling it with the version I was using. The problem is that all the libraries used are on other versions than I need them to be and so I could not recompile it. I also thought about writing the application in c# but I am not used to it at all, which would throw many new problems that I would be willing to take if it would be a possibility to work out my project.
Q: Is loading the code into your Android application an option?
A: No.
Android loads code from ".dex" files not ".class" files.
The ".class" files would need to be translated using dx.
The Android dx command doesn't understand Java 17 ".class" file format.
Also the code in the JAR is likely to depend on classes in the Java SE class library that the Android doesn't provide.
Q: What about running it in a separate Android VM?
A: No.
An Android VM requires ".dex" files; see above.
Also, the Java SE class library issue; see above.
Q: What about launching an OpenJDK or Oracle Java 17 JVM on the Android device to run the JAR?
A: In theory Yes, but in practice No. As far as I am aware, there is no port of OpenJDK Java SE to the Android OS platform.
Q: What about using Termux?
A: OK ... that might work. See Is it possible to install the JDK on an android device?.
I have no experience with this, and don't know what problems you may run into doing this. But I suspect that you wouldn't be able to distribute something that relies on Termux via the Google Playstore.
Another option is to download the source code1 for the application and try to build it in your Android dev environment
If the code uses Java classes / packages / libraries that are not available for Android, recode the relevant parts of the application to use Android equivalents instead.
Ditto if the code uses Java language features that are not yet supported in Android Java.
It probably won't be easy. It may turn out to be impractical.
1 - You said in a comment that the code your are trying to use is "open source". So the "download source and build it" option is available to you. I'm puzzled why you tried to decompile and recompile it instead ...
I'm trying to use the C++ library Spot (https://gitlab.lrde.epita.fr/spot/spot) in a Java project. I wanted to realize the interface between Java and C++ with JNA (https://github.com/java-native-access/jna). Because the Java application should also run on Windows, I tried to cross compile the library first with
./configure --host=x86_64-w64-mingw32 --disable-python LDFLAGS="-static -static-libstdc++ -static-libgcc"
and then of course make/make install on a Linux system. Because I can't expect the Windows system to have libstdc++/libgcc I wanted to link it statically into the library. My problem is now the following: When I try to open an compiled .exe in Windows, it still tells me libstdc++/libgcc not found. Of course, JNA also gives me an UnsatisfiedLinkException when I try to load the library in my Java program, because the modules are still not found, even though i explicitly linked them statically.
So what am I doing wrong? What else can I try to avoid having libstdc++/libgcc installed on the host system? I am now trying this for a week and have no clue how to overcome this, so a question here is kind of my last resort.
Thanks
I am new to java and I need to manipulate java bytecode for some purposes (see this). Java bytecode manipulation need following imports:
org.objectweb.asm
java.lang.instrument
I resolved org.objectweb.asm by downloading ASM package from asm website and related imports have been resolved.
I don't know how to resolve java.lang.instrument, My default ADT bundle hasn't it:
How do I resolve this import? Should I download any library? from where?
any help would be appreciated.
Thanks.
The java.lang.instrument package isn't available for Android. Just like AWT and Swing. Have a look at this question:
Android & Dalvik - Get the size of an object
But it makes sense. Android apps are written at the source level in Java, but they don't run on the JVM -- they run on the dalvik VM. There's no contract there that says they have to support the standard Java library.
Sorry :(
You're out of luck – find a way that does not rely on java.lang.instrument. java.lang.instrument is part of Java SE, but is not available on Android because of fundamental limitations of Dalvik.
The java.lang.instrument package was removed from dalvik core library, because this package makes a fundamental assumption that the execution format being used by the VM is a .class file. .class files do not appear on Android at all.
https://groups.google.com/forum/#!topic/android-developers/MR4W2roQ3Xw
Javassist is another tools to manipulate java bytecode. There is already someone who tried to use javassist in android. You might want to try it. As far as I know, bytecode manipulation on android runtime isn't possible, except in instrumentation (usually for testing). Manipulation on compile time is a different story, because java .class file generated first before converted to Dalvik bytecode. So if you modify .class file before being dexed, the dexed classes will be the modified one.
This article also worth reading, because it noted of ASMDEX which claim can manipulate DEX bytecode.
The java.lang.instrument package was removed. So you can't perform bytecode manipulation at runtime. However you can perform bytecode manipulation at build time with javaassist or ASM.
This sample project performs bytecode manipulation. It's usage is discussed here.
I am from .net world. I remember .net will immediately complain if you build with one dll but supply a different dll at run time.
I am now adding some hadoop reference to my project and find the following article.
http://answers.mapr.com/questions/364/maven-repository-for-mapr-jar-files
I just don't understand how this happens.
Java can build with one jar but run with a different jar?
Thanks
yes. this is often the case with APIs (you compile the API, but at runtime you may run with a newer version of the API which may be included with the implementation). everything will work out fine as long as the classes/method prototypes referenced in your compiled code are unchanged from the jar you compiled against.
For a specific definition of compatibility, see binary compatibility (thanks to #MiserableVariable for the link).
There is Java tool (it is called Mallet)
http://mallet.cs.umass.edu/download.php
which I want to use in my .NET project.
To convert this tool to .NET library at first I've tried to build it in single .jar file using Apache Ant. I've done everything corresponding to instructions at link above.
Download Developer Release from Mercurial repository.
Download Apache Ant, install JDK, set JAVA_HOME var to use Apache Ant.
Using Ant I've built single mallet.jar file.
And then I would to convert mallet.jar to .NET library using IKVMC.
When converting, I've got a lot of warnings such as:
Warning IKVMC0108: not a class file "cc/mallet/util/tests/TestPriorityQueue$1.cl
ass", including it as resource
(class format error "51.0")
Despite of these warnings, mallet.dll was created. But when I try to reference to it from my .NET project, it looks "empty". It has not any classes or namespaces. I don't forget to reference to IKVM.OpenJDL.Core.
And this is unusual that I can't find any same problems in Google.
I think that problem is in warnings. And I have never worked with Ant and I don't understand all process exactly.
The class format version 51 was introduced with Java 7.
IKVM most likely doesn't support that version yet and the file name you quote (cc/mallet/util/tests/TestPriorityQueue$1.class) points at an anonymous inner class of TestPriorityQueue that certainly is needed for the library to work correctly.
My suggestion: compile Mallet using an older JDK or at least using the -source and -target switches set to 6 (to ensure that it's compile for Java 6).
FYI v8.1 (currently in RC) of IKVM supports Java 8:
http://weblog.ikvm.net/2015/08/26/IKVMNET81ReleaseCandidate0.aspx
http://sourceforge.net/p/ikvm/mailman/message/34502991/