Add support for Booleans

[gselzer]

This PR adds support for Booleans.

This PR is motivated by the desire to support the conversion to/from RAI<BooleanType> in PyImageJ.

[ctrueden]

I presume most of this is just cut-paste-adapted from the other types, so it is likely to work the same. However, there is a question of unit tests: there aren't any. Maybe we should write some quick down-the-middle tests for all the existing types including boolean, just as an extra layer of caution?

[hanslovsky]

Typo, might need to be fixed in wrapped as well. Is this a typo that already exists throughout imglib2-unsafe?

Suggested change

	public long getAddres()
	{
	return wrapped.getAddres();
	}
	public long getAddress()
	{
	return wrapped.getAddress();
	}

[gselzer]

Yeah, I saw that too @hanslovsky, but it's all over the place. Here's another example.

I figured this would be a breaking change to address, so I didn't fix it.

I suppose we could write getAddress and deprecate getAddres 😅

[gselzer]

I presume most of this is just cut-paste-adapted from the other types, so it is likely to work the same. However, there is a question of unit tests: there aren't any. Maybe we should write some quick down-the-middle tests for all the existing types including boolean, just as an extra layer of caution?

@ctrueden what would you want to test? All of this functionality assumes you have an address in memory to operate on. How do we get such an address.

That said, I'd love to test this functionality. I just don't know how.

[gselzer]

Here's another point of discussion: in the short term, we don't actually have a use case for the vast majority of this code. I actually only want the NativeBoolean work right now to solve imglib/imglyb#13.

But we may be able to use the BooleanType work later, as @ctrueden outlines in his comment

[ctrueden]

@gselzer To allocate a block of memory, I believe you can use the long allocateMemory(long bytes) function of com.sun.Unsafe, which IIUC is the equivalent of C's malloc. You will need to call freeMemory (the equivalent of C's free) after you are done with it, because the memory is not on the Java heap and will therefore not be garbage collected automatically.

Alternately, there is probably a way to use ByteBuffer.allocateDirect to make a ByteBuffer object and then obtain the memory address of that ByteBuffer.

[gselzer]

@ctrueden please let me know what you think of these tests

[gselzer]

So @ctrueden I'm actually going to remove most of the code out of this PR. We have no use for any of this Boolean work right now, and I don't think that BooleanType implementations can align with the LongAccess API

I'd want to support some type of BoolLongAccessType, with a BoolLongAccessTypeBoolTypeConverter (or the same thing but for BitTypes), but there are problems for both BoolType and BitType:

• BoolTypes cannot be created from any type of Access, be it BooleanAccess, LongAccess, etc., meaning that while we can make a BooleanAccess from our BooleanLongAccessType, we cannot make a BoolType that wraps the BooleanLongAccessType.
• BitTypes can only be made from a LongAccess, which means we'd need to write a LongLongAccessTypeBitTypeConverter. But this then gets super confusing dimension-wise and would probably not work well.

For these reasons, I want to basically only keep the NaiveBoolean work. I put the other work on a different branch.

[gselzer]

One thing I'd like to draw attention to is the naming of NativeBooleanUnsafe, OwningNativeBooleanUnsafe, etc. This contrasts with ImgLib2's NativeBoolType.

I named these new classes as such since there is no definite connection between NativeBooleanUnsafe and NativeBoolType, although they interpret bits the same way.

But, this leads to a bit of confusion. For example, we can make an ArrayImg<NativeBoolType, OwningNativeBooleanUnsafe>, which sounds weird as the first type parameter is missing the ean.

So: should we name these consistently, or would that make too strong of a connection between these objects?

[ctrueden]

@gselzer Thank you very much for your work on this PR! It is mostly fabulous. 🎇 My only concern is the naming of the Unsafe-backed boolean access, which I argue should be named BooleanUnsafe, not NativeBooleanUnsafe.

@gselzer If you agree, you can either push a commit renaming it, or else just give me a thumbs up and I will do it myself, before merging.