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.
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 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.
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.
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.
The Java runtime provides a set of standard system libraries for use by programs. To what extent are these libraries similar to the system calls of an operating system, and to what extent are they different???
Half the point of java was to make it platform independent, so what it tries to do is provide an api that remains the same regardless of the OS underneath it.
If the OS is underpowered, Java will add library code to compensate for it.
If the OS has an implementation that doesn't map, Java will do it's best to map it.
If a new function becomes popular and Java users need to provide access to it, a new library can be created through which you can access the new functionality. If this library is popular, it will be restructured and added into the Java SDK at some point
For instance, an implementation of some concurrency libraries became popular, and soon they were voted upon and added to the standard libraries. This happens all the time.
That obviously depends on the OS you're running on, since the system calls are generally different for every OS :-).
That said, I believe Java was mostly inspired by Unix conventions (not surprinsingly, as Sun is a Unix vendor), so some Java system libraries are similar to Unix sytem calls.
E.g. java.nio.MappedByteBuffer was probably inspired by Unix's mmap() call. But ultimately most concepts are present on most OSes, so you cannot really say what inspired what.
Some of Java's "low-level" functions are basically "wrappers" around some OS
system calls.
I don't see an objective way (and reason) to "compare" both.
If you are interested in this topic, you can search the Java source code
for the native keyword, which indicates some "hidden"
(mostly OS-dependend) functionality.
Java's standard library often has a similar feature set compared to the native library but there are several important differences.
Java is Object Oriented, whether you like it or not. The advantage of this is that certain concepts are easier to manage. For example, most file related operations are found directly in the File object. Compare this to Posix, where a FILE is a handle which is really just a number; an index into your process's open file list. The Posix approach is very close to how the OS actually implements stuff. But in Java you don't see that or know it or care.
Java has certain lowest-common-denominator behaviours in certain cases. There are many AWT APIs that are the way they are because AWT needed to be identical on a number of separate platforms. That turned out to be madness, and Sun quasi-deprecated most of AWT, because supporting platform equally meant supporting every platform crappily. The newer library, Swing, implements almost everything in pure Java, and thus is far better at cross-platform stuff, and thus has a richer API. And that API is very different from the native windowing library. Also, Swing doesn't integrate too well because it uses so little of the native OS.
Java has certain limitations that the native libraries don't have. For example, you don't have function pointers. Thus you have Listeners and Runnable and other Java patterns for doing things that in C++ would involve function pointers. So any API that needs one of these features will be significantly different in Java than in the native OS.
So in conclusion, Java often has libraries that offer similar behaviour to the native OS, and sometimes offer completely different behaviour, but it's best to think of Java as a platform in its own right. Sometimes you need advanced performance, such as OpenGL or super-fast data transfer, in which case you'll want a specific Java API (Jogl, nio), but most of the time you should evaluate Java as its own thing.