DB2 forces BITWISE-OR if ResultSet.TYPE_SCROLL_INSENSITIVE used

I use JDBC to connect to a db2 luw with blu accelaration 11.x db2 luw without blu acceleration has the same issue.

conn.createStatement(
                ResultSet.TYPE_SCROLL_INSENSITIVE,
                ResultSet.CONCUR_READ_ONLY,
                ResultSet.HOLD_CURSORS_OVER_COMMIT)
ResultSet rs = stmt.executeQuery(sql);

A possible query in our application is (simplified) where myNumericColumn is a numeric datatype:

SELECT * FROM myTable WHERE
    myNumericColumn = 123 OR 'ALL' IN (123)

123 can be changed to another value. A prepared string is possible like 'ALL'. In this case the query is like:

SELECT * FROM myTable WHERE
    myNumericColumn = 'ALL' OR 'ALL' IN ('ALL')

The right hand will be true, so the left hand will not be evaluated. If I remove the right hand (or change the condition to evaluate to false) we got a numeric overflow exception (compare numeric with string).

com.ibm.db2.jcc.am.SqlDataException: Overflow occurred during numeric data type conversion.. SQLCODE=-413, SQLSTATE=22003, DRIVER=4.23.42

If I change the createStatement to the following command or remove all ResultSet-attributes (ResultSet.TYPE_FORWARD_ONLY will be used as default) there is no exception.

conn.createStatement(
                ResultSet.TYPE_FORWARD_ONLY,
                ResultSet.CONCUR_READ_ONLY,
                ResultSet.HOLD_CURSORS_OVER_COMMIT)

Why forces the JDBC / JDBC-driver / database to use a bitwise or if I change the type of ResultSet? How can this behaviour be changed?

Thanks and best regards

Solution

The answer is simple: do not do such things.
There is a statement in the predicates description:

All values specified in a predicate must be compatible

There is no any guarantee, if a predicate of a search condition is really evaluated and in which order in some particular case.