Enable cache retrieval where runtime type enforcement is enabled.

[jerrinot]

CacheManager has Iterable<String> getCacheNames();.

However there is no way to discover what types were configured for a given cache name. However without knowing a type it's impossible to retrieve a cache from CacheManager.

Related issue: #339

[cruftex]

+1

[smillidge]

+1

This is the issue I raised at the JavaOne JCache BOF but couldn't explain very well as I couldn't remember the API !

[chrisdennis]

Thinking out loud (and not really thinking that hard if I'm honest). Would it be better/cleaner to have a type agnostic retrieval method that returns Cache? Then the cache could be interrogated for it's type by retrieving it's configuration? I vaguely recall this being suggested when we introduced the option of stricter type checking on caches.

[cruftex]

Would it be better/cleaner to have a type agnostic retrieval method that returns Cache?

The actual interface is type agnostic. You can retrieve arbitrary typed caches with it. However, the semantic isn't type agnostic. The semantic says that its technically a Cache<Object,Object>, which means the cache is not restricting and checking the types (which is only true for storeByReference in reality anyways...).

I think we should investigate whether we can make getCache(name) type agnostic and not being identical in semantic of getCache(name, Object.class, Object.class). That means getCache(name) should return any cache, if known. There are good reasons for it:

• getCache(name) would be the intuitive way to get access to a cache, which name is returned by the iterator
• We cannot add a new method to the interface (in Java 6)
• The JavaDoc says: This method may only be used to acquire {@link Cache}s that were configured without runtime key and value types, I think that cannot be true for any environment, since there will be always configurations that restrict the usable types (e.g. copier and serialization)
• The exiting semantic is available with getCache(name, Object.class, Object.class), we don't need to provide this in two methods, Furthermore, its more clear if explicitly specified, that users really want to make sure that they get a cache able to store arbitrary objects (do they?)

[cruftex]

In short, the mismatch is:

The signature is now:

  <K, V> Cache<K, V> getCache(String cacheName);

So I can request a cache of arbitrary types like:

  Cache<String, BigDecimal> cache = manage.getCache(cacheName);

But getCache() requires that the configured cache types are Object, Object.

We should make getCache() return any cache with that name.

[brianoliver]

This can’t really be allowed as any cache configured with a type can then be changed to some other type at runtime, without type checking.

eg: If an application configures a Cache with Strings for keys and Dogs for values, but then you allow

<K, V> Cache<K, V> getCache(String cacheName);
To work on any cache, you then permit the following:

Cache<String, Cat> catsCache(“animals-cache”);

Cat mrFits = …;

catsCache.put(“Mr Fits”, mrFits);

ie: You completely allow a Dog cat to be corrupted with a Cat.

You either have type safety, or you have none. There’s no “half way”.

So I can request a cache of arbitrary types like:

Cache<String, BigDecimal> cache = manage.getCache(cacheName);
But getCache() requires that the configured cache types are Object, Object.

We should make getCache() return any cache with that name.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #340 (comment)

[cruftex]

This can’t really be allowed as any cache configured with a type can then be changed to some other type at runtime, without type checking.

Yes, you can do that. But that's no worse then before. You can do right now:

Cache<String, Dog> dogCache = manager.getCache("cache");
Cache<String, Cat> catCache = manager.getCache("cache");
dogCache.put("sammy", new Dog());
catCache.get("sammy"); // => boom!

Or:

 ((Cache) manager.getCache("cache",String.class, Dog.class)).put("sammy", new Cat()); 

There is no runtime type checking, never was. A cache needs to implement it explicitly.

[cruftex]

I can understand Brains' argument insofar, that the current semantic may save a user from a mistake, but it is no strict enforcement. On the other hand the current semantic makes simple things complicated or impossible. E.g. how would a piece of code look like that clears all caches of a cache manager?

[brianoliver]

There is no runtime type checking, never was. A cache needs to implement it explicitly.

This is not true. Implementations can provide runtime checking.

You’re talking about changing the semantics of the API.

If you don’t want any runtime checking, then we should propose it and remove it completely in version 2.0 (but maintain back-wards compatibility as required).

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #340 (comment)

[cruftex]

My:

There is no runtime type checking, never was. A cache needs to implement it explicitly.

Should be read as:

You cannot do runtime type checking by the API, because of type erasure. There is no way to enforce correct typing on this level. Of course a cache can implement runtime type checking and there is nothing bad about that.

Anyhow, it was an idea, that doesn't mean that we do not need to carefully check all the implications and the effort that might bring with it. Other ideas?

[brianoliver]

You cannot do runtime type checking by the API, because of type erasure.

Correct.
There is no way to enforce correct typing on this level.

Unless the types are specified and/or configured, which allows implementations to perform runtime checking.
Of course a cache can implement runtime type checking and there is nothing bad about that.

If we remove the type parameters all together, implementations won’t even be able to achieve runtime type checking. There’d be no way to provide types in a standard manner for implementations to check them. Suddenly “type-checking” would become an implementation-specific, non-standard feature.

A lot of thought when into the current design, backed by a lot of feedback from other groups that had to face the same challenges with type-erasure.

eg: We talked extensively with the Java Language team and the JPA Experts.

Anyhow, it was an idea, that doesn't mean that we do not need to carefully check all the implications and the effort that might bring with it. Other ideas?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #340 (comment)

[cruftex]

@brianoliver: Your email replies end up crippled in the GitHub issue.

If we remove the type parameters all together, implementations won’t even be able to achieve runtime type checking.

That is not what I am suggesting. Please read from the beginning.

We talked extensively with the Java Language team and the JPA Experts.

That means you neglect the fact, that after the API is implemented and now in use for a while, that there is more knowledge about it then before?

New aspects, e.g. with the EE integration, come in. Containers have different requirements on the API then an application.

On the other hand I can totally understand a general resistance of changing API semantics, even the tiniest. This comes always with pain you cannot for see in advance.

[brianoliver]

@cruftex

Have you actually tried doing the following?

Cache<String, Dog> dogCache = manager.getCache("cache");
Cache<String, Cat> catCache = manager.getCache("cache");

From what I recall, the TCK tests indicate this is not possible, which contradicts what you're saying.

That is not what I am suggesting. Please read from the beginning.

@cruftex You clearly said..

I think we should investigate whether we can make getCache(name) type agnostic and not being
identical in semantic of getCache(name, Object.class, Object.class). That means getCache(name)
should return any cache, if known.

Perhaps I'm not doing a great job here. I'm simply attempting to point out the "why" this is not possible and the impact on the API and compatibility. It's not whether I personally like it or not.

If you want to suggest something that works without breaking any implementation or the semantics of existing applications, go for it. In the meantime understand and humbly appreciate the effort that's already been invested here and not simply discount it as "something we didn't think of" or the guidance and advice from other Experts in the community or Java Platform Team, including the language designers that have been before us. Also appreciate that we invested a large amount of time in the "what if" scenarios, in which your suggestion was already covered.

@cruftex

That means you neglect the fact, that after the API is implemented and now in use for a while, that
there is more knowledge about it then before?

Totally incorrect. At no point have I done this and I find it personally offensive to suggest as such.

Again, as Leads we invested a large amount of time thinking and trailing many of the scenarios you're suggesting. The API wasn't some naive effort. We invested a lot of time reaching out to groups that have done this before (and thus seen the impact), together with the Java Language Team, including the changes you're suggesting.

As maintainers we have a duty to adhere to the rules of the JCP and the Java Platform. Those rules includes strict adherence to avoiding the possibility of breaking the API or existing semantics. This is one of the very foundations of Java development.

At this point I believe your suggestions break these rules, or change the behavior / intent of the specification which means they can't be achieved in a maintenance release. Whether I like a suggestion or not, whether I like the rules or not, those are the rules.

Ultimately I feel you're neglecting the fact that there are six or seven implementations of this specification, with potentially hundreds / thousands of systems sitting on it. While it's very easy to make breaking/radical changes when a product / project has few or seemingly no customers, the impact of even the smallest change to a standard comes at a huge cost.

@cruftex

On the other hand I can totally understand a general resistance of changing API semantics, even the
tiniest.

This is not a general resistance. Again, there are rules that prevent the changes your suggesting.

I'm certainly not against changes. I have a list of things that I would have never done in JCache and those who know me, know my frustration with the things that are in the API which I still personally believe should not be. Over the years I've invested a large amount of effort to simplify the API, not make it larger, add new features or make it more complicated. I invested more time removing "features" from the "feature soup", so that it was at least consistent, implementable and testable, rather than adding them. There's definitely a few rough edges, but it's not that bad.

If I had my way, JCache 2.0 would have even less features and methods, so it's more widely applicable to a broader range of implementations.

This comes always with pain you cannot for see in advance.

For this case, it's complete non-sense. What you're suggesting had been considered and not just in passing. Furthermore, my position on what should not be in JCache hasn't changed since it's release. In fact, it's only strengthen my views.

Moving forward I'd strongly urge you to arrange your thoughts in terms of "what can be done now" for a maintenance release v's "what has to be done in the future".

Doing this we can have constructive conversations about fixes that need to be made right now and things that we can fix in the future which need broader input, investment and discussion.

[cruftex]

My proposal, changing the semantics of getCache(name), is not possible. This will break existing applications and implementations.

There are technical ways to introduce the requested functionality in a backwards compatible way. Starting a conversation about this, needs some prioritization and directions from the Spec Leads first.

The types can be requested via JMX via the CacheMXBean.getValueType() and CacheMXBean.getKeyType() methods. This requires that management is enabled, which can be
done, via CacheManager.enableManagement by knowledge of the cache name.

The above holds for the Specification alone. I analyzed various implementations (RI, coherence, hazelcast, ehcache, infinispan, caffeine, cache2k,.... ) No implementation except Oracle Coherence
is registering with the platform mbean server at the moment. I opened this issue for that:
jsr107/jsr107tck#83