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

Adds IEvent interface for Record event support #56

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

danorris709
Copy link

Adds, and migrates all references, to the IEvent interface to allow creating record based events in the future.

I'm not sure if this was the correct way to do this, but I ran the tests against everything I changed, and added one for the Record events because I wasn't sure it'd work with phases, and they passed. I was going to run the performance tests, and see if there was any notable difference for records, but it was giving a 12 hour ETA so I decided against doing that.

Copy link
Contributor

@PaintNinja PaintNinja left a comment

Choose a reason for hiding this comment

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

Thanks for your PR. Did a quick code review on my phone, looks good. Assigning to Lex for further testing.

In terms of performance, I expect record component getters to be faster than normal class getter methods, but event posting and subscribing to be around the same as normal classes. Even if performance ends up being the same, having the record syntax for some events would be nice.

@@ -34,12 +34,12 @@ public static ListenerList getListenerList(Class<?> eventClass) {
}

static ListenerList getListenerListInternal(Class<?> eventClass, boolean fromInstanceCall) {
if (eventClass == Event.class) return EVENTS_LIST; // Small optimization, bypasses all the locks/maps.
if (eventClass == Event.class || eventClass == IEvent.class || eventClass == Object.class) return EVENTS_LIST; // Small optimization, bypasses all the locks/maps.
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is Object.class added?

Copy link
Author

Choose a reason for hiding this comment

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

When I was running the tests I kept getting a weird error where it was trying to cast Object to IEvent when getting the Listener list. It's because the get parent call returns the class it extends, not the interface it implements so the record test class' parent was Object

Copy link
Contributor

Choose a reason for hiding this comment

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

Odd... The record's parent class should be java.lang.Record as that's what all record classes extend.

Copy link
Author

Choose a reason for hiding this comment

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

Yes, this is what I thought at the time especially because when looking at it in ClassNode that's what it says. However, the Class<?> superclass = eventClass.getSuperclass(); call was giving Object (otherwise I assume I would've seen the same casting exception but for Record)

@PaintNinja
Copy link
Contributor

Benchmarks take a long time because it tests on a huge amount of JVMs by default iirc. You can speed this up by changing the VALID_VMS in the root build.gradle to only have Microsoft 17 and 21.

@danorris709
Copy link
Author

Thanks for your PR. Did a quick code review on my phone, looks good. Assigning to Lex for further testing.

In terms of performance, I expect record component getters to be faster than normal class getter methods, but event posting and subscribing to be around the same as normal classes. Even if performance ends up being the same, having the record syntax for some events would be nice.

My assumption was that the record events might gain some performance from the default implementation on methods such as isCanceled where they assume always false.

Either way, I'll re-run them on a smaller sample size as you suggested and get back with the results.

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

Successfully merging this pull request may close these issues.

2 participants