CMake 'JNI' macro question . . .
by Matthew Harmsen
Andreas,
I would like to request your assistance on the following 'CMake' issue
requested by Adam:
* https://fedorahosted.org/pki/ticket/9
Basically, on Fedora 16 and later, the default location of Java Native
Interface (JNI) jar files was
changed to reside under '/usr/lib/java' for 32-bit platforms, and
'/usr/lib64/java' for 64-bit platforms.
Per the TRAC ticket, I made a change in the spec files to handle this
via the 'jpackage-utils' RPM.
However, I do not know if 'CMake' can change the 'JAVA_LIB_INSTALL_DIR'
macro located in
the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on
the '%{_jnidir}' macro of
'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there
is a different way of handling
this where the following logic comes into play:
* '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms)
* '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms)
* '/usr/lib/java' on Fedora 16 and later (32-bit platforms)
* '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on 64-bit
platforms)
o I am fairly confident that this case may actually REQUIRE a
compiler override, as it does
not look as if 'jpackage-utils' computes its '%{_jnidir}' macro
based upon the 'JVM' architecture
being utilized, but rather the '%{_libdir}' macro based upon the
operating system architecture
located in the appropriate
'/usr/lib/rpm/platform/<platform>/macros' file
* '/usr/lib64/java' on Fedora 16 and later (64-bit platforms)
Your assistance on this matter is greatly appreciated.
Eventually, do you think that we may want the appropriate logic added to
the '/etc/rpm/macros.cmake' file?
Thanks,
-- Matt
12 years, 4 months
Serial Version ID and Serializaed classes
by Adam
Eclipse produces a hefty number of wranings about SerialVersionID. I
think that we can safely be rid of them by accepting the autogenerated
ID. Here's what this implies:
If we ever use one of these classes in a serailzed manner where we don't
control both sides of the connection, we have to make sure that the
deserializer can read the persisted form. There are Two main cases:
serialize to a file,
serialize across a socket,
For now, the only case where we serialize is in the case of a session
failover. This is pretty much a non-issue, as the serialization is done
betwen two version of the code that are identical. Actually, we don't
even really support session failover ,but we could in theory support it.
Serialization to a file is not done, nor has it ever really bee n a
good idea. Typcially, file formats should be human readable.
Serialization to a socket is primarily done in RMI. We aren't planning
on supporting that.
Still, it pays to be careful. So, here's the deal. We take the
autogenerated ID, and that makes sure that only versions that match the
serial version ID can read the file/socket. If we change areound the
order of the member variables, change their types, add in new memebers,
etc, we will need to regenerate the SerialVersionID to make sure that
it doesn't give some wierd errors. I think that this will be caught by
code reviews, so long as people are attuned.
So, to sum up: get rid of the warning the "right" way, it is unlikely
to be a problem regardless, but lets be careful in code reviews.
Does this work for everyone? IF so, I'll create a patch.
12 years, 4 months
