JAVA 8 now available for VMS

[Sue]

As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.

To download please visit

https://www.hpe.com/global/java/download/ivms/1.8.0

Sue

[Bob Koehler]

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

Won't run on any of my systems. :-( Sigh.

[Bill Gunshannon]

Post by Bob Koehler

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

Won't run on any of my systems. :-( Sigh.

Maybe it's time to retire those VAXen, Bob. :-)

bill

[Bob Koehler]

Post by Bill Gunshannon
Maybe it's time to retire those VAXen, Bob. :-)

Only one is a VAX. Which will have to be pried out of my cold, dead,
hands.

But I shoud think about the PDP-11. Pro350 never did turn out to be
much use.

[Kerry Main]

-----Original Message-----
Bob Koehler via Info-vax
Sent: April 7, 2017 9:26 AM
Subject: Re: [Info-vax] JAVA 8 now available for VMS

Post by Bill Gunshannon
Maybe it's time to retire those VAXen, Bob. :-)

Only one is a VAX. Which will have to be pried out of my cold, dead,
hands.
But I shoud think about the PDP-11. Pro350 never did turn out to be
much use.

Hey - Pro350 was great console for Nautilus VAX's (85xx/87xx/88xx)!

(or was it Pro380?)

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Bob Koehler]

Post by Kerry Main
Hey - Pro350 was great console for Nautilus VAX's (85xx/87xx/88xx)!

IIRC, it came complete with a "hold cluster" button.

[Bill Gunshannon]

Post by Bob Koehler

Post by Kerry Main
Hey - Pro350 was great console for Nautilus VAX's (85xx/87xx/88xx)!

IIRC, it came complete with a "hold cluster" button.

I'm still waiting for it to show up on my doorstep like the little
orphan it is. :-)

bill

[Bob Koehler]

Post by Bill Gunshannon

Post by Bob Koehler

Post by Kerry Main
Hey - Pro350 was great console for Nautilus VAX's (85xx/87xx/88xx)!

IIRC, it came complete with a "hold cluster" button.

I'm still waiting for it to show up on my doorstep like the little
orphan it is. :-)
bill

If you're serious, we'll need to argange pickup or transportation.

[Bill Gunshannon]

Post by Bob Koehler

Post by Bill Gunshannon

Post by Bob Koehler

Post by Kerry Main
Hey - Pro350 was great console for Nautilus VAX's (85xx/87xx/88xx)!

IIRC, it came complete with a "hold cluster" button.

I'm still waiting for it to show up on my doorstep like the little
orphan it is. :-)
bill

If you're serious, we'll need to argange pickup or transportation.

I would love to have it but I have no idea how to get it here. I doubt
the USPS would even handle it. I don't even know where you are located.

bill

[Bill Gunshannon]

Post by Bob Koehler

Post by Bill Gunshannon
Maybe it's time to retire those VAXen, Bob. :-)

Only one is a VAX. Which will have to be pried out of my cold, dead,
hands.

Yeah, mine too. Don't even miss the fact that they can't run Java.

Post by Bob Koehler
But I shoud think about the PDP-11. Pro350 never did turn out to be
much use.

Hey, no problem, stick it in a box and send it my way. I'll see to it
that it doesn't get lonely or feel neglected.

bill

[Dirk Munk]

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0
Sue

That is nice of course, but there is a bit of a problem.

It is based on Java 8.051, and that version dates from 2015-07-14.

Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.

I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

[Dirk Munk]

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the
availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0
Sue

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

Java 9 is due in July 2017.........

[Arne Vajhøj]

Post by Dirk Munk
Java 9 is due in July 2017.........

Oracle has stated that their Java 9 implementation will be available
July 27th.

But it is common that other vendors (from IBM and down) come out
a bit later.

I would say that if HP get Java 9 out the door <9 month after Oracle,
then it is at an acceptable level.

Arne

[Simon Clubley]

Post by Dirk Munk
Java 9 is due in July 2017.........

This OTOH, isn't a major problem for me. The question for me is more
about having _supported_ versions of a product on VMS and Java 8 will
be supported for quite some time after the release of Java 9.

Seeing Java 9 on VMS should be a lower priority than seeing the
current version of Java 8 on VMS and seeing new versions of Java 8
rapidly also becoming available for VMS when they are released.

Simon.

[Stephen Hoffman]

