[JAVA_STATE_MANAGEMEN-2] getVersion() method in StateManager might be misnamed Created: 19/Apr/12  Updated: 26/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, naming

 Description   

I noticed, the StateManager has a method getVersion() which actually returns a Collection of String values.
JavaDoc states
/**

  • Retrieve the versions of {@link javax.state.ext.version.VersionableState}

    supported by this manager.
    *

  • @return the collection of versions supported
    */
    Collection<String> getVersion();

Unless the strings are parts of a single version, e.g. Major, Minor, Patch, etc. I believe this should better be called getVersions().



 Comments   
Comment by peteraymond [ 26/Apr/12 ]

Agreed. I suggested getSupportedVersions just before you came on the call.





[JAVA_STATE_MANAGEMEN-8] Consider a more generic Key Created: 08/Aug/12  Updated: 22/Aug/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While the Key interface in javax.state provides some flexibility towards different implementations, the question, whether the key couldn't simply be a Generic type should be explored.
Similar to the pattern in java.util.Map<K,V> with K as the key and V already used for value in many places.

As the only method Key provides at the moment is a String value, this could e.g. be the toString() method in Object, if the generic value needs a most common base type. BasicKey already substitutes toString() with the key value. As of now, the get() method in Key does not seem referenced anywhere.



 Comments   
Comment by mitch.upton [ 22/Aug/12 ]

I agree we should be using a generic 'K' type parameter to represent the key (not String, not Key, but whatever the client code wants). I think we'll need to define StateManager like this:

public interface StateManager<K, V> extends StateOps<K, V>, Closeable

{ ... }

And State like this:

public interface State<K, V> extends Closeable { ... }

Now, we need to consider the serialization/deserialization of keys (K). For values (V) we allow a client (at least right now) to either implement Serializable or provider a DataHandler in the Binding they specify when getting the StateManager. Right now, that DataHandler is only required to handle values of type V.

We could extend the responsibility of the DataHandler to include handling keys (K) too, or allow the specification of another DataHandler for keys of type K. Perhaps a good middle-ground solution would be to say that clients can optionally specify a DataHandler for K, but if they don't, K must either implement Serializable or we'll use any DataHandler specified for V.

Make sense?





[JAVA_STATE_MANAGEMEN-7] Consider adding an State:recordFully() method Created: 08/Aug/12  Updated: 08/Aug/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: mirceamarkus Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the following pattern is used for storing an State Object:

State<ByteChannel> state = mgr.getOrCreateState(key);
ByteChannel channel = ... create a ByteChannel from a file, etc ...
state.setContents(channel);
state.record();

We might want to also add an blocking State:recordFully method as well and make the record method non-blocking. Similar to the way DataInputStream:readFully works: http://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInput.html#readFully(byte[])






[JAVA_STATE_MANAGEMEN-4] Would javax.state.UnknownStateException be clearer as StateKeyNotFoundException? Created: 26/Apr/12  Updated: 26/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: peteraymond Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Would javax.state.UnknownStateException be clearer as StateKeyNotFoundException?






[JAVA_STATE_MANAGEMEN-1] Clarify JDK Version Dependency Created: 19/Apr/12  Updated: 19/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java SE


Tags: jdk7-applicable, language, version

 Description   

The API interface javax.state.Closeable raises the valid question, if the recently added java.lang.AutoCloseable interface could be extended there, too.
The only reason not to do so, would be if strict backward-compatibility with Java 6 or earlier was desired.
Otherwise using AutoCloseable would add value of the new Java 7 try-with-resources block being applicable to the spec.

The only difference is, that try-with-resources requires the close() method to throw an exception, the current close() method in the interface doesn't. Not sure, if this was a big show-stopper, but the value of using some new Java 7+ functionality might justify such tweak.

Other JSRs, though they have mostly become of the core Java package also picked up AutoCloseable, e.g. javax.sound.midi.Transmitter.






[JAVA_STATE_MANAGEMEN-5] Is javax.state.CoreCapabilities extending javax.state.Constants confusing? Created: 26/Apr/12  Updated: 26/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: peteraymond Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I found using javax.state.CoreCapabilities extending javax.state.Constants confusing when also having the BasicCapability implement Capability.






[JAVA_STATE_MANAGEMEN-3] Should StateManagementHelper.safegetOrCreateStateManager be safeGetOrCreateStateManager i.e. capital G Created: 26/Apr/12  Updated: 26/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: peteraymond Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Should StateManagementHelper.safegetOrCreateStateManager be safeGetOrCreateStateManager i.e. capital G






Generated at Tue Mar 03 21:23:45 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.