Oracle recently started publicly laying out a plan for versions of Java the language from versions 9 on. One of the proposals for Java 9+ was to have a unified type system, which fundamentally means that everything would be an object (in the java.lang.Object sense). In simpler terms, this means the end of primitives. It is less clear what this means for arrays (in the java.util.Array sense), at least to me. Arrays are technically Objects, but they have special byte code instructions, similar to primitives and they have some other subtleties that separate them from Objects. They do not work particularly well with generics for example.
This proposal is put forth to address specific criticisms of removing primitive types from Java the language, in the hopes that the Java platform and language can continue to be used as a "systems" programming environment.
I am proposing a numeric tower with user defined integer numeric types. A user defined integer numeric type would provide the following information:
- How many bytes? (must be >= 1)
- What happens on under/overflow?
- Roll around
- Throw exception
- Auto promote
- Is the type signed or unsigned?
- What type to auto-promote to if it is an auto-promoted type
Additional constraints could be put on integer numeric types, such as providing a valid range, but this proposal does not call for such things in order to keep the implementation as simple as possible.
- No byte code instructions need to be added or removed.
- Existing byte could still run.
- Existing Java classes could still compile.
- It is one step in achieving the simplified unified type system.
- Ability for users to define custom numeric types with reasonable performance.
- The compiled byte code could take advantage of primitive instructions and behavior appropriately when underflow/overflows are detected.
- Hotspot should be able to optimize non primitive numeric types and unroll when appropriate.
- Existing math operators (+ - * / %), bit shifting operators (>> >>> <<), numeric comparison operators (< <= > >= == !=), bitwise operators (| & ^ ~), unary operators (++ -- + - ~ !), postfix operators (++ --) and assignment operators (e.g. +=) could compile to method invocations or existing byte code instructions.
- The removal of auto-boxing of primitives.
-
The introduction of classes named java.lang.int, java.lang.long, etc. breaks the long standing Java convention of classes beginning with an upper case letter.
-
What if two users define the same or similar types? What should the behavior be in the following scenarios?
- Equality of two 32 bit signed types?
- Casting up/down/sideways of numeric types?
-
I am an amateur programming language implementor and enthusiast. There are likely complexities involved that have not occurred to me.
- This proposal does not cover float, double, boolean or char primitives.
Imagine that the following class is defined:
java.lang.int of type signed, 32 bit with underflow/overflow.
Existing Java code could compile and (as far as I know) it is not valid to ever have a period following an int in existing Java syntax, method invocations on int instances could be added, without backwards compatibility issues. Additional research would of course need to be done to verify the accuracy of this assertion and to determine if there are any addition concerns not raised here.
Any version of Java 9 or later?
Oracle: Brian Goetz et al.
Well, this is really none of my business. Thanks for reading this far!