I think it's reasonable to say that if the the user code is transmitted as a managed intermediate representation then it's not native. Arguing beyond that probably isn't productive.
But that's this particular blog post. Java can be native, if you compiled all the user code to machine code ahead of time.
If the VM is shipped as native code and the app is bundled with it as "code" that runs on the VM, is that fundamentally different from shipping an app written in compiled-to-machine code that bundles some data (JSON, XML, a SQLite database, etc.)? It definitely "feels" different, but I'm not convinced that the former is not "native" just because more of the logic is in the data rather than the machine code.
So, anything that uses a JIT, such as the LLVM JIT, is not "native"? Are programs written in C# not native, even on Windows? Are programs in Java for Android not native, even though it is the language much of the OS is written in and what the standard UI toolkit is built for?
Seems like lots of projects are likely to become non-native over time, by this definition, even if they start out "native" with a basic C/C++ codebase, since lots of projects accrete some sort of scripting or extension interface that might use a runtime of some sort. Is Emacs not native? Does it really matter if the runtime (which is machine code) was made by the compiler developer or by the application developer in some cases?
I feel like there's an arbitrary line, and it's not entirely useful distinction to make.
A native app can be big and slow and ugly and fail to follow the OS UI guideliness. An app with a runtime can be small(ish) and fast and beautiful and strictly adhere to the UI guidelines for the OS in question. I want the small, fast, beautiful, app with standard UI behavior, no matter whether it's delivered with a runtime embedded or built from C/C++ (and a few others) and without a JIT.
I mean, we're just arguing semantics here, which is kinda silly. I think it's pretty neat; I don't really like working in Java, but I'd rather work in Java than C/C++, so if I needed to deliver a cross-platform GUI app, I'd certainly consider it.
LLVM IR is transformed into native code only once. You don't ship the assembler to your users for a C program.
Of course the JVM has advantages that it can dynamically optimize code according to actual execution profiles.
If I am not mistaken with the right instrumentation LLVM can also makw your program generate a special optimization profile which you can then apply to your final build compilation.
> Are programs written in C# not native, even on Windows?
C# always had AOT compilation to native code via NGEN.
Just that few people bother to use it, because it only allows dynamic linking, the optimizer is tailored for fast startup time and requires an extra effort with application signing.
Windows 8 apps were always AOT compiled on the store via a "cloud compiler", based on Bartok from Singularity project. Using a format known as MDIL.
Windows 10 apps are always AOT compiled via .NET Native, which shares the backend with Visual C++.
Mono always supported AOT compilation and it is the way Xamarin apps are deployed on iDevices.
> Are programs written in C# not native, even on Windows?
Well I think that's a different meaning of the word 'native'. They're native in terms of being written using the recommended techniques for that platform, but not native in terms of being natively compiled.
But as you say it's just a discussion of semantics.
> So, anything that uses a JIT, such as the LLVM JIT, is not "native"?
Correct.
> Are programs written in C# not native, even on Windows?
No they are not, because .Net uses an intermediate representation, being Windows and Microsoft confers no magic "native"-ness.
> Are programs in Java for Android not native, even though it is the language much of the OS is written in and what the standard UI toolkit is built for?
Programs in Java for Android are not native.
Much of the kernel (Linux) is written in C. According to "Francesco Iovine, AndroidStudio lover" over at Quora[0] the UI toolkit is written in Java and the virtual machines (Dalvik and Art) are written in C++.
> Is Emacs not native?
Emacs is a strange and evil beast whose name we shall not invoke. No, but seriously – I imagine Emacs is a hybrid native / Emacs lisp program. Many programs with embedded scripting languages are hybrid beasts but they ought to be thought of as native apps if they are compiled for a certain bare metal hardware platform. I presume the core of Emacs is C. Ergo, native.
> Does it really matter if the runtime (which is machine code) was made by the compiler developer or by the application developer in some cases?
Yes, I believe it does matter.
> I feel like there's an arbitrary line, and it's not entirely useful distinction to make.
No, I don't believe it's arbitrary.
> A native app can be big and slow and ugly and fail to follow the OS UI guideliness. An app with a runtime can be small(ish) and fast and beautiful and strictly adhere to the UI guidelines for the OS in question. I want the small, fast, beautiful, app with standard UI behavior, no matter whether it's delivered with a runtime embedded or built from C/C++ (and a few others) and without a JIT.
True. But that is neither here nor there, that's a whole other issue.
> I mean, we're just arguing semantics here, which is kinda silly.
No, we are not. A native app is one which is either hand-crafted assembly for a specific hardware platform or compiled ahead of time targeting a specific platform. Native code is non-portable, the source code might be portable, but generally is not unless care is taken. Assembly code is never portable. Non-native (whether by VM: Java, C#, … or interpreted: Ruby, Python, …) tends to be more portable.
Suppose I write a C program and then deploy it on a target machine where it is continuously running thereafter. Then I develop a loadable module (.so) which I compile, upload to the target and get the C program to load it with dlopen. Is that native or not?
If it's native, why isn't JIT to machine code not native? Because of the convenience of all of the above happening on a fine-grained level (individual functions), and all on the target machine?
Also, what is "compiled ahead of time"? Ahead of what time? Why is that specific time important? Obviously, code is compiled ahead of its compiled image being run; the compiled version cannot be run any sooner. Any JIT-ted function is compiled ahead of being called.
On most operating systems, we can load programs after the OS boots. Those programs can be developed after the OS booted.
I think that the only true definition of "native" is that the program image was compiled before the hardware was built and turned on for the first time, and was present in its ROM.
Anything else is not "ahead of time" and not native, damn it!
Installing a program on your PC is just a form of JIT. The system was fired up without that program being there, and the program was snuck in just moments before the user's intent to use that program. Not ahead of the True Scotsmans proper time: the time when components were stuffed into the circuit board and it was powered up.
I think you're looking a bit too manically for holes in what is a pretty informal term that's useful in everyday discussions. It's not a mathematical proof that you're a genius for finding a gap in.
The term is misused. Native means "native machine code", in any shape or form with no interpretation layer in between. OP seems to be confused between native vs. non-native axis and monolithic/static vs. modular/dynamic.
If the software image is compiled in its entirety before being installed on a target, that is "monolithic". If parts of it can be dynamically loaded, it is "modular". Dynamic loading of functions with JIT is just heaping on more modularity: hyper-modular.
A situation involving JIT is non-native only in the sense or to the extent that there is non-JIT-ted code in the image. If there is an interpreter so that some things execute without being JITted, those things are not native.
I don't believe that the term is not misused. What is happening perhaps is that you disagree with the term. And that's fine, that's your prerogative. I don't think that I am confused.
“Each program that is compiled on IBM i gets turned into a set of TIMI instructions. Essentially, it gets compiled down to a set of intermediate code. For decades, that’s been a pretty common step for a compiler to take – get to an intermediate representation of the program before creating the machine-level instructions. One big difference, though, is that the compiler on IBM i does not go any further. It leaves the intermediate code connected to the program object, and then the lower levels of IBM i act on the intermediate code to translate it into the instructions used by the Power hypervisor and Power processor beneath the OS. IBM i does this only when necessary, not every time the program executes. Typically, the translation takes place once when the program is moved from one release of the operating system to a later one, and never again while it runs on that later release.”
> Java is AOT compiled to native code on installation on Android 5 and 6.
Then by your reasoning and terminology I think you'd also call IBM's tech AOT compiled, not JIT'd given that it happens once per OS release or app move, not each time the app is executed.
And I would say that the applications that get delivered this way on AS/400 and Android 5 and 6 are delivered as non-native (intermediate code as the article says). And then get translated AOT to native which is stored somewhere else and the non-native code is kept around.
Neat, I didn't know that about Android 7 and Dalvik. Is it the same for Art?
> There are AOT compilers available for Java and C#, just as there are interpreters for C and C++.
>> So, anything that uses a JIT, such as the LLVM JIT, is not "native"?
> Correct.
Oh, come on. You can't seriously believe this nonsense. A native C++ program embedding (for example, to parametrically specialize some constructs at run time) an LLVM JIT which is in C++ again is going to be as native as they come.
> I presume the core of Emacs is C. Ergo, native.
And that C++ program I mentioned isn't, according to you, even though most of Emacs is delivered in interpreted byte code form. And if Emacs stated JITting the bytecode, it would cease being native. You really seem to have some weird and/or inconsistent definitions.
Native used to mean machine code for the hardware but there's so little of that nowadays that I think people often use it to mean anything that's more tied to one platform than a web app so it's a bit ambiguous.
