I want to replace the current Java process by a new one just like the Unix exec does. There has been already a similar question here, but I'd prefer a solution consuming as few memory as possible (the accepted answer suggest to use ClassLoaders, which could lead to memory leaks; a similar simple solution would be to use another process just to start the proper one). It can be surely done in a platform-dependent way using JNI, and I think I can do it for Unix (and a solution for Unix seem to already exist), but I know nearly nothing about the corresponding Windows API. What Windows function should I call? Has anybody done it already?
With Windows there are many subsystems to choose from that run on the base OS, so it helps to have some sense of what you are aiming for. For example, if you can use the C run-time library then you can just use the _exec() family of functions which are very similar to their unix cousins. Perhaps you can modify jniexec to work with windows using these.
The Win32 API doesn't include the concept of 'exec'. THe POSIX API does. The low-level WinNT API has the building blocks, but it's quite complex to use them, and, at least in the past, required recourse to undocumented functionality.
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?
This question already has answers here:
Why Java doesn't support function like clrscr in C?
(2 answers)
Closed 9 years ago.
My friend asked a question
Why Java doesn't support function like clrscr in C?
The answer given by SO's users were
John3136 : since Java is cross platform and can be run without a console, the meaning of clrscr has to change depending on how the app is run and on what platform.
mvp : Java was designed to be write/compile once, run anywhere. And this function does not quite fit into this agenda.
My question is that isn't the cross platform discrepancies handled by JVM?
How would a function like Thread.sleep() and System.out.println() work then? They also depend on the underlying platform like the threads are implemented [may be] differently in Linux and in Windows?
My main concern is that if function like System.out.println() works in different platform then it is possible to implement clrscr for different platforms as well. I am a little skeptical on John's and mvp's answer
The problem is that a reliable implementation of clrscr requires the library method to know what kind of device it is connected to ... so that it can do the appropriate thing to clear the screen. A library might be able to know how to do this on Windows, but it can't be done on all platforms.
The general philosophy has been that if some functionality cannot be implemented across all supported platforms, then standard Java classes won't support it.
However, this doesn't mean that you can't implement your own library to do clrscr yourself ... after having figured out how to do it on all platforms that matter to you. Or you could find a suitable 3rd-party library. You risk making your application non-portable, but that's your concern.
The other explanation is that the Java SE libraries don't provide any support for old-school terminals / terminal emulators. (The equivalent of the old "termcap" libraries.) Why? Because there is little call for it in these days of computers and phones with graphic screens. (I can't remember the last time I used a real 24x80 terminal ... but it was probably more than 25 years ago!)
I am a little skeptical on John's and mvp's answer:
It is hard to address your disbelief. Maybe the only thing that will convince you is for you to try to implement clrscr in Java yourself across a wide range of platforms and output devices ...
How would a function like Thread.sleep() and System.out.println() work then?
All operating systems (or at least all that are capable of supporting Java) provide native API's / libraries with the required functionality.
In the case of Thread.sleep, the JVM implementation typically uses the POSIX sleep(...) function.
In the case of System.out.println, out is a PrintWriter and the JVM creates a PrintWriter that is connected to the standard output device. The println call most likely results in a call to the POSIX write function.
This is NOT the case for clrscr. This functionality is not supported by the C standard libraries.
System.out.println uses the standard output stream, which can be a console or something else (say you IDE's output window for example).
The console itself can be accessed with System.console() which, as pointed out by the documentation, can return null. In that situation it is not clear what clrscr would be supposed to do.
As mentioned in the question that you referenced, C does not support clrscr as a standard feature. Since the console is being cleared, it implies the existance of a O.S. system call that allows to do this. Assuming not all O.S.'s implement this system call, it would simply not be possible to implement it in Java or in fact in any other language as a standard feature.
I had a question that may sound dumb to many, but I can't stop to post it here as found nothing there on the Internet.
Why does java doesn't have clrscr sort of function that we use in C?
If I created a java concole application that iterates over and over based on user input and then if I want to provide the user an option to clear the screen, then why its not supported in java.
I know there are some ways like this and this.
Is it something related to Java being OOP (I highly doubt but don't have a concrete answer).
OOP has nothing to do with it. It's more clrscr is more a function of the environment the Java is running in than Java itself, and so it is not in Java's scope.
Or to put it another way: since Java is cross platform and can be run without a console, the meaning of clrscr has to change depending on how the app is run and on what platform.
I believe it does not exist because of portability issues. Even in C, clrscr() is not really portable - not all platforms support it.
But Java was designed to be write/compile once, run anywhere. And this function does not quite fit into this agenda.
Is it possible to write an antivirus program in Java such as that it can intercept a program from being executed? Can I have such a deep control of the OS in Java?
update:
what about c#? same restrictions apply or that is a better way?
Having such influence on the OS is possible. There is only the problem, that you will lose the platform independency or at least have to write the code for every given platform due to the reason that such actions require quite deep access of the system which could be achived with JNI, which would tie the method you use it in to the OS.
I don't think that sort of control is possible with Java, primarily because it uses a VM and is shielded from the OS. Or rather the OS is shielded from the Java VM. This is by design.
Edited to add for clarity: I am assuming that you want to write the entire solution in Java, and not mix languages.
I am not convinced that it would work even with JNI.
In the case of "intercepting" when the OS starts a new process (or writes to a file or whatever), you need to write some kind of driver or kernel module which hooks into the OS. That driver/module is most certainly written in native compiled code. So the OS is the one in charge here, and will eventually call your native module.
So, as I see it, Java is not even involved here.
Thats the basic approach anyway. It may be possible using something like pam in Linux which is configurable to do almost anything related to security and file/process permissions and can call other processes to do its bidding. Seems far fetched though to run a JVM instance for each new process the OS tries to start.
As HalloDu said, this is technically possible with the use of JNI. However, IIRC, most antivirus programs use some sort of driver to intercept opened files and scan them before allowing the OS to continue using the file. This being the case, the amount of native code you would have to write (in C or possibly C++) would be substantial and is likely to outstrip your Java code in size.
When writing low-ish level apps, I'd stick to C. However, it might make sense to code things like the GUI in a higher level language, though Java wouldn't be my choice there either, because it's kind of a pain to interface with C. Personally, I'd do the whole damn thing in C just because mixing languages tends to be a pain. If I had to mix languages, my choices would by C and python, simply because ctypes makes interfacing with C really easy.
It is possible with the JNI. You would mostly be using Java for a GUI and C/C++ for any other sort of antivirus work though.
What is the point in making your own Antivirus? It is a lot of work, but I guess it would be cool if you made it a portable one that block and removes all the more nasty ones. If you must persist, ClamAV, it is an open source and pretty good AV (no realtime protection) but programmed in C++.
Your best bet might be to write the GUI and much of the logic in Java, then have a C or C++ back-end that does the scans.
You can then re-use the front-end across platforms and keep the platform specific stuff in the lower levels.
This way you can use the strengths of both languages--Java's platform independence and ease of use and C/C++'s ability to directly access the underlying platform.
First, I have no experience doing this. But like the beginning of any good program, I have problem that I need to fix, so I'm willing to learn.
So many of you are probably already familiar with pdftk, the handy utility for handling various pdf-related tasks. So far as I can tell, most of these features are available in much newer, lighter libraries/extensions, except the one I need (and probably the only reason it still exists): merging form data files (fdf and xfdf) with a form PDF and getting a new file as the output.
The problem is that my server doesn't have gcj, which is fundamental to build/compile pdftk. I don't know if it's because I'm on Solaris or if it's for some other sysadmin-level reason, but I'm not getting gcj anytime soon. And there are no pre-compiled binaries for Solaris as far as I can find.
So I'm thinking that the MAKE file and C code can be rewritten to import the Java library (very ancient version of itext) directly, via javac.
But I'm not sure where to really start. All I know is:
I want a binary when I'm done, so that there won't be a need for a Java VM on every use.
The current app uses GCJ.
So my first thought was "Oh this is easy, I can probably just call the classes with some other C-based method", but instead of finding a simple method for doing this, I'm finding tons of lengthy posts on the various angles that this can be approached, etc.
Then I found a page on Sun's site on how to call other languages (like C) in a Java class. But the problems with that approach are:
I'd have to write a wrapper for the wrapper
I'd probably be better off skipping that part and writing the whole thing in Java
I ain't ready for that just yet if I can just import the classes with what is already there
I'm not clear on if I can compile and get a binary at the end or if I'm trapped in Java being needed every time.
Again, I apologize for my ignorance. I just need some advice and examples of how one would replace GCJ dependent C code with something that works directly with Java.
And of course if I'm asking one of those "if we could do that, we'd be rich already" type questions, let me know.
I'm not sure what you are looking for exactly, so I provided several answers.
If you have java code that needs to run, you must:
Run it in a jvm. You can start that vm within your own custom c-code, but it is still using a jvm
Rewrite it in another language.
Compile with an ahead-of-time compiler (eg gcj)
Incidentally, you could compile a copy of gcj in your home folder and use that. I believe the magic switch is --enable-languages=java,c (see: here for more)
If you have c-code you want to call from java, you have four options:
Java Native Interface (JNI). It seems you found this
Java Native Access (JNA). This is slower than JNI, but requires less coding and no wrapper c-code. It does require a jar and a library
Create a CLI utility and use Runtime.Exec(...) to call it.
Use some sort of Inter Process Communication to have the Java code ask the c-code to perform the operation and return the result.
Additional platform dependent options
Use JACOB (win32 only: com access)
I am not sure if I understand what you are looking for.
If you are looking to incorporate the C code into Java to make a native binary without the gcj, I think you are out of luck. You can include the C in Java, but it would be a primarily Java program meaning you would need the JVM on each run. Is there anything stopping you from compiling the gcj yourself?