This release is very good news. Getting a far more current Java, and
one with better TLS support, is most helpful. Work-arounds can be
removed.

Post by Dirk Munk
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

[Arne Vajhøj]

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

There are only two sort of products:
* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

:-)

Arne

[David Froble]

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....

You forgot about the one that "just works" ....

[Arne Vajhøj]

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....
You forgot about the one that "just works" ....

No.

That is just a temporary state.

Arne

[David Froble]

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....
You forgot about the one that "just works" ....

No.
That is just a temporary state.
Arne

Well, from that perspective, EVERYTHING is temporary. Now, let's see, how much
hydrogen does the local star have left?

[Arne Vajhøj]

Post by David Froble

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....
You forgot about the one that "just works" ....

No.
That is just a temporary state.

Well, from that perspective, EVERYTHING is temporary. Now, let's see,
how much hydrogen does the local star have left?

The number of months the average CIO will wait for first bullet
to become likely before assuming second bullet is not that big.

Relying on a platform with no future is a very high business risk.

Arne

[David Froble]

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....
You forgot about the one that "just works" ....

No.
That is just a temporary state.

Well, from that perspective, EVERYTHING is temporary. Now, let's see,
how much hydrogen does the local star have left?

The number of months the average CIO will wait for first bullet
to become likely before assuming second bullet is not that big.
Relying on a platform with no future is a very high business risk.
Arne

Attempting to exist in this big bad universe on an insignificant little mudball
is high risk. You got any better ideas?

:-)

[Arne Vajhøj]

Post by David Froble

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj

Post by David Froble
You forgot about the one that "just works" ....

No.
That is just a temporary state.

Well, from that perspective, EVERYTHING is temporary. Now, let's see,
how much hydrogen does the local star have left?

The number of months the average CIO will wait for first bullet
to become likely before assuming second bullet is not that big.
Relying on a platform with no future is a very high business risk.

Attempting to exist in this big bad universe on an insignificant little
mudball is high risk. You got any better ideas?
:-)

Number of reachable and livable planets are sort of limited.

Most IT platforms has alternatives.

Arne

[Bill Gunshannon]

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
The Java 9 release is expected on the 27th of July, 2017, too. (The
"fun" with any of these ports.... It's always a moving target.)

* those where the next release is around the corner and you need to plan
for the upgrade
* those where the next release is not around the corner and you need to
plan the migration to another product

Uh ....
You forgot about the one that "just works" ....

I think he was hinting that that particular version is a myth.

bill

[Simon Clubley]

Post by Stephen Hoffman
This release is very good news. Getting a far more current Java, and
one with better TLS support, is most helpful. Work-arounds can be
removed.

Yes, this is good news and it's a lot better than the previous situation,
but HP/VSI need to stay focused on making sure that Java 8 is updated
quickly on VMS as new releases become available.

Some reading for those who don't know about the types of security issues
involved (based on past comments, Stephen will already know about these
types of issues):

https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html

(Specifically, focus on the highly scored ones and compare the Java 8
version numbers against the version number of the Java 8 version which
HP has just released.)

Simon.

[Stephen Hoffman]

Post by Simon Clubley

Post by Stephen Hoffman
This release is very good news. Getting a far more current Java, and
one with better TLS support, is most helpful. Work-arounds can be
removed.

Yes, this is good news and it's a lot better than the previous
situation, but HP/VSI need to stay focused on making sure that Java 8
is updated quickly on VMS as new releases become available.

OpenVMS itself and all of its associated packages. The
time-to-active-exploits is cratering. The attackers are automated,
massively distributed and very quick to pick up on reported
vulnerabilities.

The Apache Struts parser bug is a recent salient example.

http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html

Ransomware attacks targeting insecure and network-accessible databases
— insecure default settings, among other causes — are also popular.
MongoDB, Elasticsearch and CouchDB have all been popular targets, and
those attacks will persist for years, looking for any newly-available
targets. Lists of bugs to research and test are much more available
than some folks might realize, too.

BTW: Here's a relevant quote, from among folks discussing candidates
for new security attacks: “openvms needs to be taken down a few pegs
too, {expurgated}!”.

[Simon Clubley]

Post by Stephen Hoffman
BTW: Here's a relevant quote, from among folks discussing candidates
for new security attacks: “openvms needs to be taken down a few pegs
too, {expurgated}!”.

If that's in any way a recent quote, then perhaps _now_ VSI will
start listening to us and focus on the basic things and get up to
speed on what's expected of an OS vendor in 2017 instead of
pie-in-the-sky things like blockchain technology.

Simon.

[j***@yahoo.co.uk]

Post by Simon Clubley

Post by Stephen Hoffman
BTW: Here's a relevant quote, from among folks discussing candidates
for new security attacks: “openvms needs to be taken down a few pegs
too, {expurgated}!”.

If that's in any way a recent quote, then perhaps _now_ VSI will
start listening to us and focus on the basic things and get up to
speed on what's expected of an OS vendor in 2017 instead of
pie-in-the-sky things like blockchain technology.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Does March 26th count as recent (assuming the previously
removed context is as below, which seems vaguely plausible)?

https://twitter.com/search?q=%23lulzsec%20sabu%20irix%20openvms&src=typd

"TRENT MICRO‏ @RedTeamDad Mar 26

oh man i hobe sabu hacks on irix or dgux next! openvms needs to be taken down a few pegs too, assholes!
#lulzsec #infosec"



Further reading:
https://twitter.com/RedTeamDad
profile quote: "All tweets are jokes, lightén up"
...
Typical tweet: "Robots are taking all the good social
engineering jobs. Rise, hackers, and seize the means
of production. Massacre the cyber bourgeoisie"
...
etc
etc

Signal to noise ratio, trustworthiness, and relevance, all
hard for me to determine based on easily understandable
evidence.

Perhaps someone who is in with the in crowd might be
better positioned to enlighten other readers here.

[Simon Clubley]

Post by j***@yahoo.co.uk
Does March 26th count as recent (assuming the previously
removed context is as below, which seems vaguely plausible)?

Yes, it does. Thank you John (and Stephen).

Let's see what happens over the next few months...

Thanks,

Simon.

[Stephen Hoffman]

Post by Simon Clubley

Post by Stephen Hoffman
BTW: Here's a relevant quote, from among folks discussing candidates
for new security attacks: “openvms needs to be taken down a few pegs
too, {expurgated}!”.

If that's in any way a recent quote,

It's recent. Whether the author of the comment intended it as a joke,
I do not know. One of the folks that presented the second round of
DEFCON bugs made similar comments, BTW.

[Arne Vajhøj]

Post by Stephen Hoffman
The Apache Struts parser bug is a recent salient example.
http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html

It is a pretty bad bug.

But it is Struts 2 - and Struts 2 never became as widely used as Struts 1.

Arne'

[Arne Vajhøj]

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the
availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

u51 -> u121 should not be that big a lift (compared to 6->8).

Arne

[Simon Clubley]

Post by Arne Vajhøj
u51 -> u121 should not be that big a lift (compared to 6->8).

If the port has been developed with that in mind, I agree with that.

Let's see if reality matches what we would expect for an operating
system which is being advertised as a secure operating system.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
u51 -> u121 should not be that big a lift (compared to 6->8).

If the port has been developed with that in mind, I agree with that.
Let's see if reality matches what we would expect for an operating
system which is being advertised as a secure operating system.

The majority of the fixes should be in system independent code aka
simple copy.

Arne

[Simon Clubley]

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

You are not being negative; this is a very reasonable question to ask.

I don't know if VSI or HP did this port, but the current version needs
to be more recent than this.

I will accept this is an initial release, but the next question is
how long will it be before the current version is released ?

This will give you a good indicator of how long it will be before
the fix for a future critical security problem is available on VMS.

If OTOH, we don't see the current Java 8 version released for VMS
in the next month or two, then the question to be asked is if this
release is a one-off release for VMS or not ?

We have all seen releases of an open source product being released
for VMS and then see that version rapidly become outdated.

VSI/HP needs to be showing they can track the current released versions
of a product and this is a very good test case.

Simon.

[Craig A. Berry]

Post by Simon Clubley

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

You are not being negative; this is a very reasonable question to ask.
I don't know if VSI or HP did this port, but the current version needs
to be more recent than this.
I will accept this is an initial release, but the next question is
how long will it be before the current version is released ?
This will give you a good indicator of how long it will be before
the fix for a future critical security problem is available on VMS.
If OTOH, we don't see the current Java 8 version released for VMS
in the next month or two, then the question to be asked is if this
release is a one-off release for VMS or not ?
We have all seen releases of an open source product being released
for VMS and then see that version rapidly become outdated.
VSI/HP needs to be showing they can track the current released versions
of a product and this is a very good test case.

I would like to know how Dirk knows what Java version it's based on. It
reports this:

$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)

