• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

when to use ...implements Serializable

 
nimo frey
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When should I use "Entity implements Serializable" ?

Always? Or only for Entities containing primary keys?

And another question: Should I prefer primitive types or their wrapper types?
Is there really a difference in case of performance or something else?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are we talking about here? JPA in general? Or a specific ORM?


And another question: Should I prefer primitive types or their wrapper types?
Is there really a difference in case of performance or something else?

Performance, as is always the case, is the wrong metric to consider at this stage. If you are talking about mapping a thing to a database field a primative and an Object implies differernt stuff. Most significantly a primitive cannot be null, so neither can your mapped field.
 
nimo frey
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I use JPA with Hibernate as Provider.

In documentations, there is no strange way to implement(always)Seriazible. Some do that, the others do not.

Is there a rule, when to need Seriazible?

I have mapped all my entities with that interface
and want to be sure,
that it does not matter (all works fine, I guess.)

For example:

public class MyEntity implements Serializable {

private static final long serialVersionUID = ...

// this static class is for composite keys of MyEntity
public static class MyEntityID implements Serializable
{
private static final long serialVersionUID = ...

}

}

To the primitive types..for all my fields,
I use wrapper-types, but for IDs it makes no sense,
as IDs cannot be null.
So should I use primitive types for ID-Fields?
I have red, that for performance-issues,
we should use primitive types where it s possible
(e.g. where a field cannot be null.)
[ December 18, 2008: Message edited by: nimo frey ]
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

but for IDs it makes no sense,
as IDs cannot be null.
So should I use primitive types for ID-Fields?
I have red, that for performance-issues,
we should use primitive types where it s possible
(e.g. where a field cannot be null.)

Agreed. Primary keys cannot be null, so a primitive type is fine. That is, unless your POJO needs to be used in conjunction with something else (such as JAX-RPC).

Performance is still not really a concern I'd care about choosing a property type. Where did you read this as an issue?
 
nimo frey
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For example:


I have red it somewhere else in the past, I do not really know where. However, I have searched and found e.g. these links
http://www.glenmccl.com/tip_016.htm
http://www.java2s.com/Tutorial/Java/0040__Data-Type/PrimitiveWrappersindetail.htm

I guess, it is obvious, that primitive types should preferred when it is possible.

thanks.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I guess, it is obvious, that primitive types should preferred when it is possible.

I'd disagree. I can't think of any situation when the choice between primitives and Objects is a major performance concern in any database backed application I've worked on.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic