Mac OS X is based on Darwin, which is largely a version of BSD, which is a Unix-like operating system. Linux is also a Unix-like operating system. Both are POSIX-compliant, which means that most system calls have the same API.
If you write software in C or C++, without using OS X-specific GUI or other libraries, then it should not be very hard to compile it on OS X as well as on Linux.
Ofcourse, for Java code that all hardly matters - Java bytecode runs anywhere where you have the right version of the JVM available.
As @jesper says, most will work the same. The problem is that "most" is undefined and impossible to discuss in general. The exact results vary with versions, and you have at least two sets of versions, one for OS-X and one for Linux. Plus throw in the Java Native stuff that probably has a version of its own.
From my experience as a systems programmer, Java would not be the language of first choice. Machine independence is the last thing that a systems programmer usually wants.
Joined: Aug 30, 2005
Well... Just out of curosity.....
Could you directly call systems level methods against
The jvm? Since all the jvm does is abstract
Lower level methods like open() read(), etc.....
Could you actually program directly against the jvm
Rather than using the I/o classes?
I know this would be silly... But I was just wondering.
Perhaps we have different definitions of systems programmers.
For me, a systems programmer is doing very low level work. Not using a Socket (as a Java programmer) but implementing the socket code at the OS level. Doing that can get down into the hardware level, with device drivers, etc. None of that is something you want to do in the JVM. The JVM works at a high level to the operating system. Systems programmers work in or below the operating system.
Joined: Aug 30, 2005
Yeah that makes sense... But I'm wondering wether doing operations directly against the jvm might even be possible at all.
When my job title on my business card said "Systems Programmer", that meant that I worked with operating system internal code that was not available to applications programmers. The concept of having a separate corporate department for that kind of function is pretty much non-existent outside the mainframe world, but there were reasons for the title - our code HAD to work or the entire company would shut down, and we worked with stuff that the bulk of the programmers were denied access to for security reasons. It carried a significant premium in salary for that reason.
Technically, BTW, I believe that BSD is 100% considered as "Unix". Linux is not, although for 90% of everything, the differences are mostly cosmetic. SCO's lawyers notwithstanding.
To tap into low-level OS functions from Java, you need to create JNI classes (Java Native Interface). These are classes that, instead of being implemented in bytecodes like regular Java classes are, are implemented in hardware/OS-specific binary executable code. I can consider this as systems-level programming, since the usual protection mechanisms aren't effective. You, as the native-code class developer can do anything you like, including violation of the usual Java security processes. And, if the class fails, it will take down the entire JVM.
In over a decade of work, I've not done any JNI since at least Y2K. Java these days is pretty complete, I'm not needing direct access to specialized hardware, and the JVM optimizers are sufficiently powerful that in almost all cases a good Java algorithm can more than make up for the time and expense needed to code a critical routine in machine code.
Still. there are times when you need it, so it's good that it's there.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Aug 30, 2005
Well, what I'm actually asking is, can you do "assembly" style programming at the JVM level. i.e. would byte code programming be a "JVM" equivalent of assembly language ? And if so, would it be possible to learn the basics of computing and assembly language by coding against the JVM ?
Yes, you can program the virtual instruction set of the JVM just like you can any other assembly language. That is, in fact, what JVM-interpreted languages like Jython do. There exist libraries to help in the manipulation of bytecodes although I'd have to google to see if there's a full-blown assembler. JDKs come with a disassembler.
The only major difference between this approach and coding actual hardware machine language is that the Java protection rules are built into the JVM, so it won't let you do things that violate Java's run-time restrictions.