Develop Reference

New JDK 12 with no JRE? How does this work? [duplicate]

This question already has answers here:
How can I get Java 11 run-time environment working since there is no more JRE 11 for download?
(4 answers)
Closed 3 years ago.
For a very long time now, I have been able to explain and separate the concepts of the jdk and the JRE quite succinctly. The jdk was for developers and you only need it if you plan on developing, where is the JRE is essentially the resources associated with the Java virtual machine, which is needed by anyone wanting to run Java regardless of whether they are a developer or not.
Now, everywhere I read, people are telling others that they don't need a JRE, and that the jdk includes everything that is necessary. So, my initial thought is that the virtual machine and all the required libraries to run Java come with the jdk. That's fine.
However, I'm having difficulty understanding what a regular user experiences then. I have seen on my own devices updates to Java in the notification area, and I know tons of people who run Java on their computers and other devices that are not developers.
That being said, what exactly are they updating now if there is no JRE? They have to have a Java virtual machine on their machine in order to run Java, correct? Does the new virtual machine run software that is written with jdk 12? Specifically, I'll assume it has to work with openjdk 12?
These changes are a little bit confusing, so I'm trying to find out if any of you might have some information about them.
Thanks!

Presumably because they're rev'ing one or more aspects of the development environment, but have no need for a change to the JRE.
One example I can think of would be to patch javac... the output might still work just fine on the previous JRE, but javac could have been changed to produce more efficient byte-code or patch some security vulnerability.
Those by themselves don't strike me as "major rev" worthy, but that may well be a marketing decision rather than a technical one.
EDIT: The Actual List of Changes:
https://openjdk.java.net/projects/jdk/12/
GC Thing (experimental)
Benchmarking thing
New syntax for switch/case (it looks like lamdas switch(foo) {case bar, baz -> qux();})
"JVM Constants API"? How is that not a JRE thing? (edit: it could be that the API was already present, but has now been made public)
Drop support for one of two 64 bit architectures on ARM. Needless redundancy is needlessly redundant.
"Default CDS Archives" CDS: Class Data-Sharing More efficient reflection?
"Abortable Mixed Collections for G1"
"Promptly Return Unused Committed Memory from G1"

Apple deprecates Java, what are our technical options as programmers? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Need guidance on alternative JVMs for Apple OS X
So that's it, Apple may not be producing a JVM themselves nor shipping it with OS X anymore:
http://www.infoq.com/news/2010/10/apple-deprecates-java
We've got a huge Java application running on Windows, Linux and OS X (and OS X is a big part of our [rich] userbase), what will, as developers, our options be?
Will it be realistic to run our app on another OS X JVM (an Oracle one)?
Or is a move away from Java to be considered? If so, what would that technically mean? Try to use some automated porting tool (not unlike Excelsior Jet for Windows, is there anything similar for OS X?)? Rewrite our entire app (which would be huge) to Objective-C and maintain two different versions? (a Java one and an Objective-C one?).
We may decide to drop OS X support altogether too, at least as long as Microsoft or Oracle do not kill Java on Windows.

Will it be realistic to run our app on another OS X JVM (an Oracle one)?
That depends on how GUI intensive your application is, and how much you / your users care about having a fast GUI and the Mac "user experience" for the Mac version of your app.
But yes, it could be totally realistic. Wait and see what Oracle does, and in the meantime, try out Soy Latte.
Or is a move away from Java to be considered?
Depends how much effort you have to burn. And how much effort you can justify for supporting Mac users. No matter how you do it, you'll end up having to support two codebases.
We may decide to drop OS X support altogether too ...
That's realistic.
... at least as long as Microsoft or Oracle do not kill Java on Windows.
That's ridiculous FUD-mongering!
Microsoft can't do it, because they have no control of the Java codebase. (If they tried to do it by backdoor means, they'd be up against the wall for anti-trust violations ... all over the world.)
Oracle would be insane to try to do it for many reasons. Besides, they can't (in theory) because the OpenJDK for Windows codebase is open source and there other existing high quality Java implementations for Windows (e.g. IBM's).
But since we're into FUD-mongering, a more likely scenario (compared to "the end of the world" for Java on Windows) is:
Oracle does a deal with Apple to take over Apple's rights to the Java-on-Mac codebase.
Oracle "monetizes their investment" by selling Java-on-Mac licenses to developers or end-user.
That would certainly be "in character" for Oracle, and they'd be within their rights to do this. It wouldn't make them popular with the open-source community, but the signs are that they don't really care about that.

This strongly depends if Apple will make it an optional download (like Rosetta) or completely leave it.
If it is an optional download, you are in the same situation as under Windows.
If abandoned, then you must consider if OS X is a supported platform anymore.
You may in any case strongly consider supporting the OpenJDK project which currently is the best bet for filling the void Apple is creating here.

