Java runs on a wide range of 32 and 64 bit platforms. If you have
enough money you can get yourself a mainframe or a CPU with 256
processors.

But I think what you are getting at is the observation that given the
same amount of silicon, a 64 bit CPU will typically be slower since
more RAM and bandwidth are used to get the same job done.  The reason
for 64 bits is to address huge virtual memories.  You can plausibly do
all your IO with memory mapping or virtual RAM allowing you to boost
performance simply by buying more real RAM without redesigning your
software.

The java program is the same, so the question really addresses the
implementation of the JVM that runs it.  And the question of which is
'faster' depends on a great many things.

Between a given 64-bit datapath and a given 32-bit datapath, each may
have pros and cons versus the other.

A 64-bit control might be able provide some very efficient instructions,
and a program (a JVM in this case) might be coded to take advantage of
that.  Or, a 64-bit control might be implementing the same instructions
as the 32-bit processor.

A 64-bit processor should have an order of magnitude more registers
compared to a 32-bit processor.  If the program can exploit this, then
some operations that would require loading from memory (typically the
slowest instruction) can work in register space instead.

A 64-bit processor is likely to have been designed from scratch
relatively recently, and thus, may have a very sophisticated
forwarding/pipelining architecture which could make it more efficient
than another chip executing the same series of instructions.

A 64-bit processor has a much larger addressing space, and much wider
buses.  This means that things like sequential reads from memory can be
optimized by grabbing big chunks of RAM per load instruction, in
anticipation of spatial locality.  It also means that cache associations
can be made much wider, and caches can be much taller than the
equivalent 32-bit variety, and this should also result in a more
efficient datapath.

There are some diminishing returns, even some liabilities, when so many
transistors are put on a chip, as is implied by the requirement of a
64-bit datapath.  So we are likely looking at a multicore processor
instead of a one giant single path.  Then it's a significant factor
whether the program (the JVM and the OS) can exploit the performance
benefits implied by the processor architecture.

Now your question was only about integers.  That's a tough one.  Many of
the considerations around the datapath also apply in various ways to the
ALU (arithmetic logic unit(s)).  On the other hand, a 64-bit ALU might
not necessarily outperform a 32-bit one with the same operations on
32-bit register data.

Overall, I would certainly expect a 64-bit processor to do no worse than
a 32-bit processor running the same program, but I would also expect
certain benefits of the 64-bit datapath to give increased performance as
a side effect of the wider paths, more registers, cache design, etc.
Further, if the program was designed for the 64-bit architecture, then
it should be expected to take advantage of any performance benefits that
are offered by that architecture.

Regardless, the *program* isn't the java program, it's the JVM.