We did want to force the Template Framework user to specify a type when using dataNames. The motivation here was that someone might think they have a limited universe of types, and that they don't need to specify types because in their universe the types are limited and all sampling/toList code can handle everything from the universe. But what happens once you start mixing these universes? Then you will have to go and fix all cases where the two universes are not compatible, and insert filtering.
So now you have to always specify a type via "subtypeOf", "supertypeOf" or "exactOf".
There could be cases where you are really ok getting EVERYTHING, and opt-in to it explicitly. You are ok if you will later be blamed if you forgot to handle a case.
We can add a "allTypes" to disable the current exception, and proceed with getting dataNames and structuralNames from all types.
Important is that this is well tested, see:
test/hotspot/jtreg/testlibrary_tests/template_framework/tests/TestTemplate.java
So now you have to always specify a type via "subtypeOf", "supertypeOf" or "exactOf".
There could be cases where you are really ok getting EVERYTHING, and opt-in to it explicitly. You are ok if you will later be blamed if you forgot to handle a case.
We can add a "allTypes" to disable the current exception, and proceed with getting dataNames and structuralNames from all types.
Important is that this is well tested, see:
test/hotspot/jtreg/testlibrary_tests/template_framework/tests/TestTemplate.java
- relates to
-
JDK-8344942 Template-Based Testing Framework
-
- Resolved
-