If your vendor doesn't support the latest acceptable security, demand it. Vendors are not going to change unless they get pressure from their customers. Threaten to switch to a different vendor.
With system replacement cycles stretching out to 5 years and beyond, companies are running systems that have moved to "mature support" (if supported at all beyond availiability of replacement parts). Even if customers can pressure those vendors to change their policies, that is usually only going to be reflected in new products - many vendors don't have the ability to "ramp back up" support on mature systems. I've run into this with various 2-, 3-, and 4-letter-name vendors.
This is not just an issue with Java. It affects things like SSL as well. To give a specific example (without naming names, but it was a 3-letter-name company), their SSL implementation was part of the RTOS package they purchased from their supplier (a well-known provider of that sort of thing). By the time SSL "broke" on that product, the RTOS supplier had obsoleted that package. In fact, newer products from the vendor (for the last several years) included a different, newer, RTOS / SSL. Due to the customer uproar about the older product's SSL no longer working (a campaign which I had a not-insignificant part in), the vendor paid the old RTOS supplier an also-not-insignificant amount of money to add a fix for that SSL problem to the obsolete RTOS. The vendor then resurrected their obsolete build system and built the first new firmware release in over 6 years (for hardware that was discontinued over 5 years ago). It went through internal testing, some bugs were fixed, and it was released to select customers (including me) for beta testing. It was approved and the vendor was going to publish it on their web site the following week. In the week between the approval and the publication, Firefox changed its behavior
again and stopped working with the firmware due to a different SSL issue. Faced with the choice of paying the RTOS supplier to do a complete upgrade of the SSL package and hope that no future SSL issues would cause browsers to stop working, again, or to say "the hell with it" and decide that hardware that has been discontinued for over 5 years wasn't going to get that level of support, they went with the second choice. I can't blame them.
Another vendor, this one with a 2-letter-name (which recently changed its name to a 3-letter-name) sells combined hardware / software (OS) support for an obscene amount of money. How obscene? Well, you could buy 10 systems on the used market for less than the vendor charges for a year's support. Their SSL implementation? It's from 2007! Or perhaps older, as the latest remote management firmware reports a 2007 date. Their response to requests from customers paying the obscene amount of money for support? Pretty much "Derp!" Do you remember the old "We don't have to care - we're the phone company!" trope from before the Bell System breakup? Well, that's this vendor's apparent philosophy.
At the beginning of this year, I wrote a blog post titled
"Is no crypto always better than bad crypto?" where I questioned the browser behavior of just going "nope - not gonna talk to that system" for certain categories of issues. You might want to take a look and see if you agree with me or not. Since I published that post, Firefox has changed its behavior slightly and there's a "yes, I know what I'm doing and I want to override this" checkbox in the Advanced dialog box for certain additional SSL issues that wasn't there when I wrote that post.