[RFC] Implement custom iterator for JSONArray to ensure fetched values are JSON compliant
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
Piste de recherche
Start with JSONArray.iterator and review the related behavior in JSONObject, JSONArray put* operations, and toString methods; issue #672 provides the referenced context. Decide between lazy iterator wrapping and proactive wrapping during insertion, then verify that code-built values exposed to JSON processors are compliant without changing parsed objects.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
This has been a "known" issue for some time, but as mentioned in #672, the JSONArray.iterator method is exposing the raw values from the backing array instead of JSON-compliant values.
We should do 1 of 2 things:
- Implement a private/internal
JSONArrayIteratorclass that would ensure any fetched values are properly "wrapped" and thus suitable output to JSON processors. - Update all of our
put*operations to ensure that all values are properly "wrapped" in bothJSONObjectandJSONArray. This would also allow us to simplify ourtoStringmethods and remove the wrapping from there as all values should be proper JSON.
Option 1 keeps the wrapping "lazy" and thus would only guarantee JSON compliance on values that are fetched. Fetching a non-wrapped value multiple times would cause wrapping to happen each time.
Option 2 makes the wrapping more proactive; guaranteeing that our JSON compliance happens up-front even if the value is not fetched later. Fetching an initially non-wrapped value multiple times would cause NO wrapping to happen at fetch as it would have been pre-wrapped by the put operation.
Both options only affect code-built JSONObjects/Arrays. Parsed objects would be unaffected as the parser is only placing JSON-compliant values in the backing collections.
Thoughts on whether we should implement either option, something else, or neither?
- Langage dominant
- Java
- Étoiles
- 4.7k
- Forks
- 2.6k
- Merge moyen
- 6 j 20 h
- PR mergées (30 j)
- 2
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.
Autres issues de stleary/JSON-java
-
Fix before the next release
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
New JSONPointer tests needed Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
-
Fix before the next release
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Toutes les issues de stleary/JSON-java
Issues similaires
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Ouvertearea/plugin
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
kestra-io/plugin-kestra#190 ·
-
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
google-ai-edge/LiteRT-LM#3739 ·
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Add canonical URLs and a sitemap Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
integra-team-red/meet-map#249 ·
-
[Studio][Bug] Cancelled create-user dialog keeps the password and admin switch for the next attempt Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
apache/rocketmq-dashboard#5064 ·