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.
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?
Just wondering if there are any Java implementations that work without a JVM. The reason I'm interested is, well, simply because I'm curious, and I was wondering if there were any "lightweight" Java implementations (without all the Sun libs attached).
I'm also interested in embedding Java in C++, but embedding the JVM in C++ seems rather ridiculous to me. I just want to exploit some of the Java language features in my C++ apps, but not exploit all the frivolous Java APIs.
EDIT:
I see from a lot of the answers I've gotten that I need to clarify...
I recently got in to developing node.js applications, which uses JavaScript. JavaScript in istelf is a language spec, it doesn't automatically come with the DOM, window.open, etc., although it did for a while. I'm wondering if there's something similar to Google's v8, except not for JavaScript, but for Java. In the end, I don't care if I can't write Hello World apps with it, I just want to be able to embed Java in a C++ application the way I can embed JavaScript in a C++ application with v8 or SpiderMonkey. If I could do that, then I could implement console output in C/C++ and then make that implementation callable from Java.
Do you want the Java VM alone without the API(STandard Library) ?
The JRE is composed by the JVM (Virtual MAchine) and the Standard Library, I have doubt that you can find a java implementation without the JVM ... You could find a compiler that compile java source code into native code(take a look at GCJ), but not a Java implementation without the VM.
Take a look at this wikipedia page to see some alternative Java implementations .
There's GCJ (GNU Compiler for Java), but the project has been deprecated since OpenJDK was open sourced.
there are light weight java processors designed for use in small devices for example JOP
As others have hinted, the "JVM" is the mechanism that knows how to load classes, interpret "bytecodes", and manage storage. It does not inherently include any of the java.lang... stuff, except that a few classes (String, Class, et al) are needed to represent classes and other basic data structures in the JVM.
As a result, Java without a JVM is just a bunch of meaningless bits.
There are (or were) compiled versions of Java that do/did not need the interpreter (though a reasonably compact interpreter is quite easy to build). A primitive class loader and some sort of storage management are still necessary, but class loading can be kept simple and for short-lived apps (or those that live with special restrictions) the storage manager need not do garbage collection.
As pstanton suggests, there are "lightweight" Java (or "Java-like") implementations that are suited for small devices.
IMHO, You need to re-exampine what it is you really want.
Java runtime consists of two main components
The JVM to run the code
The standard libraries which come with it.
You suggest you want to use Java, but you don't really have anything left without these.
For example, you cannot even write a "hello world" program without the libraries as String is a class in the JDK.
I have just recently discovered Project Sumatra, which aims to bring the JVM to the graphics card. From their webpage this includes a custom compiler (called Rootbeer) for Java.
This is all good news, however, I would like to hear from someone with more knowledge about the project internals if this means that project Sumatra applies to other JVM languages as well? Will it be possible to make Aparapi calls from Scala or Clojure directly? Or will you have to develop some core functionality in Java and then access that via other JVM languages?
I only just came across this question. Apologies for taking so long. Full disclosure I am the Aparapi inventor/lead and co sponsor of Sumatra.
Unlike Aparapi Sumatra has the advantage of working from the IR (Intermediate Representation) of Java methods from inside the JVM. This means that ultimately it will detect opportunities for GPU offload based on patterns found at this abstract level. Aparapi had to reverse engineer opportunities from bytecode.
It is likely that Sumatra will initially key off user hints, rather than trying to auto-parallelize code. The main focus at present is the new 'lambda' feature of Java 8 and it's companion 'stream API'. So where Aparapi required the user to inherit from a Kernel base class. Sumatr a will likely use the 'explicit' hint of parallelism suggested by:-
IntRange.range(1024).parallel().forEach(gid->{out[gid]=a[gid]+b[gid];});
Although for obvious cases, such as
for (int id=0; i< 1024; i++){
out[gid]=a[gid]+b[gid];
}
It should be entirely possible to offload this loop. So support for other JVM based languages will depend on how ambitious we are looking for opportunities to auto-parallelize. I suspect that many patterns from other languages (JavaScript (Nashorn), JRuby, Scala, JPython etc) will be detectable.
AFAIK Rootbeer (a university project) and Aparapi (an AMD based project) are unrelated, so you may haved missed something here.
Regarding Aparapi itself it states in its Wiki that it won't work with Scale/Closure etc. or in fact with anything except pure Java, since it depends on patterns used by JDK's javac to properly analyse bytecode. It also requires you to extend its Kernel class to be able to convert the bytecode into OpenCL and execute it in GPU. So it looks like you would use one or another.
Back to your question: based on all this you would have to develop in Java and call it from other JVM languages.
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.
I'm wondering if it would make sense to do some low level or OS stuff (a project) using Java. Reason why I ask is because I would like to expand my knowledge in Java and I'm into doing stuff like file compressor, bulk file renamer, etc. Are there any examples out there that I can look at or play with? Or should I just be using C or C++ instead?
stuff like file compressor, bulk file
renamer, etc.
I wouldn't consider that "low level or OS stuff".
In my book, "low level or OS stuff" means things like device drivers. For that kind of thing, Java is very badly suited because it runs in a VM and simply does not have access to the OS API and the hardware (well, unless you run a Java-based OS).
For the two examples you name, Java could work quite well, but you could also easily run into limitations that are hard or impossible to overcome: Java's filesystem API dictates what you can do, and if that's not enough, the only thing left is to call native (i.e. C/C++) code via JNI or Runtime.exec().
I'm wondering if it would make sense to do some low level or OS stuff(a project) using Java.
Generally speaking, no. The low-level stuff is either taken care of by the JVM (or the operating system) or is impossible to do in pure Java.
However, if you are really interested in this kind of stuff, wander across to the JNode project and take a look at the various student projects on offer. JNode is a complete operating system that boots and runs on a "bare-metal" PC and is implemented (almost) entirely in Java.
Low level OS stuff is not very related to Java; Java uses a lot of abstractions (and hence making it higher level). You can, however, use the Java language and VM to interact with lower level API's using Java Native Access.
The problem with "low level" is: what is low level? Do you want to execute assembly instructions? And then there is Java: completely platform independent. Using more lower level API's in Java means that you lose the independency from your platform (think of: OS or hardware).
You can, however, also learn more about Java bytecodes: this is also quite low level.
If you provide more information on your project, I can give you a more specific answer.