search

eishay / jvm-serializers

Benchmark comparing serialization libraries on the JVM
http://groups.google.com/group/java-serialization-benchmarking
3.29k stars 562 forks source link

Fixed the Jaxb/aalto Benchmark and added a simple Jaxb Benchmark. Add… #58

Closed dhermanns closed 9 years ago

dhermanns commented 9 years ago

…ed ms to the logging.

I created annotated Media-Classes for Jaxb to work. Think that could be useful for someone else since Jaxb is widely used (and seems to be badly slow in comparison to the other tools ;-).

cowtowncoder commented 9 years ago

Sounds good in general, but are new value classes really needed? For most other non-schema-based (and code-generating) frameworks a little bit of annotations may be needed, and are added in the shared case. Would this not work with JAXB? Or at least sharing some/most value types?

dhermanns commented 9 years ago

As described e.g. here: http://blog.bdoughan.com/2012/07/jaxb-no-annotations-required.html

You may workaround certain annotations e.g. like the @XmlRootElement and add this information programmatically. But I'm not sure if this can be done e.g. for the @XmlAccessorType annotation.

So i would argue that at least i need the duplicated value classes here ;) . But since I believe that this is the common usecase to have jaxb annotations, i think it's a good idea that the benchmark uses the annotations, too.

cowtowncoder commented 9 years ago

@dhermanns I did not mean you have to get by without annotations, but that there is no shame in adding annotations into the shared value classes: they already have a few annotations. What is the harm there? Serialization frameworks typically do not make use of annotations of other packages; even Jackson which may optionally use JAXB annotations only does so if specifically requested to. So I am trying to understand why you don't think it is possible to add those as necessary to existing value classes.

As to accessor type, do you really get an exception? My experience has been that as long as field and getter/setter agree it is legal to define various accessor types. Or, alternatively, why not allow use of getter/setters over fields? That's pretty common and I have not had problems with that.

The reason for copied, modified classes so far has been mostly for cases where source code generation is needed, f.ex. by protobuf. It is bit of a pain to manage parallel type hierarchies.

dhermanns commented 9 years ago

Ah ok - if mixing up the value classes with different annotations is no problem for you, than I can change it that way (when I find the time ;). I agree - this should work for Jaxb as well.

You can use getter over fields as well - that should work. But I had the problem that the default, if you specify nothing at all, was not working for me. Tatu Saloranta notifications@github.com schrieb am Fr., 23. Okt. 2015 um 16:56:

@dhermanns https://github.com/dhermanns I did not mean you have to get by without annotations, but that there is no shame in adding annotations into the shared value classes: they already have a few annotations. What is the harm there? Serialization frameworks typically do not make use of annotations of other packages; even Jackson which may optionally use JAXB annotations only does so if specifically requested to. So I am trying to understand why you don't think it is possible to add those as necessary to existing value classes.

As to accessor type, do you really get an exception? My experience has been that as long as field and getter/setter agree it is legal to define various accessor types. Or, alternatively, why not allow use of getter/setters over fields? That's pretty common and I have not had problems with that.

The reason for copied, modified classes so far has been mostly for cases where source code generation is needed, f.ex. by protobuf. It is bit of a pain to manage parallel type hierarchies.

— Reply to this email directly or view it on GitHub https://github.com/eishay/jvm-serializers/pull/58#issuecomment-150598213 .

cowtowncoder commented 9 years ago

@dhermanns Ok good, just wanted to make sure we are discussing same issue. And yes, mixing is fine, given that it has already been done and has not been problematic so far. If there are issues those need to be addressed of course, there is no law against duplicating code where it is necessary.

dhermanns commented 9 years ago

Moved the annotations to your original value classes now. Deleted my duplicated value classes. I think this should be what you suggested...

cowtowncoder commented 9 years ago

Yes. Looks Good To Me.