Is there an advantage to running JRuby if you don't know any Java?

I've heard great things about JRuby and I know you can run it without knowing any Java. My development skills are strong, Java is just not one of the tools I know. It's a massive tool with a myriad of accompanying tools such as Maven/Ant/JUnit etc.
Is it worth moving my current Rails applications to JRuby for performance reasons alone? Perhaps if I pick up some basic Java along side, there can be so added benefits that aren't obvious such as better debugging/performance optimization tools?
Would love some advice on this one.

I think you pretty much nailed it.
JRuby is just yet another Ruby execution engine, just like MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun and all the others.
The main differences are:
portability: for example, YARV is only officially supported on x86 32 Bit Linux. It is not supported on OSX or Windows or 64 Bit Linux. Rubinius only works on Unix, not on Windows. JRuby OTOH runs everywhere: desktops, servers, phones, App Engine, you name it. It runs on the Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea and Oracle JRockit JVMs (and probably a couple of others I forgot about) and also on the Dalvik VM. It runs on Windows, Linux, OSX, Solaris, several BSDs, other proprietary and open Unices, OpenVMS and several mainframe OSs, Android and Google App Engine. In fact, on Windows, JRuby passes more RubySpec tests than "Ruby" (meaning MRI or YARV) itself!
extensibility: Ruby programs running on JRuby can use any arbitrary Java library. Through JRuby-FFI, they can also use any arbitrary C library. And with the new C extension support in JRuby 1.6, they can even use a large subset of MRI and YARV C extensions, like Mongrel for example. (And note that "Java" or "C" library does not actually mean written in those languages, it only means with a Java or C API. They could be written in Scala or Clojure or C++ or Haskell.)
tooling: whenever someone writes a new tool for YARV or MRI (like e.g. memprof), it turns out that JRuby already had a tool 5 years ago which does the same thing, only better. The Java ecosystem has some of the best tools for "runtime behavior comprehension" (which is a term I just made up, by which I mean much more than just simple profiling, I mean tools for deeply understanding what exactly your program does at runtime, what its performance characteristics are, where the bottlenecks are, where the memory is going, and most importantly why all of that is happening) and visualization available on the market, and pretty much all of those work with JRuby, at least to some extent.
deployment: assuming that your target system already has a JVM installed, deploying a JRuby app (and I'm not just talking about Rails, I also mean desktop, mobile, other kinds of servers) is literally just copying one JAR (or WAR) and a double-click.
performance: JRuby has much higher startup overhead. In return you get much higher throughput. In practice, this means that deploying a Rails app to JRuby is a good idea, as is running your integration tests, but for developer unit tests and scripts, MRI, YARV or Rubinius are better choices. Note that many Rails developers simply develop and unit test on MRI and integration test and deploy on JRuby. There's no need to choose a single execution engine for everything.
concurrency: JRuby runs Ruby threads concurrently. This means two things: if your locking is correct, your program will run faster, and if your locking is incorrect, your program will break. (Unfortunately, neither MRI nor YARV nor Rubinius run threads concurrently, so there's still some broken multithreaded Ruby code out there that doesn't know it's broken, because obviously concurrency bugs can only show up if there's actual concurrency.)
platforms (this is somewhat related to portability): there are some amazing Java platforms out there, e.g. the Azul JCA with 768 GiBytes of RAM and 864 CPU cores specifically designed for memory-safe, pointer-safe, garbage-collected, object-oriented languages. Android. Google App Engine. All of those run JRuby.

I would modify what Peter said slightly. JRuby may use more memory compared to standard Ruby, but that's usually because you're doing the work in a single process what would take several processes with Ruby.
You should try the Rails.threadsafe! option with a single JRuby runtime (for example, the Trinidad gem with the --threadsafe option). We've heard several stories where it gives you great performance and low memory usage, while leveraging multiple CPU cores with a single process.

JRuby is one of the few implementations that uses native threads. So if you care to do some multithreading, go for it.
As far as hosting is concerned, you have to put your app in some sort of java container, which I personally find to be far less straightforward than using something like passenger (for Rack apps)
I use JRuby for an app as we communicate over JMS and it works fine, but if I wasn't using any Java I would certainly stick to CRuby. My biggest beef is that in testing, running tests takes forever with JRuby as you have to spin up a VM each time you run them. This makes it a lot harder to TDD as it's a significant hit on your testing time.

Jruby has advantages if you're on Windows. It supports 64 bits and you can use a lot of proprietary databases with standard JDBC drivers.

The latest releases are significantly faster than Ruby but also use significantly more memory. If that is your only reason for using JRuby, I wouldn't bother unless you have a specific performance need that it solves, simply because, while it is pretty popular, it is less standard for hosting and less people use it as compared to standard Ruby. That being said, there are many other reasons to use JRuby such as a need for interoperability with existing Java code and the need to deploy in environments where Java has been "blessed" by the operations department and Ruby has not.

(Why) does Tomcat/Java perform better on Linux than on Windows?

I just read this (one) study in which Tomcat under Linux outperformed Windows.
From your experience, is this generally true? Any deep reason that could explain the performance difference?

I don't thing such benchmarks can be so informative, then this one is 4 years old.
By the way these differences usually reside in certain choices related to how the operating system manages memory, cache and threads..

I take any benchmark with a grain of salt. It's possible to game any comparison.
I find that one key is to try and spot any bias that the person doing the comparison might have. There was an infamous comparison of the Java EE Pet Store done with .NET several years back. The group doing the study had been paid by Microsoft. They didn't do all they could to optimize the Java EE solution, putting it in a bad light. The results were discredited as a result.
Does WebPerformance.com have any Linux bias?
If not, there are a lot of factors that enter into such a result. I'd compare all of them carefully, and try to see if I could spot anything important that might have been left out.

Few points (mostly speculation):
Tomcat developed by FOSS on FOSS software, so it is reasonable that it would perform better on FOSS software.
Linux is better operating system ;-)
Generally. It depends on fine tuning experience... If you know windows well you'll tune it better for windows and if you know Linux better then...

