Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add nullability marker annotations #344

Merged
merged 4 commits into from
Jan 11, 2018

Conversation

TheMrMilchmann
Copy link
Collaborator

As previously discussed in Slack, this PR adds JSR-305 like annotations to support null-analysis and to enhance Kotlin interopertability. (See here for more info.)

@Spasi As suggested I did not add @Nullable to most stack allocation methods (the exception being String conversion methods, since they can also be null when the passed CharSequence is null).
I'm open for further suggestions and will implement them ASAP if requested.

@TheMrMilchmann
Copy link
Collaborator Author

I just cloned this branch into a fresh environment and realized that the latest commits seem to be missing some changes. I'll quickly rebase and fix this.

@TheMrMilchmann TheMrMilchmann force-pushed the nullability-markers branch 2 times, most recently from 9e237fe to c49cffa Compare December 5, 2017 13:52
@TheMrMilchmann
Copy link
Collaborator Author

Rebased and updated. Should be good to go now (this time for real)!

@Spasi Spasi force-pushed the nullability-markers branch from 2b947c2 to e1a7372 Compare January 10, 2018 08:51
Copy link
Collaborator Author

@TheMrMilchmann TheMrMilchmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the most part, this is looking good. All I found was one issue and a few nitpicky parts.

I would like to hear your opinions first before I change anything.

@@ -365,6 +367,9 @@ val NativeType.isPointer
val NativeType.isPointerData
get() = this is PointerType && this.mapping !== PointerMapping.OPAQUE_POINTER

val NativeType.isPointerObject
get() = this is PointerType && (this.mapping !== PointerMapping.OPAQUE_POINTER || this is ObjectType)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, currently, does not seem to include JObjectTypes which I think I fixed and is something that was lost at some point. IIRC this was also the reason to make JObjectType a class.

Changing the expression to (this is PointerType && (this.mapping !== PointerMapping.OPAQUE_POINTER || this is ObjectType)) || this is JObjectType should to the trick.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I refactored some aspects of the type system a bit and this was simplified to:

this !is ValueType && (this.mapping !== PointerMapping.OPAQUE_POINTER || this is ObjectType)

The property was also renamed to isReference, which I think is more appropriate.

@@ -531,23 +532,31 @@ public ByteBuffer ASCII(CharSequence text) {
/**
* Encodes the specified text on the stack using ASCII encoding and returns a ByteBuffer that points to the encoded text.
*
* @param text the text to encode. If {@code text} is null, null is returned.
* @param text the text to encode
* @param nullTerminated if true, a null-terminator is included at the end of the encoded text
*/
public ByteBuffer ASCII(CharSequence text, boolean nullTerminated) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the documentation of "text encoding"-methods does not refer to any "allocation"-method we should probably explicitly document what happens if the operation fails here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's nothing special about the encoding methods, they fail in the same way as other stack allocation methods with an OutOfMemoryError("Out of stack space.").

@@ -442,6 +493,19 @@ public static long nmemAlignedAlloc(long alignment, long size) {
return ALLOCATOR.aligned_alloc(alignment, size);
}

public static long nmemAlignedAllocChecked(long alignment, long size) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is missing documentation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

- Added additional nullability information with [JSR-305](https://jcp.org/en/jsr/detail?id=305) annotations.
* Enables null-analysis to be used to improve the code quality of LWJGL applications.
* Improves type-safety for applications using LWJGL in Kotlin
([Read the Kotlin documentation](https://kotlinlang.org/docs/reference/java-interop.html#jsr-305-support) for more info.)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should probably be a dot (.) at the end of the last bullet point.

I'm not quite sure whether I like the current wording. Any objections?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have changed the wording a bit.

@Spasi Spasi force-pushed the nullability-markers branch from e1a7372 to 17976eb Compare January 10, 2018 17:55
@Spasi Spasi force-pushed the nullability-markers branch from 17976eb to 82f02e5 Compare January 11, 2018 22:44
@Spasi Spasi merged commit 737d011 into LWJGL:master Jan 11, 2018
@Spasi
Copy link
Member

Spasi commented Jan 11, 2018

The next snapshot (3.1.6 build 9) will have all the latest updates in bindings, but not the nullability annotations. It will be promoted to stable when it's up. Starting from build 10, the above changes will be available for testing.

Thank you @TheMrMilchmann for the great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants