I'm writing a class to provide some logging output in JSON format.
One issue is that the various Java projects I work on already use JSON and have dependencies on 3rd party libraries like gson or Jackson.
The work the class needs to perform is quite small and I figured it should be easy to avoid creating a new dependency on any particular JSON library, analagous to SLF4j which picks up whatever logging framework is already present.
My plan is that the class would pick up a JSON engine and use it, or throw a "missing JSON library" exception at start-up.
Does this already exists? I can't find anything on the net.
Is the Java JDK service provider java.util.ServiceLoader suitable?
It seemed easy enough to implement when I used it to plug in a java.nio.file.spi.FileTypeDetector for mime type detection with Apache Tika (best explained on this useful blog post.
You could try Class.forName(), passing the full name of the core class for Gson, Jackson, or whatever other JSON library is in use. If the class is not on the classpath, you will get a ClassNotFound exception. If you did this test only once, the cost would be reasonable.
In Java SE/EE, you can generate a Java model from an XML schema and then marshal and unmarshal Java to XML or JSON. The marshallers use reflection and annotations which are not available for most Java mobile APIs which have more or less a Java 1.4 compatibility level.
Is there any existing solution for Java-to-JSON binding on such restricted platforms that does not use platform specific APIs (e.g. Android)?
A possible approach might be an XJC plugin that suppresses annotations and adds marshal() and unmarshal() methods to each model class.
See also: Is there a need in JAXB implementation for Android?
I have not seen such solutions.
It is surely possible to workaround both annotations and reflection by generating the marshalling/unmarshalling code directly in schema-derived classes - just as you suggest. Actually JAXB 1 worked in this way in many senses. However I'm not sure if there's a pressing need for such technology.
ps. I've implemented a JAXB analog for JavaScript (compiler is based on XJC) so it would be definitely possible.
There is a solution named JSONx Framework, but it requires jdk1.8 at the least.
I want to retrieve list of member variables of a specified class along with other information like datatype, size, value,etc. This is possible using Reflection class. But is there any way other than Reflection class to get this information?
Thanks in advance.
The only other way I'm aware of is via source-code analysis, with tools like Spoon.
Yes introspection may help you apart from Reflection
Just use the methods provided by the field class of your class. See object Class.
reflection, this is actually easiest way to do that
parsing source code using generated compiler (antlr project has java grammar file), it's a little bit more complicated and will require additional dependencies in your project, this is suitable only in case you have source code
reading java class file and analyzing it, the most complicated. you'll have to create a java bytecode parser to read binary file. But this could be the fastest way (no additional deps LALR-k parsing, no overhead like in reflection), you'll be in control what to read, how to read, could work with compiled java code.
The question is why do you think reflection is not suitable for you?
It made much faster in java 1.5 comparing to previous java releases.
The org.springframework.util.ReflectionUtils class is actually quite the helper in these cases.
Apache commons-lang package has a very useful tool: ReflectionToStringBuilder. Here is the link to javadoc: http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/builder/ReflectionToStringBuilder.html
I am implementing a log server in C++; that accepts log messages from a Java program (via log4j socket appender). How do I read these java logging objects in C++?
You should configure the log4j appender to send XML format messages. Then it is simply a matter of reading XML in C++.
Serialized java objects is a byte stream which need meta information from the Java Runtime to be able to reconstruct the java objects. Without that meta information available in the system you must add that information yourself, which is tedious and error prone. I second the idea of sending XML instead - that is what XML serialization was invented for :)
Another very fast way of language-agnostic serialization is protobuf. proto-files (meta-files that describe your data-structures) are compiled using protoc which writes IO-code for various target languages.
I'm using it in my app and did some benchmarking which might give you a clue if it serves your purpose.
The only downside I'm aware of is that protobuf does not handle references at all. If one of your objects contain the same object twice it will be written twice instead of just once with a reference to the previous instance (which is the case with Java serialization).
Concerning your original question, I agree with Thorbjørn that reading and writing of serialized Java objects will be too hard and error prone.
If you consider going the protobuf way, feel free to use this logging event protobuf file as a starter.
json is the best way to go for this kind of problems.
Log4cxx is a Log4j port to C++, perhaps you can glean some ideas from that or even use it directly?
JSON! JSON! JSON! JSON!
What's the simplest-to-use techonlogy available to save an arbitrary Java object graph as an XML file (and to be able to rehydrate the objects later)?
The easiest way here is to serialize the object graph.
Java 1.4 has built in support for serialization as XML.
A solution I have used successfully is XStream (http://x-stream.github.io/)- it's a small library that will easily allow you to serialize and deserialize to and from XML.
The downside is you can only very limited define the resulting XML; which might not be neccessary in your case.
Apache digester is fairly easy: http://commons.apache.org/digester/
JAXB is newer and comes with annotation goodness: https://jaxb.dev.java.net
XStream by the folks at Thoughtworks has a simple API and even deals with things like duplicate and circular references. It seems to be actively developed and is well documented.
http://x-stream.github.io/
Use java.beans.XMLEncoder. Its API is very simple (actually a little too simple; it'd be nice to wire it to a SAX ContentHandler), but it works on many graphs out of the box, and it's easy to create your own persistence delegate for any odd-ball classes you might encounter.
The syntax used by XMLDecoder allows
you to invoke any method, instance
or static, including constructors,
so it's extremely flexible.
Other encoders name
elements and attributes after class
and field names, so there's no fixed schema for the result. The XMLEncoder's
XML follows a simple DTD and can
easily be validated or transformed,
even when you've never seen the
types it uses.
You can assign objects an
identifier, and reference them
throughout the graph.
You can refer to constants defined
in classes or interfaces.
And, it's built into Java SE, so you don't need to ship an extra library.
Simple
Although XStream and JAXB can serialize an some object graphs succssfully they can not handle very complex graphs. The most powerful solution for large complex graphs is Simple XML Serialization. It can handle any graph. Also, it’s fast and simple to use without any dependencies.
To quote the Simple project page:
Simple is a high performance XML serialization and configuration framework for Java. Its goal is to provide an XML framework that enables rapid development of XML configuration and communication systems. This framework aids the development of XML systems with minimal effort and reduced errors. It offers full object serialization and deserialization, maintaining each reference encountered. In essence it is similar to C# XML serialization for the Java platform, but offers additional features for interception and manipulation.
The Simple API is, well, simple! It's really good. http://simple.sourceforge.net/
You can also use XStream: http://www.ibm.com/developerworks/library/x-xstream/index.html
JAX-B is part of the standard APIs and really easy to use.
If you need control over the XML that gets generated, I recommend taking a look at Betwixt (http://commons.apache.org/betwixt/) - it adds a lot of functionality to Apache's digester (Digester is good for building object graphs from XML, but is not so good for generating them).
If you really don't care about the XML that gets generated (just that it can be deserialized in the future), then the XMLEncoder/Decoder classes built into Java or good - as long as the objects you are serializing follow the JavaBean specification. The biggest area I've run into problems with the XMLEncoder/Decoder solution is if you have a bean that returns an immutable list for one of it's properties - the encoder doesn't handle that situation very well.
If you need to control the structure of the XML, the XStream is a good choice. You can use annotations to define precisely the structure/mapping of the XML and your objects.
I'd second (or third) XStream. It reads and writes XML without needing any special binding configuration or placing lots of extraneous syntax in the XML.
I put together a list with a lot of xml serialization libraries and its license
XStream is very simple http://x-stream.github.io/
XStream is a simple library to serialize objects to XML and back again.
java.beans.XMLEncoder perhaps?
Jackson
The Jackson Project is a processing and binding library for XML, JSON, and some other formats.
… Jackson is a suite of data-processing tools for Java (and the JVM platform), including the flagship streaming JSON parser / generator library, matching data-binding library (POJOs to and from JSON) and additional data format modules to process data encoded in Avro, BSON, CBOR, CSV, Smile, (Java) Properties, Protobuf, XML or YAML; and even the large set of data format modules to support data types of widely used data types such as Guava, Joda, PCollections and many, many more…
If you are really only interested in serializing your objects to a file and then deserializing them later, then you might check out YAML instead of XML. YAML is much easier to work with than XML and the output files are very human-readable (which may or may not be a requirement). Check out yaml.org for more information. I've used JYAML successfully on a recent project.