On 14/05/2020 17:46, Mark Thomas wrote: > On 14/05/2020 16:48, Christopher Schultz wrote: >> All, >> >> I'm interested in the history of the StandardSession.writeObjectData >> method. I've been looking at it lately because I'm interested in >> possibly (optionally) encrypting the sessions in the backend session >> store. But this isn't about encryption at all. >> >> The code for StandardSession.doWriteObject(ObjectOutputStream stream) >> looks like this: >> >> >> // Write the scalar instance variables (except Manager) >> stream.writeObject(Long.valueOf(creationTime)); >> stream.writeObject(Long.valueOf(lastAccessedTime)); >> stream.writeObject(Integer.valueOf(maxInactiveInterval)); >> stream.writeObject(Boolean.valueOf(isNew)); >> stream.writeObject(Boolean.valueOf(isValid)); >> stream.writeObject(Long.valueOf(thisAccessedTime)); >> >> >> Is there any reason we are writing object wrappers for these primitive >> members instead of just writing the primitives directly? > > That code goes all the way back to at least Tomcat 3.1.x (20+ years ago). > >> It turns out that the byte stream is identical whether one uses >> objects or primitives, > > That surprises me. Looking at the JRE source code it really surprises > me. So much that I am going to go and try it for myself.
My testing shows the opposite. There is a significant difference between writing primitives and writing objects. Given backwards compatibility requirements we can't change this in 9.0.x and earlier. > One reason we might want to stick with writing objects is to support > sessionAttributeValueClassNameFilter. I'm only going from reading the > source so I could easily have missed something but it looks like that > will only work if we write/read objects. We only care about this for session attributes. We know our internal attributes are safe so we could switch to primitives in 10.0.x. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
