This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Java 8 SE – I Just Removed It

Remove Java 8 SE

I have just removed Java 8 SE from my computer.
I wrote a blog post a while back about how Oracle was changing the way it licenses the Java virtual machine 8 Standard Edition (SE).
You can read it here: SAP JVM and the Oracle Java SE 8 Licensing Confusion

At the time of the post, it was not very clear how the license changes were going to impact the use of the Java 8 SE virtual machine.

What’s Changed?

Briefly, at the end of January 2019, Oracle have essentially now stopped free updates to the Java 8 SE for non-personal customers.
This means that you as a personal user can continue to update Java 8 SE, but as a corporate user you may only apply updates to Java 8 SE if you have purchased a subscription to receive the updates.

I’m a Corporate User

If you are a corporate user of the Oracle 8 SE, unless you have a subscription, you can no longer update Java 8 SE.
If you wish to remain secure and remove security risks from your computers, you should de-install it if you do not want to purchase a subscription from Oracle.
If you do not uninstall Java 8 SE, but continue to update it, and you are audited by Oracle, then you may need to pay for a subscription.

Can Oracle Audit Me?

The Java 8 SE auto-update application now displays a prompt on machines that have the auto-update enabled and that have an internet connection.
If you choose to “Install” (you already have it installed) then at that point Oracle deem that you have accepted the license agreement and they can audit your company for the use of Oracle products.

How Do I Remove Java 8 SE?

For me it was easy.
My Java 8 SE installation has the auto-update function enabled, so it simply told me the license terms had changed and offered me the button to simply remove it. So I did.

You may need to uninstall it from within the Windows program uninstallation tool within Windows Control Panel.
Your IT teams may have already started the removal process automatically.

What If I Need an Up-to-date Java 8 VM?

If you need a Java 8 JVM, you can move to an open source version of Java, such as OpenJDK, or a number of others.

For SAP customers wanting to run their SAP tools, you can actually use the SAPJVM for use with your SAP tools such as SAP Software Download Manager, SAP HANA Studio, SAP ABAP tools on Eclipse and other Java based tools.

How Do I Download SAPJVM?

Downloading the SAPJVM is simple.
Take a look at SAP note 1442124 “How to download a SAP JVM patch from the SMP”.


References:

https://www.it-implementor.co.uk/2019/01/sap-jvm-and-oracle-java-se-8-licensing.html
https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support
upperedge.com/oracle/top-3-reasons-oracle-java-users-are-unknowingly-out-of-compliance/
www.oracle.com/downloads/licenses/binary-code-license.html www.oracle.com/downloads/licenses/javase-license1.html www.oracle.com/technetwork/java/javase/terms/oaa.html

SAP Netweaver AS Java 7.50 End of Maintenance

If you’re a green-field or brown-field SAP customer and you will be deploying on-premise, you may well have a capability requirement to deploy Adobe Document Services for your SAP estate.
This is usually the case if you will be creating professional PDF documents, for example, for invoicing or payslips.

If you do have this requirement, then you need to be aware of the up & coming end of mainstream maintenance for SAP Netweaver AS Java 7.50.
You see, normally, the end of mainstream maintenance of SAP Netweaver based products is no big deal, you can always pay the extra cost for an extension to your maintenance agreement.  This is quite nicely titled “Extended Maintenance”.  Neat.
However, like the sub-title to a never ending action movie trilogy, “this time it’s different.”
SAP have definitively stated in SAP note 1648480 that there will be no extended maintenance for Netweaver AS Java 7.50!

Application Server Java within SAP NetWeaver 7.50 will be supported in mainstream maintenance to end of 2024. Extended maintenance will not be offered.

The SAP product availability matrix (PAM) and also SAP note 1648480 both state that Netweaver AS Java 7.50 is supported until 31 December 2024.
But why is this different to SAP Netweaver AS ABAP you may be asking?
It comes down to the third-party technology within the Java stack and the mismatch of available support cycles from the third-party vendors in accordance with SAP’s support cycles.
This is noted in the SAP note previously mentioned.

Although there is no detail in the SAP note, it does make sense if you know that SAP take updates for the SAP JVM from Oracle (the custodians of Java).
As we know from my previous article, the Oracle JVM 8 is being sunset, which could be causing a bit of a headache (cost) for SAP since the Oracle JVM 8 technology is incorporated into SAP JVM 8.
The SAP JVM 8 is the underpinning of Netweaver AS Java 7.50.
Coincidence?  Maybe.  But also remember from my article that Oracle are very kindly providing a paid-for subscription service for updates to JVM 8.
I guess SAP will be one of those customers.

So what are your options now you’re aware of the NW AS Java 7.50 end of maintenance?
There are currently no options available for deploying Adobe Document Services within an SAP Netweaver AS Java instance!
But, there is the possibility that you can use the new SAP Cloud Platform Forms by Adobe SaaS offering from SAP.
Quite simply, you pay per PDF.

In the short-term you may well decide to stick to the tried and tested method of deploying ADS in NW AS Java 7.50.
Just consider the overheads that this may induce and compare it to the SaaS option “SAP Cloud Platform Forms by Adobe”.

Examples of overheads:

– How many ADS instances you run: maybe 2x PRD (with HA/DR), 2x Pre-PRD (with HA/DR), 1x TST, 1x DEV, 1x SBX  ??
– Cost of SAP Netweaver licenses for each of those.
– Cost of any SSL licenses.
– Cost of operating system support.
– Cost of hardware & maintenance to run those.
– Cost of backups (admin & actual storage costs) to run those.
– Cost of HA/DR setup (cluster & replication maybe).
– Overhead of the risk assoiated with unplanned maintenance / outages (meltdown/spectre anyone?)
– Overhead of admin & regular security patching (we’re all doing the SAP super Tuesday patching – right).
– Overhead of yearly DR tests.
– Overhead of yearly backup & restore tests (are you even doing these?).
– Overhead of yearly PEN tests (if on the same subnet as your credit card transactional processing systems).
– Current rough uptime/SLAs.

SAP JVM and the Oracle Java SE 8 Licensing Confusion

What is the issue for users of Oracle Java SE 8 ?
In January 2018, Oracle released a statement that it was extending the end-of-life for Oracle Java SE 8 updates to “at least” January 2019.
With no official update for another extension, we have to assume that we are reaching that cut-off point.
See the Oracle statement in full here: https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support

What does this statement mean for Oracle Java SE 8 end-consumers?
For consumers of Java programs who wish to execute those programs using the Oracle SE JVM 8, there is no issue.
You can continue to do so, still for free, at your own risk.  Oracle always recommends you maintain a recent version of the JVM for executing Java programs.

What does this statement mean for corporate consumers?
For corporate consumers, the same applies as to public consumers.
If you are simply executing Java programs, you can continue to do so, for free, at your own risk.
However, if you use the Oracle Java SE 8 to compile Java bytecode (you use the javac program), *and* you wish to receive maintenance updates from Oracle, you will need to pay for a license from Oracle (a subscription if you like).
If you don’t want to pay, then you will not be eligible to receive Oracle Java SE 8 updates past January 2019.
Are there any other options, yes, if you are an SAP customer, you have the option to use the SAP JVM.

If you are not an SAP customer, there are alternative distributions of Java available from third-party projects such as OpenJDK.
More information can be seen here: https://www.azul.com/eliminating-java-update-confusion

What does all of this mean for consumers of the SAP JVM?
In short, there is no real license implication, since the SAP JVM is an entirely separate implementation of Java since 2011 when SAP created it’s own SAP JVM 4.  See SAP notes 1495160 & 1920326 for more details.
You will notice that in the SAP notes for SAP JVM, SAP indicate the base Oracle Java patches which have been integrated into the SAP JVM version (see SAP note 2463197 for an example).

The current SAP JVM 8.1 still receives updates, as usual, however, SAP also recommend that you look to move to the latest *supported* version of the SAP JVM for your SAP products.
For those who didn’t know, you should be patching the SAP JVM along with your usual SAP patching and maintenance activities.
See here for a Netweaver stack compatibility overview: https://wiki.scn.sap.com/wiki/display/ASJAVA/SAP+JVM+Netweaver+compatibility+and+Installation

SAP are constantly applying SAP JVM fixes and enhancements.  A lot of time these are minor “low” priority issues and timezone changes.
To see what fixes are available for your SAP JVM version, you can search for “SAP JVM” in the SAP Software Download Centre, or alternatively look for SAP notes for component BC-JVM with the title contents containing the words “SAP JVM patch collection”.  Example: “2463197 – SAP JVM 8.1 Patch Collection 30 (build 8.1.030).”

There are different methods to apply a SAP JVM update depending on the SAP product you have.  Some are simply deployed with SAPCAR, some with SUM and some with “unzip”.  Check for SAP notes for your respective SAP product.

As with any software there are sometimes security issues for the SAP JVM.
SAP will issue security notes and include the CVSS score (see 1561103 as an example).  These notes should be viewed as critically as you view all SAP security notes and included as part of your “super Tuesday” patching sessions.

Java VM 5.0 Default Heap Size

If you have Java 5.0 (1.5), you may wish to know the default heap size for a JVM.
If you don’t specify -Xmx or -Xms to control the heap size, then the defaults are used.

They are described in detail in the strangely title “Ergonomics in the 5.0 Java Virtual Machine” page here: https://www.oracle.com/technetwork/java/ergo5-140223.html

The page states:
In the J2SE platform version 5.0 a class of machine referred to as a server-class machine has been defined as a machine with
2 or more physical processors
2 or more Gbytes of physical memory

On server-class machines by default the following are selected.
Throughput garbage collector
Heap sizes
initial heap size of 1/64 of physical memory up to 1Gbyte
maximum heap size of ¼ of physical memory up to 1Gbyte
Server runtime compiler

So if you have a “server class” machine, you could expect your Java 5.0 JVM to utilise a maximum of 1GB of heap with no tuning (-Xmx & -Xms).

Although it’s not very clear, it seems that a non-“server class” machine would allocate the same as a Java 1.4.2 virtual machine:

In the J2SE platform version 1.4.2 by default the following selections were made
Serial garbage collector
Heap sizes
initial heap size of 4 Mbyte
maximum heap size of 64 Mbyte
Client runtime compiler

Therefore, a maximum of 64MB of heap would be utilised.

I don’t know if a single dual core CPU is recognised as a “server class” machine, but you can find out what your Java version thinks your machine is by running:

> java -help
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)

where options include:
-d32         use a 32-bit data model if available
-d64         use a 64-bit data model if available
-client       to select the "client" VM
-server      to select the "server" VM
-hotspot    is a synonym for the "client" VM [deprecated]
                 The default VM is server,
                 because you are running on a server-class machine
.

-cp <class search path of directo....

As you can see, the output tells you that it thinks you are running on a “server class” machine.

Either way, it’s probably best to use the “-server” command line option to be sure, plus the “-Xmx” option to restrict memory usage if you don’t need a whole 1GB heap.