Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

new JDK 1.8.0_112

746 views
Skip to first unread message

Roedy Green

unread,
Oct 18, 2016, 6:24:23 PM10/18/16
to
JDK 1.8.0_111 and 1.8.0_112 are out.

Eric Douglas

unread,
Oct 19, 2016, 8:03:17 AM10/19/16
to
On Tuesday, October 18, 2016 at 6:24:23 PM UTC-4, Roedy Green wrote:
> JDK 1.8.0_111 and 1.8.0_112 are out.

111 and 112? Which one works? Last update there was a 101 and 102 and we had problems with 102. So I guess we stick with 111, even though when we fixed the rest of the machines on our network by removing 102 and installing 101 I just put 122 on my machine which seems to be working fine.
So, 111, or early release is at least up to 122...

Eric Sosman

unread,
Oct 19, 2016, 8:20:56 AM10/19/16
to
From Oracle's download page:

"Java SE 8u111 includes important security fixes. Oracle
strongly recommends that all Java SE 8 users upgrade to this
release. Java SE 8u112 is a patch-set update, including all of
8u111 plus additional features (described in the release
notes). "

Also, a few links from that same page:

http://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html

http://www.oracle.com/technetwork/java/javase/8u112-relnotes-3124973.html

Will there be anything else, Sir?

--
eso...@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

Eric Douglas

unread,
Oct 19, 2016, 8:33:39 AM10/19/16
to
On Wednesday, October 19, 2016 at 8:20:56 AM UTC-4, Eric Sosman wrote:
> From Oracle's download page:
>
> "Java SE 8u111 includes important security fixes. Oracle
> strongly recommends that all Java SE 8 users upgrade to this
> release. Java SE 8u112 is a patch-set update, including all of
> 8u111 plus additional features (described in the release
> notes). "
>
> Also, a few links from that same page:
>
> http://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html
>
> http://www.oracle.com/technetwork/java/javase/8u112-relnotes-3124973.html
>
> Will there be anything else, Sir?

It just seems odd...why they call them both public release, and they list the lower number first for downloads, and the higher numbered one crashed our system last time...
Now I guess we want to test both versions, since higher should be better (if it doesn't crash the system?) and the first bug fix listed says they made it faster?
Version 122 seems to work, maybe we should run the 'early release' versions in production!?

Eric Sosman

unread,
Oct 19, 2016, 9:28:57 AM10/19/16
to
Which to adopt for production is, of course, your call and not mine.
If the choice were mine, though, I doubt I'd opt for 122 -- 112, maybe,
but 122 would seem just a wee bit rash. :)

112's list of bug fixes is considerably longer than 111's, but I'm
not in a position to say how important that might be in your situation.
If you're using SecureRandom.PKCS11 you'll have an easier time with 111
than with 112, but there may be other countervailing considerations.

If you don't need the bug fixes *and* you run only apps and applets
that are trusted, you might be able to stick with what you're using
now. But if anyone in your organization runs apps or applets downloaded
from untrusted sources, the fixes for seven CVE's may be of interest ...

Eric Douglas

unread,
Oct 19, 2016, 10:15:07 AM10/19/16
to
On Wednesday, October 19, 2016 at 9:28:57 AM UTC-4, Eric Sosman wrote:
> 112's list of bug fixes is considerably longer than 111's, but I'm
> not in a position to say how important that might be in your situation.
> If you're using SecureRandom.PKCS11 you'll have an easier time with 111
> than with 112, but there may be other countervailing considerations.
>
> If you don't need the bug fixes *and* you run only apps and applets
> that are trusted, you might be able to stick with what you're using
> now. But if anyone in your organization runs apps or applets downloaded
> from untrusted sources, the fixes for seven CVE's may be of interest ...

I haven't heard of SecureRandom.PKCS11 so if my application has any reference to such a thing it would have to be from a third party jar.

We develop an application in house which runs on webstart, our own custom API we made from scratch. We use self signed jars from a free keystore I generated years ago from the keytool that came with the Java. Our own app should be trusted. All I noticed in the change list for the latest Java was something about dropping support for MD5 but I'm not sure what that is. Our oldest signed jars (2011) contain "SHA1-Digest" hashes and our current jars contain "SHA-256-Digest".

I'm not sure how to tell Java we trust an applet but I know we run at least a couple. In particular we print shipping labels from FedEx which requires applet, and the ever fun GSA Login button (http://fedpay.gsa.gov/) runs an applet with ActiveX controls that look like 1995.

Arne Vajhøj

unread,
Oct 19, 2016, 9:26:19 PM10/19/16
to
On 10/19/2016 8:03 AM, Eric Douglas wrote:
I think this topic has come up so many times recently.

111 = 102 + security fixes
112 = 102 + security fixes + other fixes

So I think the logical upgrade strategy is:

101 or 102 works and want to minimize risk => pick 111
want latest and greatest => pick 112
101 works, 102 does not work and bug not fixed in 111/112 => stay at 101

Arne

0 new messages