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.

SAP Secondary Oracle DB Connection–EasyConnect

When you run an SAP system on a non-Oracle database platform, you may sometimes need to connect to a secondary Oracle database (for example, in a SAP BW environment you could need a connection to multiple source database systems).

The process that is usually followed, is to create the TNSNAMES.ora in the appropriate location on *every* SAP application server of the SAP system.  Then put the TNS service name and username/password into the DBCO transaction within SAP.

There are a couple of downsides to this approach:

1, You generally have to put the TNSNAMES.ora file in /sapmnt/<SID>  as this is already shared across the SAP system’s application servers.

2, You have to keep the TNSNAMES.ora file updated.  Any changes require a complete restart of the SAP system in order for the file to be re-read.

This is where the Easy Connect string can be used.
Instead of entering the TNS service name into the DBCO transaction, you simply enter all the service details, removing the need for the TNSNAMES.ora file.

An example of the Easy Connect string is:

“servervname.com:1521/tns-service-name”

We are supposing that:

– “tns-service-name” is the TNS service name for your target database (listened for on the target Oracle listener)
– Port 1521 (default port) is used by the listener.
– The server on which the listener is located is servername.com.

You must include the double quotes in the DBCO entry.

Based on the above entry, you can then dynamically change the value as and when needed.
No need for a restart of the SAP application server.

Reference: SAP note: 808505 – Secondary connections to Oracle database

HowTo: Using DBMS_STATS to Restore Stats

Scenario: You’re about to implement some major changes to the Oracle database that will adjust the database statistics.
Oracle provide the DBMS_STATS package to help administer stats.  The package includes some procedures that can be used to export/import stats, plus restore them to a previous point in time.

When statistics are updated using DBMS_STATS.GATHER_*_STATS, it saves the previous version in the database (can be changed with DBMS_STATS.ALTER_STATS_HISTORY_RETENTION procedure).  Also, see table DBA_TAB_STATS_HISTORY.

These versions are retained for a specific retention period, which you can check using the GET_STATS_HISTORY_RETENTION procedure:

SQL> set serveroutput on
SQL> DECLARE
v number;
BEGIN
v := DBMS_STATS.GET_STATS_HISTORY_RETENTION;
DBMS_OUTPUT.PUT_LINE(‘Stats history retention: ‘ || v || ‘ days.’);
END;
/

Stats history retention x days.

PL/SQL procedure successfully completed.

You can also check the date of the oldest stats history:

SQL> set serveroutput on
SQL> DECLARE
v timestamp;
BEGIN
v := DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY;
DBMS_OUTPUT.PUT_LINE(‘Oldest stats history: ‘ || v);
END;
/

Oldest stats history: 15-DEC-13 11.29.32.143688 PM

PL/SQL procedure successfully completed

To restore the statistics you can use one of the relevant procedures:

DBMS_STATS.RESTORE_DICTIONARY_STATS
DBMS_STATS.RESTORE_FIXED_OBJECT_STATS
DBMS_STATS.RESTORE_SCHEMA_STATS
DBMS_STATS.RESTORE_SYSTEM_STATS
DBMS_STATS.RESTORE_TABLE_STATS

See here for parameters:
https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/d_stats.htm#insertedID2
As an example, the RESTORE_SCHEMA_STATS procedure takes the following parameters:

ownname   Schema owner,
timestamp   Timestamp,
force   TRUE|FALSE   Restore even if stats are locked, default TRUE,
no_invalidate   TRUE|FALSE   Invalidate cursors, default get_param(‘NO_INVALIDATE’).

If the stats are restored to a specific timestamp, it means that whatever statistics values were applicable to a specific table at a specific point in time, are applied to the tables.  If the table’s statistics are not changed then there will be gaps in the history.
You can imagine this being like a roll-forward through the DBA_TAB_STATS_HISTORY table, until the timestamp specified.

WARNING: If the table’s statistics are not changed then there will be gaps in the history.  In which case, you may not be able to restore previous statistics if the table stats have not changed within the last history window (default 31 days).

Some great examples are here: https://www.morganslibrary.org/reference/pkgs/dbms_stats.html

You should also note, that under an SAP system, the Oracle stats gatherer is called by BR*Connect, and note that it calls the GATHER_TABLE_STATS procedure for each table that is mentioned in table DBSTATC for tables that have stats enabled in DBSTATC.
If the table is not enabled to collect stats, then it may have stats delivered by SAP (see SAP note 1020260), in which case, there may not be any history.

Also see my blog post on SAP statistics and DBSTATC.