bdv.util.volatiles.VolatileViews.wrapAsVolatile no longer accepts bdv.util.volatiles.SharedQueue
Closed this issue ยท 5 comments
This change in VolatileViews removed rather than deprecated several function signatures:
01fe2d2#diff-8d96319df0d38532431233b4eb8e3df42a91b4fc2a8e428d602af6814c230543R55
For example, bdv.util.volatiles.VolatileViews.wrapAsVolatile
no longer accepts bdv.util.volatiles.SharedQueue
as a the second argument. It now only accepts bdv.cache.SharedQueue
.
Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: bdv.util.volatiles.VolatileViews.wrapAsVolatile(Lnet/imglib2/RandomAccessibleInterval;Lbdv/util/volatiles/SharedQueue;Lnet/imglib2/cache/volatiles/CacheHints;)Lnet/imglib2/RandomAccessibleInterval;
at org.janelia.saalfeldlab.n5.bdv.N5VolatileSource.getSource(N5VolatileSource.java:59)
at org.janelia.saalfeldlab.n5.bdv.N5Viewer.addSourceToListsRealType(N5Viewer.java:388)
at org.janelia.saalfeldlab.n5.bdv.N5Viewer.addSourceToListsGenericType(N5Viewer.java:356)
at org.janelia.saalfeldlab.n5.bdv.N5Viewer.buildN5Sources(N5Viewer.java:298)
at org.janelia.saalfeldlab.n5.bdv.N5Viewer.exec(N5Viewer.java:182)
at org.janelia.saalfeldlab.n5.bdv.N5Viewer.lambda$run$2(N5Viewer.java:138)
at org.janelia.saalfeldlab.n5.ui.DatasetSelectorDialog.ok(DatasetSelectorDialog.java:718)
at org.janelia.saalfeldlab.n5.ui.DatasetSelectorDialog.lambda$run$5(DatasetSelectorDialog.java:314)
Perhaps a deprecated form of bdv.util.volatiles.VolatileViews.wrapAsVolatile
could be re-added that accepts the deprecated bdv.util.volatiles.SharedQueue
The fix for downstream dependencies is to replace import bdv.util.volatiles.SharedQueue
with import bdv.cache.SharedQueue
.
Argh... I let bdv.util.volatiles.SharedQueue extends bdv.cache.SharedQueue
to avoid this problem. But, of course, ... binary compatibility... At least it should be fixable by rebuilding.
Changing to the non-deprecated SharedQueue
is better, of course. Thanks Mark!
Can I just push to the update site
Yes, go ahead and upload it straight to Java-8. Unfortunately, due to other priorities, it will probably be another year before we can establish anything more formal. The good news is that deploying hot-fixes with the current scheme is super fast and easy.
What I do hope to get in place very soon is melting-pot CI testing, in response to changes to pom-scijava on the main branch. That will catch problems, but of course doesn't stop people from upload changes to Java-8 before they make their way into pom-scijava (which is backwards from how it ultimately should work).
Ok, I pushed it.