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"

Ouverte
#457 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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:

  1. Keep API 19 support — replace the factory calls with Java 8 equivalents (Collections.emptyList() / singletonList(x) / unmodifiableList(Arrays.asList(a, b)), same for Set/Map). Mechanical, ~26 sites, keeps immutability. I can send a PR if you want this.
  2. Document the new requirement — state in the README that Android needs API 30+ or core library desugaring, and ideally have commonmark-android-test run on an emulator (or fail lint on NewApi) 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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. 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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.