but VMS ports have seldom been known for rational version numbers that
correspond to the upstream code. I do find the "rc1" in the version
somewhat problematic in that it implies this is a release candidate
rather than a final release.

As far as keeping the release current, one could do that if one were to
hire one or two full-time Java engineers who did nothing but that
year-in, year-out. But I don't expect VSI will have the resources to do
that anytime in the foreseeable future.

[Arne Vajhøj]

Post by Craig A. Berry
I would like to know how Dirk knows what Java version it's based on. It
$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)
but VMS ports have seldom been known for rational version numbers that
correspond to the upstream code. I do find the "rc1" in the version
somewhat problematic in that it implies this is a release candidate
rather than a final release.

https://www.hpe.com/global/java/download/ivms/1.8.0/ says:

"The JDK 8.0 kit implements the Java SE 8.0 (a.k.a. 1.8.0), and is based
on Oracle's Java™ Standard Edition 8.0_51 Solaris Reference Release."

:-)

Arne

[Simon Clubley]

Post by Craig A. Berry

Post by Simon Clubley

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

You are not being negative; this is a very reasonable question to ask.
I don't know if VSI or HP did this port, but the current version needs
to be more recent than this.
I will accept this is an initial release, but the next question is
how long will it be before the current version is released ?
This will give you a good indicator of how long it will be before
the fix for a future critical security problem is available on VMS.
If OTOH, we don't see the current Java 8 version released for VMS
in the next month or two, then the question to be asked is if this
release is a one-off release for VMS or not ?
We have all seen releases of an open source product being released
for VMS and then see that version rapidly become outdated.
VSI/HP needs to be showing they can track the current released versions
of a product and this is a very good test case.

I would like to know how Dirk knows what Java version it's based on. It
$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)

The original link at https://www.hpe.com/global/java/download/ivms/1.8.0
makes reference to "Standard Edition 8.0_51 Solaris Reference Release".

Simon.

[David Froble]

Post by Craig A. Berry
As far as keeping the release current, one could do that if one were to
hire one or two full-time Java engineers who did nothing but that
year-in, year-out. But I don't expect VSI will have the resources to do
that anytime in the foreseeable future.

Craig, as you may be aware, it's much easier to suggest spending other's money
than your own.

It's sad that when someone does something, instead of complementing them,
regardless of how up to date that something is, they get berated for doing
something. Makes some people wonder why they should bother, if instead of the
pat on the back they get the kick in the ass.

I'm also wondering how much some people are willing to pay for a totally up to
date version, as soon as that version is released? Though I think I'm aware of
that vast sum ....

[c***@gmail.com]

Post by David Froble
It's sad that when someone does something, instead of complementing them,
regardless of how up to date that something is, they get berated for doing
something. Makes some people wonder why they should bother, if instead of the
pat on the back they get the kick in the ass.

No news here. We've been kicked around for 30+ years. Thick skin is a job requirement.

For the record......

JAVA 8 Release - 2 people, full time, 12 months; impact on other work - gigantic
Blockchain - 2 people, one 30-minute phone call per month; impact on other work - zero

[David Froble]

Post by c***@gmail.com

Post by David Froble
It's sad that when someone does something, instead of complementing them,
regardless of how up to date that something is, they get berated for doing
something. Makes some people wonder why they should bother, if instead of the
pat on the back they get the kick in the ass.

No news here. We've been kicked around for 30+ years. Thick skin is a job requirement.

Well, it should NOT be!

[John Reagan]

Post by David Froble

Post by c***@gmail.com

Post by David Froble
It's sad that when someone does something, instead of complementing them,
regardless of how up to date that something is, they get berated for doing
something. Makes some people wonder why they should bother, if instead of the
pat on the back they get the kick in the ass.

No news here. We've been kicked around for 30+ years. Thick skin is a job requirement.

Well, it should NOT be!

I just pretend I'm in a Monty Python skit

http://www.montypython.net/scripts/argument.php

[Arne Vajhøj]

Post by c***@gmail.com
For the record......
JAVA 8 Release - 2 people, full time, 12 months; impact on other work - gigantic
Blockchain - 2 people, one 30-minute phone call per month; impact on other work - zero

I think it is a good investment.

