comp.lang.java.programmer Google Group

Re: converting from one charset encoding to another ...

2009-11-25T08:18:17Z

OK, you have made me wonder about what to do when you don't know the
encoding of a file you got. As long as I know this is not taken care
by Readers even though some heuristics may be used
So, what do you do in those situations?
Thank you
lbrtchx

Re: Thread in a hashtable

2009-11-25T06:23:49Z

In article <RUKOm.50406$KP1.36...@newsfe1 6.ams2>,
. . .
Guesses:
- Improve multithreading adoption at a time when most coders were afraid
of it or considered it voodoo
- Most of the JFCs were Java example code too
- There would have been Applet security holes if synchronization didn't
prevent unpredictable updates to the basic data types like HashMap,

Re: book request

2009-11-25T06:08:23Z

On Mon, 23 Nov 2009 23:45:27 -0800 (PST), Ztx4 <oladham...@gmail.com>
wrote, quoted or indirectly quoted someone who said :
It will be easier to find with this info:
978-0136012672 ISBN
Daniel Liang
See [link]

Re: book request

2009-11-25T05:12:01Z

It's consdierably less expensive at
[link]

Re: Hash table performance

2009-11-25T04:35:41Z

In article <hei5nr$5n...@news.eternal-sep tember.org>,
Ah, perhaps a cache of expensive function results.
I see what you mean: floats and doubles are just rational approximations
of reals, so they always end in zero or repeat.

The method hash() is adapted to the power-of-two array size:
<[link]>

Re: Hash table performance

2009-11-25T04:25:48Z

I did a quick microbench to test division versus shifting. I was
surprised by the result, I expected them to be "close enough", but it
looks like, on my machine at least, there is an order of magnitude
difference:
<results>
Nothing: count = 874270000
Shift: count = 869828000
Divide: count = 91958000

Re: Hash table performance

2009-11-25T02:45:12Z

I dunno. I have a feeling that while the example is contrived, it isn't
unreasonable. Doubles and their bit pattern don't seem to be as random
as people expect.
Look at Tom's attempt to introduce some randomness by dividing by ten.
I don't think those he produced bit patterns are random at all. I see a

Re: Hash table performance

2009-11-25T02:30:45Z

In article <hehvr3$qs...@news.eternal-sep tember.org>,
Is this just the contrived nature of the example? If the keys were
really positive integers less than 10 million, then HashMap<Integer,
Double> would solve the problem. If the domain were some other subset of
the reals for which Double's hashCode() proved inadequate, one might

Re: The future of Java

2009-11-25T01:42:57Z

On Sun, 22 Nov 2009 21:56:54 -0500, Arne Vajhøj <a...@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :
I have seen vendors wriggle out of these sorts of promise by creating
a new product and just letting the old one languish. The wording of
the GPL licence may make that difficult for Sun and Oracle. Does the

Re: The future of Java

2009-11-25T01:23:00Z

On Sun, 22 Nov 2009 22:05:05 -0500, Arne Vajhøj <a...@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :
Under heavy loads a system can have can a variety of behaviours:
in increasing desirability
1. the system crashes outright.
2. the throughput drops precipitously. (e.g. virtual ram thrashing).

Re: Hash table performance

2009-11-25T01:04:32Z

I wasn't using bit masking and powers of two, I was using double the
previous table size then add 1, and integer modulo to limit the hash
index to the table size. I even started with a hash table size of 101.
I was using closed hashing however, which did not help.
I was *still* getting a huge clump of collisions right in the middle of

Re: Hash table performance

2009-11-24T23:58:33Z

Ahaaa, yes, of course. Those bits in full:
0.0 000000000000000000000000000000 000000000000000000000000000000 0000
1.0 001111111111000000000000000000 000000000000000000000000000000 0000
2.0 010000000000000000000000000000 000000000000000000000000000000 0000
3.0 010000000000100000000000000000 000000000000000000000000000000 0000

Re: Hash table performance

2009-11-24T23:55:58Z

I suppose that it is mature since they've made it available and I also
suppose that they found out that benefits of EA were not that great
for many classes of programs when compared to longer JITting - but
that's just my thinking.
Semantically yes but in the case of synchronized method there is no
accompanying bytecode instruction, namely monitorenter/monitorexit

Re: Hash table performance

2009-11-25T00:57:55Z

No, it applies to all untagged value types including byte, int, long, float,
double and any user defined value types like complex numbers or vertex
data.
Interestingly, this reminds me of a lecture one of the JVM designers gave,
describing how they felt it was preferable to build a VM upon dynamic
language principles. The JVM's awful performance here is a direct

Re: good porn site

2009-11-24T23:18:07Z

I am not sure but in reality it might be hard to find a really good
one :-)))
Care to recommend? :-))))