I have a third-party C++ library with a very large number of methods (several hundreds) called from java through JNI and making use of multi-dimensional Object arrays like below:
public static native Object[][][] method1(int param1, Object[][][] param2, Object[][][] param3)
Note: each of those methods has a slightly different signature.
I have that third-party C++ library and its wrapper java class running in its own java process and remotely called by other java processes through Spring jms-remoting (it was very easy/mechanical to come up with the java interface required by Spring jms-remoting: just removing the "static native" keywords from the method signatures, that's it).
That approach has worked flawlessly and required minimal development efforts (thank you Spring team !)
I'm now trying to migrate from Spring-boot 2 to Spring-boot 3 where jms-remoting support has been removed.
Because I don't have full knowledge about what those Object[][][] objects contain, I'm currently trying to find a new remoting solution also based on RMI/Serializable (like jms Spring-Remoting).
Any suggestion regarding which frameworks may help me to achieve that goal ?
Thanks a lot in advance for your time and your expertise.
Best Regards
Related
I have a gwt project that acts as a semantic engine for other projects.
I recently realized very very little of the code is specific to gwt. Its almost all pretty basic java. In fact, the only things specific to gwt is retrieving files.
So what I would like to do is to separate out the gwt completely so I can use the same basic code for other Java projects - such as Android or Processing apps.
So, "Semantic Core" project could be inherited by GWT,Android and Processing apps and I wont have to maintain separate versions for each.
To do this, however, I need some way for other projects to "give" the Semantic Core project their own file-handleing methods.
My current idea how to do this;
One method I thought how to do this was to have SemanticCore define a Interface for FileManager with a method like;
getFile(String,MyErrorHandler,MySuccessHandler)
And then have the class's for MyErrorHandler and MySuccessHandler defined also in the SemanticCore project, effectively being runnables that take a string as a parameter.
With this Interface defined, other projects (GWT,Android etc) have to define their own class that implements it
eg, GWTFileHandler implements FileManager
Then create a object of this class, and pass it to the SemanticCore;
SemanticCore.setFileManager(new GWTFileHandler());
The semantic core can then use it at its leisure to retrieve files in a way suitable for the platform its on.
Question;
Is this a good way to do it? It seems wrong to me I am creating a new object, when I'll only be using static methods from that class.
Alternatives?
I hope my description is clear. As this all has to be GWT compatible in the "SemanticCore" project, any use of reflections is ruled out.
Thanks,
The recommended approach IMO is to use Deferred Binding to pick the GWT compatible version of your FileHandler or other GWT specific implementations. Extract the common interface for all versions and in your GWT module file you point to correct GWT implementation.
You can then instantiate your specific implemenation using GWT.create :
MyInterface implemenation = GWT.create(MyInterface.class);
more in depth info on the gwtproject site.
Deferred Binding is a technique used by the GWT compiler to create and
select a specific implementation of a class based on a set of
parameters. In essence, deferred binding is the GWT answer to Java
reflection. It allows the GWT developer to produce several variations
of their applications custom to each browser environment and have only
one of them actually downloaded and executed in the browser.
I'm developing a small application that passes messages around, which are POJOs. I'd like to construct a registry of the types of messages that can be handled. I originally planned to stick them in an enumerated type as follows.
public enum Message
{
INIT( InitMessage.class, "init" ),
REFRESH( RefreshMessage.class, "refresh" );
private Message( Class<?> messageClass, String messageCode )
// etc..
}
I don't like this approach, as I have to maintain a central enumerated type to manage the allowed classes. I'd prefer to instead annotate the POJOs.
#MessageDefinition( "init" )
public class InitMessage
{
// .. some properties with appropriate getters and setters
}
I checked out the Tomcat source from Subversion, and even with the help of an IDE, it was taking me a very, very long time to wade through the levels of abstraction and get to some gutsy code showing me how it scans the classes in a webapp searching for annotated classes to register #WebServlet, #WebListener, etc. Even more off-putting was the fact that I could only really see references to those annotations in test classes.
My question is how do annotation driven frameworks scan for annotations? It's hard to know which classes you're hoping to scan, even moreso before they've been loaded by the classloader. I was thinking the approach might be to look for all files that end in a .class extension, load them and check for annotations. However, this approach sounds pretty nasty.
So I guess it boils down to:
how does Tomcat find annotated-classes? (or any other frameworks you're familiar with)
if Tomcat's (or the framework you mentioned above's) approach sucks, how would you do it?
is there a better way that I should architect this overall?
Note: Scan the classpath for classes with custom annotation is great, but I'd love to do it with standard Java 7 if possible.
Update:
Reflections is not suitable. It has a tonne of dependencies, and to make things worse, it relies on old versions of libraries - in particular one that takes pride in deprecating dozens of features every release, and releasing rapidly.
I'm thinking about following this guide and using ASM if possible:
http://bill.burkecentral.com/2008/01/14/scanning-java-annotations-at-runtime/
Tomcat scans for annotations using a cut-down (so only the bits Tomcat needs are present) and package renamed (so it doesn't clash if the web app ships with BCEL as well) version of Apache Commons BCEL. It looks for every .class file, reads the byte code and extracts the annotations.
For the details, you can look at the source code. Start at line 1130 of this file:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?annotate=1537835
The other popular library for doing this sort of thing is ASM.
the problem is quite simple yet maybe not resolvable?
Atleast for me :/
Situation:
Let's say I have a dynamic Page System where the Server provides additional copies of self containing GWT Modules. Meaning a main GWT instance on the client side is supposed to manage the new incoming GWT Scripts, which are simply added by the main instance itself using Tags.
Now the main GWT instance needs to communicate with the newly created script instances in the most easiest (GWT internally) way possible.
So what is out of the question: Writing stupid JSNI Wrappers on both sides, if not absolutely required.
Soltuions I came up with were:
Make a module both use, including a common interface, example:
package com.whatever.interfaces;
public interface Communication {
void showMessage(String message);
}
So both would now inherit this module and know of the definition.
The main client would now load the dynamic JS and register an implementation of Communication and the dynamic one would go and use it. I tried storing references on $wnd and on elements using setPropertyObject. On $wnd they are null, which maybe/probably related to the the GWT Iframing? For the property on the RootPanel element for example, ClassCastException would be raised.
Is there any good way to encounter this? Another idea I have is using JSNI for calling the interface as an implementation on the bridge module, but I'm not sure if this a good way.
Your help is appreciated, thanks.
EDIT:
Well I have pretty much come to the conclusion that this is not possible whatsoever.
Even though you might have used same interfaces somewhere, they will be very own instantiations of it, for different modules compiled, even if using the same module as a common ground.
The approach using JSNI certainly is somewhat possible, but not without mapping all attributes to real JS Objects and remapping them back. Meaning you can't pass complex Java Objects around like you probably would be used to. My conclusion would be, using CodeGenerators you could build the JSNI Wrappers automatically and the remappers, for both modules, but this is too much of a hassle for me.
I'm still open if someone comes up with a better idea, but I just want to provide some inside on my findings, so others can benefit of my wasted time ;)
A while ago, I created a simple prototype implementation to share Object instances to other GWT modules. You can find the code on https://code.google.com/p/gwt-plug/. And yes, as you described, it's a problem to transfer Java objects. As far as I remember, you can only transfer primitive values (int, float, ...), Strings and JavaScriptObjects. But JavaScriptObjects are a good possibility
As you already found out communicating between separately compiled GWT modules is somewhat of a challenge since everything is obfuscated. It is possible though through javascript, JSNI, JSO's and JSON.
You can use JSNI to create communication hooks through javascript directly on the $wnd object. Sort of an event bus approach would work.
You can use JSON to pass around complex objects.
You can use JSO's (JavaScript Overlays) to consume and manipulate the JSON in each of the disperate modules.
Putting all that together you would end up with a mini-framework library module that you would share between the various GWT modules you want to have communicate with each other. They would each inherit the common framework module and compile in their own obfuscated form but since they are using javascript and JSON as a common language they won't have to worry about the obfuscation.
Make sense?
As explained in the xsee's answer, you can create a hook from GWT using JSNI
In order to do this, take a look to very useful project http://code.google.com/p/gwt-exporter/
I'm writing a big Red5 Java application for the web.
Red5 a Flash Media Server alternative that is java based and is written with the spring framework.
I want to have many versions of my application online, each with different behaviors and different classes enabled or disabled.
I'm looking for a way to convert my code into modules based code that will allow me to remove/add modules/features from the main application.
I know about OSGI http://www.springsource.org/osgi but it says that it needs a SpringSource dm server and I have no idea how it's gonna work together in red5 and it's seems very complicated to fully understand.
I don't have a good knowledge of spring framework in general, i work with it db-related and that's it. red5 uses it more extensively.
so can anyone please make any sense from this information ? is there something that can be done to divide my code to modules ?
any information regarding the issue would be greatly appreciated.
My preferred method of dealing with this kind of situation is Dependancy Injection (DI). Spring has a DI capability built in, for which a tutorial is easy to find online. However, Spring's DI is not as good, for many reasons, as that provided by Guice, which I would highly recommend. (The main advantage of Guice over Spring's DI in my opinion is type safety.)
DI is basically a mechanism for replacing class implementations at runtime. Rather than hard code dependancies into classes (by having a class construct other classes directly for example) you code them to have their dependant classes passed to them in their constructors. The DI framework will then pass the correct instances at runtime according to the configuration. Spring configuration can be done via annotations or an XML file, Guice uses a subclass of com.google.inject.AbstractModule.
So you could use different configuration files for the different instances of your application, and have them provide different sets of features for activation, or indeed different implementations of the same feature. If you set up the application to use this technique then the only thing that need differ between instances is a single configuration file.
After a bunch of XML config files, I've seen Java moving to Annotation based configurations.
Are annotations playing the role of DSL here?
Is it because the static nature of Java? I'm thinking in Ruby which doesn't have ( afaik ) things like that. Is it because Ruby has good metaprogramming capabilities?
Are there alternatives ( I mean other than using a bunch of .xml files )
Basically annotations are a tool that allows you to process source files at compile-time and do action corresponding to annotations found in the file (possibily deriving a new source).
They are quite useful for many purposes like expliciting constraints while avoiding cluttering the code or enrich the behaviour of some methods.
I wouldn't say that they are so similar to DSLs of Ruby since in this case you annotate code with a particular syntax while in Ruby you can design your own DSL from scratches and use it as you wish.
Java ships a tool called apt (like the one you suspect) that is able also to work with annotations at run-time but they are usually used to give compile-time infos to your sources. This doesn't mean that in certain circumstances you can't easily adapt the annotation mechanism to work out the same things that you would obtain with a DSL but they don't exist for the same purpose.
As already said, annotation can be used to create DSLs quite efficiently, bacause they add some sort of metaprogramming capabilities to the langauge. However for that purpose you could use byte code injector or even any other Java language feature.
However the primary purpose of annotations is to be able to annotate source code elements with metadata.
If you are asking for alternatives for creating internal DSLs in Java, just look at the Fowler's DSL book WIP and choose from different concepts which can be used for implementing internal DSLs, many of them are present in Java. If you are asking for alternatives for metaprogramming, then there are also many: different byte code injectors, aspect oriented programming using AspectJ or Spring or code generation.