I don't mind working with a product specif api. If you work with jdbc, hibernate, jms, coherence etc, as long as you keep that localized to some specialized classes, everything is alright with me. But as soon as you start seeing it all over the place, then there is a serious problem. Especially if it just as easily could have been taken out. This is not a Gigaspace problem (they provide a lot of different ways to get things done), but a developer issue: selecting the right approach for the job.
Fair enough... but I'm not sure why you painted GigaSpaces with that particular brush if it's not something GigaSpaces is unique about.
The problem is not only lock in, but also code that is easy to understand and easy to test. And the original question was not about lock in, but about a performance claims you made about Gigaspace vs Coherence (so we are definitely not on the original subject anymore).
Well, for pure datagrid operations, the tests and performance claims should be supremely easy to test: get a reference to the cache, put data in, destroy the reference; get another reference to the cache, check to see if that data's still there. Wash, rinse, repeat under load.
My point about performance was that datagrid was only part of the performance solution here.
It is not just the api, but all the remoting executing space proxies, autowiring, component scans and other junk that make easy to understand code hard to grasp. It could be that my brains are not compatible with this way of working, but I trust them when they something smells.
Again, fair enough - you have your own environment and circumstances you have to work through. But... dude, you're throwing around specific terms (from multiple products, by the way) that refer to things that are more or less hidden from you.
If you need remote execution, yes, you use a remote proxy. (Horrors! You're using RMI! Oh wait, you're not - CORBA? No... hmm, SOAP? No... oh, this is a space, so I suppose "space proxy" comes in.)
What's more, that's presented to you as something that beginners in Java should be able to handle: an interface. You configure that interface to call something remote. Just like EJB, just like a SOAP proxy, just like every other proxy.
If you can't handle an interface as a concept, you have MUCH bigger problems than the ones we're talking about here. I have a hard time believing that's the case.
Now, there's more: async remote execution muddies the waters, too.. but GigaSpaces uses the same model that java.util.concurrent uses. It's that way because it's kinda necessary if you're doing async invocation, the remote part doesn't factor in except in configuration.
I understand your frustration, I really do - but you're building a LOT of straw men here.
(And most of your complaints besides the executors - hey, wait, aren't those a standard java concept? - are based around spring configuration, not GigaSpaces. Even there, you could throw a dart at a crowd of java programmers, and you'll hit someone who understands how to use Spring almost every time.)
I don't mind programming against some vendor specific api's, but as soon they start to appear all over the place, something definitely is wrong. That is also the reason why I liked Spring in the beginning, and think it is a dead end now.
See, I'd have felt the opposite. Spring was nice-ish in the beginning but now that i spend less time worrying about configuration, it's a "live end." I don't mind having a dependency in my projects, esp. when everyone else is familiar with that dependency, for better or for worse.
I only have experience with Gigaspaces on a project for the last 7 months. But in a lot retrospectives in my team. Gigaspaces came on top of our complaints list. That is why we are trying to reduce dependency on Gigaspaces while developing. Just write normal Pojo's and leave those nasty annotations at home. But as soon as we are creating the deployment artifacts, we use everything that Gigaspaces provides.
Nothing wrong with that! But just like Spring and @Autowired and @Service, @Repository, etc., you don't HAVE to use any gigaspaces annotations in your objects at all. You get slightly suboptimal performance characteristics *sometimes* - it really depends on exactly what you're doing - but you can certainly do it with no intrusions on your code whatsoever.
But then again, the annotations definitely add value. It depends on what you want.
A Pojo with annotations is not a Pojo anymore. It is just as bad as extending some class, or adding some interfaces. If I was the only one on the teams that was complaining about this issue, I would certainly have given it more time.
I disagree (surprise!) but my point was that you didn't need to use any of the annotations; you can safely and easily disregard their use if that doesn't fit your idea of what a POJO is.
Captcha: "finesse this" -- wow.
