Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Impl: RI
    • Labels:
      None

      Description

      After updates to CurrencyUnit, the jdk-stub module no longer compiled.
      Please while it isn't part of the "portable RI", let's always ensure, it's up do date with the spec given this will become the de facto RI for either SE 9, CLDC 8/9 or both.

        Activity

        keilw created issue -
        keilw made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        keilw made changes -
        Original Estimate 0 minutes [ 0 ]
        Remaining Estimate 0 minutes [ 0 ]
        Due Date 2013-01-19 00:00:00.0 2013-01-31 00:00:00.0
        keilw made changes -
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Hide
        keilw added a comment -

        Fixed the Stub again, a change of the getValid* methods in CurrencyUnit forced it, after code was broken there.
        This module should probably also be included in a CI Job to ensure consistency.

        If returning <code>null</code> is a mandatory requirement for these timestamps, leaving them as Long object instead of a simple long primitive type might be acceptable, but I see a possible overhead or risk of people using AutoBoxing in real life when they gather such primitive values from System.currentTimeMillis(), System.nanoTime() or similar.
        Ultimately that will be up to advise by Oracle Architects, if a complex type is feasible, especially if this affects java.util.Currency, too.

        Show
        keilw added a comment - Fixed the Stub again, a change of the getValid* methods in CurrencyUnit forced it, after code was broken there. This module should probably also be included in a CI Job to ensure consistency. If returning <code>null</code> is a mandatory requirement for these timestamps, leaving them as Long object instead of a simple long primitive type might be acceptable, but I see a possible overhead or risk of people using AutoBoxing in real life when they gather such primitive values from System.currentTimeMillis(), System.nanoTime() or similar. Ultimately that will be up to advise by Oracle Architects, if a complex type is feasible, especially if this affects java.util.Currency, too.
        keilw made changes -
        Due Date 2013-01-31 00:00:00.0 2013-03-31 00:00:00.0
        atsticks made changes -
        Component/s Platform: SE/JDK Adaptations [ 14830 ]
        keilw made changes -
        Tags standalone
        keilw made changes -
        Tags standalone jdk standalone
        keilw made changes -
        Tags jdk standalone jdk
        keilw made changes -
        Due Date 2013-03-31 00:00:00.0 2013-04-09 00:00:00.0
        keilw made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        atsticks made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        keilw made changes -
        Component/s Impl: RI [ 14824 ]
        Component/s Impl: SE/JDK Adaptations [ 14830 ]

          People

          • Assignee:
            keilw
            Reporter:
            keilw
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: