Oracle Formally Proposes That Java Adopt Ahead-of-Time Compilation (infoworld.com)

An anonymous Slashdot reader quotes InfoWorld: Java applications will get faster startup times thanks to a formal proposal to include ahead-of-time compilation in the platform. The draft Java Development Kit proposal, authored by Vladimir Kozlov, principal technical staff member at Oracle, is targeted for inclusion in Java 9, which is expected to be available next summer. "We would love to see this make it into JDK 9, but that will of course depend on the outcome of the OpenJDK process for this JDK Enhancement Proposal," said Georges Saab, vice president of software development in the Java platform group at Oracle, on Thursday. Ahead-of-time compilation has been a stated goal for Java 9 to address the issue of slow startup...

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine. The ultimate goal is to improve the startup time of small or large Java applications while having "at most" a limited impact on peak performance and minimizing changes to the user workflow.
Tests indicates some applications perform better while some actually perform worse, so it's being proposed as an opt-in feature where dissatisfied users "can just rebuild a new JDK without ahead-of-time libraries."

Comments

Only makes sense for niches

[angel'o'sphere]

Penty of Enterprise software relies on byte code morphing/instrumentation and all things we get from Aspect Oriented Programming. Ahead of time compilation makes only sense in Applications that don't use such featers and should be simply part of the build process if developrs chose so and not necessarily a "language feature".
After all there are plenty of third party AoT Conpilers for the JVM.

Re:Only makes sense for niches

[Anonymous Coward]

It's not going to be a language feature. It's part of the JDK toolkit. Reading comprehension skills, do you have them?

Re:Only makes sense for niches

[lgw]

Reading comprehension skills, do you have them?

He uses Aspect Oriented Programming, so code is impossible to read and thus he doesn't practice reading comprehension much. (Also, Kirk could kick Picard's ass, and EMACS > VI).

Re:Only makes sense for niches

[Big Hairy Ian]

Yep Oracle are wasting perfectly good oxygen again

Re:Only makes sense for niches

[Anonymous Coward]

Everyone knows EMACS is bigger than vi, the real question is: which is better? :P

Re: Only makes sense for niches

[AuMatar]

Breaking that kind of coffee is the best reason for making this mandatory I can think of.

Re: Only makes sense for niches

[WarJolt]

AOT makes sense for certain application. Also AOT doesn't mean AOT only. If you want to use it with a tracing JIT I see no reason why these technologies are incompatible.

The problem I have with Java is that with some java programs it takes less time for an equivalent C program to compile and run than an that java program to do all of its dynamic linking and finally run. You don't have to do AOT, but all those string compares during loading really slows things down. Each symbol has to be looked up and compared.

With native libraries often times shared libraries are already in memory. The libraries are simply mapped into a processes address space. In java land each time you load a library it takes up its own space and that overhead is not shared by multiple processes. It seems silly that these processes can't share their compilation efforts.

We have a ways to go with runtimes. The first step is oracle admitting they are the problem.

Re: Only makes sense for niches

[K. S. Kyosuke]

So you want to remove the advantages of the language implementation while keeping the disadvantages of the language? How does that help?

Re:Only makes sense for niches

[Anonymous Coward]

Emacs is an operating system therefore better, even than Linux

Re: Only makes sense for niches

[pz]

it takes less time for an equivalent C program to compile and run

No kidding. I have a pretty sophisticated self-specializing application that we rely on in my lab. It occasionally needs to create a semi-custom C program to run a particular computation with new parameter settings. It's so fast to generate the few thousand lines of C code and compile them that you barely notice the times when it needs to spin a new specialization of the code versus running an already-compiled version.

Re: Only makes sense for niches

[Anonymous Coward]

How does it not help? It doesn't. Nor, can it not.

Re: Only makes sense for niches

[AuMatar]

Because Aspect oriented programming and bytecode inspection produce unreadable, unmaintainable codebases. It shouldn't be done, ever. We've known for decades that self modifying code is a bad idea, if you use it you're bad.

Re:Only makes sense for niches

[Anonymous Coward]

It's a really good operating system, the only drawback of which is the shitty default text editor.

Re:Only makes sense for niches

[arglebargle_xiv]

"Ahead-of-time compilation"? That's like "compilation" isn't it, the thing that's been used to build code since 1952?

Oracle announces more than half-century old technology as new feature of Java! Press ecstatic! Slashdot reports! And then the next day reports the same thing again! And then a third time just to be sure!

Re:Only makes sense for niches

[Anonymous Coward]

Penty of Enterprise software relies on byte code morphing/instrumentation and all things we get from Aspect Oriented Programming. Ahead of time compilation makes only sense in Applications that don't use such featers and should be simply part of the build process if developrs chose so and not necessarily a "language feature".
After all there are plenty of third party AoT Conpilers for the JVM.

Beware the slew of patents and lawsuites

Re:Only makes sense for niches

[angel'o'sphere]

In principle Java is "ahead of time" compiled to byte code.
And during execution on most platforms "just in time" compiled to native code.

The announcement is about compiling directly to native code, which makes only in rare cases sense.

Re: Only makes sense for niches

[angel'o'sphere]

That is nonsense.

You don't see the manipulated byte code, and aspect oriented code is clearly readable as object oriented code.

The only slight problem is e.g. generated code by hibernate or the spring framework while you are debugging. But for that you simply right click on the relevant code in the stack frame and make it "invisible" (forgot the correct name of the command), then the debugger simply steps over framework code.

We've known for decades that self modifying code is a bad idea, if you use it you're bad.
The code is not self modifying but is modified by tools either after compiling or during load time. Also: it is a matter of taste if self modifying code is good or bad. It is called meta programming, many people are fluent in it. If you are not: if you use it you're bad.

Re: Only makes sense for niches

[angel'o'sphere]

If the C program was equivalent it had a comparable amount of files/classes.

There is no way it compiles remotely as fast than a Java program, sorry.

Dynamic loaded classes are of course not shared in Java processes, unlike *.so's or *.DLL's. However if a JVM links in a native *.so it is of course shared like any other process.

We have a ways to go with runtimes. The first step is oracle admitting they are the problem.
Why those exaggerations? We have no problem.

The applications that start up super slow are *.EAR files in Application Containers, like WebSphere or JBoss, and in those cases AOT would be inapplicable, because the container wants to interpret all those annotations and weave in its managing code.

Most slow starting programs are a problem of the teams developing them, I doubt they would bottom line produce better software if they used C or C++.

A real Java compiler?

[HornWumpus]

If it's 'just in time' to make your app perform, does that make it a JIT compiler?

Next: I need to link between Java, C++ and C# modules.

Re:A real Java compiler?

[tomhath]

does that make it a JIT compiler?

Java already has a JIT compiler, which is why startup times are slow. This proposal if for an AOT - Ahead Of Time - compiler.

Re:A real Java compiler?

[lgw]

This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.

It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.

You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.

You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.

Re: A real Java compiler?

[AuMatar]

Linking to C and C++ is fairly easy. JNI is a bit clunky but not hard to understand. C++ just requires a thin C layer around the object oriented calls

Re: A real Java compiler?

[lgw]

C++ just requires a thin C layer around the object oriented calls

Ah, yes, the "thin layer" that means you don't work directly with STL vectors, strings and maps, and, well, objects. Also, no exceptions. Bridging between an OOP language and an OOP language via C code means you need two awkward transitions between C-style code and OOP code.

I've done that far to many times. It can be quite constraining for your C++ code, depending on what kind of problem you're trying to solve. Also, that kind of marshaling is expensive. I've worked on plenty of Java codebases where 90% of CPU time was various serialization and deserialization code.

Well, better than nothing, but JNI was really intended to allow small chunks of C code to either do a bit of expensive calculation, or be a custom driver, or just wrap a system call that Java didn't, but in any case be a synchronous part of a Java function call. Much like C# with it's built-in marshaller, which punishes you for doing anything beyond wrapping system calls that the .NET runtime doesn't.

Re:A real Java compiler?

[BitZtream]

This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.

The stack overflow you link to has nothing to do with AOT. They all use a standard JVM and JARs, just all packaged into a single exe file. Its still JIT for the ones that include the JRE bits, the others just download and install a JRE for you. Using C and C++ code from Java is non-trivial but easy enough.

It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.

Its just as easy in Java, except better hidden, cause you're not supposed to do it, in order to keep the 'cross platform' nature of Java at its core. Microsoft wants you to bind your C# apps to the Windows platform so they encourage the use of P/Invoke to work around unimplemented features of the framework. Its handy, but goes against one of the core tenets of Java.

You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.

Technically, what you compile C# (and all .NET) to isn't actually executable either. Its byte code as well, that can be easily and quickly turned into cached binaries that are essentially AOT compiled ... but thats stored in a different director on the machine and isn't the exe you run, mono will do actual full AOT with the right options, but by default doesn't either. Full AOT takes away several features of the .NET framework, just like it would with the JRE. They'd be implemented in an entirely different way. .NET dlls are just OLE components at their hearts, you've probably heard of OLE as one of the other names it goes by: DDE, OLE2, ActiveX, COM, DCOM. These are ALL THE SAME THING in different revisions, with more features in the later ones. .NET being the latest. Loading and running .NET assemblies is only slightly more difficult than loading an ActiveX in C or C++. Its non-trivial, and you won't find a ton of examples, but its not black magic. Its no more difficult than getting an XPCOM or Corba object to load, and Mozilla can even do that properly so lets not act like its rocket science.

You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

You would embed the JVM in your application or a plugin for your application and execute the JAR from there, the same way you do with .NET runtime objects. Not really rocket science here either, though again it is non-trivial.

Its the same as loading pretty much any interpreted language from C or C++, just different libraries and function calls. You do realize that the 'java' command is a C application that loads a bunch of Java libraries and execute JAR files right?

Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.

Its been done: https://www.ikvm.net/

Run .NET code in java, run Java code in .net. Its big, its bulky, it works pretty well, but I don't recommend doing it for weekend fun.

Re: A real Java compiler?

[Dutch Gun]

I also do this all the time between my C# (tools) code and C++ (game engine) code, and I've never found it constraining, although it's certainly tedious to recreate all the APIs in C. Creating a C-style interface for just about any C++ objects is reasonably straightforward if you break it down into handle (address of object) + method. As for exceptions, game development generally doesn't use them (in native code), but yes, that would require each native method to wrap the API function in a try-catch block, then pass along errors as a C-style error code.

If performance is an issue, then it may be a sign that your interop API may be a bit too fine grained, and needs a mechanism to batch calls a bit, perhaps by moving a bit of logic down into native code so you can make fewer, more meaningful interop calls. Performance work is, unfortunately, often diametrically opposed to clean design.

Re: A real Java compiler?

[lgw]

Have you tried Managed C++? I've been through this 3 times now, and each time the team didn't believe me until we did the experiment. There's a quite nice boost in performance when your C++ code can, e.g., iterate through a list of strings as input without any copying or marshaling.

More complex classes require conversion or some tedious hand-coded wrappers, but we did a lot with just library containers, and the ability to just use C# objects directly from normal C++ code that knows nothing of .NET (thanks to some wrappers) is quite nice.

I also do this all the time between my C# (tools) code and C++ (game engine) code, and I've never found it constraining, although it's certainly tedious to recreate all the APIs in C. Creating a C-style interface for just about any C++ objects is reasonably straightforward if you break it down into handle (address of object) + method

The awkwardness depends a lot on whether your C++ style is "never (need to) explicitly clean up anything ever" code, or "C code with classes". If you're still doing the latter, catching exceptions and returning status codes, explicit clean-up code at the bottom of functions, or in destructors, that sort of thing, then it's not a big deal to make C-style wrappers.

OTOH, if you're using scoped objects and not in the habit of explicit clean-up, then it gets really awkward when you start doing stuff like: OK, I need to return an array. I can't return a pointer to my vector, since no shared pointers, so I'll have to copy it into a C-style array. Who's going to free that? Well, obviously, the caller should allocate it, and free it when appropriate, but how does the caller know how big to allocate? OK, I need another API function to just get the size, which is going to have to do all the same work. And so on and so on. All solvable, but you end up with a lot of copies being made, and a minefield for either leaks or dangling pointers if you don't completely understand how long the managed code is going to use that pointer you gave it.

