I am fairly new to Java or programming in general. On my journeys through the internet to master this language I have come up the saying "write once run anywhere" multiple times.
But I have found many software that requires you to pick the right version for your OS. Sometimes there is only one version available.
Could you explain to me why that is so?
[expanded per the comments]
Java runs on a Virtual Machine, the JVM. In an ideal world this means that the Operating System is abstracted away behind this and you only have to make sure your code works with the JVM which will make it work with the underlying OS. This can already be undone by using the wrong path separators or line endings; it is not an absolute truth.
An application can use many Operating System-specific approaches/libraries/functions/etc that might make it not feasible to restrict yourself to one general codebase. Instead they might want to leverage some advantages provided by a platform and create a separate application with it.
The statement should probably be somewhere along the lines of "Write once in a general fashion, run anywhere" but that's not as snappy.
This statement is often linked to Java but there are also other languages that incorporate this: weblanguages like Javascript and HTML will run on any browser because the browser itself forms the abstraction between the language and the underlying OS.
Other languages don't have this (entirely?) since they work differently: C# will use the underlying .NET framework which as it is only exists for Windows. There exists a cross platform variant (Mono) but it would be an overstatement to consider C# truly cross platform.
The Java program or source code is compiled to generate "bytecodes" ( an intermediate binary format). Second, the bytecodes is executed by an interpreter which is part of the Java Virtual Machine (JVM).
"Write Once, Run Everywhere" refers to the fact that an application written is Java can be run on any hardware which has the Java Virtual Machine (JVM), and that the JVM is now licensed to hundreds of operating systems vendors systems including Microsoft for Windows.
Well, some stuff is really cross-platform (most of standard Java library), while some other stuff may need right version for the OS. Generally, this applies to software that uses dynamic libraries, that aren't written in Java. In this case, versions for different OSes are packed with libraries for this OS.
In case there's version only for one OS - it could be because required libraries don't exists for other OSes or developer didn't port it. There is still possibility that it's actually cross-platform, but developer tested it only under one OS.
Your question is more based on platform dependency/independency.
Java is a programming language which is platform independent which means the code which you write will produce the same output on all machines running Windows, Linus, Unix, etc... without any changes to the code. To run a Java program you need to have JVM (Java Virtual Machine) installed. Now what does JVM do.? Well, it translates your code into Machine code which the Operating System could understand. Therefore JVM is platform dependent since every OS has a different Machine code.
So, basically you write a Java Program only once and can be used/run everywhere.
you can write source code in one platform and run it any where.some times you can encounter problem if a new java version is available but still current version runs the code.
I was wondering if anyone have gotten Java up and running on a BeagleBoard or Cubox? I'm thinking about buying one for a project I'm working on on my spare time, but as parts of this project is written in Java I first wanted to know if these tiny computers can run a JVM at all?
From what I read on http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html there are editions for ARM, and Solid-Run (the manufacturer behind Cubox) have also written some info on their wiki: http://www.solid-run.com/mw/index.php/Oracle_Java_on_CuBox.
However, what I would need to know is:
Can I consider ARM JVM == x86/x64 JVM in terms of functionality (a.k.a. "will my code run without changes") (my code is pretty non-graphical, mainly a HTTP API)?
Are there any license "problems" with JVM on ARM (compared to JVM on x86/x64)? That is, if I suddenly want to mass-produce my little spare-time hobby project and sell Cuboxes, will Oracle sue me?
Anyone have any experience with Hibernate/HSQLDB on ARM?
Perhaps too many questions in one, but I think they're all related enough to be put in the same thread. In general, I want to know more about JVM on ARM and how developed and mature it is.
Thanks!
Answers to 1 and 2 are on the Oracle page. "development is free, but royalties are required upon deployment on anything other than general purpose systems. In all cases, these products are fully Java SE compliant"
As for 3, I don't know about Hibernate (which shouldn't be a problem), but HSQLDB has been used on ARM by Symbian and others at least since 5 years ago.
I am thinking about buying an Apple Powerbook 1.5 GHz machine. While my primary focus for that machine would be internet, I may also do some programming on that machine since it would be the machine I would be taking to college...
What I wanted to know if there would be any major difference in context with the compilers used etc? Would I have to setup a completely different environment for the Power PC?
To be fairly clear, my primary categories of work include:
* Python {i know mac supports this right out of the box}
* PHP/MySQL
* HTML/CSS
* Javascript
* Java - I will be starting to learn Java, do this is pretty significant.
I am a complete n00b as far as Mac OS is concerned. Any and every help is appreciated.
PS: If this falls in the wrong category, I apologise.
Keep in mind that, with the latest recent release of OS X, 10.6 or Snow Leopard, Apple has pulled the plug on Power PC Macs: 10.6 does not run on any PPC Mac. Based on its past support policies, you can expect that Apple will continue to provide security updates and, possibly some bug fixes and minor features, for 10.5 (Leopard) until the next release of OS X (as yet, unannounced). But you can also expect that more and more things will be released by Apple or third-parties that are Intel-only, like the things already mentioned. Of the list you mentioned, it would seem that the only immediate concern is Java 1.6; Python and the rest will be no problem for a long-time to come.
By the way, you might want to check out MacPorts and Fink, two independent projects that tailor and package for OS X hundreds of popular open source packages. If it isn't already shipped with OS X or you need a newer version, you may find something you need there.
The Powerbook can't do Java 1.6. That might be a problem for you. You also can't do iPhone development on it. Other than that, once it's maxed out on RAM it's a pretty decent development environment.
I own a MacBook (intel core 2 duo processor) myself and would strongly discourage you to get an older model than that if you want to get reasonably up-to-date java support. (Java 1.6 does not work on older models as far as I know) I really like my macbook and it is a great development machine for me, but I have strong doubts on the java support (See for example http://stuffthathappens.com/blog/2007/10/28/os-x-java-definitive-timeline/).
I have an 12" 1.5 Ghz, 1.25GB ram G4 Powerbook and I wouldn't recommend it for java development due to the fact that running an IDE (Eclipse or NetBeans) will be painfully slow. Also expect to buy a new battery for an old laptop.
If 10.5 is not enough for you, you may want to consider installing Linux since the StuffIt you mention is easy to install with e.g. Ubuntu.
I have a request for a contracting gig and one of the requirements in the first draft of the specs says the software (a GUI application for end-users) should run on Win 2000 and Mac OS 7.5. I have no idea why they would want to support such ancient systems, but I guess it leaves me with Java as the only option other than raw C, or doesn't it?
So if it would be Java, are there restrictions on what Java version I can use on those targets?
Also, though it wouldn't be strictly on topic, I'd appreciate comments on strategies for making software run on both targets. Actually, supporing those ancient systems as well as modern ones might even be harder than supporting Mac and Win, right?
As another sideline, I'd also appreciate facts that could be used to talk the client out of this and make him go with OS X and XP. Like "hey, only 2% of all Macs in use today still use OS older than X".
Edit: My main purpose here is to be well prepared technically to negotiate what the specs really should be.
Things like that are often the result of some manager thinking "gee, my aunt still uses OS 9 and I bet, there's people even more old-fashioned, so let's just play it safe and write down 7.5". There's no technical judgement whatsoever involved, and that's OK. It's just that, in those cases, you have to explain carefully what tradeoffs there are and if you succeed, it usually gets you much more realistic specs. It's not even unlikely that they'd ditch Mac OS altogether if they have to bet money on it.
With that kind of specs, if you don't actively help the client reshape them, what's going to happen is, you put the number in the offer that would pay for all the crazy stuff and then yet some, and less experienced competitors won't see all the implications and put a lower number in their offer, get the gig and it all ends in tears for everybody. You can go "heh heh, told you so", but don't get the cash, either.
Edit: Thanks for still posting facts and advice although I already accepted an answer to my original question. I'll keep upvoting that stuff, and it certainly helps. Also thanks for empathizing with me and trying to save me from signing a bad contract! But don't worry, I'm not actually going to code for Mac OS 7.5 ... ;-) Really, really overseeing all the implications would be well out of my depth anyway.
Unless this is a seriously lucrative contract, or you desperately need the money, I'd recommend running away from it as fast as possible. The chances are the client is not only targeting seriously old OS's, but also old hardware. That'll mean you'll have all sorts of problems with performance (for you can bet the entire value of the contract that they want an app with modern features and performance on this ancient kit). It's near guaranteed to end in tears...
The Java Runtime for MacOS 7.x was called Mac OS Runtime for Java (MRJ) and supported at least Java 1.1.8. If my memory servers me right, the Swing implementation was pretty bad - so you would need to use AWT.
At least on the ancient MacOS systems, you will have stability & performance problems. Don't take this contract, this is guaranteed to end in a fiasco.
Unless this is a seriously lucrative contract I would stay away from this one.
I've worked on contracts like this in the past and they are almost always more trouble than they're worth. Whilst I appreciate you are just trying to be prepared, you really need to find out more about why they want to do this - its pretty unusual.
OTOH. If the contract is a big one and they are only talking a couple machines - it might be worth your while to offer to buy and install machines for them!
Coding for an older VM such as 1.1 will force you to code to a lower common denominator and will add considerably to development and testing time - you need to take this into account. The machine will almost certainly be underpowered in terms of memory and cpu.
Win2k will support at least Java 1.4 and possibly 1.5.
It's up to 1.1.8 for all Mac OS Classic (not X)
One useful stat is that about 85-90% of all Macs run OS X 10.4 or 10.5. Most of the other 10% are running older versions of OS X.
I'm not definite on this, but I believe Mac OS 7.5 will only run versions 1 and 1.1 of Java.
Introduction
I heard something about writing device drivers in Java (heard as in "with my ears", not from the internet) and was wondering... I always thought device drivers operated on an operating system level and thus must be written in the same language as the OS (thus mostly C I suppose)
Questions
Am I generally wrong with this
assumption? (it seems so)
How can a driver in an "alien"
language be used in the OS?
What are the requirements (from a
programming language point of view)
for a device driver anyway?
Thanks for reading
There are a couple of ways this can be done.
First, code running at "OS level" does not need to be written in the same language as the OS. It merely has to be able to be linked together with OS code. Virtually all languages can interoperate with C, which is really all that's needed.
So language-wise, there is technically no problem. Java functions can call C functions, and C functions can call Java functions. And if the OS isn't written in C (let's say, for the sake of argument that it's written in C++), then the OS C++ code can call into some intermediate C code, which forwards to your Java, and vice versa. C is pretty much a lingua franca of programming.
Once a program has been compiled (to native code), its source language is no longer relevant. Assembler looks much the same regardless of which language the source code was written in before compilation. As long as you use the same calling convention as the OS, it's no problem.
A bigger problem is runtime support. Not a lot of software services are available in the OS. There usually is no Java virtual machine, for example. (There is no reason why there technically couldn't be, but usually, but usually, it's safe to assume that it's not present).
Unfortunately, in its "default" representation, as Java bytecode, a Java program requires a lot of infrastructure. It needs the Java VM to interpret and JIT the bytecode, and it needs the class library and so on.
But there are two ways around this:
Support Java in the kernel. This would be an unusual step, but it could be done.
Or compile your Java source code to a native format. A Java program doesn't have to be compiled to Java bytecode. You could compile it to x86 assembler. The same goes for whatever class libraries you use. Those too could be compiled all the way to assembler. Of course, parts of the Java class library requires certain OS features that won't be available, but then use of those classes could be avoided.
So yes, it can be done. But it's not straightforward, and it's unclear what you'd gain.
Of course another problem may be that Java won't let you access arbitrary memory locations, which would make a lot of hardware communication pretty tricky. But that could be worked around too, perhaps by calling into very simple C functions which simply return the relevant memory areas as arrays for Java to work on.
Writing Solaris Device Drivers in Java covers a A RAM disk device written in Java.
Another one for Linux. Goes more in depth on why you might want a DD in Java as well (since some people were wondering by the looks of the other posts and comments)
A device driver could be a lot of things
I actually write device drivers in java for a living: drivers for industrial devices, such as scales or weighing devices, packaging machines, barcode scanners, weighing bridges, bag and box printers, ... Java is a really good choice here.
Industrial devices are very different from your home/office devices (e.g. scanners, printers). Especially in manufacturing (e.g. food), companies opt more and more for a centralized server which runs an MES application (e.g. developed in Java) The MES server needs to interface with the devices of the production line, but also contains business logic. Java is a language that can do both.
Where your home/office devices are often built-in to your computer or connected with an USB cable, these industrial devices usually use Ethernet or RS232 connectors. So, in essence, pretty much every language could do the job.
There is not much standardisation in this area yet. Most vendors prefer to create their own protocol for their devices. After all they are hardware builders, not software geniuses. The result is that there is a high diversity of protocols. Some vendors prefer simple plain-text protocols, but others prefer complex binary protocols with CRC codes, framing, ... Sometimes they like to stack multiple protocols (e.g. a vendor specific handshaking algorithm on top of an OPC layer). A strong OOP language has a lot of advantages here.
E.g. I've seen java print at a continuous speed of 100ms/cycle. This includes generating a unique label, sending it to the printer, receiving a confirmation, printing it on paper and applying it to the product using air pressure.
In summary, the power of java:
It is useful for both business logic as complex interfacing.
It is just as reliable in communication with sockets as C.
Some drivers can benifit from Java's OOP power.
Java is fast enough.
It's not impossible, but possibly hard and possibly makes not much sense.
Possible is it, because Java is a normal programming language, as long as you have some way to access the data, it's no problem. Normally in a modern OS the kernel has a layer to allow raw access to hardware in some way. Also already exist drivers in userspace, at least the userspace-part should be no problem to implement in Java.
It makes possibly not too much sense, because the kernel has to start a JVM to execute the driver. Also JVM-implementations normally eat up much memory.
You could also use Java-code compiled to be executed natively on the platform (not with the help of a JVM). This is usually not that efficient, but it could be suitable for a device-driver.
The question is, does it make sense to implement the driver in Java? Or stated in another way: What is the benefit you hope for, if you use Java for implementing the driver instead of another alternative? If you can answer this question, you should find a way to make it possible.
At the end the hint to JNode, a project that tries to implement a complete OS purely based on Java.
You have a too narrow view of device drivers.
I have written such device drivers on top of MOST in an automotive application. A more widespread use might be drivers for USB devices if Java ever gets a decent USB library.
In these cases there is a generic low-level protocol which is handled in native code, and the Java driver handles the device specifics (data formats, state machines, ...).
For the motivation, please remember that there is plenty of fast languages which are better than C for programming; they might not be as fast as C, but they are safe languages: if you make a mistake you don't get undefined behavior. And "undefined behavior" includes executing arbitrary code supplied by some attacker which formats your HD.
Many functional languages are usually compiled to native code.
Device drivers contain the most bugs in an OS kernel - I know that for Linux (Linus Torvalds and others keep saying so) and I heard that for Windows. While for a disk or Ethernet driver you need top-notch performance, and while in Linux drivers today are the bottleneck for 10G Ethernet or SSD disks, most drivers don't need that much speed - all computers wait at the same speed.
That's why there are various projects to allow writing drivers which run outside of the kernel, even if that causes a slowdown; when you can do that, you can use whatever language you want; you will just then need Java bindings for the hardware control library you use - if you were writing the driver in C, you would still have a library with C bindings.
For drivers in kernel mode proper, there are two problems that I've not yet seen mentioned:
Garbage Collection, and that's a tough requirement. You need to write an in-kernel Garbage Collector; some GC algorithms rely on Virtual Memory, and you cannot use them. Moreover, you probably need to scan the whole OS memory to find roots for the GC. Finally, I would only trust an algorithm guaranteeing (soft) real-time GC, which would make the overhead even bigger.
Reading the paper which was mentioned about Java Device Drivers on top of Linux, they just give up, and require programmers to manually free memory. They try to argue that this will not compromise safety, but I don't think their argument is convincing - it's not even clear whether they understand that Garbage Collection is needed for a safe language.
Reflection and class loading. A full Java implementation, even when running native code, needs to be able to load new code. This is a library you can avoid, but if you have an interpreter or JIT compiler in kernel (and there's no real reason that makes it technically impossible).
Performance. The paper about a JVM on Linux is very bad, and their performance numbers are not convincing - indeed, they test a USB 1.1 network driver, and then show that performance is not so bad! However, given enough effort something better can surely be done.
Two last things:
I'd like to mention Singularity, which is a complete OS written in a C# variant, with just a Hardware Abstraction Layer in a native language.
About picoJava, it's a bad idea to use it unless your system is a really memory constrained one, like a smart card. Cliff Click already explained why: it gives better performance to write a good JIT, and nowadays even smartphones can support that.
Have you perhaps heard a reference to the JDDK?
Writing a device driver 100% in Java is not possible without native code to provide the interaction between (1) the OS-specific driver entry points and conventions, and (2) the JVM instance. The JVM instance could be started "in-process" (and "in-process" may have different meanings depending on the OS and on whether the driver is a kernel-mode or user-mode driver), or as a separate user-land process with which a thin, native driver adaptation layer can communicate and onto which the said driver adaptation layer can offload actual user-land work.
It is possible to compile java code to hardware native (i.e. not JVM bytecode) instructions. See for instance GCJ. With this in hand, you're a lot closer to being able to compile device drivers than you were before.
I don't know how practical it is, though.
Possible?
Yes but only in special circumstances. Because you can write an operating system in Java and C#, and then, should be able to write device drivers for it. The memory hit to these drivers and operating systems would be substantial.
Probable?
Not likely. Atleast not in the world of Windows or MacOS or even Linux... At least not anytime soon. Because languages like C# and Java depend on the CLR and JVM. The way these languages work means that they cannot effectively be loaded into ring0.
Also, the performance hit would be rather large if managed languages were employed in device drivers.
Device drivers have to be written in a language which can execute in the kernel, either compiled into it, or loaded as a module at runtime. This usually precludes writing device drivers in Java, but I suppose you theoretically could implement a JVM inside a device driver and let it execute Java code. Not that any sane person would want to do that.
On Linux there are several user-land (i.e. non-kernel) implementations of filesystems which uses a common abstraction layer called (fuse) which allows user-land programs to implement things which are typically done in the kernel.
The Windows Driver Foundation (WDF) is a Microsoft API that does allow both User and Kernel mode device drivers to be written. This is being done today, and it is now compatible with w2k and later (used to not have w2k as a supported target). There is no reason that JNI calls can't be made to do some work in the JRE . . . ( assuming that JNI is still the way to call Java from C/C++ . . . my knowledge is dated in that arena). This could be an interesting way to have high level algorithms directly munch on data from a USB pipe for something to that effect . . . cool stuff!
PCIe user space device drivers can be written in Pure Java. See JVerbs for details about memory-based direct hardware access, in the context of OFED. This is a technique that can be used to create very high performance systems.
You can examine the PCI bus to determine the memory regions for a given device, what ports it has, etc. The memory regions can be mapped into the JVM's process.
Of course, you're responsible for implementing everything yourself.
I didn't say easy. I said possible. ;)
See also Device Drivers in User Space, which discusses using the UIO framework to build a user space driver.
First of all, note that I'm not an expert on device drivers (though I wrote a few myself back in the day), much less an expert on Java.
Let's leave the fact that writing device drivers in a high-level language is not a good idea (for performance and possibly many other reasons) aside for a moment, and answer your question.
You can write device drivers in almost any language, at least in theory.
However, most device drivers need to do plenty of low-level stuff like handling interrupts and communicating with the OS using the OS APIs and system calls, which I believe you can't do in Java.
But, if your device communicates using, say, a serial port or USB, and if the OS doesn't necessarily need to be aware of the device (only your application will access the device*), then you can write the driver in any language that provides the necessary means to access the device.
So for example you probably can't write a SCSI card driver in Java, but you can write a driver for a proprietary control device, USB lava lamp, license dongle, etc.
* The obvious question here is, of course, does that count as a driver?