RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v5]
Igor Ignatyev
iignatyev at openjdk.java.net
Wed Sep 30 21:21:26 UTC 2020
On Wed, 30 Sep 2020 20:20:08 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:
>>> The other method, `invokeAndCheck` is different. It can call, for example, `String.concat("abc", "def")` and expect the
>>> String "abcdef" as result. It does really need to be generic.
>> although I still don't see them as really being that much different, I'm fine w/ keeping them as-is.
>>
>>
>>> `invokeAndCompareArrays` / `ArrayDiff` compares two huge arrays and present a nice short _slice_ in the difference
>>> area. The short slice is possible because we do a limited task - compare arrays. `invokeAndCheck` , on the other hand,
>>> can have as parameters the `utf16`, a string of 10K symbols. Do we really need a 10K string as output in our log?
>>
>> I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having
>> relative information in the exception is always a good thing. should 10K symbols become a problem (this though would
>> also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this.
>>>
>>> > you don't need `ArrayCodec::of(Object array)` anymore, do you?
>>>
>>> Unfortunately, it is used in the ArrayCodec.format (which is used in TestStringIntrinsics.java) - to make it possible
>>> to call it with everything and not swamp the code with overloads.
>>
>> hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in
>> `ArrayDiff::of`, do you?
>
>> I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having
>> relative information in the exception is always a good thing. should 10K symbols become a problem (this though would
>> also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this.
>
> Ok, I got it. I was blind and stupid, sorry. Fixed, please check the e6fb6d04cad
>
>> hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in
>> `ArrayDiff::of`, do you?
>
> <sigh>... I can see no better solution here. The `ArrayDiff::of` checks that both component types are the same in
> addition, but I probably could have avoided duplicating the switch (we can ignore double guessing the type). The issue
> is that <E> in ArrayDiff is forwarded to first and second, I would need to declare them as generic
> (ArrayCodec<Object>). The type system seem to not allow me to fix that nicely.
> > I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having
> > relative information in the exception is always a good thing. should 10K symbols become a problem (this though would
> > also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this.
>
> Ok, I got it. I was blind and stupid, sorry. Fixed, please check the
> [e6fb6d0](https://github.com/openjdk/jdk/commit/e6fb6d04caddc4b410a594574f570cfcb9445e4a)
I'd use `StringBuilder` to construct the message.
> > hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in
> > `ArrayDiff::of`, do you?
>
> <sigh>... I can see no better solution here. The `ArrayDiff::of` checks that both component types are the same in
> addition, but I probably could have avoided duplicating the switch (we can ignore double guessing the type). The issue
> is that in ArrayDiff is forwarded to first and second, I would need to declare them as generic (ArrayCodec). The type
> system seem to not allow me to fix that nicely.
wouldn't the following patch do?
--git a/test/lib/jdk/test/lib/format/ArrayDiff.java b/test/lib/jdk/test/lib/format/ArrayDiff.java
--- a/test/lib/jdk/test/lib/format/ArrayDiff.java
+++ b/test/lib/jdk/test/lib/format/ArrayDiff.java
@@ -123,41 +123,10 @@ public class ArrayDiff<E> implements Diff {
if (!bothAreArrays || !componentTypesAreSame) {
throw new IllegalArgumentException("Both arguments should be arrays of the same type");
}
-
- var type = first.getClass().getComponentType();
- if (type == byte.class) {
- return new ArrayDiff<>(
- ArrayCodec.of((byte[])first),
- ArrayCodec.of((byte[])second),
- width, contextBefore);
- } else if (type == int.class) {
- return new ArrayDiff<>(
- ArrayCodec.of((int[])first),
- ArrayCodec.of((int[])second),
- width, contextBefore);
- } else if (type == long.class) {
- return new ArrayDiff<>(
- ArrayCodec.of((long[])first),
- ArrayCodec.of((long[])second),
- width, contextBefore);
- } else if (type == char.class) {
- return new ArrayDiff<>(
- ArrayCodec.of((char[])first),
- ArrayCodec.of((char[])second),
- width, contextBefore);
- } else if (type == String.class) {
- return new ArrayDiff<>(
- ArrayCodec.of((String[])first),
- ArrayCodec.of((String[])second),
- width, contextBefore);
- } else if (!type.isPrimitive() && !type.isArray()) {
- return new ArrayDiff<>(
- ArrayCodec.of((Object[])first),
- ArrayCodec.of((Object[])second),
- width, contextBefore);
- }
-
- throw new IllegalArgumentException("Unsupported array component type: " + type);
+ return new ArrayDiff(
+ ArrayCodec.of(first),
+ ArrayCodec.of(second),
+ width, contextBefore);
}
/**
-------------
PR: https://git.openjdk.java.net/jdk/pull/112
More information about the core-libs-dev
mailing list