I'd like to use of the Vista+ feature of I/O prioritization. Is there a platform independent way of setting I/O priority on an operation in Java (e.g. a library, in Java 7) or should I revert to a sleeping-filter or JNx solution? Do other platforms have a similar feature?
If you really need to use this feature and you really want to do this in Java, you can always use Java JNI to hook the JVM into your own, custom C/C++ implementation of an I/O handler. It allows you to write native (OS specific) code and call it from a Java application.
This is the kind of thing that is difficult for Java to support because it depends heavily on the capabilities of the underlying operating system. Java tries very hard to offer APIs that work the same across multiple platform. (It doesn't always succeed, but that's a different topic.)
In this case, a Java API would need to be implementable across multiple versions of Windows, multiple versions of Linux, Solaris, and various other third party platforms. Coming up with a platform independent model of IO prioritization that can be mapped to the functionality of the range of OS platforms would be hard.
For a now, I suggest that you look for a platform specific solution that goes outside of Java to make the necessary tuning adjustments; e.g. use Process et al to run an external command, or do the work in a wrapper script before starting your JVM.
From a google search it does not seem that Java supports IO Prioritization yet.
Windows Vista does but I don't know anything about it. Is it per process or more fine-grained?
Linux since 2.6.13 supports ionice(1), which will set IO priority on a per process basis.
Related
I am currently in high school. I was recently browsing the internet looking for what employees in the software industry usually want and what the job requirements are like.
I came accros a job description and one of the requirement is:
Strong, object-oriented design and coding skills (C/C++ and/or Java
preferably on a UNIX or Linux platform)
Note the last part: Java preferably on a UNIX or Linux platform.
I don't understand this. Isn't Java run inside a virtual environment/machine? Why would it matter what OS it is running on since Java cannot directly interact with the OS?
A developer job description may require experience with some OS for several reasons:
First, as you noticed already, there are languages that talk directly to the OS and the code needs to be aware of the underlying OS (like C/C++, which are listed in your job description).
Secondly, even if the programming language abstracts away anything that's OS-specific from you (including the file-system / path separators), you are still going to deploy / configure / run / monitor your applications on top of some OS and you need to know (at least) the basics in order to do that.
For a Java job description, If UNIX/Linux "is a plus", it usually means you're going to run your code on a UNIX/Linux system and you should know how to start a process (your own java app or some application server), how to deploy an application in a container, how to read log files and so on...
While Java the language runs on a virtual machine, the Java library must abstract access to facilities available on the host platform. Ideally, these abstractions are cross-platform, but the devil is in the details—hence the preference for experience on a particular target platform.
Develop once debug everywhere
While conceptually it shouldn't make any difference on what target platform the java code is executed on unfortunately in practice it isn't always that simple but a rather tedious task to get the code running on any platform.
Beginning from easy to circumvent mistakes e.g. using / or \ instead of java.io.File.separatorChar or : / ; instead of or java.io.File.pathSeparatorChar
there are most often problems including methods implemented in native code that often aren't that compatible across different platforms.
It might be even possible your employer is looking for someone to implement native java methods using JNI.
First, you're right in that Java runs inside of a virtual machine - it doesn't directly expose the inner workings of the system to you. However, that doesn't mean that each system doesn't differ in some way under the covers - different flavors of operating systems have different kernels, different ways they think about scheduling, different ways to handle threading, and different interrupt chains (Linux has quite a few signals, whereas Windows has a handful).
As far as Java (the language) is concerned, it runs the same everywhere. How it's actually accomplished is dependent on the native JVM that it's running on.
For this job posting, though, I wouldn't read too much into the UNIX/Linux portion. This is more or less gauging how comfortable someone would be working in a UNIX or Linux environment while programming Java. The majority of IDEs available for Java are cross-platform, but that shop may be using Mac or some flavor of *nix (RHEL, Debian, Ubuntu, etc). It'd also be important to make use of the command line/shell script, since a lot of the convenience of working with UNIX/Linux is on the command line.
Not every shop uses Windows machines to develop on. Just a heads-up.
Java does not differ on different platforms. That is the most highlighting feature of Java ( portability ). The JVM abstracts the underlying platform.
However, platform matters when it comes to a software development, which involves not just the coding part. Mostly in industries, devs work on Linux platform by logging into a terminal. You don't get a GUI as in Windows and a good IDE like NetBeans. So in that case, you should know how to compile and run a java program from terminal.
Example, In linux, In order to create a package, you create a directory ( folder ), say myJava/. You go into it (cd myJava) and write the SomeThing.java file and compile using javac SomeThing.java and you get a SomeThing.class file ( inside myJava ). Now in order to execute this, you need to use the java command. Prior using it, you need to move to the parent directory containing this package. Then execute as java myJava.SomeThing. You wouldn't be knowing this unless you play around in Linux platform. Other things like setting up the classpath etc are also matters of concern
Is it possible to write an application in Java that runs in the tray and when a certain application is launched, it can detect it? I want to do this for certain programs to find out how long I use them for a weekly basis. I'm new to Java, so I don't know if Java is even the best language for this, or if it has the proper access to the operating system to do this.
Java in itself does not have much integration into system-specific features (nor do most other general-purpose languages). If you're talking about windows, the system language of choice would be C# (or C/C++). On Mac, it'd be ObjectiveC (or C/C++). On linux, it'd be C.
To access process monitoring facilities on a given system, you need to first understand the APIs you're going to be using. Then you can evaluate whether a given language has built-in or third-party library support for those APIs.
In the case of Java, you'd need to either write some JNI (C code), use JNA (Java only), or parse the output of Runtime.exec() (call various system/shell commands) to access the system APIs related to managing and/or monitoring processes.
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.
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.
I am wondering how it's the interoperability between JRE6 and the JVM from rtsj. It seems that I have to use only their implementation (since the code will be interpreted using their JVM), so I cannot use many of the features that Java 6 has to offer.
Can it support a GUI? (say for example to modify the parameters of an industrial process).
I might be wrong, hoping to get some feedback from you.
Also, it seems that are more real time implementations for Java. Which one did you use and which one did you like most?
In order to provide real-time behavior, the JVM needs to be very specifically engineered. This includes integration at the operating system level to get access to real-time scheduling features of the host OS.
The Sun rea-time JVM is compatible with J2SE5, for instance. http://java.sun.com/javase/technologies/realtime/faq.jsp#4
Generally, any specialized instance of a system (OS, JVM, etc) that offers niche functionality, like security or real-time behavior, tends to be a release behind the general purpose version.
As to using a GUI for real-time, you should investigate using 2 tier client-server control of the real-time process using something like JMX, RMI or web-services (whichever is the lightest-weight). Using a GUI directly in real-time code seems like it could introduce lots of potential problems for the application as it tries to execute withing real-time constraints.
See my answer to another question for some more examples of RTSJ commercial-grade implementations. The latest version (2.1) is compliant with JDK1.5, so you should have Swing/AWT available.
While it is feasible to write a GUI to execute within the same JVM as real-time processes, it's not clear that this is a good architectural decision. It is more likely that you'd prefer to isolate the real-time behaviors in a JVM and provide a separable interface that implements to GUI in a separate memory space.
In principle, you are supposed to be able to write RTSJ code such that it runs in the same JVM with non-real-time threads (and I have done a lot of this) but it can be tough to get synchronization right.
As this book describes, there can be interoperability between the JRE of Sun Java and the rtsj implementation.