You can compile a Java application and run it in any machine where the Java virtual machine is located, independently of the underlying hardware.
Since Ruby on Rails was built upon Ruby, I'm concerned if building software in Ruby in any environment is the same or not. There exists versions of Ruby for Windows, Linux and Mac at least.
So, could you do the same with a Ruby application and with a Java application? In other words, how cross-platform is Ruby?
EDIT: I mean Ruby by itself, not Ruby running in another virtual machine like in jRuby. Should I expect more cross-platform gotchas development in Ruby than in Java or are both almost the same?
Ruby is a scripting language and it is interpreted at the run time by the Ruby interpreter , The Ruby code is interpreted and converted to machine level language i.e Assembly code . Talking about the platform Independence you can run ruby code in any of the the platform like Linux ,Windows or Mac if you have platform dependent Ruby Interpreter installed.
Where as in Java , it is Compiled and converted to an intermediate byte class and this byte class is interpreted by platform dependent JVM (Java Virtual Machine ) .
In that way you can think you Ruby source file as byte class which can be run on any platform ,with one difference byte class is already compiled but ruby source file will be compiled at the Run time .
Ruby binds fairly closely to the underlying platform. This is especially the case when it comes to process/threading mechanisms, and various forms of IPC. These are more significant challenges to overcome, compared to "trivial" ones as directory seperator, and so forth. I'm pretty sure that there isn't parity between, say, the Windows Ruby runtime and the Linux Ruby runtime.
With Java, the IPC/process/thread model is the same on all platforms that runs the JVM.
Java is cross platform. Ruby is not. It very much feels like an afterthought of, "oh we have windows users, let's try and get it working".
In Java I have experienced less than 10 cross platform issues in years of heavy use. The areas that this was in, were obviously areas that would be tricky. System/File system specifics.
In ruby, I've experienced problems even when doing the first rails tutorial as have others (https://github.com/twbs/bootstrap-sass/issues/696) . I wouldn't consider ruby cross platform. The platform relies on a whole host of dependencies, which anytime one of them uses anything platform specific the whole thing breaks. i.e. see this error:
ExecJS::RuntimeError on Windows trying to follow rubytutorial
I also inherited a largish ruby project and it relied on capistrano, webkit, bcrypt and these needed a dev build kit and native builds. It did not just work. See the people having trouble here:
https://github.com/codahale/bcrypt-ruby/issues/116
It's funny, at one point they suggest someone follows a japanese post :)
As long as you don't touch hardware or threading, Ruby should work on the three major operating systems. For web development, Ruby will mostly work the same everywhere. For more advanced applications, no, because it does not offer the abstractions of the JVM (that you probably have in mind).
If nothing else, you could run JRuby, a Ruby interpreter written in Java.
Related
Nowadays, I've started hearing a lot about Java. I know that its because its meant to be cross platform. But is it really?
How much can we trust the client to have JVM installed? I've quite a few books on Java in my home and really wish to read them. But every time the same question strikes me. Will the apps which I develop with Java run on most of the machines? Isn't that bad?
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
So, Is it worth to learn Java for cross platform? Any ideas regarding the percentage of people having JVM installed?
I would like to correct you, People dont require jre installed they require jvm.
Since Java only relies on JVM, it is platform independent (if the platform has JVM installed).
But the main thing is, That the programmer do not have to know specific knowledge of the Platform and program his application keeping one specific platform in mind. He just has to write code generate byteCode and rest part is handled by JVM, to run it on any other platform.
If you compare java with other language you will get the exact difference like in In c/c++ the source code(c program file) after the compilation using a compiler is directly converted to native machine code(which is understandable to particular machine on which u compiling the code). And hence the compiled code of c/c++ can not run on different OS.
Nowadays, I've started hearing a lot about Java. I know that its because its meant to be cross platform. But is it really?
Yes, Java is cross-platform - or, more accurately, portable. It runs on the most used architectures and platforms, often without modification, which makes it one of the most portable languages out there. (But keep in mind that you can write unportable code in almost any language and Java is no exception.)
How much can we trust the client to have JRE installed?
We can't, but that's almost never problem.
Most languages need runtimes in order to operate. The C language (and some of its derivatives, like C++) get away with the fact that the C runtime is often already installed in the OS.
For most other languages, we trust the end user to be at least willing (not even necessarily able) to install the required runtime in order to run our (and others') software. Most software these days (and this often includes C++ software) installs its required dependencies automatically in the installation script. If this isn't desirable for any reason, an alternative is to bundle (statically link) the runtime with the program when deploying it.
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
Not all languages that compile to native code are the same. They have different features, different tools, different libraries available, and so on.
In any case, make sure you're not confusing native compilation with static linking of any dependencies (runtime or libraries).
Even, tell me how much percent people have a JRE installed.
About 97% of enterprise computers and 89% of desktops in the USA are estimated to run Java.
The client needs a JVM, not a JRE. They will run on almost all machines. I don't have a percentage but considering that pretty much every major OS has a JVM available to them, I would say around 95% (underestimation in my opinion). Java definitely does not have a limited audience so that shouldn't stop you from using Java.
Updated in light of Andreas' comment. I was under the impression that a lot of machines came pre-installed with Java. However, the JVM can be easily downloaded so you still don't have to worry too much about whether you're going to miss out on a large audience.
I think you mixed two different concepts:
Cross-platform: A program is considered to be cross-platform if it can run on different platforms without a need to recompile it.
Q: Is Java cross-platform?
A: Of course it is.
Native app: A program that runs on the targeted platform without a need to install, download any other software. Usually the program is compiled into a machine binary. However, it may in some definitions include programs/scripts that are not machine binaries, but the target it platform is guaranteed to run them with its built-in library/software.
Q: Can Java run on any platform without JVM?
A: No. JVM is not shipped with any platform that I'm aware of, so it needs to be downloaded and installed before any Java program can run.
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
It all depends on what you want to achieve. If you want to create native apps, drivers, etc, then Java is definitely the wrong tool. But if you want to create an app that can run on all platform without having to recompile it and create a version for each platform, then Java can be a good option.
So, Is it worth to learn Java for cross platform? Any ideas regarding the percentage of people having JVM installed?
Again, it really depends on what you want to achieve. Java is a good option for creating cross-platform apps and it is worth learning. However, there are other options that you may want to look into, compare, and decide which one to learn. C# is a great language, and just recently, Microsoft announced its plans to make it truly cross-platform, so it is another good option.
Most PCs have JVM installed. Theodoros Chatzigiannakis provided some statistics in his answer. But you shouldn't be too worried about the numbers. Those few who don't have JVM installed, will be willing to download and install it if they like your app.
Note: In the past, you could run apps written in C# on platforms other than Windows, but you needed a .Net Framework equivalent (e.g. Mono). With Microsoft recent announcement, we should be able to use Microsoft .Net Framework itself on other platforms. We will see how this will turn out.
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
I'm confused about Java portability. If the Java language is portable, why is enum unknown in J2ME?
In C++, it's not important which platform or library is used. The "C++ language" doesn't change in all platforms.
My purpose is developing a Java library that just uses primitive types like int, String, or Array (something like a library for Genetic algorithms). I want to use this library in mobile and desktop applications. But it seems that enum and some other keywords do not exist in all platforms.
So I think I misunderstood the meaning of "Java portability". What does that mean?
There are three flavors of Java: ME for mobile, SE for desktops, and EE for enterprise.
"Java is portable" refers to the SE version. It means that you can run Java bytecode on any hardware that has a compliant JVM.
It doesn't mean that ME is the same as SE is the same as EE. EE has EJBs, but SE and ME don't. That does not make them less portable.
C++ language doesn't change in all platforms.
This statement is not strictly correct. Microsoft adds extensions to their C++ that won't run elsewhere.
ANSI C++ might mean portable source code, as long as you stay away from platform-specific extensions. It does not mean portable bytecode; you may have to recompile and relink.
You want to run genetic algorithms on phones? I know that mobile devices have become pretty powerful, but I'm educated to think that GA would be a server-side functionality. Mobile devices feel more like view to me.
Every hardware architecture has its own somewhat unique instruction set (add ax, bx...) when you build a C++ code, the compiler turns it into a machine code specific to the system/architecture you are working on. So you have to customize and build your code for different architectures for it to work on them.
But What happens in java is, When you build it, it is compiled into a Byte code (as opposed to machine code). And the java virtual machine(JVM) interprets the Byte Code into an instruction that is understandable by the specific architecture you the program is running on.
There is JVM for every major architecture and operating system so the code you write on windows will be interpreted and run on MAC-OS or linux without any source level modification by you.
That is why Java is portable and that is where the Write Once Run Everywhere motto comes from
Java is known as a "portable language" because Java code can execute on all major platforms. What's more, once you've compiled your Java source to "byte-code" .class, those files can be used on any Java-supported platform without modification, unlike many other languages, which require compiling "machine code" for each platform, e.g. a separate ".exe" for 32-bit vs 64-bit environments.
Another meaning of "portable", used mainly in Windows environments, means that the Java run-time environment can be run from any arbitrary location in your filesystem and does not need to be "installed", that is, have important information stored in the Windows registry. This is also true for most Java applications, and enables them to be run from different drive letters, via for example an external storage device like a USB flash drive from any computer without having to install the application first.
Java provides three distinct types of portability:
Source code portability: A given Java program should produce identical results regardless of the underlying CPU, operating system, or Java compiler.
CPU architecture portability: the current Java compilers produce object code (called byte-code) for a CPU that does not yet exist. For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code. This non-existent CPU allows the same object code to run on any CPU for which a Java interpreter exists.
OS/GUI portability: Java solves this problem by providing a set of library functions (contained in Java-supplied libraries such as awt, util, and lang) that talk to an imaginary OS and imaginary GUI. Just like the JVM presents a virtual CPU, the Java libraries present a virtual OS/GUI. Every Java implementation provides libraries implementing this virtual OS/GUI. Java programs that use these libraries to provide needed OS and GUI functionality port fairly easily.
See this link
While C and C++ language syntax and semantic are standardised, to write a truly cross-platform application is extremely difficult, unless you limit yourself to extremely basic applications.
There are a number of high level and low level reason for this - from the endianness up to how to interact with the underlying operating system (eg. opening a window).
In addition, C/C++ source code only can be considered portable, not the result of the compilation - resulting executable code and libraries are not portable, with major difference between system architectures (different CPUs for example) and Operating Systems.
Java is a fairly successful attempt to solve both of these issues:
Java does not compile code to assembly, but to a more abstract "bytecode" - a pseudo-assembly language which is "interpreted" or "recompiled on the fly" by the virtual machine (JVM) into assembly. This conversion is usually fairly efficient as bytecode is mostly quite a low level language. Some version of the ARM processor can even execute bytecode natively.
Thus, once a java app is compiled, the result can run on "any" architecture (provided a JVM is available for that machine)
Java comes bundled with a really large runtime library which provides not only an extensive implementation of the most common data structure (implemented in the JVM in the most efficent way for a particular architecture) but also provide an "hardware and software abstraction layer" - you can interact with the system in a standard way while coding, it is the JVM job to translate it into appropriate architecture and OS calls. As an example, Java provides the Swing framework, which allows you to create a GUI in a system independent way - ie, you open a window, and this is translated into Win32/MFC calls in Windows and XWin calls in Linux
Said that, there are different "types" of java:
JavaSE is the most common
JavaME is a cut down version with a limited library and not implementing the Java5.0 language changes
JavaEE for enterprise use, same as JavaSE but with a much larger runtime
Android Java, mostly compatible with JavaSE but with additional functionalities specific to android phones
However, you should be aware that the Java architecture has been designed to allow interoperability, in particularly to allow to mix libraries built for different versions or even different "types"
it means that your java program written on one machine will run on any other machine provided that machine has JVM.
refer to this link.
Portability refers to the ability to run a program on different machines. Running a given program on different machines can require different amounts of work (for example, no work whatsoever, recompiling, or making small changes to the source code). When people refer to Java applications and applets as portable, they usually mean the applications and applets run on different types of machines with no changes (such as recompilation or tweaks to the source code).
I have been developing ActionScript apps for half a year or so. As far as I can see, mxmlc compiler is just a sh-script to call javac --{options} in more convenient way. This gives me an idea that my source code is compiled into native java byte-code.
From all above I can conclude that either Flash Player should require JVM installed or be a JVM itself. Or maybe Java is used to generate Adobe custom binary file just as any other compiler would do, but Java is cross-platform and an industry standard, so to avoid portability problems Adobe (Macromedia) could choose in for ActionScript/Flex.
Can you explain to me this?
The development environment for ActionScript is written in Java, but compiling ActionScript does not result in a Java-compatible binary. Instead, it compiles to a binary which runs on the ActionScript Virtual Machine. So Flash Player has a virtual machine, but it is not Java-related.
Alright everyone,
Let's say i wanted to make a system that used only assembly and java, my question would be, as long as i included all of the jvm folders, classes, jars, etc.. java should still function effectively?
i understand there are those things that are compiled platform specifically but this is why i am asking, is it possible, using assembly to replicate all of the .exe, or other executable files that java has included into a pure assembly/java system?
If you are asking whether it is possible to build a system in Java and assembly language that runs on "bare metal", the answer is yes. There are a couple of current examples:
JavaOS is targeted primarily at the embedded systems domain. (Sun consider SunOS to be a "legacy" product line these days.)
JNode aims are broader, and encompass embedded systems, desktop systems, servers and cloud computing.
Be aware that building a system of this kind is a multi-year, multi-person project requiring deep understanding of virtual machine internals, compilers, garbage collectors, hardware architectures, device driver writing and so on.
If you are asking about something else, please be more explicit.
EDIT: responding to the OP's followup question:
It is not practical to use the Java and other "exe" files per se. They require a fully fledged operating system underneath them; e.g. Windows, Linux, whatever. If you had access to the source code, you could conceivably rewrite as required to make them run on "bare metal", but that would entail significant architectural changes, especially if you want to write device drivers, etc in Java. (Besides, the core of Sun's JRE is implemented in C++ ... ).
You cannot directly use the existing Java class library JAR files, because they include a significant amount of platform specific code. However, you can build your own Java class library JARs from an existing open-source version of the Java class libraries (e.g. the OpenJDK 6.0 J2SE libraries). You deal with the platform specific code by providing your own versions as native libraries or (as JNode does) as Java classes.
If I understand your question correctly, you mean something like JavaOS. Sure, its possible to implement the JVM raw on the hardware, not sure why you would, though. And if you did, why you wouldn't use C instead of Assembly for most of the work.
Its theoretically possible to implement the jvm in a whole other language. The best example I can think of is Python/Jpython where there is the original C implementation and a pure Java implementation of the language.
The main argumant against this is -- its a ton of work for not much benefit.
The official Sun jvm and supporting jni libraries are written mostly in C, you would need to provide native assembler implementations for most of the C POSIX APIs at the very least.
Also the original design goal of C was 'a portable assembly language' and to a large extent it still meets these goals. C produces efficient machine code and most C compilers will let code machine instructions inline with the C code.
Another benefit of C is the number of cross compilers available, you dont need to run the development environment on tHe target architecture, you can deveop and unit test on your favourite paltform/IDE, when you are ready you can then export your executables to the target platform.
Jikes RVM and Sun's Maxine provide a JVM implementation with little (of the order of 1 kloc) native code. However, both VMs require an OS and are only research implementations. The process of creating a stream of octets that form machine code, is obviously achievable in Java.
Have a look at JNode. They have been working on this for years.
http://www.jnode.org/