On 14/05/2020 18:41, Christopher Schultz wrote: > Mark, > > On 5/14/20 12:53, Mark Thomas wrote: >> 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. > > Hmm. I did a micro-test with just writing a single Long.valueOf() > value and a (primitive) long alone to an ObjectOutputStream. I didn't > test the StandardSession itself.
I performed the same micro-test. >> Given backwards compatibility requirements we can't change this in >> 9.0.x and earlier. > > Agreed. > >>> 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. > > I'll have to play-around a bit to see what was wrong with my initial tes > t. JRE version? I used a newish Java 8. Long value? I used 1000. I did something stupid? Source code here: https://github.com/markt-asf/tomcat-bugs/blob/master/src/java/org/apache/tomcat/ObjectStreams.java Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
