RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Fri Mar 21 15:49:01 UTC 2014
Chris,
Thanks for the feedback.
What do you think about the following:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/
Best regards,
Vladimir Ivanov
On 3/19/14 5:18 AM, Christian Thalinger wrote:
>
> On Mar 18, 2014, at 2:35 PM, John Rose <john.r.rose at oracle.com
> <mailto:john.r.rose at oracle.com>> wrote:
>
>> On Mar 18, 2014, at 1:36 PM, Christian Thalinger
>> <christian.thalinger at oracle.com
>> <mailto:christian.thalinger at oracle.com>> wrote:
>>
>>> Why are we not using an Enum instead of an "untyped" byte?
>>
>> Byte is moderately typed, in the sense (which I rely on during
>> development) that you can't assign an int or char to a byte w/o a cast.
>> That's why it is not just a plain int.
>>
>> But those values (L_TYPE etc.) are used a lot as numbers, and
>> specifically as low-level array indexes, and also comparisons (x <
>> V_TYPE).
>>
>> To turn them into enums, we'd have to add lots of calls to
>> '.ordinal()' to turn them right back to numbers. That dilutes
>> (completely IMO) the value they have as enums to raise the level of
>> the code.
>
> But without being strongly typed we get bugs like this one:
>
> @Override
> - MethodHandle bindArgument(int pos, char basicType, Object value) {
> + MethodHandle bindArgument(int pos, byte basicType, Object value) {
> // If the member needs dispatching, do so.
> if (pos == 0 && basicType == 'L') {
>
> I’m just saying that for the sake of maintainability and correctness an
> Enum would be better.
>
>>
>> — John
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
More information about the mlvm-dev
mailing list