Good signal. Very long time since VMS has been current on almost anything.

And Java is an enabler of of so many things.

Someone with an I64 (not me unfortunatetly) could try and get
Jython, JRuby and Scala running.

That would add 3 languages to VMS.

Recent Tomcat should be relative easy.

JBoss AS / WildFly could follow.

Hibernate Oracle DB should work out of the box.

Some volunteer could do RDB dialect for Hibernate (if it is not already
done).

Couple of low end RDBMS'es like Derby, H2 and HSQLDB should run out of
the box.

Some volunteer could try some of the common NoSQL databases in Java like
Voldemort.

Arne

[Simon Clubley]

Post by David Froble
It's sad that when someone does something, instead of complementing them,
regardless of how up to date that something is, they get berated for doing
something. Makes some people wonder why they should bother, if instead of the
pat on the back they get the kick in the ass.

They are not getting berated for doing something; I've already said it's
a very nice stepping stone to where VMS needs to be. However, there are
also many other stepping stones needed to complete the path to where VMS
needs to be.

Post by David Froble
I'm also wondering how much some people are willing to pay for a totally up to
date version, as soon as that version is released? Though I think I'm aware of
that vast sum ....

That would depend in part on how much they pay for that same up to
date product on other platforms.

Simon.

[Arne Vajhøj]

Post by David Froble

Post by Craig A. Berry
As far as keeping the release current, one could do that if one were to
hire one or two full-time Java engineers who did nothing but that
year-in, year-out. But I don't expect VSI will have the resources to do
that anytime in the foreseeable future.

Craig, as you may be aware, it's much easier to suggest spending other's
money than your own.
It's sad that when someone does something, instead of complementing
them, regardless of how up to date that something is, they get berated
for doing something. Makes some people wonder why they should bother,
if instead of the pat on the back they get the kick in the ass.
I'm also wondering how much some people are willing to pay for a totally
up to date version, as soon as that version is released? Though I think
I'm aware of that vast sum ....

There are two sides of this.

I can completely follow you regarding focusing on the positive here
(Java 8 becoming available) over some minor issue (u51 vs u121).

And furthermore I don't think the issue is really critical. VMS systems
today are rarely in the frontline, so all those security fixes related
to applets and other web does not impact the majority of VMS systems.

But all that said, then it is part of being a serious player in
server OS to get patches out fast.

So to me bottom line is that it is important that VSI:
* will eventually catch up u wise
* have a plan for how to get to the state where patches routinely go
out fast
and less important what month u121 gets out.

Arne

[Stephen Hoffman]

Post by Arne Vajhøj
There are two sides of this.
I can completely follow you regarding focusing on the positive here
(Java 8 becoming available) over some minor issue (u51 vs u121).

That also goes to product fit and finish.

Much like testing and the user interface and the documentation, to the
thought that was given to the product or package.

To what other and less-obvious parts of the product might have been
thought through, or might have been half-arsed and shipped.

There are expectations associated with premium-priced packages.

OpenVMS got a good part of its start because of its degree of fit and
finish in comparison with other platforms, too.

Post by Arne Vajhøj
And furthermore I don't think the issue is really critical. VMS systems
today are rarely in the frontline, so all those security fixes related
to applets and other web does not impact the majority of VMS systems.

I'm working with OpenVMS systems that are front-line. That are
exposed. That are also having "fun" with audits and with the
gremlins, too.

Post by Arne Vajhøj
But all that said, then it is part of being a serious player in server
OS to get patches out fast.

It's all part of being a competitive server product, and particularly
one being marketed around its security.

[Craig A. Berry]

Post by Stephen Hoffman

Post by Arne Vajhøj
There are two sides of this.
I can completely follow you regarding focusing on the positive here
(Java 8 becoming available) over some minor issue (u51 vs u121).

That also goes to product fit and finish.
Much like testing and the user interface and the documentation, to the
thought that was given to the product or package.

Sigh. And to the degree it plays nice with the rest of the ecosystem.
The JAVA$80_SETUP.COM procedure defines the following in the process
logical name table:

"DECC$ARGV_PARSE_STYLE" = "enable"
"DECC$EFS_CASE_PRESERVE" = "enable"
"DECC$EFS_CHARSET" = "enable"
"DECC$FD_LOCKING" = "true"
"DECC$READDIR_DROPDOTNOTYPE" = "enable"

With the exception of DECC$ARGV_PARSE_STYLE, which has to be defined
before image activation to have any effect, those should all be done in
a LIB$INITIALIZE psect so they won't bother any other software with
different requirements.

[David Froble]

Post by Craig A. Berry

Post by Stephen Hoffman

Post by Arne Vajhøj
There are two sides of this.
I can completely follow you regarding focusing on the positive here
(Java 8 becoming available) over some minor issue (u51 vs u121).

That also goes to product fit and finish.
Much like testing and the user interface and the documentation, to the
thought that was given to the product or package.

Sigh. And to the degree it plays nice with the rest of the ecosystem.
The JAVA$80_SETUP.COM procedure defines the following in the process
"DECC$ARGV_PARSE_STYLE" = "enable"
"DECC$EFS_CASE_PRESERVE" = "enable"
"DECC$EFS_CHARSET" = "enable"
"DECC$FD_LOCKING" = "true"
"DECC$READDIR_DROPDOTNOTYPE" = "enable"
With the exception of DECC$ARGV_PARSE_STYLE, which has to be defined
before image activation to have any effect, those should all be done in
a LIB$INITIALIZE psect so they won't bother any other software with
different requirements.

"What? You think your computer is for anything other than running our software?"

Must be typical weendoze developers ....

[Steven Schweda]

Post by Craig A. Berry
With the exception of DECC$ARGV_PARSE_STYLE, which has to be defined
before image activation to have any effect, those should all be done in
a LIB$INITIALIZE psect so they won't bother any other software with
different requirements.

DECC$ARGV_PARSE_STYLE can be set in a LIB$INITIALIZE.
It's the only one which needs that much special treatment,
but if you do _it_, then you might as well do the others at
the same time. The Info-ZIP programs do it that way, for
example.

[hb]

Post by Craig A. Berry
Sigh. And to the degree it plays nice with the rest of the ecosystem.
The JAVA$80_SETUP.COM procedure defines the following in the process
"DECC$ARGV_PARSE_STYLE" = "enable"
"DECC$EFS_CASE_PRESERVE" = "enable"
"DECC$EFS_CHARSET" = "enable"
"DECC$FD_LOCKING" = "true"
"DECC$READDIR_DROPDOTNOTYPE" = "enable"

The logical name table is OK, but they should be defined in user mode.
But then you need to do that before any javac, java, jar, ... command.
That's not convenient. The right thing would be to set the CRTL features
at image initialization time (maybe based on a config file, located in a
java directory and/or the login directory; should be easy, no rocket
science).

Post by Craig A. Berry
With the exception of DECC$ARGV_PARSE_STYLE, which has to be defined
before image activation to have any effect, those should all be done in
a LIB$INITIALIZE psect so they won't bother any other software with
different requirements.

The image activator does not evaluate DECC$ARGV_PARSE_STYLE, so the
logical does not have to be defined before image activation. The CRTL
evaluates this. So you have to set the feature before its code runs,
when called from your main program - in case of C, or when called at RTL
initialization time - in case of C++.

[Craig A. Berry]

Post by hb

Post by Craig A. Berry
Sigh. And to the degree it plays nice with the rest of the ecosystem.
The JAVA$80_SETUP.COM procedure defines the following in the process
"DECC$ARGV_PARSE_STYLE" = "enable"
"DECC$EFS_CASE_PRESERVE" = "enable"
"DECC$EFS_CHARSET" = "enable"
"DECC$FD_LOCKING" = "true"
"DECC$READDIR_DROPDOTNOTYPE" = "enable"

The logical name table is OK, but they should be defined in user mode.
But then you need to do that before any javac, java, jar, ... command.
That's not convenient. The right thing would be to set the CRTL features
at image initialization time (maybe based on a config file, located in a
java directory and/or the login directory; should be easy, no rocket
science).

Yes, my feeling exactly.

Post by hb

Post by Craig A. Berry
With the exception of DECC$ARGV_PARSE_STYLE, which has to be defined
before image activation to have any effect, those should all be done in
a LIB$INITIALIZE psect so they won't bother any other software with
different requirements.

The image activator does not evaluate DECC$ARGV_PARSE_STYLE, so the
logical does not have to be defined before image activation. The CRTL
evaluates this. So you have to set the feature before its code runs,
when called from your main program - in case of C, or when called at RTL
initialization time - in case of C++.

