I'm dealing with a software vendor who says that, application needs JVM multilanguage. But I read about java locale and java 6 support almost(if not ) all country locales. So what's the difference between jvm multilanguage and, just the jre installer on Oracle site?
In the old days, you could download a US-English version of the JRE and an Internationalized version. For example: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase11-419415.html#7452-jre-1.1.8_15-oth-JPR
They discontinued the English-only JRE bundles with Java 1.5. So the vendor's requirement is moot ... unless you are using a really old JVM.
JVM Multi-language refers to support running code from other programming languages like Ruby/JRuby, Groovy, Scala, etc. Oracle JVM is one of them. Probably, the software you're dealing with need support to other programming languages for some reason.
Ask the vendor what they mean - do they mean internationalized support (i.e. multiple human languages) - or do they mean that some components of the vendor software are written in a non-Java JVM computer language (e.g. Scala, Jython, Clojure, etc), and that you will also need the runtime support components for those non-Java languages.
Related
I came through this document where the same java code compiles in Oracle JDK but not on OpenJDK. Some references for the same problems are present here too on SO.
Does it mean "javac" is vendor specific?
And if the answer is yes ? then there is a possibility that they may produce different bytecode. Refer here.
So if the bytecode is different, How will Oracle's JVM handle bytecode
generated by OpenJDK's javac?
Is it safe to say: "Java is "Write Once and Run Anywhere, provided the javac compiler and JVM are from the same vendor? "
The javac is not vendor specific, however different compilers can have different bugs and this can cause a difference.
What makes much more difference is the built in libraries available, esp classes which are not intended to be used by developers. e.g. sun.misc.Unsafe.copyMemory(5 args) didn't exist until Java 6 update 18 in Oracle JDK and is only available in the last update of OpenJDK. AFAIK, it is not available in IBM JVM.
The Write Once, Run Anywhere means compile once, run anywhere. C++ for example can be written once and run anywhere provided you re-compile it for each system.
Once you have compiled your Java code, it will run on any system which has the libraries you used.
The best answer to your question would be "it depends." Generating different bytecode is not necessarily generating bad bytecode. Bear in mind that the first document you reference is discussing OpenJDK 6 and Oracle JDK 6. Back then, OpenJDK and Oracle JDK were in fact often subtly incompatible because Oracle hadn't brought the two JDK projects together the way they did with JDK 7. Now they're almost identical code bases, but prior to 7 that wasn't the case.
Will java code compiled using OpenJDK always run on Oracle's Hotspot or vice versa?
If they are the same version, yes.
But if you compile on Java 7 and try to run on Java 6 or earlier, you will get problems (unless you use the -target switch appropriately).
There are also differences in both the Java language and Java compilers' interpretation of the JLS between different versions of Java. But these differences typically lead to compilation errors, not to different code.
In reality, OpenJDK and Oracle JDK are pretty close. In fact, for matching versions I'd expect the bytecodes produced by the respective javac compilers to be virtually identical. Compiler bug fixes made to one codebase are ported to the other as a matter of course, and code generation bugs in the bytecode compiler are pretty unusual. Other differences in generated bytecodes (i.e. not due to bugs) are unlikely to impact on the behaviour of a properly written program.
Is it safe to say: "Java is "Write Once and Run Anywhere, provided the javac compiler and JVM are from the same vendor? "
Erm ... no. There are differences in Java behaviour for different platforms; i.e. Java on Windows and Java on Linux behave differently in some respects. Some of these differences are directly attributable to the platforms themselves; e.g. pathname syntaxes and file locking are different on Windows and Linux. Others are due to issues with mapping from Java to the platforms' different native windowing system.
These differences are nothing to do with compilers or code generation.
Sitting with a jar file compiled with OracleJDK, that runs on that system. When I tried to run it on mine when I have OpenJDK installed, it refuses to run. And keeps giving me a missing class error.
I have been researching Golang and I see that it has a compiler.
But is it compiling Go into assembly level code or just converting it into BYTECODES and then calling that compilation? I mean, even in PHP we are able to convert it into BYTECODES and have faster performance.
Is Golang a REPLACEMENT for system level programming and compiling ?
This is really a compiler (in fact it embbeds 2 compilers) and it makes totally self sufficient executables. You don't need any supplementary library or any kind of runtime to execute it on your server. You just have to have it compiled for your target computer architecture.
From the documentation :
There are two official Go compiler tool chains. This document focuses
on the gc Go compiler and tools (6g, 8g etc.). For information on how
to work on gccgo, a more traditional compiler using the GCC back end,
see Setting up and using gccgo.
The Go compilers support three instruction sets. There are important
differences in the quality of the compilers for the different
architectures.
amd64 (a.k.a. x86-64); 6g,6l,6c,6a
A mature implementation. The
compiler has an effective optimizer (registerizer) and generates good
code (although gccgo can do noticeably better sometimes).
386 (a.k.a. x86 or x86-32); 8g,8l,8c,8a
Comparable to the amd64 port.
arm (a.k.a. ARM); 5g,5l,5c,5a
Supports only Linux binaries. Less widely used than
the other ports and therefore not as thoroughly tested.
Except for
things like low-level operating system interface code, the run-time
support is the same in all ports and includes a mark-and-sweep garbage
collector, efficient array and string slicing, and support for
efficient goroutines, such as stacks that grow and shrink on demand.
The compilers can target the FreeBSD, Linux, NetBSD, OpenBSD, OS X
(Darwin), and Windows operating systems. The full set of supported
combinations is listed in the discussion of environment variables
below.
On a server you'll usually target the amd64 platform.
Note that Go is well known for the speed of compilation. When deploying my server programs, I don't build for the different platforms on the development computer : I deploy the sources and I compile directly on the production servers. Since Go1 I never had a code compiling on one platform and not compiling on the other ones.
On Windows I had no problem in making an exe on my development computer and simply sending this exe to people never having installed anything Go related.
Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
Source - golang.org
Golang is a compiler-based language, it can easily be compiled on the development computer for any targeted system such as linux and mac.
A golang project when have compiled turns to a self-sufficient executable and can be ran on the targeted system without anything additional. It's because the golang compiler turns your code into bytes ready to execute on a system which can run compiled c code.
I'm evaluating components for a new embedded platform. CPU is an ARM9 and OS is Linux. Because the platform will be in use at least for 10 years I think the language should be chosen carefully as well. I'm already running Mono on possible target platform. Beside that I'm to dumb to compile Mono with my Compiler (according to Google more or less everyone else has the same problems), it's already running. I've written some benchmarks for our specific needs and I was quite impressed that Mono was never more than twice as slow compared to plain C. Memory usage is OK, and when I remove all unneeded files the footprint is acceptable. I just like to know if anyone else uses Mono on an embedded platform? Did you have any problems? Things which everyone should consider?
Given that the iPhone and Android are ARM, Mono is very well supported on ARM. And because Novell sells supported versions of Mono targeting those platforms, it is likely to stay well supported for quite some time.
One thing to note is the Mono runtime is licensed under the LGPL, so you need to ensure your usage complies with the license, or you will need to purchase a commercial license for Mono.
Is it possible to use one framework written in one Parrot (LLVM) language in any other Parrot (LLVM) language?
(Like usage of .NET Framework from any CLR language)...
Parrot and LLVM are two different things made by two different organizations.
Parrot is a VM, and LLVM is a VM that can also compile statically.
Edit
Assuming the comments to my answer are correct:
LLVM allows you to call other LLVM code and also external C like libraries.
Parrot allows you to call other Parrot code, but not external C like libraries.
http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines
LLVM
Stands for low-level virtual machine. It uses low-level opcodes that easily map to native machine code.
Languages: Fortran, C, C++
Applications: Systems Programming, Compiler Development
Parrot:
This is a high-level virtual machine. Its opcodes are much higher level then those in most virtual machines. This allows Parrot to generate efficient native code for dynamic languages.
Languages: Ruby, Perl, PHP
Applications: server-side scripting
I was currently developing a desktop application in C# using mono and testing in SuSE and Windows. The concept doesn't matter much, but it is a "web lint" program that will scan a web site and return possible issues with security and/or cross browser compatibility. However, I want to be able to offer binaries for multiple platforms. Should I stay with Mono, or is there another platform that would give me a better availablility of platforms, such as on Macs, Windows, Linux, and others (possibly mobile platforms), and make it easier to port?
Well, your best bet always is to use a language that actually exists on all the platforms. That usually means Java, I think, though even perl has flavours for mobile platforms (depending on the mobile platform in question).
I do most of my cross-platform work in C and perl, but there are some headaches with C (lots of #ifdef's), and perl may not be on a mobile platform you care about (yet). You'll have to evaluate the languages/compilers/interpreters that are common to all the platforms you want to target and then choose from that list. Without knowing the full list of such platforms, we'll have a hard time telling you what to use, though Java has enough buzz-wordness to likely be a strong candidate.
Iff you know C++, Qt will cover many platforms.
C# and Mono is probably cross-platform enough for most desktop environments. The trick will be the "mobile platform" requirement.
Mobile operating systems are wildly diverse and there's not a lot you can do to generalize. Some have Java, like the Blackberry. C# may get you onto Windows Mobile-based platforms. iPhones do their own thing. You pretty much have to pick a platform and target that. That may end up informing your desktop platform choice.
Just stick to the Mono, make sure that you have Gendarme code inspector (FxCop for Mono) checking your code for portability issues, and you should be fine.
Java will run on Windows, Linux and Macs. Should be easy to transition from C# - use Apache HTTPClient for grabbing the web content you are scanning, and the scanning code should be more or less the same. However the downside is requiring the user to have the Java runtime installed.
Python is another option - you can build stand-alone executables for Windows, and it comes with most Linux distributions by default, and also Mac OS X (citation needed ;) ). This is a lot less hassle for Windows users (language is compiled into the executable, no other downloads required).
If mono runs on Mac OS X then surely that is a good platform as well?
It really depends what you want to do. For web development, if HTML/JavaScript is enough then stick with it. If you need more advanced stuff I would use ASP.NET with Mono (what you probably did) since you already know that. (You can use Visual Studio here.)
Another option might be (since you are a C# developer) to use Silverlight. That gives you Windows and Mac platforms covered and hopefully Moonlight will cover Linxu platform later. (You can use Visual Studio and Expression Blend here.)
If you need desktop application then Java is probably the easiest since you already know C#. But if you know C/C++ try to take a look at wxWidgets for example.
Why limit yourself to the traditional C#/Java? Have a look at Adobe AIR and Microsoft SilverLight