Look in the SERVICE layer for ImmediateWindowProvider implementations #92
Conversation
loader/src/main/java/net/neoforged/fml/loading/ImmediateWindowHandler.java
Outdated
Show resolved
Hide resolved
Is this referring to the SERVICES set in EDIT: If this is the case, there's an additional question I have; currently the
However, the |
No idea! Looks like an oversight. We should deduplicate the set to avoid such mismatches in the future. |
- Throws if the SERVICE layer was not built instead of using a default layer - Extracts the discoverer service type constants to a new shared class and adds the ImmediateWindowProvider to this list.
|
I've implemented the requested changes, and also extracted the service set into a constants class that gets shared between the two discoverers, which I've added the ImmediateWindowProvider type to. I think that at some point in the future we should have a breaking change to move it into the SPI project, to be more consistent with the other service types. |
|
Looks good, will need to test this somehow however 😅 |
This was discussed in the NeoForge Discord
| */ | ||
| void crash(String message); | ||
| } | ||
| @Deprecated(since = "2.0.16", forRemoval = true) |
There was a problem hiding this comment.
I think I got this version number correct, but I could be wrong. I figured we should keep the interface around for binary compatibility at least, but I can remove it if it's deemed unnecessary.
…terface for binary compatibility
FiniteReality
force-pushed
the
feature/service-layer-earlywindow
branch
from
beb9dda to
bd6ae49
Compare
|
Looks nice. |
I take this as an approval of the changes, and assumed that tech was unable to provide a proper approval due to external circumstances. Merging. |
This change was discussed in https://canary.discord.com/channels/313125603924639766/852298000042164244/1210370060737314818
There's a few ways to actually implement this, but I chose the most obvious. One behavioural change from this approach is that we no longer load ImmediateWindowProvider implementations from unnamed modules; if we're moving towards more use of modules, this seems like a sensible trade-off to me, and shouldn't pose a challenge for most mods as we build modules for them on the fly already.