Develop Reference

Languages that compile to Java Bytecode and can run on the JVM

I am an embedded programmer and working with an embedded JVM.
This enables running Java files on constrained devices.
These Java files are first compiled to bytecode into .class files which are then further optimized and uploaded to the device which has a micro JVM to run the optimized bytecode.
The micro JVM does not support all features, e.g., no reflection.
The main benefit is obvious: this allows programming in Java for constrained devices.
However, I was thinking that plenty of languages compile to bytecode, some are listed https://en.wikipedia.org/wiki/Java_bytecode.
So in theory these languages could also be used to program.
I'd like to obtain a list of common languages that compile down to bytecode and was wondering if you could help.
For example, Python has special implementations that reduce to Java Bytecode, if I'm not mistaken, and stuff like C to Java virtual machine compilers also exist.
So what languages would you think are logical to try and run on the devices? Any pointers on how to or similar experiences?
Also, I'm not clear what the difference is from reading Wikipedia between (Python) bytecode and Java bytecode, could anybody help explain that?

I'm agree with you about the overall idea and it would be nice to develop an embedded application using any language that can run on a JVM. But there are some practical issues that you should consider and I think that's why none of major vendors or open source initiatives have any active/serious project on this (as far as I know).
As you mentioned, a JVM implementations that can run on embedded devices, each have their own constraints and limitations. The most obvious one is that some packages may not be available at runtime. In order to apply such a constraint, you should either control it in the compile process or have a toolchain (sort of an SDK) which accepts the bytecode and checks such constraints.
This situation would be worth when a developer tries to use a third party library that is available for that specific language. It's not easy to guess if a library is safe for use against such a framework or not.
One great facility for developers would be to have their IDE check such issues on the fly (something like inspection in IntelliJ Idea). This makes it much more smoother to move toward using such a solution. But again the problem is that for each such languages there need to be a specific plugin compatible with their own syntax.
Also some of JVM languages that are actually implementation of an existing language (e.g. Jython or JRuby) are most of the time out of sync with the original language in case of supporting libraries/syntax changes of that language.
Anyway, I think in order to have a list of JVM languages you could easily find them on Wikipedia. Maybe you mean those who may worth considering in this regard by having a large community and tools support. In my opinion, you should focus on the following JVM languages as those who may worth to include in your final list:
Groovy
Kotlin
Scala
These are all pure JVM languages and are only using different syntax than Java.
Regarding the topic in general, I should say that when you search for embedded JVM implementations, you'll notice that it's also a fairly academic concepts and they're so many publications in this topics regarding the overall architecture, threading support, toolchain, error handling, memory management, etc. This means that you should have a very great experiences/background on both embedded systems and programming language concepts and implementation to be able to devise a proper architecture for such a platform.
About your last question regarding the difference between Python bytecode and Java bytecode (if I understand your question correctly), these are both conceptually the same but each has its own syntax and constraints. The bytecode concept refers to the piece of software that is the output of the compiler and is the platform independent representation of the original code and can be run/interpreted at runtime by another software component which is the virtual machine. In Java world, this software is called the Java Virtual Machine (JVM). I'm from the Java world so I don't know what it's called in Python vocabulary but it should be something similar (e.g. Python virtual machine).
I think due to the complexity of developing such a toolchain and also considering the unprecedented development of new IoT and SoC devices, many of them capable of running a more higher level operating systems, maybe in a long run most developers prefer to develop for a more high end devices using more high level APIs and SDKs. Who knows! In that case, we would have a same situation that we're in today for PCs. Languages like C and Assembly are still in use, but they have their own domain of applications. I mean throughout the time, layers of abstraction are being added on top of the previous one. The same thing can happen for embedded devices.

How does Java differ on different platforms?

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

What is the meaning of "Java is portable"?

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).

building a system in Java and assembly language that runs on "bare metal"

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/

Is .NET a write once, run anywhere (WORA) platform like Java claims to be?

I remember Sun's slogan so vividly... "Write Once, Run Anywhere". The idea being that since programs are compiled into standard byte codes, any device with a Java Virtual Machine could run it. Over the years, Java seems to have made it onto many platforms/devices.
Is this the intention or was it ever the intention of .NET. If so, what kind of efforts are being put forth to make this a reality?

To correct some comments by others here, .Net was ALWAYS intended to be multi-platform. That is why Microsoft separated the namespaces into "System.*" (which were platform-neutral) and "Microsoft.*" (which were Windows specific).

There is Mono which runs on Linux, Solaris and OS X. In practice .Net is still pretty much a Windows-only platform. It's not really in Microsoft's interests to push it to be WORA, on the contrary. Appearing to be cross-platform however is. A lot of people have been really paranoid about Mono on Linux. MS's supposed strategy is to first let it grow to be an important part of the Linux application platform and then release the lawyers. I wouldn't bet my future on .Net's portability.

