We have two system one Running with JDK 1.6 and another with JDK 1.7. To communicate between the two node we are using ProtoStuff Serialization to convert binary & transfer to other node where its again the binary is de-serialized.
JDK 1.7 added new field 'suppressedExceptions', so now if we serialize the Throwable in JDK 1.7 in one node and transfer to another node its not able de-serialize & vice versa.
As two nodes uses different technology its not possible to migrate from JDK 1.6 to JDK 1.7 & JDK 1.7 to JDK 1.6.
Is there any solution to solve this problem, Thanks in advance for the reply.
With Regards,
Pavan
Protostuff-runtime does not support backward compatibility between two class versions if new field is added to one of base classes. This is caused by tag shift - when you add new field to base classe, all tag numbers in the childred classes are shifted. So, in general, there is no good solution for your problem.
But if you switch encoding to json, then problem should disappear. With protostuff-json, fields are stored using their names (instead of tags), so adding new field in the middle of class hierarchy should not be a problem anymore.
Related
Our department has inherited code that uses Apache PDFBox 1.8.x or earlier and we are in the process of trying to migrate it to Apache PDFBox 2.0.x. I have versions of the last three major versions (1.7.x, 1.8.x, and 2.0.x) that I've looked to for guidance as well as the Migration to PDFBox 2.0.0 and the PDFBox Jira Board.
I have resolved a lot of the various issues in this migration, but I'm still having problems migrating some of the TextPosition related code. The project originally forked the TextPosition code and created setters/getters for all the internal TextPosition fields. I realize this breaks the contract of TextPosition (like Java String) being immutable, so I've pulled all that out. We still have some code that relies on the endX/endY fields, but there are no native getters for these fields and they are marked as private, so a subclass can't even access these fields. Are there any recommendations on how to access the endX/endY values?
Also, related to TextPostion, it looks like the PostionWrapper class was dropped on 2.0.x, but I can't find any reference to a replacement for it. What should we use in place of PositionWrapper?
This issue has been resolved by #Tilman adding getters for endX and endY (and for some more values) to PDFBox; for details see the PDFBox issue PDFBOX-3576 created by the OP. The new getters are available from PDFBox version 2.0.5 onwards.
An alternative for the OP would have been to access the members via reflection. But reflection might not be allowed in all contexts, and members which are now part of the public API are less likely to break over time.
I have unknown data which I get it straight from query/datatable How do I use WebApiContrib.Formatting.Xlsx library? which it asks me to have a model for every xlsx reports. I have tried to generate dynamic class from datatable but it doesnt seem working.
This will be possible with the 2.0 release, which supports custom column resolvers and more robust serialisation for ExpandoObject. You can grab the prerelease version now on NuGet, and I plan to document the new functionality over the nice big break I have coming up soon.
We are having a pdf which when opened in Acrobat Reader shows a version of 1.5 but when using Pdfbox(version 1.8.3) the version shows 1.3.
The code that we are using:
`aDocument.getDocument().getVersion()`
where aDocument is an instance of PDDocument.
Pdfbox version we are using is 1.8.3
Any help regarding this will be highly appreciated.
Hitesh Saliya already discussed that PDF in his question Adobe showing incorrect PDF Version (of PDF) in Properties. In this answer it became appearant that
version 1.3 was correct if one only takes the version header into account (there are no Version catalog entries in the document to consider);
at least version 1.5 was correct if one also took into account that object streams, cross reference streams, layers, and transparency are used.
In a way, therefore, both PDFBox and Adobe Reader are correct.
Thus, one first has to decide what one considers the version of a PDF document to be.
Is it the version the PDF file claims to be?
As a special case, what about PDFs claiming different versions? E.g. different entries in header and catalog, or different entries in different incremental updates.
Is it the version a chosen indicator program (e.g. Adobe Reader in a fixed version) recognizes for the PDF?
Is it the smallest / the largest version according to the respective PDF reference/specification the PDF is valid?
Could even any version in that range be a correct answer (resulting not in the version but the versions of a document)?
Some mixture of the above, e.g. the maximum of the version claimed and the lowest version according to which the PDF is valid?
Seriously, though, one can hardly expect anything more than option 1 to be implemented in a general purpose PDF library.
I have 2 libs: owls.jar and envy.jar. They depends on lib jena.jar but two differnet, incompitables versions. envy using old version - jena.jar, owls new - jena2.jar
I want to use them togever at web application running on glassfish-3.0.1. I`m using IDEA 11 for deploying my web app.
I have directory tree like this:
webapp/web-inf/lib/envy.jar
webapp/web-inf/lib/owls.jar
webapp/lib/envy/jena.jar
webapp/lib/owls/jena2.jar
I add into manifest.mf of envy and owls libs class-path like this: ../../lib/envy/jena.jar
I use -verbose:class option and I always get loaded class from jena.jar.If I`m using or not using envy.jar at all, I always get loaded class from jena.jar. Only if I delete envy.jar then classes loads from jena2.jar
Is there are any way to use both of this libs?
The only way to use 2 different version of the same class is to laod them through 2 different classloaders. That is you have to load owls.jar__and __jena.jar with one class loader and envy.jar and jena2.jar with another. This solution has its own pitfalls, you should probably right custom code that will be able to use another classloader when it's necessary, maybe you will end up with writing your own class loader.
As far as I know there is no built in solution for such situation. May be, it is easier to use older version of one the jar's above that can support the same version of jena.jar This is much easier solution.
Will there be any difference in the bytecode or the compiled code using different JDKs(eg: 1.4 & 1.5 in this case). If so, how would a JVM recognize and address it at runtime?
The class file format has version information in it.
See the Java class file format. The major_version and minor_version fields are used to differentiate different versions of class files.
And yes, there can be differences. For instance, JDK1.4 didn't support generics. It couldn't load classes that contain them (produced by a 1.5 compiler).