Conversation
lbergelson
left a comment
There was a problem hiding this comment.
A few little issues.
I recommend we change from returning bundle Collection to bundle List. It's rare we actually want an unsorted bag of file names.
| private static final long serialVersionUID = 1L; | ||
|
|
||
| private final Map<String, BundleResource> resources = new LinkedHashMap<>(); | ||
| // don't use LinkedHashMap here; using HashMap resolves unnatural resource ordering issues that arise |
There was a problem hiding this comment.
I'm not sure I follow what's going on here when you have a LinkedHashMap. Shouldn't serializing a linked hashmap deserialize it to the same map?
There was a problem hiding this comment.
Hm. I was having problems when roundtripping these through JSON, but I can no longer reproduce the issue, so reverting to our beloved LinkedHashMap.
There was a problem hiding this comment.
So I realized what the issue was here. JSONObject internally uses a HashMap (implying, I think, that JSON doesn't preserve the serialized order of JSON attributes), so when you roundtrip through JSON, the iteration order from JSON is based on the HashMap order. If we use LinkedHashMap in Bundle, then the order after a roundtrip gets scrambled, and tests fail (but only for some cases because sometimes the roundtrip order matches and sometimes it differs).
There was a problem hiding this comment.
Ahah, that makes sense. Seems like a weird decision to not maintain internal order, but it's good to know about. Cana we change our tests to use an order independent comparison?
There was a problem hiding this comment.
I added an resource-order-independent equals method for use in the tests.
|
|
||
| final private static Set<String> TOP_LEVEL_PROPERTIES = Collections.unmodifiableSet( | ||
| new HashSet<String>() { | ||
| new HashSet<>() { |
There was a problem hiding this comment.
Can these static declarations be migrated to use Set.of() instead of these anonymous classes?
There was a problem hiding this comment.
Oh yeah, thats an improvement. Done.
| final Collection<Bundle> bundles = toBundleCollection(jsonString, ioPathConstructor); | ||
| if (bundles.size() > 1) { | ||
| throw new IllegalArgumentException( | ||
| String.format("A JSON string with more than one bundle was provided but only a single Bundle is allowed", |
There was a problem hiding this comment.
The format string is missing the template variables.
| e); | ||
| } | ||
| } | ||
| if (bundles.size() < 1) { |
There was a problem hiding this comment.
Nitpicky but I isEmpty might be better
| final String primaryContentType = getRequiredPropertyAsString(jsonObject, JSON_PROPERTY_PRIMARY); | ||
| final Collection<BundleResource> bundleResources = toBundleResources(jsonObject, ioPathConstructor); | ||
| if (bundleResources.isEmpty()) { | ||
| LOG.warn("Empty resource bundle found in: ", jsonObject.toString()); |
There was a problem hiding this comment.
Should we allow empty bundles at all?
There was a problem hiding this comment.
Actually, we already don't. I'll remove this (the Bundle constructor will throw anyway), and add a negative test to BundleTest to demonstrate that.
| return new IOPathResource( | ||
| ioPathConstructor.apply(getRequiredPropertyAsString(jsonObject, JSON_PROPERTY_PATH)), | ||
| contentType, | ||
| format == null ? null : format); |
There was a problem hiding this comment.
I think this ternary is unnecessary since you're not dereferencing format here.
| "}\n", | ||
| BundleResourceType.ALIGNED_READS, | ||
| Arrays.asList(BundleResourceTestData.readsWithFormat) | ||
| """ |
| public static final String JSON_PROPERTY_FORMAT = "format"; | ||
|
|
||
| public static final String JSON_SCHEMA_NAME = "htsbundle"; | ||
| public static final String JSON_SCHEMA_VERSION = "0.1.0"; // TODO: bump this to 1.0.0 |
There was a problem hiding this comment.
Will update the schema in a separate PR when I move the bundle classes out of the beta package.
| * @return Collection<Bundle> | ||
| * @param <T> IOPath-derived class to use for IOPathResources | ||
| */ | ||
| public static <T extends IOPath> Collection<Bundle> toBundleCollection( |
There was a problem hiding this comment.
Do we really want this to be Collection and not something with an order? I would think List might be better? The input order is usually important in some way, changing the encounter order can often change either errors generated or floating point aggregations even if it's something that seems like it should be file order agnostic.
There was a problem hiding this comment.
Changed to Lists.
437912b to
1be2b85
Compare
1be2b85 to
8b0e589
Compare
bf33fee to
79ba8d9
Compare
|
@lbergelson I updated the names and organization of the bundle content type strings in this, which is why there are now so many changes. |
lbergelson
left a comment
There was a problem hiding this comment.
@cmnbroad Looks good to me. I'm not 100% sure why you want to decouple the content type names from the enums but that seems fine.
Also contains some commits with minor updates to take advantage of Java 17 and Java text blocks.