Discussions
Categories
- 385.5K All Categories
- 5.1K Data
- 2.5K Big Data Appliance
- 2.5K Data Science
- 453.4K Databases
- 223.2K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 47 Multilingual Engine
- 606 MySQL Community Space
- 486 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.2K ORDS, SODA & JSON in the Database
- 585 SQLcl
- 4K SQL Developer Data Modeler
- 188K SQL & PL/SQL
- 21.5K SQL Developer
- 46 Data Integration
- 46 GoldenGate
- 298.4K Development
- 4 Application Development
- 20 Developer Projects
- 166 Programming Languages
- 295K Development Tools
- 150 DevOps
- 3.1K QA/Testing
- 646.7K Java
- 37 Java Learning Subscription
- 37.1K Database Connectivity
- 201 Java Community Process
- 108 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.4K Java EE (Java Enterprise Edition)
- 22 Java Essentials
- 176 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 208 Java User Groups
- 25 JavaScript - Nashorn
- Programs
- 667 LiveLabs
- 41 Workshops
- 10.3K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 6K Other Languages
- 2.3K Chinese
- 207 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 474 Portuguese
Big Issue with float, double, Java Floating Point.

I have found that double and float types in java are heirs to arithmetic underflow and overflow at any use.
I have found that presently, floating point is an arithmetic approximation. My problem is that
the java language needs to be changed here, so that one may have arithmetic accuracy with
floats and doubles.
There is also a trigonometric shortfall when it comes to BigDecimal.
I have attempted to, and have more carefully described these problems, via the java bugs database:
JDK-8190947
JDK-8197995
JDK-8190991
JDK-8190946
-These types, as things are, must be computationally discarded, used only in terms of push and pull,
and be programmed around using BigDecimal, which will be a waste of memory,
program execution speed, and a total confusion due to the lack of any operator
usage options on BigDecimals.
-It is the case that set, get methods, constructors and mutability methods are all based
around float and double, not BigDecimal, which is part of the previous problem.
-It is the case that setting up BigDecimals can be and is a circumstantial waste of memory
with very many tasks, combined with the fact that the fact that having to use BigDecimal
method calls is nowhere near as efficient or legible to developers or mathematics and enginner
programmers (and useful with their time) as
+, -, *, /, %, +=,-+,*=,/=,%=, ++, --
.This is a syntax argument largely, but also an instruction argument
since BigDecimals have to be set up or used with an extra, thereby second, call.
-It is the case that every other major language includes both floating point and accuracy mode
options with these two types and or Objects, either as a source code instruction or as a
compiler switch option. These languages at least provide both options for floating
point and mathematical accuracy mode.
-It is so that the present arithmetic underflow and underflow are total disadvantages,
that need only be altered in place, for preconditions, postconditions and in place.
This is in regard to programs that have been compiled and built already.
-My Oracle Support technical reviews seem not to recognise these real problems in
technical analysis, or only interpret matters in terms of the
Java Language Specification on these issues, which of itself possesses inadequecies in these places.
Can someone please reply to me on these things?
Can Oracle update the Java SE language?
Answers
-
Here, https://bugreport.java.com/ all the information that you need to report a bug.
-
Issue being, i have already done that, with these:
JDK-8190947
JDK-8197995
JDK-8190991
JDK-8190946
Issue also being, I have been shut down via a bunch of assessments which
are exactly engaging to the questions, or, politely, that are circumstantially accurate.
-
You need to discuss these bugs on core-libs over at openjdk.java.net
-
While I also do that, is there anyone involved who can respond usefully, here?
-
This isn't the right place to discuss it unfortunately. The stds body reviews specifications as submitted by OpenJDK and so it is at that project that the conversation needs to take place. Appreciate that's frustrating, but we're effectively downstream from OpenJDK.