Since Point2D objects can have coordinate values between 0 and 1, I had
to remove the wee optimization of comparing the squares of the distance.
Also modified it so that the origin Point's coordinates can be updated to
update the Comparator.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1853 6335cc39-0255-0410-8fd6-9bcaacd3b74c
int low = Integer.MAX_VALUE - 2; // = 2147483645
int high = Integer.MAX_VALUE; // = 2147483647
int mid1 = (low + high) / 2; // = -2
int mid2 = low + (high - low) / 2; // = 2147483646
int mid3 = (low + high) >> 1; // = -2
int mid4 = (low + high) >>> 1; // = 2147483646
So we'll use the last one (non-sign-propagating shift) as it is likely to be
fastest and clearest.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1850 6335cc39-0255-0410-8fd6-9bcaacd3b74c
line as the thing we're suppressing, to more closely couple them.
Also, removed one hanging on a method by using a temporary variable within.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1848 6335cc39-0255-0410-8fd6-9bcaacd3b74c
is Boolean, Byte, Short, Character, Integer, Long, Float, or Double.
This has always made sense for Boolean, but with 1.5 they added these
methods everywhere and they are the preferred method for obtaining an
instance of any of those classes unless you absolutely want different
object references.
Since many Integer objects have a low value, the small bit of overhead
incurred for calling these methods should more than make up for itself
in saved memory and garbage collection time.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1847 6335cc39-0255-0410-8fd6-9bcaacd3b74c
an Entry interface that can be used to get the count directly from
an Entry (without having to know that values are stored internally as
an int[]). It turned out to be a bit ugly.
What I really need to do is hide all the int[] business by rewriting
this class, which will also clean up the ugliness.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1839 6335cc39-0255-0410-8fd6-9bcaacd3b74c
JDBC connection at a time. JDBC connections are thread safe, but we frequently
have to execute statements like:
insert into FOO values(0, blah, blah);
select LAST_INSERTED_ID()
to get the value assigned to an auto-increment column. If another thread
slipped in between those statements and inserted something into its own
auto-increment column having table, we'd get funny business. And indeed we very
occasionally see this race condition happen in the thread-happy webapps.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1838 6335cc39-0255-0410-8fd6-9bcaacd3b74c
server side prepared statement caching and it's causing things to break when
for some reason the prepared statements are being closed (perahps automatically
by the new MySQL deriver) and then being reused.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1834 6335cc39-0255-0410-8fd6-9bcaacd3b74c
safe and particularly not so in the webapp where one thread might come slip a
read-only connection into the session before an update was about to happen.
This ends up being a giant refactor, but it's much cleaner this way (to pass a
connection into the Table whenever it is doing anything), so I've taken the
pain. Fortuanately, code that uses the convenience methods doesn't need to
change, so as a part of this refactor I've taken the opportunity to switch a
bunch of old stuff to the new, concise, future proof hotness.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1830 6335cc39-0255-0410-8fd6-9bcaacd3b74c
that we can route read-only queries to one or more read-only mirrors of a
database (the MySQL database drivers supports round-robin load balancing of
queries to read-only slaves).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1822 6335cc39-0255-0410-8fd6-9bcaacd3b74c
to typesafe 1.5 patterns; tidied some things up. Two impactful changes:
- jora.Table now takes the class object of the row class, rather than its name;
I also removed support for the derived table stuff as we don't use it and it
was a PITA to make work cleanly with proper type-safety;
- SortableArrayList got split into SortableArrayList (which does its sorting
using a Comparator) and ComparableArrayList which contains elements that
implement Comparable. In the world of loose typing, one class could do both,
but in strong typing land, they have to be separate classes.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1810 6335cc39-0255-0410-8fd6-9bcaacd3b74c
make things work on the client. We're starting with parameterized types which
are backwards compatible with 1.4 anyway so all Retroweaver is doing to such
classes is changing the classfile format version number. We'll get more jiggy
later as we become more comfortable with the process.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1809 6335cc39-0255-0410-8fd6-9bcaacd3b74c
ray