Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

JSR 354 interoperability for obtaining numeric value from Quantity

Offen
  • Stimmt etwas nicht?
#260 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
api

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
195
Forks
41
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus unitsofmeasurement/unit-api

Alle Issues in unitsofmeasurement/unit-api

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.