commonmark / commonmark/commonmark-java
Android: List.of() (API 30+) used in core since 0.24.0 contradicts the README's "minimum API level is 19"
Personne n'a encore pris cette issue.
- Langage dominant
- Java
- Étoiles
- 2.7k
- Forks
- 336
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
Summary
Since 0.24.0 the core commonmark module uses java.util.List.of(...) (and a few Set.of/Map.of). On Android these methods exist only from API 30 (Android 11). The README still says:
It works on Android too, but that is on a best-effort basis, please report problems. For Android the minimum API level is 19
An app with minSdk < 30 that does not enable core library desugaring crashes on the first parse on API < 30 devices:
java.lang.NoSuchMethodError: No static method of(Ljava/lang/Object;)Ljava/util/List;
at org.commonmark.internal.InlineParserImpl.parse(InlineParserImpl.java)
This is the same class of problem as #366 / #373 (Objects.requireNonNullElseGet, fixed by #369). The List.of usages were introduced deliberately in #322 as a Java 11 clean-up, so this is a report that the clean-up and the Android support statement now disagree — not a claim that the change was wrong.
Steps to reproduce
Android app, minSdk 24, no coreLibraryDesugaring, org.commonmark:commonmark:0.30.0, run on an API 24–29 emulator:
Parser.builder().build().parse("*a*") // NoSuchMethodError: List.of
With isCoreLibraryDesugaringEnabled = true + com.android.tools:desugar_jdk_libs:2.1.5 the same code works on API 24 (verified on an API 24 emulator).
Where the API 30+ calls live (0.30.0, commonmark module)
List.of / Set.of / Map.of occurrences by file:
| File | Count |
|---|---|
internal/InlineParserImpl.java |
8 |
renderer/markdown/CoreMarkdownNodeRenderer.java |
3 |
renderer/html/CoreHtmlNodeRenderer.java |
3 |
parser/Parser.java |
3 (incl. Javadoc example) |
internal/ParagraphParser.java |
2 |
internal/IndentedCodeBlockParser.java |
2 |
renderer/text/CoreTextContentNodeRenderer.java, renderer/markdown/MarkdownRenderer.java, renderer/html/HtmlWriter.java, renderer/html/DefaultUrlSanitizer.java, parser/block/AbstractBlockParser.java, node/SourceSpans.java |
1 each |
0.22.0 had none; 0.24.0 introduced 8 in InlineParserImpl.
Why CI did not catch it
commonmark-android-test is only run through ./gradlew :app:lint in .github/workflows/ci.yml (minSdk 19, no emulator run), so a runtime NoSuchMethodError never surfaces there.
Possible resolutions
Either would be fine from a consumer's point of view — the important part is that the README and the code agree:
- Keep API 19 support — replace the factory calls with Java 8 equivalents (
Collections.emptyList()/singletonList(x)/unmodifiableList(Arrays.asList(a, b)), same forSet/Map). Mechanical, ~26 sites, keeps immutability. I can send a PR if you want this. - Document the new requirement — state in the README that Android needs API 30+ or core library desugaring, and ideally have
commonmark-android-testrun on an emulator (or fail lint onNewApi) so future regressions are visible.
Context: I hit this while building an Android Markdown renderer on top of commonmark-java (https://github.com/Jimmy-Jung/RichMarkdown-Android). We chose minSdk 30 for now, so this is not blocking us — reporting because the README statement is likely to mislead other Android users.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par examiner les occurrences indiquées de List.of, Set.of et Map.of dans le module commonmark ainsi que la configuration des tests Android dans .github/workflows/ci.yml. Reproduisez l’échec sur les API 24–29 sans core library desugaring, puis vérifiez que la résolution choisie maintient la cohérence entre le README, le comportement à l’exécution et les attentes en matière de prise en charge d’Android.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- android, java
- Domaine
- mobile-dev
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 74/100