So much easier for the C++ code to just take a reference to a vector as input, and never even realize it built a CLR List instead of a std::vector as it went (or, worst case, return a shared pointer to a vector, and copy it into a CLR list - less efficient, but no leaks or dangling pointers possible).

Re: A real Java compiler?

[Darinbob]

STL isn't OOP though, and is no disadvantage if you can't use it.

Re:A real Java compiler?

[Anonymous Coward]

> You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

It's pretty straightforward to run Java from a C program (or it was about 10 years ago, when I worked on a project which needed it): if you think about it, it's what the "java.exe" does. Once the JVM is launched inside your code, then you can run code within it.

Re: A real Java compiler?

[Dutch Gun]

I haven't tried managed C++, but it sounds interesting (if I hadn't already done all the work).

I'm using modern C++ everywhere, but I still haven't found the transition to a C-style interface too onerous in most cases. As you surmised, the most awkward sections tend to be when dealing with C++ types passed around at the interface level. My typical approach is to transform the data into a structure that works in the managed code. For instance, my engine works natively with UTF-8 strings, so I need to convert between UTF-8 and 16 for each string passed. Sort of a pain, yes, but it's just a quick conversion function, and I haven't found the performance to be that bad in my case.

Part of the complexity of my system is that I not only use managed to native code interop, but I also have to transmit a lot of data across a process boundary as well. The native part of the editor window that shows the rendered game view is isolated in a separate process, so that any problems or crashes in it don't bring down or hang the main editor. As such, the nature of this system lends itself to simpler C-style interfaces anyhow, since I have to serialize everything into primitive data streams and re-interpret all those commands and data in the other process. That means the data has to be transformed into a serializable format at least once anyhow.

 

Re: A real Java compiler?

[lgw]

One other thing to look at is shared memory as a "transport". I did very fast IPC between C# and some kernel-mde C code (initiated from the C# side) once - yeah, still some serialization, since you can't use raw pointers, but not a lot.

Re: A real Java compiler?

[lgw]

Are you being an academic purist insisting nothing but Smalltalk is real OOP? Otherwise I don't get your point,

Re: A real Java compiler?

[Darinbob]

It's one of the major criticisms when STL was introduced. It's based on templates and not objects. You can't easily subclass a template, and definitely not STL containers. STL doesn't fit into most definitions of OOP, academic or not.

Re: A real Java compiler?

[Dutch Gun]

That's actually how my interprocess communication library handles the details underneath the interface (the Windows FileMapping API). And yep, it's extremely fast.

Re: A real Java compiler?

[lgw]

I wish I worked on anything where that sort of performance mattered these days. Other challenges, sure, but not as fun.

Re: A real Java compiler?

[Xest]

"If performance is an issue, then it may be a sign that your interop API may be a bit too fine grained"

Therein lies the problem though, sometimes you have little choice but for that to be the case and in those circumstances managed to native marshalling is incredibly expensive.

I had some old legacy code I had to take on board that used native Lua as a scripting language, and the cost of marshalling between executions of Lua scripts was incredibly expensive - there wasn't really anything you could batch, the results of the former had to be . I tore out the old scripting engine and replaced it with a new one supporting multiple pluggable languages, for tests using our real world scripts those that ran on the CLR were drastically faster, using a managed Lua implementation (MoonSharp) execution was twice as fast, using IronPython it was 4x as fast, and supporting C# as a scripting language itself and precompiling those scripts at startup meant execution was between 40x and 80x as fast (though startup was marginally slower of course, which didn't really matter, as it's a long uptime server service). Individual precompiles post-startup when scripts are updated or replaced were negligible in impact.

