[jira] [Created] (CHAIN-56) clever Context with generic type auto-cast feature
clever Context with generic type auto-cast feature
Key: CHAIN-56
URL: https://issues.apache.org/jira/browse/CHAIN-56
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Simone Tripodi
Fix For: 2.0
Generics could help us on improving the Context class; since it is clear that
Context is a place where storing/retrieving objects identified by a key, I
propose adding two helper methods:
{code}
/** @since 2.0 */
T T retrieve( String key );
/** @since 2.0 */
T void store( String key, T object );
{code}
that would help users avoid the redundant code of type cast/checking when
assignments are already known (it throws a {{ClassCastException}} if types are
not assignable). At the same time, old pattern is supported, users can choose
their
preferred way to go, depending on their needs.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-56) clever Context with generic type auto-cast feature
[
https://issues.apache.org/jira/browse/CHAIN-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096897#comment-13096897
]
Simone Tripodi commented on CHAIN-56:
-
the proposed {{store}} method is useless, since {{Context}} already inherits
from {{MapString,Object}} where {{put(String,Object)}} already perform the
same feature.
OTOH, {{retrieve(String)}} does the magic.
clever Context with generic type auto-cast feature
Key: CHAIN-56
URL: https://issues.apache.org/jira/browse/CHAIN-56
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 2.0
Generics could help us on improving the Context class; since it is clear that
Context is a place where storing/retrieving objects identified by a key, I
propose adding two helper methods:
{code}
/** @since 2.0 */
T T retrieve( String key );
/** @since 2.0 */
T void store( String key, T object );
{code}
that would help users avoid the redundant code of type cast/checking when
assignments are already known (it throws a {{ClassCastException}} if types
are not assignable). At the same time, old pattern is supported, users can
choose their
preferred way to go, depending on their needs.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CHAIN-56) clever Context with generic type auto-cast feature
[
https://issues.apache.org/jira/browse/CHAIN-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-56.
-
Resolution: Fixed
fixed on
[version-2.0-work|https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work]
branch, see
[r1165075|https://svn.apache.org/viewvc?view=revisionrevision=1165075]
clever Context with generic type auto-cast feature
Key: CHAIN-56
URL: https://issues.apache.org/jira/browse/CHAIN-56
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 2.0
Generics could help us on improving the Context class; since it is clear that
Context is a place where storing/retrieving objects identified by a key, I
propose adding two helper methods:
{code}
/** @since 2.0 */
T T retrieve( String key );
/** @since 2.0 */
T void store( String key, T object );
{code}
that would help users avoid the redundant code of type cast/checking when
assignments are already known (it throws a {{ClassCastException}} if types
are not assignable). At the same time, old pattern is supported, users can
choose their
preferred way to go, depending on their needs.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096971#comment-13096971 ] Sebb commented on MATH-650: --- I think the simplest would be to just print out the values of the arrays at the end of the static block, and feed them back into the code. Rather than deleting the setup code, it could be left as documentation - either commented out or disabled via an if (false) block. I've done most of the work to implement this. Thoughts? FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
