I stuck with a problem. I use Chilkat for Java and as i understand there is no, any Maven Repo for it. As it is a two-component library - i need to inject .dll, via System.load(). This part is clear to me, but also they provides something, like wrapper, which calls methods in .dll.
So, i don't want to import their .jar to my project, but, then i call native methods by my own it fails with java.lang.UnsatisfiedLinkError. Because, then java tries to invoke a native method it adds some stuff at the beginning of it's name. For example: if i declare native method in my package, then it will be invoked, java will add all package hierarchy names to it's name.
Can i somehow call directly the native method by it's name, without any runtime "adaptations" ?
javac can generate the bindings you might be looking for ...DLL export viewer (among several others) can list exported methods. Or for SO, just use dumpbin /EXPORTS ./filename. That method names would change at runtime is not a reality, this only happens once when obfuscating them, at build time - which usually excludes all the objects, which need to stay accessible (for reflection).
Just start a new JNI project and learn how it works with vastly reduced complexity. There still is a chance, that this one JAR might pass licensing information in the native assembly - or that the native assembly performs cryptographic functionality for the JAR. An a commercial library is not to be treated alike open source - I'd read THEIR licensing terms, to begin with.
Related
Is there a way to get notified when a method from a Different JVM is called.
Dev Env: JDK8, Windows 10 (later on cloud for deployment).
I have couple of Java applications running, One in App Server and another is standalone batch process.
Whenever a core java class method is called on either of these JVM's e.g. PrintStream.print, I need to get handle to input string and log it somewhere else.
I tried with
1. Java bytecode manipulation libraries e.g. Javassist, to transform byte code using Instrumentation, but it allows to have handle and manipulate User Defined classes / Third party library classes only - not java., sun. etc... (even if we do it somehow, it says - it violates JRE binary licence - Official Javadoc says this process of instrumenting the rt.jar class violates the JRE binary code license - so this may not be the go ahead approach.
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html )
Reflections - Can be used when you are on the same JVM, not sure if it works on different JVM.
Appreciate suggestions.
I am writing an application in Qt that I want to extend with plugins.
My application also has a library that the plugins will use. So, I need a 2 way communication. Basically, the plugins can call the library, and my application which loads the plugins will call them.
Right now, I have my library written in C++, so it has some classes. The plugins can include the header files, link to it and use it. I also have a header file with my interface, which is abstract base class that the plugins must have implemented. They should also export a function that will return a pointer to that class, and uses C linkage.
Up to this point I believe that everything is clear, a standard plugin interface. However, there are 3 main problems, or subtasks:
How to use the library from other languages?
I tried this with Python only. I used SIP to generate a Python component that I successfully imported in a test.py file, and called functions from a class in the library. I haven't tried with any other language.
How to generate the appropriate declaration, or stub, for my abstract class in other languages? Since the plugins must implement this class, I should be able to somehow generate an equivalent to a header in the other languages, like .py files for Python, .class files for Java, etc.
I didn't try this yet, but I suppose there are generators for other languages.
How am I going to make instances of the objects in the plugins? If I got to this point the class would be implemented in the plugins. Now I will need to call the function that returns the instance of the implemented abstract class, and get a pointer to it.
Based on my research, in order to make this work I will have to get a handle to the Python interpreter, JVM, etc., and then communicate with the plugin from there.
It doesn't look too complex, but when I started my research even for the simplest case it took a good amount of work. And I successfully got only to the 1st point, and only in Python. That made me wonder if I am taking the right approach? What are your thoughts on this.. maybe I should not have used Qt in my library and the abstract base class, but only pure C++. It could probably make the things a bit easier. Or maybe I should have used only C in my library, and make the plugins return a C struct instead of a class. That I believe would make the things much easier, since calling the library would be a trivial thing. And I believe the implementation of a C struct would be much easier that implementing C++ class, and even easier that implementing a C++ class that uses Qt objects.
Please point me to the right direction, and share your expertise on this. Also, if you know of any book on the subject, I'd be more than happy to purchase it. Or some links that deal with this would do.
C++ mangles its symbols, and has special magic to define classes, which is sort of hacked on top of standard (C) object files. You don't want your files from other languages to understand that magic. So I would certainly follow your own suggestion, to do everything in pure C.
However, that doesn't mean you can't use C++. Only the interface has to be C, not the implementation. Or more strictly speaking, the object file that is produced must not use special features that other languages don't use.
While it is possible for a plugin to link to your program and thus use functions from it, I personally find it more readable (and thus maintainable) to call a plugin function after loading it, passing an array of function pointers which can be used by the plugin.
Every language has support for opening shared object (SO or DLL) files. Use that.
Your interface will consist of functions which have several arguments and return types, which probably have special needs in how they are passed in or retrieved. There probably are automated systems for this, but personally I would just write the interface file by hand. The most important is that you properly document the interface, so people can use any language they want, as long as they know how to load object files from their language.
Different languages have very different ways of storing objects. I would recommend to make the creator of the data also the owner of the memory. So if your program has a class with a constructor (which is wrapped in C functions for the plugin interface), the class is the one creating the data, and your program, not the plugin, should own it. This means that the plugin will need to notify your program when it's done with it and at that point your program can destroy it (unless it is still needed, of course). In languages which support it, such as Python and C++, this can be done automatically when their interface object is destroyed. (I'm assuming here that the plugin will create an object for the purpose of communicating with the actual object; this object behaves like the real object, but in the target language instead of C.)
Keep any libraries (such as Qt) out of the interface. You can allow functions like "Put resource #x at this position on the screen", but not "Put this Qt object at this position on the screen". The reason is that when you require the plugin to pass Qt objects around, they will need to understand Qt, which makes it a lot harder to write a plugin.
If plugins are completely trusted, you can allow them to pass (opaque) pointers to those objects, but for the interface that isn't any different from using other number types. Just don't require them to do things with the objects, other than calling functions in your program.
I have an application that is developed in Java that has nice GUI and all. I don't have the source code and also the dll's of that. But I have the compiled classes of that application (.jar files).
Now, I want to automate that application. I mean the application needs manual intervention.
Can I use that compiled classes so that I can use its functions to automate the functionality of that application?
If so, how would this be done?
You shouldn't have to "got the compiled classes out of that application (.jar)". A better idea would be to treat it just like any other 3rd party JAR and add it to your CLASSPATH when you compile and run.
You'll write your own class that instantiates an instance of that 3rd party class and calls its methods, just like any class you get from the JDK.
You may not be able to alter that class; you might not want to even if you could.
If you must have new functionality, the OO way would suggest that you should extend that class, if you can, and override its method according to your needs.
Put that .jar into your classpath and use what ever you want from that application. If you need to use private fields or methods also you can use Reflection API for that. There is no restrictions of using objects from .jar file.
You should beware of infringing on any copyrights if the application you are referring to is proprietary. Otherwise, any java decompiler will get you the source code from those class files.
I'm aware that it isn't easily feasible to get all of the classes in a package using reflection, but I'm wondering if someone knows of a good solution/workaround, specifically for an Android project?
Given a package, I need to be able to retrieve all of the classes from it and process annotations from them using reflection.
Does anyone know of a way to do this? Are there any libraries available?
Scanning the filesystem as most solutions for non-Android Java do won't help on Android. Here's a (theoretical) solution that is android-specific: http://mindtherobot.com/blog/737/android-hacks-scan-android-classpath/
However, it remains a hack, since Java unfortunately does not directly support this.
Existing dependency injection solutions use reflection for processing the annotations, but still need the resources to be declared. See this example of DI using reflection.
If you are using Ant to build your artifacts, you could read the contents of your source directory using Bash or Java, and use this to regenerate the full hierarchy of classes automatically during each build. This might make things tricky if you rely on heavily on the Eclipse IDE though, since the list might be out of date until you run another Ant build. (Note: according to Pyscho you can make Eclipse use Ant by altering the project configuration, see comments)
Another option might be to process the AndroidManifest file using the AssetManager, but you would be limited to the resources declared in that file. The compiled classes themselves are in-lined and optimised in the classes.dex file, and as such you're unlikely to get much useful information from it.
I think you might find the answer here https://stackoverflow.com/a/1457971/1199538
there is a java file attached so you can download it and try it
short snippet from the answer following:
This method can only be used when:
You have a class that is in the same package you want to discover, This class is called a
SeedClass. For example, if you want to list all classes in 'java.io', the seed class may be java.io.File.
Your classes are in a directory or in a JAR file it has source file information (not source code file, but just source file). As far as I've tried, it work almost 100% except the JVM class (those classes come with the JVM).
Your program must have permission to access ProtectionDomain of those classes. If your program is loaded locally, there should be no problem.
You can do classpath scanning for Android at compiletime, before the JVM bytecodes have been converted to Dalvik bytecodes, e.g. using the ClassGraph library (I am the author):
https://github.com/classgraph/classgraph/wiki/Build-Time-Scanning
I have a scenario where I have code written against version 1 of a library but I want to ship version 2 of the library instead. The code has shipped and is therefore not changeable. I'm concerned that it might try to access classes or members of the library that existed in v1 but have been removed in v2.
I figured it would be possible to write a tool to do a simple check to see if the code will link against the newer version of the library. I appreciate that the code may still be very broken even if the code links. I am thinking about this from the other side - if the code won't link then I can be sure there is a problem.
As far as I can see, I need to run through the bytecode checking for references, method calls and field accesses to library classes then use reflection to check whether the class/member exists.
I have three-fold question:
(1) Does such a tool exist already?
(2) I have a niggling feeling it is much more complicated that I imagine and that I have missed something major - is that the case?
(3) Do you know of a handy library that would allow me to inspect the bytecode such that I can find the method calls, references etc.?
Thanks!
I think that Clirr - a binary compatibility checker - can help here:
Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.
Changing the library in your IDE will result in all possible compile-time errors.
You don't need anything else, unless your code uses another library, which in turn uses the updated library.
Be especially wary of Spring configuration files. Class names are configured as text and don't show up as missing until runtime.
If you have access to the source code, you could just compile source against the new library. If it doesn't compile, you have definitely a problem. If it compiles you may still have a problem if the program uses reflection, some kind of IoC stuff like Spring etc.
If you have unit tests, then you may have a better change catch any linking errors.
If you have only have a .class file of the program, then I don't know any tools that would help besides decomplining class file to source and compiling source again against the new library, but that doesn't sound too healthy.
The checks you mentioned are done by the JVM/Java class loader, see e.g. Linking of Classes and Interfaces.
So "attempting to link" can be simply achieved by trying to run the application. Of course you could hoist the checks to run them yourself on your collection of .class/.jar files. I guess a bunch of 3rd party byte code manipulators like BCEL will also do similar checks for you.
I notice that you mention reflection in the tags. If you load classes/invoke methods through reflection, there's no way to analyse this in general.
Good luck!