It was an interesting exercise in understanding the performance impact of marshalling, and the DLR vs native vs precompiled managed. If the option is there I would always avoid dropping out to native where possible. When running the CLR is incredibly fast and the cost of marshalling to/from native will typically far more than outweigh any performance gain native code might offer (if it does at all - I still think JIT offers at least post-compilation performance parity in most cases from what I've seen).

We have different use cases to you somewhat though, so your experience may differ of course, this is for risk analysis in the financial services industry.

Already been done

[kelemvor4]

It's already been done. Symantec's compiler had a native compilation option. I build some things with old java revisions so I can use it. Like most native programs, it requires a runtime to be preinstalled. In the case of Symantec, it was the "symantec native java runtime". The most recent version I have is 3.0.

In conclusion, it's a good idea to have as an option. It's already been done, and I wonder if symantec has any patents that might get in the way of this being implemented on a broader scale.

Re: Already been done

[kelemvor4]

It came with the VisualCafe compiler, btw. https://en.wikipedia.org/wiki/... Eventually they sold it to webgain, so perhaps webgain has any patents that might be attached to it.

Re: Already been done

[jgfenix]

There are also others: GCJ, Excelsior Jet and others I don't remember now.

Cycle of life

[Anonymous Coward]

Google steals from Oracle. Oracle steals from Google.

This sounds like ART on Android device, with the ahead of time compilation. Google has moved away from the AOT mechanism for apps because updates became a pain for end users. In Nougat, they use a "hybrid" approach, where the code that is executed most frequently gets compiled while your device is idle. So, some code will run JIT and others as compiled pieces.

This might not be as big of a concern for enterprise products.

Bullshit or bafflegab.

[BarbaraHudson]

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine.

If it's all compiled to native code ahead of starting the JVM, what do you need the JVM for? Their use of "native code" here is not what we usually mean. It's just "ahead-of-time" compiled libraries, same as the Android ART.

Re:Bullshit or bafflegab.

[Alomex]

It's just "ahead-of-time" compiled libraries, same as the Android ART.

Say what? From wikipedia:

Unlike Dalvik, ART introduces the use of ahead-of-time (AOT) compilation by compiling entire applications into native machine code upon their installation.

Re:Bullshit or bafflegab.

[K. S. Kyosuke]

Yes, it happens before initiating its execution. Same thing that is apparently being described here. Of course, the VM still provides runtime services to the program, just like in many other contemporary languages.

Re:Bullshit or bafflegab.

[BarbaraHudson]

And it's still BS, because it's compiled to the ART runtime, not pure native machine code. Otherwise you wouldn't need the ART runtime. Think for 2 seconds - how many different SoCs does Android run on?

Re:Bullshit or bafflegab.

[Alomex]

You are wrong. You need the run time because it provides services such as GC and profiling.

At install time, ART compiles apps using the on-device dex2oat tool. This utility accepts DEX files as input and generates a compiled app executable for the target device.

The # of SoCs is neither here not there. You need to have the ART compiled to the specific SoC, when you do that you can make the AOT module generate native code for the specific SoC if you so wish.

I'm not an expert on ART, but I'm pretty sure you are wrong on this one.

Re:Bullshit or bafflegab.

[BarbaraHudson]

In other words, if the compiled code needs the ART, it's not completely native code. Thank you for playing.

Re:Bullshit or bafflegab.

[Anonymous Coward]

All you are doing is parading your ignorance: any language can have a run time component, compiled or not.

It is rather funny that you are so wrong and sassy about it. Anyway, as they say, you can lead a horse to water but you can't make it drink, so I'm signing off from this discussion.

Re:Bullshit or bafflegab.

[BarbaraHudson]

It's not as good as "real" native code. The performance is shit in comparison. Do a search for writing android apps in c/c++. Even Microsoft supports this for Android in their free Visual C compiler. ART is a bit better tha dalvik, but it's still terribly slow. Think of it - we had better response on a 386 single core 40 mhz with 8 megs of ram. And nothing;s going to fix that, including "compiling sections to native code".

Java is slow. Android is even slower. Using the ART as a shim to go between native code and Android is shit. Considering that Android only supports a small subset of Java, major fail!

Past-time Compilation

[Anonymous Coward]

Compiles after it runs! => It = Preprocessor. Favorite pastime of C programmers? The preprocessor!

Re:Past-time Compilation

[Anonymous Coward]

You don't seem to understand what a compiler is if you think the software that transforms high level languages in this context (i.e. Java on a Java VM, C# on the CLR, etc.) to their respective bytecodes is in any way comparable to a pre-process that does not shift languages.

Re:Past-time Compilation

[Anonymous Coward]

Just because a preprocess to machine code program has not been written does not mean that it cannot be done or that the preprocessor cannot "shift languages". The C99 preprocessor can act as a Turing complete language. See the post by Paul Fultz II @ http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete

Re:Past-time Compilation

[BarbaraHudson]

You can use a pre-processor, with the right macros, to generate assembly language or even binary. Just depends on hacking the pre-processor.

Re:Past-time Compilation

[BarbaraHudson]

It's been done.

fantastic!

[Gravis Zero]

Oracle is just a misstep or two away from fully ruining Java. You couldn't ask for a better enemy.

Re:fantastic!

[gweihir]

Indeed. I hope they press on vigorously, because Java becoming unusable would be one of the best things that could happen to the IT world.

Re:fantastic!

[iggymanz]

eh, that's a tiny misdeed by Oracle compared to their big crimes.

Auditors storming a company, demanding their black box audit scanning code be run with access to all networks, claiming any virtual hosting platform in any location of the company might be used to run Oracle DBMS so must pay the license fees for all of them (or else buy Oracle hardware at somewhat less an amount of extortion).....

They've become a bunch of mafia thugs in the "protection money" racket. =Avoid doing business with Oracle, or take the effort to get off their DBMS onto an alternative or they will fuck you over.

Re:fantastic!

[Gravis Zero]

I don't care about Oracle because they are a self-defaming company. I do care about which language that projects are written in and Java is not a winner.

Re:fantastic!

[dromgodis]

Java becoming unusable would be one of the best things that could happen to the IT world.

How so?

Re:fantastic!

[Anonymous Coward]

Ah yes the rabid fanaticism of so call IT professionals. My guess is you worship the other God? Like C or C++ or something. Perhaps your one of those 7th day real coders don't need IDEs, cus if you can't fit it in your head your doing it wrong. But most likely your like every other IT religo nut job out there. Hypocritical, utterly ignorant and pretty shit at your job.

Re:fantastic!

[Anonymous Coward]

You know MS has does that as well. Even worse at the uni i worked at, you still pay licence fees for computers connected to the network, that already have paid the MS tax. aka Student laptops etc. It just cheaper to pay than to lawyer up.

Re:fantastic!

[Anonymous Coward]

Yea, it should be in Lisp. I don't need to know what the project it. What it does. What the specs are. What code already exist. Clearly i know all i need to know. It is lisp.

How is this different

[flargleblarg]

How is this different from just giving -server on the command line when invoking the JVM?

Idea

[Anonymous Coward]

What if Java just let you compile for each system individually. I mean it would be a bit of a pain for software engineers to manage all those versions of java apps but think of the performance increases.

Re:Idea

[BarbaraHudson]

You already need a bunch of different JVMs - sometimes even on the same machine. The translation to function calls for different OSes can be automated, same as any other cross-compiling.

Re:Idea

[Xest]

.NET already supports this, but it has it's downsides too. For starters it breaks things like reflection, and as such it's not something that can simply be done for "free". It's something you do on a case by case basis - the reality is that performance isn't everything and there are always other factors to weigh in, sometimes performance loses, sometimes it wins, but you certainly can't assume performance always trumps every other factor.

Well, that clinches it.

[Anonymous Coward]

There's now officially no benefit to using Java.

"Write once, run anywhere" was a pipe dream from the beginning.

I never saw why compiling for different platforms was a problem. If you write in 99% ANSI C/C++ then portability is not a big deal!

Re:Well, that clinches it.

[sexconker]

Joke post? Joke post.
The minute you need to call a library or access something the OS provides, you're fukt.

Re:Well, that clinches it.

[Anonymous Coward]

By "fukt" I presume you mean "can write long-lived code that uses the OS that just works".

On the other hand, use anything in Java and now you have a security hole. Well, eventually, after it runs. And a few hours after maven downloads all of the dependencies.

Re:Well, that clinches it.

[pauljlucas]

ANSI C doesn't specify things like either word size or endianness. Granted, many C programs don't care; but, when you need to, you have to write different code for different platforms.

Re:Well, that clinches it.

[Anonymous Coward]

True, but a char will never be shorter than 8 bits, an int shorter than 16, or a long shorter than 32 in ANSI C. That's enough to write portable code for most use cases.

Re:Well, that clinches it.

[Anonymous Coward]

What a weird post.

Re:Well, that clinches it.

[Anonymous Coward]

ANSI C doesn't even provide fucking standard calls for TCP/IP. Despite the fact that even most embedded systems have that now. In fact its more common that standard input output and error streams. C is stuck in the fucking stone age.

fix some other problems

[ooloorie]

There are a bunch of other problems with Java. Why not fix those at the same time as changing the compilation model?

We could call that new version of Java "Swift" or "C#".

Great, now I need a new Java joke

[Anonymous Coward]

I guess this means my favorite Java joke won't work anymore:
Knock knock.
Who's there?
.
.
.
.
.
.
Java

Re:Great, now I need a new Java joke

[Tablizer]

That's probably McAfee in the way.

"ahead of time compilation"

[Anonymous Coward]

So, just "compilation"?

Re:"ahead of time compilation"

[Anonymous Coward]

Yes, but given the context (languages that are compiled to an intermediate language to run on a virtual machine) it makes sense to refer two the two stages of compilation with some specificity.

Re:"ahead of time compilation"

[Anonymous Coward]

s/stages/instances/ to be more clear

Re:"ahead of time compilation"

[Anonymous Coward]

Yep, now we have "just-in-time" compilation, "it's-about-time" compilation, and soon "short-of-time compilation."

That's when the compiler doesn't finish before launch deadline, and just marks the uncompiled code "dirty." :-P

This raises the question

[overshoot]

Now that Oracle has figured out how to keep anyone from doing this without paying them, how much will they charge?

Enough to encourage migration away from it

[HBI]

That is the Oracle way. Encouraging substitute goods might as well be their corporate motto.

Tachyons

[Anonymous Coward]

I'm sure OnLive tried to harness the power of tachyons.
It did not go well. They failed before getting anywhere.

No. Java is useful.

[Anonymous Coward]

No! Java allows mediocre programmers to use huge codebases, to produce mediocre programs. That is very important for many not widely used programs, such as internal software at big corporations, medium sized government departments, etc.

Maybe Java should just stay at Java 6.

Garbage

[speedplane]

I wish they'd spend more time on improving their garbage collectors than compilation time. It can take 30 seconds to a minute to garbage collect 25GB of memory, a huge problem for servers. The G1 garbage collector (G1GC) is promising, but it's still far to buggy to use in production. If this GC issue does not get fixed, I could see it incentivizing server software to switch to C/C++.

Re: Garbage

[turbiina]

As an admin who had done a enough of java tuning i would suggest you to run more small instances behind a load balancer instead of one big java vm ( especially on multi core/cpu machines, if possisble of course) and garbage collectors more often,monitor gc log and memory- the smaller teeth for memory consumption,the better. But anyway I would like java just die. there is enough evil in the world even without java( and oracle )

Re:Garbage

[binarylarry]

Or you could find developers that know what they're doing?

Re:Garbage

[K. S. Kyosuke]

Azul's C4 would be of any help?

Re:Garbage

[JaredOfEuropa]

With decent garbage collection, developers won't have to bother. I notice the difference between developing for iOS and Android. In iOS, memory management is almost a non-issue. You still need to know what you're doing and how things work when you run into a memory leak or unexpected shortage of memory, but in your day to day code you will very rarely have to keep anything memory related in mind. Android is an entirely different matter. When I build a memory intensive screen in Xamarin (in c#), it usually is one hour to write the xaml, one hour to wire things up to the data source and get things to run... and two days to get it to perform on Android and plug the memory leaks. I am sure an experienced Android dev can make it work much faster, but whether it takes an hour or a day, it is wasted effort that in this day and age ought to be spent on developing functionality rather than doing housekeeping that the system ought to be doing.

Re:Garbage

[willy_me]

ARC results in much lower latency when cleaning up memory. This results in better user interfaces and helps explain why it works well with iOS. The JVM employs garbage collection that offers better performance at the cost of higher latency. If you load balance multiple instances (as suggested by another poster) you get overall improved performance. The JVM is better suited for server applications where its garbage collection implementation is safer and requires less overall energy to perform a given job.

Your problems with Android will have more to do with API design and your approach to programming said APIs then they will the type of garbage collection used by the platform. I am not suggesting that Android is great, but it has been shown to work well if approached correctly.

Re: Garbage

[speedplane]

As an admin who had done a enough of java tuning i would suggest you to run more small instances behind a load balancer

I'm already running plenty of relatively large instances. Decreasing the instance size requires that I add many more instances, which create other problems. It would be nice if Java could be run efficiently on larger servers (e.g., >32GB of RAM).

Re:Garbage

[Aaden42]

What problems have you seen with G1GC? We're running it in production for the better part of two years on both JDK 7 & 8 without issues. Early JDK 7 had some stability problems on it, but it's been rock solid since about 7u60-something and throughout JDK 8.

Re:Garbage

[Anonymous Coward]

If you are using a compacting garbage collector, garbage collection time is proportional to the amount of live memory. Generational garbage collection postpones but does not eliminate this.

Ahead of time compiling?

[Anonymous Coward]

I've been trying out this new ahead of time compiling thing in an obscure language - 'C' This 'C' is like java, but without most of the "java.io.foo.bar.wibble.set(42)" syntactic bullshit and overall just feels less bloated. And 'C' doesn't require a multi-GB runtime. I only have to compile ahead of time once, not on every load, and best of all, I haven't *ever* had any exceptions thrown. It is like Java without the pain.

idiotic neckbeards compmaining

[Anonymous Coward]

news at 9

its...

[God of Lemmings]

about damn time.

Java 16

[thinkwaitfast]

Java 16 will will be written entirely in executable machine code and will compile to source code.

Oracle is the problem

[auzy]

If Oracle genuinely cared about Java, they would release it, and the patents to the community.

You'd literally be insane to touch it at the moment. Oracle will step on too many toes eventually, and the more toes they step on, the bigger the risk of using Java long term is. They have a long history of being d**ks, but the most recent I remember, is when they forked Redhat to make their own distro, which was basically exactly the same, but a few minor kernel tweaks, and that users paid Oracle instead of Redhat.

There is NO good reason for any open source developer to support them.

Excellent -- This allows light wieght processes

[aberglas]

If JITing can be done up front and cached, and the Jited code shared between processes, this would make it feasible to run short lived processes that do specific tasks in a light weight manner. And that means avoiding the monolithic Java web serving processors.

The Java rhetoric has always been that creating processes is slow. Which is true, for Java. But not for C programs on *nix. DB connection is more of an issue.

Sure, there is some overhead in running up a PHP-like process, but for small to medium loads the deployment process is so much easier to manage. When a process ends, it looses all its resources. It is easy to see what resources a process is using, time it out etc. Cannot kill a rogue task safely in Java.

I'd like to think that this will be the end of PHP. But I am dreaming there.

I've seen this before

[bytesex]

Isn't this what the Jalapeno project did?

Does this solve a real problem?

[dromgodis]

When is the startup time of a Java program a problem in practice?

Not trolling - could you give me an example?

I work with Java every day, both for tooling and end products. The Java startup times are never a factor. What takes time is dependency management, loading of plugins, synchronization between systems etc, and you are likely to have them using any language. The time from initiating the process to the first line of Java code being executed is hardly measurable in the context.

Interpreting the Interpretation

[ememisya]

Or you can write your code in C and use JNI to execute that code.

NGEN

[ojfresdhg]

.NET/C# has had AoT (compile at installation) compilation since day 1, since .NET 1.0, since 2002. No-one uses it. For good reasons.