Sorry George this didn’t work for me

Ahh I'm so sorry. That's what comes of doing this on the plane and not checking through all the bugs I fixed on there. Fixed now. Sorry dude!

That was fast

That's because it was already fixed in my local branch :P

Backend: tested most core stuff (menu, articles, categories, modules etc): all good!
Front end: all works fine

Big improvement in loading times in front end!
About the comment for com_checkin: this seems to be an unrelated problem with debug on!

Didn’t check with 3rd party apps

So far @test is pass

From an architecture perspective, I like it much better than the current situation in Joomla! 2.x / 3.x :)

However, you are breaking backwards compatibility in the public JSession::getInstance() method. A simple way to maintain b/c would be modifying JSession::getInstance() to check if the last parameter is null, i.e.

if (is_null($handlerInterface))
{
    $handlerInterface = new JSessionHandlerJoomla($options);
}

where $options is fetched... somehow (don't ask me and I won't tell you any lies).

This way existing code will still work and will be interoperable with Joomla! 2.5 and 3.0 through 3.3. I do not have any code using direct instantiation of JSession –I only use JSessionStorage::getInstance to get a storage object and call its gc() method when purging the session– but I suspect that someone, somewhere, possibly in a custom JApplicationWeb application, might be using it.

Then again, if there is no way to fetch $options there should be an informative exception thrown, letting the developer know that they need to instantiate a session handler object. Putting a URL with a short example in the method's DocBlock would work wonders, I assume. And, of course, this kind of b/c breaking behaviour must be documented. Where? I don't know, ask the PLT :)

I did that in the constructor? I've changed it from the native handler to the Joomla handler though to be b/c like you mentioned.

Sorry, I was looking at the diff and missed the constructor entirely.

Don't worry :) If that looks good to you then that makes me feel a lot more relieved :P

@test OK

In an OAuth2 authorization workflow, internal information is saved in JSession. User leaves the site and after the external authorization step, the information is retrieved from JSession to complete the auth token retrieval.

RTC based on testing by @anibalsanchez and @compojoom Thanks!

@wilsonge can you update the @since and copyright dates bevor committing?

So, as an additional validation on this PR, using the new JSessionHandlerNative class, I am able to get sessions working on PHP 7 (see #7143 for more). With the JSessionHandlerJoomla class, we get nowhere. So on this.

Merged to 3.5-dev via e36e879