Migrate Guava Predicates and Functions to Java implementations #6047
Conversation
# Conflicts: # forge-game/src/main/java/forge/game/ForgeScript.java
# Conflicts: # forge-game/src/main/java/forge/game/phase/PhaseHandler.java
# Conflicts: # forge-ai/src/main/java/forge/ai/ComputerUtil.java # forge-core/src/main/java/forge/card/DeckHints.java # forge-game/src/main/java/forge/game/ability/AbilityFactory.java # forge-game/src/main/java/forge/game/cost/CostUntapType.java # forge-gui/src/main/java/forge/player/HumanCostDecision.java
|
@Hanmac |
# Conflicts: # forge-gui-mobile/src/forge/adventure/data/AdventureEventData.java
Rewrite `generateParticipants`
# Conflicts: # forge-game/src/main/java/forge/game/GameEntityCounterTable.java # forge-game/src/main/java/forge/game/ability/effects/PumpEffect.java # forge-game/src/main/java/forge/game/staticability/StaticAbilityContinuous.java
|
@Hanmac is this PR good, I think java is more performant than guava, also do we need guava (I don't know if java covers all other collections guava have) |
|
@kevlahnota i will look over this MR, but i think it should be good enough? we can't really drop guava fully, i would miss my Table support |
|
I looked at cutting out more of Guava and recreating the functionality within other util classes, but the scope of that started expanding too quickly for this PR at least. They have a huge number of helper methods that we use, and many of those are implemented through internal helper classes which would either need to be reproduced as well or replaced with inline logic. If we want to further lessen the dependency on Guava, I think a good direction would be expanding the functionality of For performance improvements, as mentioned above, I think |
# Conflicts: # forge-ai/src/main/java/forge/ai/ability/ChooseCardAi.java # forge-ai/src/main/java/forge/ai/ability/ScryAi.java # forge-core/src/main/java/forge/card/DeckHints.java # forge-core/src/main/java/forge/util/TextUtil.java # forge-gui-mobile/src/forge/itemmanager/ItemManager.java # forge-gui/src/main/java/forge/download/AutoUpdater.java # forge-gui/src/main/java/forge/player/HumanCostDecision.java
…mpound predicates.
There was a problem hiding this comment.
the toList method directly from stream are missing on older Android (12 and below tested, not sure on 13 and above), so this will break mobile builds.
#4bbc165460cbe87a32eb4227f5b4fda26959d9f9
|
Gah. I was excited when I saw we'd moved up to Java 17. Should I just treat the language level as though it were 11, then? |
Hmm I just discovered it when I update the auditer. Don't know which Java api are excluded on android. |
|
Android 12 and 13 reportedly support up to Java 11, and Android 14 partially supports Java 17. From what I can tell, the D8 compiler has support for backporting newer Java API members via desugaring, but it sounds like that's only being used to enable stuff from the Java 11 API on Android <= 11. If the project is gonna be set to Java 17, though, It would probably be a good idea to add a github workflow to test the android build, or otherwise report unsupported API members. It seems like an easy thing to overlook. Worth keeping an eye on this in case desugaring support for 17 gets added someday - https://github.com/google/desugar_jdk_libs/blob/master/CHANGELOG.md |
# Conflicts: # forge-core/src/main/java/forge/StaticData.java
Per #5717.
Not complete yet but wouldn't hurt to get some eyes on it while it's easier to revise things.
The switch-over of the implementation is done, but still need to finish cleaning up the helper methods. Many can be simplified through method references (e.g.
::equalsand::contains), but others don't have a good equivalent.The dependency on Guava's
Iterablesis one point of uncertainty at the moment. It's too convenient to get rid of, but a handful of the filter methods still want Guava predicates. Could reimplement these manually in anIterableUtilsclass, or could just use thepredicate::testhack to keep using the original library.