The answer is a very shaky Yes. The moment you include an external library, the answer changes to No.
For example, Microsoft has no 64-bit JET driver. JET is used by .NET to access MS Access databases.
Any applications compiled for the Any CPU target that use MS Access databases will fail on a 64-bit version of Windows.
(This is ignoring that said applications are not portable to Mono.)

Microsoft has never made those claims but they ARE making moves in the WORA arena. Silverlight 2.0 for example will use a subset of the .NET framework and be available on Windows, Linux (through the Moonlight project), MacOS, Windows Mobile, and Nokia handsets.
As others have mentioned, the Mono project has also brought the framework to multiple environments.

To put this in context, in many people's view Java never delivered on its "Write Once Run Anywhere" promise either.
At best what you got was "Write Once Debug Everywhere" or "Write Once Looks like crap Everywhere"
The successful CLR based applications have all been written using a graphical framework that is native to the target platform.
For example the following highly successful linux applications where written using c# bindings to GTK called GTK# and not using winforms like you would expect:
Banshee - music player like itunes
fspot - photo manager
TomBoy - notes program
GnomeDo - Quick launcher and dock
Equally successful windows .net applications are not written using GTK# (even though it is cross platform) they are written using winforms or WPF.
When google came to make Chrome they didn't try to use a cross platform GUI framework, instead they choose to use native GUI frameworks on each platform. Why? because that way the application, fits properly into it's environment, that way it looks, feels and acts like its native to the operating system its on.
Basically when you try to have write once run anywhere you have to make serious compromises and what you end up with is something that doesn't really work right anywhere.
The industry has largely given up on the lofty goal of write once run anywhere, as a nice idea which didn't work out in practice.
The best approach with mono/.net is to share your lower level binaries and to use a native gui framework on each target platform. GTK# on linux, winforms or WPF on windows, CocoaSharp on Mac. This way your application will look and feel like a native app.

With Mono we're getting pretty close, and with SilverLight we're allready there.

I don't think the official "intention" of .NET was WORA. I think that you could safely say that .NET was designed so that it would always run on future MS OS's. But there is nothing that precludes .NET from running on other platforms. Mono is an example of an implementation of the .NET runtime for an OS other than Windows.

Yes, this was a goal of .NET although I don't think it had the same emphasis as it did in Java. Currently, the only effor that I know of is the Mono project that is creating a version of the CLI which runs on Linux.
Interestingly enough, Silverlight actually has a slimmed down version of the CLR which can run on both Windows and Mac, which allows the same Silverlight app to run on both platforms unchanged.

It's theoretically possible, since the CLR (.Net's "virtual machine") complies with an open standard (the CLI). The question is what other implementations there are of that standard. Mono is another work in progress, but it's the only other one I know of.

I think that the idea with .NET is that it is a "Write Once, Run Anywhere (that Microsoft chooses)". However, the Mono project is slowly changing the situation.

It will never be supported on as many platforms as Java, IMHO.
The only effort is Mono, not sponsored by Microsoft.
Check here on SO and on the official site

In theory, yes. .Net Assemblies are bytecodes, which are converted to native code upon startup, using a JIT ("just-in-Time") compiler.
In practice, there aren't many platforms beyond Windows which have a .Net JIT compiler. There's one for Linux, called MONO.
Don't know about Mac, Sun etc...

