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.
Related
So I have a Java application I will be releasing to one of my communities for a price. The app is just about complete and ready to be obfuscated but the problem is;
I found that when I add the Jar to another project in Eclipse you can instantiate classes externally and use my program as an external library to make scripts outside of my program. This is not what I'm wanting to achieve here... I'm self taught so I have grey areas of knowledge as I haven't learned formally, but I'm pretty experienced in Java still... I've tried googling it and nothings coming up, maybe I'm not phrasing it correctly. But if I could get some help it would be appreciated.
Here is my structure of my packages:
src.com
Contains main class
src.com.scripts
Contains Abstract Script class
src.com.scripts.impl
Contains the actual scripts that extend the abstract Script class
What I've tried doing:
I removed the public Identifier from the Abstract Script class but then it isn't visible to the main class to call it from as it is in the package before. So how can I go about this when my project is sorted in packages and they all need to access eachother?
There is no solution.
If people want to reverse engineer your code, they will. There is nothing you can do to change that. public/private are essentially meaningless beyond helping you write good portable code.
That being said, Java is generally much easier to reverse engineer and make bindings to than other languages. Java doesn't inline functions and unless told otherwise, it will even leave all of your class and method names intact. If you had used a language like C, the optimized binary would be a bigger pain to work with, but the result would still be the same.
Just obfuscate the jar and call it a day. Manually changing how you write your code is more harmful to you than it is to them.
I have two classes in a Java program. Class A and Class B.
Class B contains a native function that will execute C++ code.
As far as I know, the C++ code will run in the same process as the Java code.
The question that I have is that how can I limit the C++ code from accessing the Java memory and reading Class A's parameters?
I am afraid you are out of luck. Unlike reflection, JNI is completely unsecurable: CallVoidMethod() or GetIntField() can access everything.
To a certain extent, obfuscation can help. If class A is obfuscated, human-readable names of all its fields and methods are gone. Usually obfuscators generate stable, predictable names, but with an easy trick they can be randomized. Proguard can also 'optimize' your class, inlining some methods. Methods that don't exist anymore, cannot be called via JNI.
But still, the fields will be there, the methods that are called from 'outside' will still be there and maybe even preserve their names. So, better don't load a JNI library that you cannot trust into your process. Well, this is true for any DLL.
In the past few weeks, I've run into several different peoples' code using .class objects. For example, ArrayList of classes : ArrayList<Class> but how to force those classes to extend some super class?.
I looked them up: http://docs.oracle.com/javase/tutorial/reflect/class/index.html
I'm just wondering why you'd want to use .class objects. I can see getDeclaredFields() and getDeclaredMethods() being potentially useful, but I can't really think of concrete examples as to why I'd actually want to use the .class objects in lieu of something else. Could anyone shed some light on this topic?
Thanks in advance.
I think you misunderstood the concept. Class class has nothing to do with compiled classes (.class).
Class is a class that represents a Java class internal structure, such as fields, methods, etc... This is a compile-time entity, which you can use in your code (even before compiling).
.class is a compiled Java class file, which is Java bytecode. This is not a "code" entity (you cannot use it as a class or object in your code -besides as any file-) and it is not available before compilation.
Reflection (Class is part of the reflection package) is useful when you want to do advanced stuff with the code, like manipulating it, accessing its members, getting information from it, etc...
A typical example where you want to use reflection is making a Java debugger. Since any code can be run on the debugger, you need reflection to get information about the object instances and their structure and show this to the user.
Reflection is one reason to use it. Another good example is dynamically constructing objects at runtime.
For example, the Spring framework uses configuration files that contain the names of Java classes. Somewhere in that code, Spring needs to build object instances of those classes. In this way, the objects are created without the compiler needing to know anything about the Java classes at compile time.
This can be useful when developing an interpreter of a scripting language running on JVM, which has an ability to call Java methods.
Also, might be useful in a system allowing for plugin extensions.
Another use case:
InputStream is = MyClass.class.getResourceAsStream("/some/resource/in/the/jar");
Plug-in are a big use for this.
Dynamically load .class files which are in say, your plugins folder and execute some specified function from said files. Then, you can have 0 or more plug-ins and any combination of them installed for your application at a time.
I am part of a project that is consolidating code written in different languages at different times into one single application.
My piece is going from C++ to Java. After reading the comments to this question: https://stackoverflow.com/questions/587458/implement-mixin-in-java I concluded that mixins in Java are not really possible without code generation schemes, and those will not be well received within the team I'm working on.
What is the correct way to implement what used to be a Mixin in C++ using vanilla Java? In particular, there used to be an MVC-type design where some Controllers had mix-and-match logic that used controller state. Controllers would inherit Mixins to gain this functionality in various permutations such that a linear inheritance path does not make much sense.
The best thing I can think of right now is a bunch of utility-type classes that contain the logic that used to be in the Mixins, and have controllers call their functionality while passing themselves in as references so that the utility classes can access their state. IMHO this really stinks and I'm hoping there is a better way.
So, what is the right way to design this in Java?
If you really want mixins, you can use a language like Scala which supports them (and runs on a JVM with Java code)
Otherwise I would composition, which is not pretty either, but is simple.
Starting with one Java base-interface, I want others to be able to extend this interface, directly or indirectly, and add bean properties and behavior to it, as a plugin system.
Then, at runtime, on the user computer, I would find all those interfaces and generate a single big class that implements them all. The fields required for the bean properties would be generated automatically, while the behavior defined in the interfaces would be implemented as static methods of an helper class (created by the plugin developers) that take the appropriate interface as first parameter, so the implementation of the interface method would delegate to a static method, passing "this" as first parameter.
This is similar to how Scala implements it's traits.
I see 3 ways of doing this:
Use Java's dynamic proxies, which are based on reflection.
Generate the source-code as a string, and compile it at runtime.
Use some bytecode manipulation library to generate the class at runtime.
Option 1 is the easiest, but least efficient, and therefore I want a better solution. Option 2 would give me an efficient implementation, but is rather ugly.
While I have seen several libraries that can do option 3, they all seem to require that I learn Java's assembler language first, which I take as a very time-consuming activity, with little benefits in the end..
Since I don't want to learn any assembler, JVM or otherwise, is option 2 my best bet, or are there libraries that can generate dynamic proxies without me using JVM assembler?
Have a look at Javassist. With it, you can make runtime changes to classes using a straight-forward API. You don't need to know about java "black magic" to use it.
When using BCEL you don't have to know java assembler. Lok at this proxy.