What JVM can be run under Mac OS 7.5?

I have a request for a contracting gig and one of the requirements in the first draft of the specs says the software (a GUI application for end-users) should run on Win 2000 and Mac OS 7.5. I have no idea why they would want to support such ancient systems, but I guess it leaves me with Java as the only option other than raw C, or doesn't it?
So if it would be Java, are there restrictions on what Java version I can use on those targets?
Also, though it wouldn't be strictly on topic, I'd appreciate comments on strategies for making software run on both targets. Actually, supporing those ancient systems as well as modern ones might even be harder than supporting Mac and Win, right?
As another sideline, I'd also appreciate facts that could be used to talk the client out of this and make him go with OS X and XP. Like "hey, only 2% of all Macs in use today still use OS older than X".
Edit: My main purpose here is to be well prepared technically to negotiate what the specs really should be.
Things like that are often the result of some manager thinking "gee, my aunt still uses OS 9 and I bet, there's people even more old-fashioned, so let's just play it safe and write down 7.5". There's no technical judgement whatsoever involved, and that's OK. It's just that, in those cases, you have to explain carefully what tradeoffs there are and if you succeed, it usually gets you much more realistic specs. It's not even unlikely that they'd ditch Mac OS altogether if they have to bet money on it.
With that kind of specs, if you don't actively help the client reshape them, what's going to happen is, you put the number in the offer that would pay for all the crazy stuff and then yet some, and less experienced competitors won't see all the implications and put a lower number in their offer, get the gig and it all ends in tears for everybody. You can go "heh heh, told you so", but don't get the cash, either.
Edit: Thanks for still posting facts and advice although I already accepted an answer to my original question. I'll keep upvoting that stuff, and it certainly helps. Also thanks for empathizing with me and trying to save me from signing a bad contract! But don't worry, I'm not actually going to code for Mac OS 7.5 ... ;-) Really, really overseeing all the implications would be well out of my depth anyway.

Unless this is a seriously lucrative contract, or you desperately need the money, I'd recommend running away from it as fast as possible. The chances are the client is not only targeting seriously old OS's, but also old hardware. That'll mean you'll have all sorts of problems with performance (for you can bet the entire value of the contract that they want an app with modern features and performance on this ancient kit). It's near guaranteed to end in tears...

The Java Runtime for MacOS 7.x was called Mac OS Runtime for Java (MRJ) and supported at least Java 1.1.8. If my memory servers me right, the Swing implementation was pretty bad - so you would need to use AWT.
At least on the ancient MacOS systems, you will have stability & performance problems. Don't take this contract, this is guaranteed to end in a fiasco.

Unless this is a seriously lucrative contract I would stay away from this one.
I've worked on contracts like this in the past and they are almost always more trouble than they're worth. Whilst I appreciate you are just trying to be prepared, you really need to find out more about why they want to do this - its pretty unusual.
OTOH. If the contract is a big one and they are only talking a couple machines - it might be worth your while to offer to buy and install machines for them!
Coding for an older VM such as 1.1 will force you to code to a lower common denominator and will add considerably to development and testing time - you need to take this into account. The machine will almost certainly be underpowered in terms of memory and cpu.
Win2k will support at least Java 1.4 and possibly 1.5.

It's up to 1.1.8 for all Mac OS Classic (not X)

One useful stat is that about 85-90% of all Macs run OS X 10.4 or 10.5. Most of the other 10% are running older versions of OS X.

I'm not definite on this, but I believe Mac OS 7.5 will only run versions 1 and 1.1 of Java.