Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

JSR 354 interoperability for obtaining numeric value from Quantity

Ouverte
  • Quelque chose ne va pas ?
#260 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
java
Domaine
api

Piste de recherche

Start by comparing the JSR 354 MonetaryAmount and JSR 363 Quantity accessors, especially getNumber(), getValue(), and the existing NumberSupplier interface. Evaluate whether a shared NumericValueSupplier or NumericComponentSupplier fits both APIs without obscuring domain meaning. Done means the compatibility and naming implications are resolved into an agreed API design.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Both JSR 354 and JSR 363 define an API with a main class/interface whose role is represent a numeric quantity with some kind of additional unit and other metadata. It would be useful for programs that need to deal with both quantities and currencies to be able to deal with both of these main value classes in a generic way in some use cases.

In my use case, a precious metals business process automation webapp, has a notion of both monetary and material accounts. It has a parameterised base class AbstractAccountLedger<B> with method public B getBalance(), with concrete subclasses MonetaryAccountLedger<MonetaryAmount> and MetalAccountLedger<Quantity<Mass>>.

However, since MonetaryAmount and Quantity defines two different accessors for obtaining the numeric component of each (public Number getNumber() and public Number getValue(), respectively), the application needs duplicate codepaths to handle each in a generic way. For exmaple, when asserting pre- and post-conditions after performing account transaction operations in the AccountsService implementation, when streaming over collections that contain instances of both account types, and when logging numeric values.

It would be extremely convenient in these cases if both JSR APIs supported a common functional interface for accessing the numeric value, so that the parameterised base class could set that as common lower bound for its type parameter B, and hence allowing the currently required multiple near-duplicate codepaths to be collapsed into single generic codepaths.

While the JDK has defined Supplier<T> since v8, that functional interface's get() method is perhaps too generic for the domain models. JSR 354 currently defines a NumberSupplier functional interface with Number getNumber(), inspired perhaps by the JDK's Supplier<T>, that is also somewhat generic - what part of the domain model does that really return, just by looking at the method name?

I would instead suggest a common functional interface NumericValueSupplier or perhaps NumericComponentSupplier is defined with single method Number getNumericValue() as a shared joint interface to address this issue.

Langage dominant
Java
Étoiles
195
Forks
41
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

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.

Autres issues de unitsofmeasurement/unit-api

Toutes les issues de unitsofmeasurement/unit-api

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

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