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.
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'm performing a thought-experiment which, judging by other questions, isn't so novel after all, but I think I'll proceed anyway. I want to sandbox a user-supplied server-side script by, among other things, confining it to a virtual filesystem and setting the root directory, and further mapping certain virtual directories to specific physical ones, inconsistent with the actual directory structure. For example (using PHP string parsing), my preconception is "~$user/..." but the less-semantic "/$user/..." would work fine too; either might map to "users/$user/$script_name/data/...". Yes, under certain circumstances multiple users can be affected by the script.
Since this is a thought-experiment and I therefore don't consider the implementation language an issue, I'm expecting to do it on my localhost and would rather use PHP than install something else. (I also have Python 2 available, and could get mod_wsgi to use it instead. I'd install Python 3 if I had to.) Ideally, I wish a PEAR module would do this - but from what I can see none does.
I tried and failed to find a server module, such as SSJS, that could accomplish this. The closest things to answers that I found were << Looking for a locked down script interpreter >> and << Allowing users to script inline, what inline scripting engines are there for either .net or java? >>. I'll move to Java or, less likely, Mono if I absolutely have to, but I'm not enthusiastic to the idea. (I'm extremely rusty on Java, and have hardly used it server-side at all. Mono is totally alien to me.)
Since they're the most promising options so far, I also wonder how extensive the sandboxing facilities are in Java and Mono. For example, can they do virtual filesystems? Entering APIs from Java user-code into the engine? Are any standard APIs offered to the script, and if so can they be removed?
Clarification
I don't really care which way this goes, but I was actually expecting Java/Mono to be the implementation platform rather than the sandboxed one, based on the questions & answers I linked. I'm a little surprised to see that flipped in the answers, but either way works.
The Java sandbox (in the way implemented for browser applets) does not offer file access at all.
In general, the Java security model has only "allow or not allow" decisions for the security manager in most cases.
Of course you could design another API instead of the normal File IO api (and similar), and have your sandboxed script access then this way (and forbid the normal way by a security manager). (I suppose some of this is already implemented in the Java application engines on the market, but I do know about nothing about this).
I have never tried to truly sandbox Mono but this might give you a starting point:
http://www.mono-project.com/MonoSandbox
File system access in the sandbox is touched on in that link.
Popular choices for Mono scripting seem to be Boo and Python. Both ship with the latest version of Mono (2.10). Visual Basic, Ruby and F# (OCaml-ish) do as well.
The Mono C# compiler can be easily embedded as a service for scripting. Here is a nice article about it.
If you are partial to PHP, you should check out Phalanger.
There are many other choices. There are new .NET based scripting languages all the time. I came across this one earlier today.
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?