Avoid Primitives in API design?

It will be usable, because of autoboxing / autounboxing in Java 1.5 and later. You can pass an int to something that expects an Integer or vice versa, and the cast will happen automatically. The same applies to return values Keep in mind that in the body of your method, you will know little more about your arguments than that they are some form of Number This will only be suitable if you don't care to differentiate between integer and floating-point representations It will not increase your performance - there will be some small penalty for the cast, but you shouldn't worry about that until you discover you have a bottleneck.

For most applications, the difference will be insignificant Whether you use a List rather than an array should really be decided by your design, but it is generally advisable to use a List unless an array is necessarily needed List s tend to be more flexible, don't need to be resized, have all of the benefits of the Collections API, etc.

It will be usable, because of autoboxing / autounboxing in Java 1.5 and later. You can pass an int to something that expects an Integer, or vice versa, and the cast will happen automatically. The same applies to return values.

Keep in mind that in the body of your method, you will know little more about your arguments than that they are some form of Number. This will only be suitable if you don't care to differentiate between integer and floating-point representations. It will not increase your performance - there will be some small penalty for the cast, but you shouldn't worry about that until you discover you have a bottleneck.

For most applications, the difference will be insignificant. Whether you use a List rather than an array should really be decided by your design, but it is generally advisable to use a List unless an array is necessarily needed. Lists tend to be more flexible, don't need to be resized, have all of the benefits of the Collections API, etc.

To answer your question about List vs. T, both expose details about implementation. List is more maintainable than T because you can change the List implementation without changing client code. If the list shouldn't be modified by the client code, Iterable would be better, as you expose nothing about your implementation details and prevent operations other than iteration.

Iterable is a nice one! Thank you! – Pindatjuh Mar 7 '10 at 18:40 P.S.I edited the question: this is an answer for the question wether List was a good replacement for T.

– Pindatjuh Mar 7 '10 at 19:03.

APIs are about semantics, so I think the answer to the question as stated (Should I avoid primitives in API design) is that it depends on what your API does. Int addOne(int integer) is semantically consistent and won't present many problems with maintenance as it reflects the problem domain. Employee getEmployee(int empID) could be classed as inappropriate and will present maintenance issues if your employee IDs change, say, to Strings.

It's a valid pattern, sometimes used for defining properties in a model-view-controller system. Additionally, if you use ints in the range of -128 to 127, they will be auto-cached by Java if you convert using Integer. ValueOf(int) which can speed things up a bit regarding Integer creation.

You can also increase the cached range using the property java.lang.Integer.IntegerCache. Gh which is always at least 127. It might be the case also that auto-boxing will also use this Integer cache, but I'm unsure.

If your class is designed for use in a high-performance environment, I'd consider other alternatives instead and use primitives.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.