Theoretically, the language is designed to be compiled into bytecode like Java which is interpreted by the Common Language Runtime, a mechanism that also allows several languages (not just C#) to work together and run on the .NET framework.
However, Microsoft has only developed the CLR for Windows. There are other non-MS alternatives being developed, the most prominent being Mono, a CLR implementation or a number of platforms (see the link).
So in theory yes, in practice - we'll see.

Yes and no. Parts of the .NET environment are standards and could be openly adopted.
For example, the runtime (CLR) has a portable version called Mono which is multi platform, open source and is used by (for example) Second Life.

The intention, or at least the pitch, was for this to be the case. The reality is that .NET can't really run on other platforms. The only major exception is Mono, which is an open source project. It's essentially a rewrite of the .NET runtime (the equivalent of the java virtual machine) that works on Linux, Solaris, Mac OS X, Windows, and Unix.
It's been fairly successful, but it's not officially supported.
If you're thinking of getting your monolithic Acme corp employer to adopt .Net and Linux, forget it. Realistically, with .NET, you're on Windows machines, period.

Yes, .NET has the Common Language Runtime (CLR) which is the .NET equivalent to the JVM. Microsoft does not support it on as many platforms as Java but with the help of the Mono project it is possible to achive cross platform applications with the usual caveats.
Bear in mind that .NET is more than just the CLR. It is a whole platform.

Since .NET is only available (officially) on Windows, then not, it isn't write one, run anywhere. However the Mono team are making a good go at helping spread .NET beyond Windows, but they are always way behind the official stuff.

I don't think that it was the original plan, for Microsoft, to create runtimes for every platform and device, but they encouraged this by using a documented (?) intermediate language.

Multiplatform was of course in the vision.. right now mono does a good job of implementing the runtime for other os.
Mono

Short answer -- no, Microsoft only supports MS operating systems (including Windows Mobile) for .NET.
Long answer -- there are public open-source projects to replicate the .NET framework for linux and other OSs, notably Rotor and Mono. They don't support everything, but you can deploy a lot of .NET code, including silverlight.

That depends on your definition of "Anywhere".
There are several flavors of Java virtual machine and of .Net framework.
And most of the time you can't just write code for a desktop vm/framework and expect it to run on a mobile phone one.
So. in a sense, even Java is not really pure "Write Once, Run Anywhere".
It is true, however, that Java's VM is currently running on several operating systems while .Net framework runs only on Windows devices.
There is one interesting initiative called "Mono" which offers .Net support on Linux, Solaris, Mac OS X, Windows, and Unix. Read here: Mono Site

dotNet can be, because of the CLR which is similar in function to the JVM.
But i dont believe MS had any intention of it being.
http://www.mono-project.com/Main_Page
might be useful, but its not a MS product.
Btw, much like how the wide spectrum of j2ee containers cloud the WORA concept for j2ee apps, ASP.NET apps running on anything besides IIS wouldnt really work the same across disparate platforms.

I don't think this was ever really a design goal of .NET - Microsoft has no particular interest in people writing software for non-Windows platforms ....
However, there is The Mono project (http://www.mono-project.com), which is "an open development initiative sponsored by Novell to develop an open source, UNIX version of the .NET development platform."

It was most assuredly meant to be WORA. It's just MS figured Anywhere and Everywhere would be Windows by now. Who knew Linux and the MacOS would still be around. But judging by all the Macs at the PDC, I guess they were either half right or half wrong!

If WORA was really an original goal, then I guess we'd see .NET implementations on all the major platforms by now, fully supported by Microsoft. I seem to recall that at the time Sun was shouting WORA from the rooftops, Microsoft's riposte was "Write Any (language) Run on One (platform)" (WARO:-). As somebody else mentioned, I think they've always been firm backers of WORASLAIW (Write Once Run Anywhere So Long As Its Windows)
As you point out, they seem to be changing tack a bit with Silverlight to try and get a piece of the Flash/Flex action now that the battlefield has shifted significantly away from the desktop and towards the browser.

But it IS multiplataform Win9x/WinNT/Mobile

Given responses from others I'm still unclear as to whether it was an actual intention of Microsoft to have .NET be a WORA initiative. The only way to really know I guess is to have somebody from the Microsoft .NET team chime in on this.
Since we cannot definitively know the original WORA intentions of .NET we can point to efforts that are attempting to make this a reality (as previous answers have talked about).
[Mono](http://en.wikipedia.org/wiki/Mono_(software))
This effort is an initiative happening outside of Microsoft.
Mono is a project led by Novell (formerly by Ximian) to create an Ecma standard compliant .NET compatible set of tools, including among others a C# compiler and a Common Language Runtime. Mono can be run on Linux, BSD, UNIX, Mac OS X, Solaris and Windows operating systems.
Silverlight
This effort is being heavily pursued by Microsoft. Silverlight 2.0 implements a version of the framework that is the same as .NET 3.0 and seems to be an attempt to successfully deliver the framework to multiple platforms through the browser.
It is compatible with multiple web browser products used on Microsoft Windows and Mac OS X operating systems. Mobile devices, starting with Windows Mobile 6 and Symbian (Series 60) phones, will also be supported.
While it does not specifically address bring functionality to GNU/Linux there is apparently a third-party free software implementation named [Moonlight](http://en.wikipedia.org/wiki/Moonlight_(runtime)).
This seems to be what we currently know, but as stated earlier, it would be very helpful if somebody from the .NET team could pitch in on this one to properly clarify if WORA was in fact an original initiative.

If Microsoft were serious about dotnet on other non windows platforms they would have released the class libraries for reuse by others ajoiding the need to rewrite the same libs again. Sun on the other hand has done this meaning less barriers are present ifnone wishesto port to another platform. Natually with java one still needs to write a vm and do the native stuff but it helps avoid a headache that is reimplementing the entire class library. The standardization of the language wS a marketing ploy to grab jon technical folk. A language without libs is worthless. Try doing your next project withnknly the prjkitive types ... That's right write your own string class etc and tell me how helpful a standardiSe language is without any libs available...

I think the idea was to create inter-operability between the different programming languages, not WORA.

.Net Core makes .Net "almost" Write Once Run Anywhere.
But there are subtle differences -
.Net Core is not really .Net
With .Net Core, you write once but build multiple times, once for each specific target OS. Whereas in Java binaries are built once and can be run on any supported OS.
dotnet build --runtime ubuntu.18.04-x64