Issue Details (XML | Word | Printable)

Key: JAVAMONEY-38
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: atsticks
Reporter: keilw
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javamoney

RI artifacts found their way into Spec/API

Created: 06/Apr/13 12:05 PM   Updated: 08/Aug/13 06:03 AM  Due: 07/Apr/13   Resolved: 14/Apr/13 07:03 AM
Component/s: None
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.4-EDR1

Time Tracking:
Not Specified

Tags:
Participants: atsticks and keilw


 Description  « Hide

This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be Collection API or JNDI with both Context and InitialContext in javax.name

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.



keilw made changes - 06/Apr/13 01:34 PM
Field Original Value New Value
Summary RI artifacts accidentally found their way into Spec/API RI artifacts found their way into Spec/API
Original Estimate 0 minutes [ 0 ]
Remaining Estimate 0 minutes [ 0 ]
Priority Blocker [ 1 ] Critical [ 2 ]
Description This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.
This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or
keilw made changes - 06/Apr/13 01:35 PM
Assignee keilw [ keilw ] atsticks [ atsticks ]
keilw made changes - 06/Apr/13 01:36 PM
Description This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or
This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?;-) package space.
keilw made changes - 06/Apr/13 01:40 PM
Description This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?;-) package space.
This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?;-) package space.

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.
keilw made changes - 06/Apr/13 01:56 PM
Description This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?;-) package space.

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.
This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be JNDI with both Context and InitialContext in javax.name;-)

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.
keilw made changes - 06/Apr/13 02:01 PM
Description This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be JNDI with both Context and InitialContext in javax.name;-)

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.
This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be Collection API or JNDI with both Context and InitialContext in javax.name;-)

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.
atsticks made changes - 07/Apr/13 01:06 PM
Status Open [ 1 ] In Progress [ 3 ]
atsticks added a comment - 07/Apr/13 01:08 PM - edited

Isolated core part targeting SE platform on same level as standalone API/TI/TCK.
Will discuss solution with EG in a separate mail with other latest topics and changes/proposals. As for now projcet structure is as follows:

SE scope:
---------

  • money-platform: contains the standalone API/RI
    • money-platform-api: contains the api targeting JDK SE 9
    • money-platform-ri: contains the implementation artifacts targeting JDK SE 9

Standalone scope
----------------

  • money-api: contains the standalone API part
    • convert: currency conversion
    • format: foramtting and parsing
    • provider: accessors
    • ext: extensions
  • money-impl: contains the standalone implementation artifacts
    • ri: contains the reference implementation, runnable on SE 7 or later
    • cdi: contains alternate loader implementation using standalone CDI (weld)
    • java-ee: contains alternate loader targeting EE 6 CDI container integration
  • money-tck: contains the technical compatibility kit (TCK)

atsticks made changes - 14/Apr/13 07:03 AM
Status In Progress [ 3 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
atsticks made changes - 08/Aug/13 06:03 AM
Status Resolved [ 5 ] Closed [ 6 ]