On 20/09/15 15:41, Claude Warren wrote:
When a class is loaded, the <init> is not run. That happens on first use.
Not sure about OSGI but in standard classloaders
Class.forName( X ) will initialize X when it is loaded
Class.forName( X, false, ClassLoader) will not initialize X.
So I suspect that a lot of code will do the static initialization. :(
Not in Jena :-)
ServiceLoader does Class.forName( X, false, ClassLoader)
There is only one Class.forName at issue here - the one in IO_Ctl. And
that has gone.
The calls in RDFReaderFImpl/RDFWriterFImpl are "same artifact" so
pointless and should be removed.
For maximum compatibility, move the Class.forName loading to the
setReaderClassName operation for now. I suggest we deprecate the
functionality in favour of RIOT.
The only use case is really using jena-core without RIOT and wanting
custom readers/writers. That's obscure and given the old reader/writers
have various idiosyncrasies, there's no evidence users that actually
upgrade are using it.
A better viewpoint to me is the one we have: jena-* artifacts are
internal structure (-> changable) of the code base, apache-jena-* are
external deliverables. This gives the project flexibility to evolve
while maintaining a contract with users.
(As noted elsewhere: including TDB in the apache-jena artifacts is 0.5M
of code which isn't much these days.)
Andy
On Sun, Sep 20, 2015 at 3:08 PM, [email protected] <[email protected]>
wrote:
When a class is loaded, the <init> is not run. That happens on first
use.
Ah, this is what I did not understand correctly. Okay, no problem.
IMHO JenaSystem.init is a step in the right direction and better way than
the current way initialization is done.
No argument here.
What would be helpful at this point is concrete improvements/alternatives
and concrete evaluation esp in OSGi. [*]
I would like to do that, but I am still working JENA-624, _very_ slowly
(bits of Sunday afternoons only). Ah, the joys of all-volunteer projects,
right? {grin}
---
A. Soroka
The University of Virginia Library
On Sun, Sep 20, 2015 at 9:53 AM, Andy Seaborne <[email protected]> wrote:
On 20/09/15 12:16, A. Soroka wrote:
On Sep 18, 2015, at 6:21 PM, Andy Seaborne <[email protected]> wrote:
How would people have the chance to call JenaSystem::set before those
static initializers run? Or am I misunderstanding the use of the hook?
The documentation
/**
* Set the {@link JenaSubsystemRegistry}.
* To have any effect, this function must be called before any other
Jena code,
* and especially before calling {@code JenaSystem.init()}.
*/
Touch Jena and it initialises.
Yes, this is what I don’t understand. If JenaSystem.init() is
gettingcalled in static initializers (and it is) then that means I must
somehow
call JenaSystem.set() in static code, too, or I don’t see how it happen
before JenaSystem.init(). Even then, it doesn’t seem that I can
guarantee that my JenaSystem.set() call will precede JenaSystem.init()
getting called.
This works with "*********** LOAD" printed and running with debug on:
JenaSubsystemRegistry r = new JenaSubsystemRegistryBasic() {
@Override
public void load() {
System.err.println("*********** LOAD") ;
super.load();
}
} ;
// Set the sub-system registry
JenaSystem.setSubsystemRegistry(r);
// Enable output if required
JenaSystem.DEBUG_INIT = true ;
// Initialize Jena directly or indirectly
//JenaSystem.init() ;
ModelFactory.createDefaultModel() ;
and ModelFactory has a static initializer. This is the first call to
"other Jena code". When a class is loaded, the <init> is not run. That
happens on first use.
Run the example code above uncommenting the "System.init()" and you will
see that the call in ModelFactory returns early (the recursive
initialization problem - much discussed in the comments and a well known
Java issue.) if the explicit JenaSystem.init() is used.
IMHO JenaSystem.init is a step in the right direction and better way than
the current way initialization is done.
What would be helpful at this point is concrete improvements/alternatives
and concrete evaluation esp in OSGi. [*]
Andy
http://jena.staging.apache.org/documentation/notes/system-initialization.html
[*] JENA-913 : The OSGi integration testing in the build is broken.
---
A. Soroka
The University of Virginia Library
