Eugen - I could not agree with you more on not having the JsonbContext, but
there are some technical limitations. The problem (I see) with not having a
context is that you either:
1. Have to process annotations and object graph every time you want to
marshall/unmarshall an object (rather bad for performance)
2. Have to have a global cache for all classes scanned so far (with a
configurable size (?) limit, to avoid memory leak)
Yes, it would free end users from managing the context themselves, but bare
in mind that JSONB is a core middleware component but might be used by
other middleware who knows better than us how to manage their context
objects. Also, if we want to employ such global cache into RI it would
probably mean more bugs to resolve later on :)
I *REALLY like* the example you showed i.e.:
Jsonb jsonb = new Jsonb.Builder()
.setClasses(Book.class, Author.class, Language.class)
.with(new MyJsonbConfig())
.use(new SomeJsonbProvider()) // optional - by default would load
one using ServiceLoader
.use(new JsonpProvider()) // used to obtain jsonp read/write
instances
.build();
As you can see I added one line to provide a config (could implement
javax.json.bind.JsonbConfig interface). I think that having a config class
is more flexible and powerfull than just setProperty method. In such case I
would drop system properties thing - it would be a job of the config class
to define where and how to pick up the Jsonb properties. JsonbConfig could
also define which provider to use etc.
Just one question - I see use() called twice - which one wins? What's the
difference between two providers in your example?
Last comment on ServiceLoader. I'm not a big fan of it and it seems I'm not
alone:
http://stackoverflow.com/questions/7039467/java-serviceloader-with-multiple-classloaders.
I already had many issues with it in production using JAX-WS. I had to
extend a bit CXF provider with custom behavior, which was the easiest part.
The problem appeared when I wanted my provider to be picked up by app
server. If you have in you classpath more than one service provider it's
the classloader who decides which one will be used - not you. And it might
differ from one OS to another (e.g. because of case sensitive JAR paths).
It was a big pain and when you use ServiceLoader you cannot really
explicitly say which provider you want to use - which is a showstopper for
me.
Cheers,
Przemyslaw