Right. I keep forgetting the specific system infernals involved here.
What I meant to say is that setting DECC$ARGV_PARSE_STYLE at image
initialization time doesn't do any good if you have not set extended
parse in the process before image initialization. Setting extended parse
in LIB$INITIALIZE is too late to do any good for the image being
initialized, though it may affect images initialized in subprocesses.

[hb]

Post by Craig A. Berry
Right. I keep forgetting the specific system infernals involved here.
What I meant to say is that setting DECC$ARGV_PARSE_STYLE at image
initialization time doesn't do any good if you have not set extended
parse in the process before image initialization. Setting extended parse
in LIB$INITIALIZE is too late to do any good for the image being
initialized, though it may affect images initialized in subprocesses.

I think you have to set extended parsing before DCL parses the command
line. I don't see anything related to image activation, here.

[Dirk Munk]

Post by Craig A. Berry

Post by Simon Clubley

Post by Dirk Munk

Post by Sue
As promised it is really our deep pleasure to announce the
availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

That is nice of course, but there is a bit of a problem.
It is based on Java 8.051, and that version dates from 2015-07-14.
Since that time there have been 15 updates (8.121 is current) with some
1000 bug fixes.
I don't want to be negative, but how long will it take before the VMS
version is 8.121 (or newer...)?

You are not being negative; this is a very reasonable question to ask.
I don't know if VSI or HP did this port, but the current version needs
to be more recent than this.
I will accept this is an initial release, but the next question is
how long will it be before the current version is released ?
This will give you a good indicator of how long it will be before
the fix for a future critical security problem is available on VMS.
If OTOH, we don't see the current Java 8 version released for VMS
in the next month or two, then the question to be asked is if this
release is a one-off release for VMS or not ?
We have all seen releases of an open source product being released
for VMS and then see that version rapidly become outdated.
VSI/HP needs to be showing they can track the current released versions
of a product and this is a very good test case.

I would like to know how Dirk knows what Java version it's based on. It
$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)

As you know by now, HPE mentioned the 1.8.051 on their website.

But you did bring up an interesting question, why is the VMS version
called 1.8.0.03? It should also have the 1.8.051 version number. These
versions numbers are the same for every platform, I don't see a reason
why they should be different for VMS. It's very confusing for people
acquainted with Java versions.

Post by Craig A. Berry
but VMS ports have seldom been known for rational version numbers that
correspond to the upstream code. I do find the "rc1" in the version
somewhat problematic in that it implies this is a release candidate
rather than a final release.
As far as keeping the release current, one could do that if one were to
hire one or two full-time Java engineers who did nothing but that
year-in, year-out. But I don't expect VSI will have the resources to do
that anytime in the foreseeable future.

[Arne Vajhøj]

Post by Dirk Munk
But you did bring up an interesting question, why is the VMS version
called 1.8.0.03?

Third HP version of 1.8 I guess.

Post by Dirk Munk
It should also have the 1.8.051 version number. These
versions numbers are the same for every platform,

No.

They are the same for all Oracle Java.

They are not the same for IBM Java.

Why should they be the same for HP Java?

Post by Dirk Munk
I don't see a reason
why they should be different for VMS. It's very confusing for people
acquainted with Java versions.

I don't think so.

People acquainted with Java version numbers would not be surprised.

They may be interested in mapping between the vendor and Oracle's
update numbers (if the vendor is basing its implementation on Oracle's).

Arne

[Arne Vajhøj]

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

This is great news.

Something is getting out.

Super cool.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Sue
As promised it is really our deep pleasure to announce the
availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

This is great news.
Something is getting out.
Super cool.

For those that need to catch up with Java from 5 or 6 to 8, then
I have written some overviews of (subjectively selected important)
new features:

http://www.vajhoej.dk/arne/articles/java16.html
http://www.vajhoej.dk/arne/articles/java17.html
http://www.vajhoej.dk/arne/articles/java18.html

Arne

[Joukj]

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0
Sue

Got it working. Works Ok for non-graphical applications. Then I tried
some application that need a graphical interface. These all failed with
the same error:

galop-jj) java -jar geogebra.jar
Exception in thread "main" java.awt.HeadlessException
at
java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:2
08)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at org.geogebra.desktop.d.a(Unknown Source)
at org.geogebra.desktop.GeoGebra.a(Unknown Source)
at org.geogebra.desktop.GeoGebra3D.main(Unknown Source)
galop-jj) sh displ

