I would like to invoke a paste operation with my java application. Is this possible without using Robot?
For example, the application would invoke a paste operation every so often, so when I am writing in notepad, I would see the contents of my clipboard.
JAVA APP Notepad
clipboard.paste() --------> clipboardContents
It sounds as if you're trying to use Java to interact or partially drive another application (such as Windows NotePad) and paste to that application, and if so there are several possible solutions, one being use of Robot, another having Java make operating system calls, though this can't be done directly with just core Java and would require use of either JNI, JNA or other platform-specific non-core utility programs such as AutoIt (if this is for Windows).
Why are you dead set on not using Robot? Can you explain your needs in greater detail?
Edit
regarding your comment:
I want to explore alternatives to Robot, as my client irrationally rejects Robot.
Since this appears to be for a Windows platform, you might consider exploring the Windows API and the API for whatever non-Java program you're trying to drive (if one exists), and then using JNA to interact with it. The Windows User32.dll would allow you to get the Window handle (hWnd) of the application that you're trying to drive, which may be necessary for this to work.
It's hard to give more specific advice without more specific information from you about your problem though.
Edit 2
regarding your comments:
I would like the app to be platform independent.
Well, Robot comes to mind then. You might want to have a sit-down with your client to find out what they dislike so much about Robot, and then gently explain that it might offer the best path towards a platform-independent solution.
Are there examples for JNA and/or JNI? I'm not familiar with either.
Yes there are lots of examples on this and other sites, and Google will help you find out more. JNA is a bit easier to work with as it doesn't require you to create a C bridge program, but it can be a little slower than JNI, and doesn't work directly with C++ code (as far as I know).
Edit 3
regarding your comments:
I have a serial port listener (java app). I need to provide its contents onto a web browser. Clipboard seemed to be a way to do it.
And this is why it's so important for you to provide the context of your problem rather than what you think your code solution should be.
Communicating between applications is not an easy thing to do, and often Java is not the best tool for this since as it is designed to be as platform agnostic as possible, it does not provide tools that allow for easy integration with low-level OS functions. I don't know the best way to solve your problem, but my intuition tells me that using clipboard may not be the way to go. Much may depend on which web browser you're talking about, whether it has some sort of API that allows for interface with other programs, things I know little about. Also where is your program sitting? On the user's computer? Have you considered using a Java web browser library of some type, creating your own specialized web browser program, and obtaining the data directly from your serial port listener (again, I have not done this myself, but have seen it described on SO)?
I don't understand how bridging to a C program will help me.
I'm not suggesting this. This would only be needed if you used JNI, something I avoid since JNA is much easier (at least for me).
Related
I am planning to create a software that will be compatible with both Windows CE and Android devices.
Nothing has been decided yet, but so far I've imagined that I could write most parts of the program using C++ code that could be reused on these two platforms, except for system-dependant things like threads. C++ is highly recommended for performance in my case.
In the case of system-dependent things I would create interfaces that would be implemented in two different ways, one using the win32 API, and the other one using the linux equivalent. The other parts of the code the logic) would be independent and reused on both platforms.
The only part of the application that would not be written in C++ would be the user interface. Using the Android API on Android platforms, and something else on Windows CE (C#, Java, don't know yet).
I've read that Android is not like other linux distributions because many linux features are not available from native code on it.
So my question is : is it possible to natively create and use sockets, threads, critical sections (and any other system-dependant things) from a native linux api using JNI (i.e the equivalent of the win32 api but for linux) or do i always have to create them into the Java layer and pass them down to the native code ?
I've not yet decided how II am going to build this, i'm just informing myself on the different possibilities.
Thank you.
NDK implemented POSIX (include pthread, mutex) and BSD socket, so you don't necessary create them with java objects.
However, STL support is still crappy IMO, which you may need to pay attention with your own code or porting any dependency libraries.
It is possible to do all of this with JNI, but I would think twice before doing so. Using JNI has its share of liabilities; it will make development and debugging considerably more difficult. You will also end up with a lot of callbacks to Java code to communicate with the GUI. Think of features like visual progress indicators for ongoing operations. And don't forget that in the end, your app's performance may suffer because of the extra indirection required by each JNI call. Be sure to measure performance in either case. JNI, or C++ for that matter, does not automatically make anything faster.
Also, it may be harder than what you think to just "mirror" your app on another operating system. Android, as an operating system, behaves differently not only on the GUI side (it is, for example, nonsense to provide a back button within in an Android app), but also on the inside, with its typical app architecture broken down into Services, Activities and Receivers. It's not just "a different GUI", not at all.
If you have backend functionality that really can and should behave identically on both platforms, then go on, write it in C++ and reuse it on Android via JNI. But it may be easier, and it may be equally or more performant, to just implement it or parts of it from scratch on Android, using Java. Without knowing any details about your project, it is impossible to say.
Why don't you try and implement a simple test app on Android using JNI? Try to use the NDK to send an HTTP request in a background thread and write the respone back to Java as a String. You'll eventually see that it works, but you will also have a better understanding of the difficulties involved.
Recently I've been exploring the world of smalltalk dialects and am very impressed (from here on in understand that when I write 'smalltalk' I'm referencing any of the modern smalltalk dialects - squeak/pharo/etc). I like the small footprint of the VM and the language itself.
As grad student and often need to write tools that support my research. Typically I use Java because I can easily deploy a tool to my colleagues without worrying too much about what their computer setup is or how tech savvy they are. It's pretty easy to whip up a GUI interface and all the end user has to do is double click on an executable JAR and they are gtg. The problem is that Java has all sorts of security issues and doesn't always run in the same way on every platform. Smalltalk, therefore, is starting to look pretty attractive.
I know that it's possible to create a smalltalk program that fires up with one double click of an icon. What I'm wondering about is whether or not I can create a sandboxed smalltalk world such that the only thing the user sees and is able to interact with is my application. I don't want them to see any aspect of the smalltalk world. This way, users can't accidentally muck things up or get confused because they have access to a plethora of options that aren't directly relevant to use of the program. Is this possible, and if so, how do I do it?
Apologies - I should've done a better job of RTFM prior to posting this question. It is apparently possible to do this via Lockdown:
http://map.squeak.org/sm/packagebyname/lockdown
Also helpful:
http://wiki.squeak.org/squeak/3563
In Pharo, you can send openWorldWithSpec to your UI so that it is full screen. An example of this is the Pharo Launcher: https://ci.inria.fr/pharo-contribution/job/PharoLauncher. When you launch this image, you can't access the rest of Pharo (at least, not easily).
I am decided to use CORBA to communicate between a C++ service and a java service. I want to know that is it possible using CORBA to inter call C++ library and java library like we call a dll in an application. It will be very helpful if anyone help me to take a good decision!
(Seems some confusion in my previous answer. I think it is better that I give another answer which state clearer my point)
CORBA is for interactions between "remote" components. Although I used the term "Remote" here, it doesn't mean that components needs to be located in remote machine. They can be in the same machine, or even same process.
The answer mostly depends on your aim:
If you are writing new libraries/components in C++ and Java, and you want to use them in the same application and have components in both language able to interact with each other, then yes, CORBA can help you in certain extend. However CORBA is helping you in the component communication part. You still need to use JNI (or other similar solutions) to invoke/startup your C++/Java component in your Java/C++ application. CORBA is not going to help you on this. You may want to do extra POC to see if having two ORBs in same application (one for C++, one for Java) is going to cause you any problem.
If you are talking about: you already have some existing libraries which is written in Java and C++ (of course, not in CORBA-awared manner), and you are looking for way to make use of these library in your new application (in Java/C++). Then no, CORBA cannot help you much on this. Of course you can still write a extra layer which expose your components in CORBA, and make use of them, but making use of CORBA here is not going to make "calling C++ library or Java library" anything easier.
However, imho, neither case above seems to be a strong reason to make use of CORBA. If you are just looking for interoperability of Java and C++ libraries, JNI, or JNA maybe something you want to look into.
I am curious about what automatic methods may be used to determine if a Java app running on a Windows or PC is malware. (I don't really even know what exploits are available to such an app. Is there someplace I can learn about the risks?) If I have the source code, are there specific packages or classes that could be used more harmfully than others? Perhaps they could suggest malware?
Update: Thanks for the replies. I was interested in knowing if this would be possible, and it basically sounds totally infeasible. Good to know.
If it's not even possible to automatically determine whether a program terminates, I don't think you'll get much leverage in automatically determining whether an app does "naughty stuff".
Part of the problem of course is defining what constitutes malware, but the majority is simply that deducing proofs about the behaviour of other programs is surprisingly difficult/impossible. You may have some luck spotting particular patterns, but on the whole you can't be confident (and I suspect it's provably impossible) that you've caught all possible attack vectors.
And in the general sphere, catching 95% of vectors isn't really worthwhile when the attackers simply concentrate on the remaining 5%.
Well, there's always the fundamental philosophical question: what is a malware? It's code that was intended to do damage, or at least code that doesn't do what it claims to. How do you plan to judge intent based on libraries it uses?
Having said that, if you at least roughly know what the program is supposed to do, you can indeed find suspicious packages, things the program wouldn't normally need to access. Like network connections when the program is meant to run as a desktop app. But then the network connection could just be part of an autoupdate feature. (Is autoupdate itself a malware? Sometimes it feels like it is.)
Another indicator is if a program that ostensibly doesn't need any special privileges, refuses to run in a sandbox. And the biggest threat is if it tries to load a native library when it shouldn't need one.
But all these only make sense if you know what the code is supposed to do. An antivirus package might use very similar techniques to viruses, the only difference is what's on the label.
Here is a general outline for how you can bound the possible actions your java application can take. Basically you are testing to see if the java application is 'inert' (can't take harmful actions) and thus it probably not mallware.
This won't necessarily tell you mallware or not, as others have pointed out. The app could still do annoying things like pop-up windows. Perhaps the best indication, is to see if the application is digitally signed by an author you trust; if not -- be afraid.
You can disassemble the class files to determine which Java APIs the application uses; you are looking for points where the java app uses the OS. Since java uses a virtual machine, there are well defined points where a java application could take potentially harmful actions -- these are the 'gateways' to various OS calls (for example opening a socket or reading a file).
Its difficult to enumerate all the APIs, different functions which execute the same OS action should require the same Permission. But java's docs don't provide an exhaustive list.
Does the java app use any native libraries -- if so its a big red flag.
The JVM does not offer the ability to run arbitrary code, or use native system APIs; in particular it does not offer the ability to modify the registry (a typical action of PC mallware). The only way a java application can do this is via native libraries. Typically there is no need for a normal application written in java to use native code (unless it needs to use devices).
Check for System.loadLibrary() or System.load() or Runtime.loadLibrary() or Runtime.load(). This is how the VM loads native libraries.
Does it use the network or file system?
Look for use of java.io, java.net.
Does it make system calls (via Runtime.exec())
You can check for the use of java.lang.Runtime.exec() or ProcessBuilder.exec().
Does it try to control the keyboard / mouse?
You could also run the application in a restricted policy JVM (the instructions/tools for doing this are not as simple as they should be) and see what fails (see Oracle's security tutorial) -- note that disassembly is the only way to be sure, just because the app doesn't do anything harmful once, doesn't mean it won't in the future.
This definitely is not easy, and I was surprised to find how many places one needs to look at (for example several java functions load native libraries, not just one).
I'm trying to make an java application to manage Linux servers from a web interface.
It is a bad idea to perform each task by calling bash shell ?
Are there any other options other than those to use C, Perl or another language?
It's not necessarily a bad idea to use bash to do the actual work. It would help if you gave us more of an idea what exactly the web interface was changing.
Java in particular does not provide much system-specific controls, because it was designed as a cross-platform language, so putting specific platform tools in would go against it's purpose.
You could certainly do it that way. Ideally you'd open up a port and accept specially crafted, specific actions which perform only the intended actions (an interface server) through a socket library.
I should think that the disadvantage(s) of calling Bash scripts for your commands is all related to error handling and return values. Each of your Bash scripts will need to return sensible, useful information to the Java app in the case of failures (or even successes). And you'll probably want a common interface for that such that each Bash script, no matter its function, returns the same types so that the Java can interpret it easily.
So, in that sense, making the changes from your Java program reduces the complexity of handing the information back and forth. On the other hand, if Bash is easier for you, you may find it more fast and flexible.
Opening up a single bash shell and sending commands (and properly parsing results) shouldn't be bad. It does tie your program to a single OS and even a single shell, but that's the nature of what you are trying to do.
What I wouldn't do is open a shell for each command and close it after each result. It seems to me that would cause unnecessary thrashing when many commands were executed in a row.
Security concerns jump at me. If you have a form like "type command" then someone clever could exploit some things. For example "configure network" is fine but "configure network; install rootkit" can be typed because a semi-colon allows commands to be chained.
All in all, this is not tight integration. If this is a personal project, go for it. It's a good learning project to turn a procedural script into a java program. If this is a serious effort to recreate the many various webapp admin tools there are, I'd seriously suggest skipping this. The VPanel/CPanel things I've seen I hate. There used to be a php based linux admin thing that looked ok but I just find them easily to learn, easy to outgrow because the net and community is full of command line knowledge.
If you are trying to automate a large deployment, look at the ruby-based puppet. It looks really neat.
I have a socket server were I perform different operations (using ifconfig by calling shell for example) and I plan to integrate an client in a JSF application.Because I'm not experienced ant I intend to make it my graduation project, but I'm not so sure if calling bash from java to configure a linux box is a good solution.
Java does have some Linux-configuring classes (well, at least, OpenJDK does). Check OperatingSystemMXBean or something like that.
You're beter to write your own server configuration utility in the language you prefer, sanitize it, make it secure and then call it via bash from your java app.
There are two questions here:
Should you try to do the configuration work in Java, or should you externalize it?
Assuming that you have externalized it, should you use bash scripts.
In this case, the answer to question 1) depends. This kind of thing can be difficult to implement in pure Java. This leaves two choices; externalize the task using a Process, or try to do it in a native code library via JNI or JPA. The latter approach is complicated and gives you JVM crashes if you make a mistake, so I would rule that out.
On the other hand, if you can find a good standard or 3rd party Java API that does what you need (without infesting your JVM with flakey JNI, etc), you should use that.
The answer to 2) is that bash scripts will work as well as any other scripting language. I think that using scripts gives you a bit more flexibility. For example, if you need to do things to compensate for differences in the different flavours of Linux, UNIX or maybe even Windows (!) you can put this into the externalized scripts. (A corollary is that the scripts need to be configurable, so don't embed them in your source code!)
Another alternative might be to run the commands (e.g. ifconfig) directly, using a fully qualified command name and supplying the arguments as an array of strings, etc. But unless your app is going to run the external command 100s of times a minute, it is probably not worth the (Java) coding effort and the loss of flexibility / configurability.
A lot of the response would depend on why you're doing this and why other more obvious solutions aren't possible. Knowing why you would choose to roll your own as opposed to installing Webmin would be good, or why you're choosing to use Web UI at all as opposed to VNC to control the box. There are some obvious responses to the later (firewall issues for instance), but there's no immediately obvious reason for the former. Without knowing more about the requirements, answering questions about implementation details like bash scripts versus perl or C is meaningless.