Add caching of values to UByte.

[lukaseder]

Thanks for these additions. As far as I can see they should be generally useful. I'll merge by the end of the week. The additions will be tracked here and released in 0.9.1, soon:

http://code.google.com/p/joou/issues/detail?id=1 http://code.google.com/p/joou/issues/detail?id=2

[schallee]

Thanks for these additions. As far as I can see they should be generally useful. I'll merge by the end of the week. The additions will be tracked here and released in 0.9.1, soon:

Cool. Thanks.

A couple of quick thoughts that might be useful:

• It would probably be good to decide which repository (googlecode or github) is the official repo
• It might be worth removing the publicly available constructors for the types and just providing factories. This would be a non-backwards compatible change so pre-1.0 would be best. Changing to factories only has the advantage of making arbitrary caching changes transparent in the future. For an immutable type public constructors aren't the most useful thing in the world and frequently interfere with future implementation changes. There is little need to allow multiple objects with the same value. I would be surprised if java 1.5 wouldn't have eliminated public constructors for primitive wrappers if it wasn't for backwards compatibility issues.
• Lastly, when I get a chance/need I'll look at caching of common values for the other types. UByte caching is easy and worth while. Caching all ULong is not possible. I looked at the openjdk source for the primitive wrappers and they're only caching like -128 - 127 for short, int and long. I believe theres a property to define that range at startup if someone is so inclined. Doing similar might be worth it though I start to wonder with how little U* is used in comparison to the primitive wrappers (why can't they just add unsigned? const would be darn nice too).

Anyhows, thanks for making this project. I was putting together my own when I finally found yours. I may have some other minor additions in the future to (toHexString for example).

------>

[lukaseder]

Considering your thoughts:

1) Deciding about a repository:

Yes, I'm about to make a decision. It was more of a decision between SVN and Git. But I've learned that the GitHub repositories can also be accessed via SVN, so I'll give up on googlecode eventually

2) Removing the public constructors:

You are right. The unsigned number types should only be created / accessed via the factory methods in org.joou.Unsigned.

3) Adding caches for larger unsigned types:

That would be great! With all of those additions, I'd like to make you the co-author of this library, if that is ok with you? I'll check later how to grant access to you on GitHub, once I've migrated googlecode over here.

[schallee]

Yes, I'm about to make a decision. It was more of a decision between SVN and Git. But I've learned that the GitHub repositories can also be accessed via SVN, so I'll give up on googlecode eventual

I've done a lot of accessing svn from git so either works.

2) Removing the public constructors:

You are right. The unsigned number types should only be created / accessed via the factory methods in org.joou.Unsigned.

It's probably worth keeping the valueOf(…) factories in the classes themselves for symmetry with j.l.*

3) Adding caches for larger unsigned types:

That would be great! With all of those additions, I'd like to make you the co-author of this library, if that is ok with you? I'll check later how to grant access to you on GitHub, once I've migrated googlecode over here.

I'm good with whatever. I'm sadly a bit flaky on the consistency area but I'm trying to do better putting some things out there that other folks may find useful too. Thanks for putting together something that others can use and putting it out there so it can be accessed. I need to just push half my personal libraries and such out to git hub myself (I did one now). I don't have time or energy to maintain them (I have kids) but if there out there at least there's a possibility of someone else benefitting;)

------->

[lukaseder]

I've done a lot of accessing svn from git so either works.

GitHub is now the master.

It's probably worth keeping the valueOf(…) factories in the classes themselves for symmetry with j.l.*

Absolutely

I'm good with whatever. I'm sadly a bit flaky on the consistency area but I'm trying to do better putting some things out there that other folks may find useful too.

Yes yes. I'll review and change if I find it inconsistent, before releasing. So do as you feel! :-)

[lukaseder]

I have released 0.9.1:

Version 0.9.1

Features and improvements

1 - Add Unsigned.ubyte(int) and ubyte(long) constructors

2 - Cache all possible UByte values for improved performance

3 - Deprecate public constructors. Do not encourage to

   construct unsigned numbers directly