Device: WSA46: [super]
Node: IP$131.180.116.52
Transport: DECNET
Server: 0
Screen: 0
galop-jj) sh sys/noproc
OpenVMS V8.4 on node GALOP 6-APR-2017 12:33:38.33 Uptime 220 04:08:51


Any ideas?

Jouk

[Robert A. Brooks]

Got it working. Works Ok for non-graphical applications. Then I tried some
galop-jj) java -jar geogebra.jar

[...]

Any ideas?

Try launching with headless=false?

I remember hearing that the default headless setting changed between Java 1.6
and Java 1.8.

In any event, I know that it can be made to work (I'm in general not that
familiar with Java; just passing along what I heard in a meeting).

[Dirk Munk]

Post by Joukj

Post by Sue
As promised it is really our deep pleasure to announce the
availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0
Sue

Got it working. Works Ok for non-graphical applications. Then I tried
some application that need a graphical interface. These all failed with
galop-jj) java -jar geogebra.jar
Exception in thread "main" java.awt.HeadlessException
at
java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:2
08)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at org.geogebra.desktop.d.a(Unknown Source)
at org.geogebra.desktop.GeoGebra.a(Unknown Source)
at org.geogebra.desktop.GeoGebra3D.main(Unknown Source)
galop-jj) sh displ
Device: WSA46: [super]
Node: IP$131.180.116.52
Transport: DECNET
Server: 0
Screen: 0
galop-jj) sh sys/noproc
OpenVMS V8.4 on node GALOP 6-APR-2017 12:33:38.33 Uptime 220 04:08:51
Any ideas?
Jouk

It is trying to find a graphical interface (video card) and can't find one.

[Craig A. Berry]

Post by Joukj
Got it working. Works Ok for non-graphical applications. Then I tried
some application that need a graphical interface. These all failed with
Any ideas?

Maybe read the release notes?[1] Which say:

java.awt.headless system property

The system property java.awt.headless defaults to "true" for this
release of Java™ 8 for OpenVMS. For Java™ applications that use AWT
graphical user interface components, it is necessary to explicitly set
java.awt.headless to false either via the java command line
("-Djava.awt.headless=false") or programmatically.

As a specific example, if you use the Archive Backup System (ABS)
graphical user interface, the start-up script
SYS$COMMON:[MDMS.SYSTEM]MDMS$START_GUI.COM should be modified to include
-Djava.awt.headless=false on the Java command line, as follows:
$ java "-Xmx64M" "-Djava.awt.headless=false" "absview.ABSView"

[1]
<https://www.hpe.com/global/java/documentation/1.8.0/ivms/docs/release_notes.html>

[Joukj]

Post by Craig A. Berry

Post by Joukj
Got it working. Works Ok for non-graphical applications. Then I tried
some application that need a graphical interface. These all failed with
Any ideas?

java.awt.headless system property
The system property java.awt.headless defaults to "true" for this
release of Java™ 8 for OpenVMS. For Java™ applications that use AWT
graphical user interface components, it is necessary to explicitly set
java.awt.headless to false either via the java command line
("-Djava.awt.headless=false") or programmatically.
As a specific example, if you use the Archive Backup System (ABS)
graphical user interface, the start-up script
SYS$COMMON:[MDMS.SYSTEM]MDMS$START_GUI.COM should be modified to include
$ java "-Xmx64M" "-Djava.awt.headless=false" "absview.ABSView"
[1]
<https://www.hpe.com/global/java/documentation/1.8.0/ivms/docs/release_notes.html>

Thanks, that was the solution....

You know this "rule for every days live" :
When all else fails read the instructions

[Craig A. Berry]

Post by Sue
As promised it is really our deep pleasure to announce the availability of JAVA 8 for OpenVMS.
To download please visit
https://www.hpe.com/global/java/download/ivms/1.8.0

One minor nit with the kitting. A non-privileged user running the setup
gets this:

%DCL-E-OPENIN, error opening SYS$SYSROOT:[SYS$STARTUP]java$80_setup.com;
as input
-RMS-E-PRV, insufficient privilege or file protection violation

so someone forgot to put W:RE on it:

$ dir/sec sys$startup:java$80_setup.com

Directory SYS$COMMON:[SYSMGR]

java$80_setup.com;1
[SYSTEM] (RWED,RWED,RE,)

Total of 1 file.