Using 'Number' class instead of primitives on a game?

Instead of using primitives directly, I am using the Number type almost everywhere on the APIs of a game I'm developing. Can this affect dramatically the performance of my game?

Don't use boxed primitives unless you really need them. A good reasons may be

• you need an representation for the undefined state (use null)
• you put them into Object-accepting classes (List, Set, Map, ...) and want to avoid boxing (by working with boxed values all the time)

Anything performance-related must be benchmarked first, otherwise you can find yourself optimizing a piece of program taking no measurable time or even "pessimizing" it. Low-level optimizations in Java are pretty hard, so you'd better concentrate on clarity and readability, so you can measure the speed, identify the bottlenecks, and optimize them afterwards.

Concerning boxed primitives, IMHO the biggest performance impact doesn't come from object creation but from the indirection (creation happens once, repeated cache misses are costly).

I disagree with dognose concerning the "fancy OOP stuff". Everything the classes offer can be used without boxing and working with boxed primitives is a pain the OOP methods can't ever make good (the unexpected NullPointerExceptions, non-working conversions, etc. are IMHO too bad).