do not get idea behind it - in samples we definitely do no want to show how to pre-fill cache - especially with
"junk account"

Before these changes, the sample had this:

// Take first account in the cache. In a production application, you would filter
// accountsInCache to get the right account for the user authenticating.
IAccount account = accountsInCache.iterator().next();

However, it didn't make much sense to have a comment telling the user should do in a 'real' application when it'd be pretty simple to show it, so I made the getAccountByUsername() helper function to give an example of what they could do. But, with an empty cache that function would only search through a set that was "empty" or "had the one account we're looking for", which wouldn't be a very common scenario in an application with more than one user.

So, rather than having either a unrealistic example of getting an account or having no example at all, I figured adding a junk account to the cache would show a more 'realistic' flow of getting a set of accounts from the cache and searching through something that wasn't empty.

However, I'll definitely add more info the comment above that, explaining that it's only done for the sample and wouldn't be something that happens in a 'real' application.

i think we need to keep sample as close to real applications as possible, for me "fake account" sounds very far from real applications

Fair enough, I just removed accounts and TokenCacheAspect.java entirely, and I guess we can demonstrate that side of things in some new sample focused on persistence.

I also added a few more clarifying comments/printed statements about how all of the account stuff is supposed to be empty on the first run, just so users don't think they're missing something when nothing happens.

did you push latest changes ?

Sorry, looks like there was an auth issue with Git when I thought I pushed them yesterday. Just pushed them now.