A DESCRIPTION OF THE REQUEST :
The following applies to Java Standard Edition, version 8 and 9.

The advantages of BigDecimal, particularly and BigInteger is that the extend of precision is only limited to a MathContext object, which in turn is only limited, almost entirely, to the extent of the String.  For addition, subtraction, multiplication, division and modulus (remainder), users can work any applicable BigDecimal upon any other.

However, function support inside the Oracle default classes for BigDecimal in particular doesn't really exist.  If I want to calculate sine, cosine, tangent, arcsine, arcos and arctangent on a BigDecimal curtailed by its MathContext, public domain, efficient and more robust libraries are highly difficult to find.

Inside the Oracle standard classes, there is no way to raise a BigDecimal to the power of another BigDecimal, which would exponentiate as well as provide a means to the nth root of a BigDecimal.  There is no square root for BigDecimals inside Oracle.  

While trigonometry might be done from radians or degrees, there needs to be a way to calculate pi via a MathContext, for as many digits, in theory, as a trigonometry input argument could be long, or within simple time requirements.  Radian trigonometry, via pi/180 conversion from degrees, can be subjet to pi in this way.

Similar applies to Euler's constant e, and exponentiation to e methods.

JUSTIFICATION :
Since it is highly difficult to obtain a professional robust library for infinite (aritrary) position arithmetic for BigDecimal as well as BigInteger; simply put, numbers and their uses in java that are as large as memory and speed permit, that are theoretically, always more larger, at least.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
An inclusion of a StrictMath class version that will work using the variability possible with BigDecimal, and BigInteger, for forward and inverse trigonometry, powers, the square root, exponentiation of e, and calculator methods for pi and e.
ACTUAL -
A total absence of implementation, forcing reliance on other libraries.  At the moment, only basic operations and modulus are robustly supported upon BigDecimal and BigInteger, pretty well for numbers as long as a java String may be.

CUSTOMER SUBMITTED WORKAROUND :
Other public domain libraries conclude by having stipulated minimum and maximum aritrary number sizes.

In theory, you can always add one BigDecimal another one, speed and memory permitting.  Similarly does apply to BigInteger.

People simply can't  find an appropriate way to continue all this accomplishment for BigDecimal, and BigInteger, parallel to the capability of java.lang.StrictMath