I need to get control over Windows of WindowsXP using Java code,
I need to click/type on particular button/textfield of given window of windowsXP,
How to do this any idea?
Approaches I tried are:
(1) I Tried AutoIT framework, but its Java Wrapper is buggy.. not stable.
(2) JNA can be used for native interfacing, by using some .dll file
to achieve the same. But I don't know which .dll file is used by windowsXP.
Can anybody elaborate on this?
I've not much idea which is much better solution.
Is there any better framework available for such thing.
Thanks.
WindowsXP uses multiple dll files, not one, and studying its API will tell you which one has which functions, and then you can use this information in your JNA interaction code. BTW, I have use AutoIt by itself to help do what you're trying to do and it works fine, and is easier than Java with JNA since it's built for this sort of thing. I've also used AutoIt with Java by having Java call small AutoIt programs and get some simple interaction via standard input and output streams taking care though of the tips and traps in this great article: When Runtime.exec() won't
Related
I want to make a program that would be able to manipulate the desktop based on user input commands (Preferably by voice, but... baby steps). Similar to Windows Speech Recognition, or Cortana.
I would like to make this as easy as possible to use and set up etc. For this reason I had planned on writing it in Java so that it would be cross-platform, and as simple as possible for users.
After looking further into how I would go about this, I saw mentioned here (Manipulating windows from other applications in Java) that I should use JNI.
I'm now wondering if (as mentioned in the top comment) it would be easier if I were to switch to C++ as using JNI might negate the cross-platform capability benefits of Java?
Or if possible, would it be possible to have the program select the appropriate JNI classes automatically based on the operating system?
In short: Does JNI negate the benefits of Java cross-platform compatibility?
Sorry if this post is a bit confusing. I've quite a few questions so this may seem a bit all over the place.
Many Operating System specific tasks cannot be done platform independent. But what Java already does a lot and JNI allows you to do too is that you can have different native binaries for different platforms - and possibly a single Java API to use all of them platform-independent.
Going C++ has the disadvantage that you need to have multiple executables. With Java you could have just 1 that loads different native code.
Although if you need a lot of different native code to implement your idea, maybe it's easier to just implement it for just 1 platform directly in a language that has bindings to all the required native APIs. Like maybe C# for Windows and something else for other platforms?
I have somoe C# source code that I want to be available for java applications under linux OS.
How can I call some C# method from java code?
I have found http://www.mono-project.com/Java but this looks like writing java code in .net environment. It is not what I look for. Rather I need to create new java library that will expose all functionality from C# code, the new library must be executed in pure java environment. Maybe that is possible with IKVM I am not sure.
Use Mono to compile your C# classes on the Linux platform of your choice;
Use JNI to write a set of facade classes between your java code and the compiled C# code.
The closest tool I can find that might be useful would be JNI4Net
I think you would still need Mono to run a .net framework on Linux as well.
Your question is going to be closed (I voted too) simply because it would finally lead to a tool recommendation.
Your best approach is to rewrite them in Java. Or alternatively, there are existing tools (commercial or free) to convert C# to Java,
CSharpJavaMerger Framework
RemObjects C# who compiles C# to JVM.
and many others
Mono is not something you should consider at this moment. Yes, IKVM.NET only helps running Java code on Mono/.NET, and it won't help you in your case.
It's not clear if you can execute the c# project or not through mono, if you can, then process intercomunication is the way to go.
If you are doing it in Linux I should use a pipe channeling to intercomunicate both processes, works really well and is easy to use.
If you can't execute the c# process, then that's another history, you cannot call directly a .net assembly from java.
And also, using mono on Linux per today gives great results (except for ASP .net), we are using it and are getting really good results (faster responses than Java in most scenarios).
I have a Java GUI application that has been interacting quite nicely with a standard C++ based DLL on the back end via SWIG-generated files. The back end program is currently a combination of C++ and managed C++/CLI. The problem is that we may eventually port all of it to C++/CLI.
Please correct me if I'm wrong, but from what I've been able to tell, SWIG currently doesn't work with C++/CLI and there are no plans to make it do so. I imagine that I could do write JNI code to make it work. But using SWIG was a whole lot easier. So what other options are there? The simpler to use, the better.
It is not correct to say that SWIG won't work with C++/CLI... You should be able to use the generated interop stubs exactly the same way you did. I didn't encounter a scenario where switching on the CLR support broke existing well formed C++ code...
I have a java code and created a jar file.
I need to create an Qt application. Can I use this code in that application?
Please help me how can i use that jar file.
Thanks,
Nagaraju.
You could take a look at the capabilities of GCC/GCJ (see http://gcc.gnu.org/ ). IF it's a good idea is a whole other story, and depends on what you have, and what you're trying to accomplish. It should be doable to link SO's created with GCJ in QT applications, but I seriously wonder if you are not better off using either C++ or Java, but not mixing them
If your Java code takes input from stdin or some file and writes output to stdout or some file, then the easiest way is to fork java to run that jar, and parse the output in your Qt code.
Things other than that, you'll need to be a bit specific. Something like "my Java code does painting the screen".
My advice is to use SWT or Swing.
You can use gcj gcj to compile the java code to library and simply call the functions of the java code from your C code.
Yes, you can use your jar file in your Qt application. I've done exactly this myself.
One way is to use the JNI Invocation API. This is part of the Java Native Interface (JNI), which makes it feasible but not pleasant to access Java APIs from C++.
A much more pleasant approach is to use CodeMesh JunC++ion, which wraps the Java APIs in C++ classes. This is a great product, if you can afford it.
If you have very little Java code, it may be easier to port it to C++.
Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!
You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).
Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)
If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.
I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.
I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.