I'm developing a Java ME project in Intellij. When I try to call a function from the javax.microedition package, all functions simply return null. After inspection, these functions exist but contain no substance (are unimplemented). For example, the javax.microedition.io.connector class function .open(String var) appears this way and always returns null:
public static Connection open(String var0) throws IOException {
return null;
}
This function does not match the documentation provided by Oracle and according to the documentation Connector is not an abstract class. All other functions I inspected seem to be implemented the same way. Did I miss a step in setting up the Java ME SDK? Am I missing something?
Additionally this is the code I try to run but returns null:
ServerSocketConnection server = (ServerSocketConnection) Connector.open("socket://:4040");
These are called stub classes. They only contain method signatures and default return values. You can use them to compile your code without problems.
When you run your app on an emulator (or on an actual device) these classes will have a proper implementation and behave as expected.
Related
I am implementing a Java wrapper for a C++ project using JavaCPP. I have defined mappings for all custom types, but I'm struggling with a call to the std::sort_heap() function that takes a function as an argument.
This is the function call in the C++ code:
std::sort_heap(heap.begin(), heap.end(), comparePairs);
comparePairs is declared like this in this file:
bool comparePairs(
const std::pair<real, int32_t>& l,
const std::pair<real, int32_t>& r) {
return l.first > r.first;
}
When I try to run this with JavaCPP (using the JavaCPP Maven plugin), I get this error:
error: no matching function for call to ‘pop_heap(std::vector<std::pair<float, int> >::iterator, std::vector<std::pair<float, int> >::iterator, <unresolved overloaded function type>)’
std::pop_heap(heap.begin(), heap.end(), comparePairs);
^
Update: the problem seems to be due to the fact that another compairePairs() with a slightly different signature function is declared in another file. The C++ compiler disambiguates them fine, considering that each compairePairs() function is called only within the same file. However, JavaCPP seems to fail at that disambiguation somehow.
This is how the other type mappings are declared:
import org.bytedeco.javacpp.tools.Info;
import org.bytedeco.javacpp.tools.InfoMap;
import org.bytedeco.javacpp.tools.InfoMapper;
[...]
#Properties(value = #Platform(include = {[...]}), target = "[...]")
public class Wrapper implements InfoMapper {
public void map(InfoMap infoMap) {
infoMap.put(new Info("std::vector<std::string>").pointerTypes("StringVector").define())
// more put calls here
;
}
}
Question is thus: why does JavaCPP fail to disambiguate overloaded functions, and how can I fix it?
Note: the C++ code is a third party project, so changing the C++ code is not an option.
Update: the issues appears to be due to the compairPairs() function being declared twice in the C++ code (in two different files), with different signatures.
As described in the comment, wrapping the function call to comparePairs() into a lambda function resolves the issue.
See https://github.com/facebookresearch/fastText/pull/936/commits/cda295f1b5851df0a26a6ac2ab04230fb864a89d
I would need help trying to understand why this is happening to me:
Using Java 1.8.0_131, I have a class such as this:
public class DynamicClassLoadingAppKO {
/*
* THIS VERSION DOES NOT WORK, A ClassNotFoundException IS THROWN BEFORE EVEN EXECUTING main()
*/
// If this method received ChildClassFromLibTwo, everything would work OK!
private static void showMessage(final ParentClassFromLibOne obj) {
System.out.println(obj.message());
}
public static void main(final String[] args) throws Throwable {
try {
final ChildClassFromLibTwo obj = new ChildClassFromLibTwo();
showMessage(obj);
} catch (final Throwable ignored) {
// ignored, we just wanted to use it if it was present
}
System.out.println("This should be displayed, but no :(");
}
}
Two other classes are being used up there: ParentClassFromLibOne and ChildClassFromLibTwo. The latter extends from the former.
There are two external libraries involved:
One library is called libone and contains the ParentClassFromLibOne class. The application includes this library in the classpath both for compiling and executing.
A second library is called libtwo and contains the ChildClassFromLibTwo class. The application includes this library in the classpath for compiling, but not for executing.
As far as I understand, the Java runtime should try to load the ChildClassFromLibTwo (which is not in the classpath at runtime) at this line:
final ChildClassFromLibTwo obj = new ChildClassFromLibTwo();
Given this class is not in the classpath, a ClassNotFoundException should be thrown, and given this line is inside a try...catch (Throwable), the System.out.println line at the end should be executed anyway.
However, what I get is the ClassNotFoundException thrown when the DynamicClassLoadingAppKO itself is loaded, apparently before the main() method is executed at all, and therefore not caught by the try...catch.
What seems more strange to me is that this behaviour disappears and everything works as I would expect if I change the signature of the showMessage() method so that instead of receiving an argument of the parent class, it is directly of the child class:
/*
* THIS VERSION WORKS OK, BECAUSE showMessage RECEIVES THE CHILD CLASS AS A PARAMETER
*/
private static void showMessage(final ChildClassFromLibTwo obj) {
System.out.println(obj.message());
}
How is this possible? What am I missing in the way class loading works?
For testing convenience, I have created a GitHub repository replicating this behaviour [1].
[1] https://github.com/danielfernandez/test-dynamic-class-loading/tree/20170504
OK, the details of why this happens are explained in this Spring Boot ticket [1] which I've been very lucky to be promptly pointed to by Andy Wilkinson. That was definitely a difficult one IMO.
Apparently, what happens in this case is that when the calling class itself is loaded, the verifier kicks in and sees that the showMessage() method receives an argument of type ParentClassFromLibOne. So far so good, and this would not provoke a ClassNotFoundException at this phase even if ParentClassFromLibOne was not in the classpath at runtime.
BUT apparently the verifier also scans method code and notes that there is a call in main() to that showMessage() method. A call that does not pass as an argument a ParentClassFromLibOne, but instead an object of a different class: ChildClassFromLibTwo.
So it is in this case that the verifier does try to load ChildClassFromLibTwo in order to be able to check if it really extends from ParentClassFromLibOne.
Interestingly this wouldn't happen if ParentClassFromLibOne was an interface, because interfaces are treated as Object for assignment.
Also, this does not happen if showMessage(...) directly asks for a ChildClassFromLibTwo as an argument because in such case the verifier does not need to load the child class to check it is compatible... with itself.
Daniel, I'm voting up your answer but I will not mark it as accepted because I consider it fails at explaining the real reason why this is happening at verify time (it's not the class in the signature of the method that's causing the ClassNotFoundException).
[1] https://github.com/spring-projects/spring-boot/issues/8181
This is a bit more complicated than you think. When a class is loaded, all functions are verified. During the verify phase also all referenced classes are loaded, because they are needed to calculated the exact types that are on the stack at any given location in the bytecode.
If you want that lazy behaviour, you have to pass the -noverify option to Java, which will delay the loading of classes until the functions that reference them are executed the first time. But don't use -noverify for security reasons when you don't have full control over the classes that will be loaded into the JVM.
First of all some context, to thoroughly explain the methods I've already tried:
I'm working in a java-based programming platform on windows which provides access to custom java functions with several other extensions. Within the source code of this modelling platform, there is a class "CVODE" which grants access to native library "cvode" to import the functionality of a C++ library CVODE.
//imports
public class CVODE {
static {
Native.register("cvode");
}
public static native int ... //methods
}
I created shared libraries from the CVODE library, which resulted in 2 files: sundials_cvode.dll and sundials_nvecserial.dll.
Adding the first library to my java path obviously resulted in
Unexpected Exception UnsatisfiedLinkError: Unable to load library 'cvode': The specified module could not be found.
as the names were not compatible. Therefore I changed the name of sundials_cvode.dll to cvode.dll and retried. Resulting in an error indicating that not all methods are present in the library sundials_cvode.dll:
Unexpected Exception UnsatisfiedLinkError: Error looking up function 'N_VDestroy_Serial': The specified procedure could not be found.
This convinces me that the library is being found and loaded correctly, but not all methods are available. Examining the dll's in question led me to the conclusion that the CVODE class requires functions from both the sundials_cvode.dll and sundials_nvecserial.dll libraries. Therefore I tried changing the platform source-code to
public class CVODE {
static {
Native.register("sundials_cvode");
Native.register("sundials_nvecserial");
}
public static native int ... //methods
}
which still results in
Unexpected Exception UnsatisfiedLinkError: Error looking up function 'N_VNew_Serial': The specified procedure could not be found.
I have confirmed this method is present in both the class file and in the dll:
So I can only guess the error results from calling the Native.register() twice. resulting in the 2nd library not being loaded or an error down the way. I'd appreciate some insight in what I'm doing wrong or how I can gain a better overview of what's going wrong.
As far as I know, you can only load one dll per class, i.e. split the classes into two, each providing the methods the particular dll provides.
See also here: https://stackoverflow.com/a/32630857/1274747
While developing an app in AIDE for Android I have come across this error. The app would compile successfully but wouldn't install, reporting this error:
Could not run the App directly as root. Consider disabling direct running in the settings.
WARNING: linker: app_process has text relocations. This is wasting memory and is a security risk. Please fix.
pkg: /storage/sdcard/AppProjects/MyProgram/bin/MyProgram.apk
Failure [INSTALL_FAILED_DEXOPT]
exit with 0
I researched what could cause this and mainly came across reasons like "certificate error, try resigning the package" and "setting a permission twice in the manifest" and other stuff, none of which have worked.
Your problem: Java thinks you define two methods with the same signature.
Java method signature definition: https://docs.oracle.com/javase/tutorial/java/javaOO/methods.html
method declarations have six components, in order:
1.Modifiers—such as public, private, and others you will learn about later.
2.The return type—the data type of the value returned by the method, or void if the method does not return a value.
3.The method name—the rules for field names apply to method names as well, but the convention is a little different.
4.The parameter list in parenthesis—a comma-delimited list of input parameters, preceded by their data types, enclosed by parentheses, ().
If there are no parameters, you must use empty parentheses.
An exception list—to be discussed later.
The method body, enclosed between braces—the method's code, including the declaration of local variables, goes here.
As you can see above, the specification of generic classes is NOT part of the java method signature. Therefore java detects two add-methods with the same signature.
I found where the problem resides. It was in some code which looked very much like this:
public class Builder<T extends Base> {
private final List<Def1> subDefs1 = new ArrayList<>();
private final List<Def2> subDefs2 = new ArrayList<>();
public Builder<T> add(final Collection<Def1> ds) {
subDefs1.addAll(ds);
return this;
}
public Builder<T> add(final Collection<Def2> ds) {
subDefs2.addAll(ds);
return this;
}
}
interface Base {}
final class Def1 implements Base {}
final class Def2 implements Base {}
I had these add methods, which both take a Collection of some kind. The problem must be something to do with Java's lacklustre generics and the dexing process, I guess...
I've got a dll written in Pascal. I've determined that I need to run CoInitialize in the Java code, but I just can't figure out how.
I found another Stack Overflow thread which should have helped here: https://stackoverflow.com/questions/15763993 but I couldn't understand how it actually worked.
My current code that I have now is here:
public interface CSQLLib extends StdCallLibrary {
CSQLLib INSTANCE = (CSQLLib) Native.loadLibrary("DatabaseLibrary", CSQLLib.class);
public HRESULT CoInitialize(Pointer p);
public HRESULT CoUninitialize();
public String doSQLQuery(String input);
public void DllMessage();
}
Example of calling CoInitializeEx from Java code using JNA:
import com.sun.jna.platform.win32.Ole32;
public class Example {
public static void main(String[] args) {
Ole32.INSTANCE.CoInitializeEx(null,Ole32.COINIT_APARTMENTTHREADED);
}
}
Note that use of CoInitializeEx is recommended by both the JNA docs and the Windows SDK docs instead of CoInitialize. CoInitialize(null) is equivalent to CoInitializeEx(null,Ole32.COINIT_APARTMENTTHREADED), but the JNA docs recommend using COINIT_MULTITHREADED instead in Java apps (indeed, they call it "the only sane choice") – however, despite what they say, some COM interfaces only work correctly with COINIT_APARTMENTTHREADED, so it really depends on the COM objects you are using. Whichever you choose, CoInitializeEx is better because it makes it obvious (rather than implicit) which COM threading mode you are using.
Note the solution you mentioned in your comment, calling CoInitialize from within your DLL written in Delphi, is not a good practice. COM should be initialised in the application not in a DLL. If you ever attempt to reuse your DLL in some other application (which is already calling CoInitialize/CoInitializeEx), it is likely your call to it will fail with S_FALSE or RPC_E_CHANGED_MODE because the application will have already initialised it.