Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief

Discussions

News: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief

  1. Cameron Purdy talks about the Oracle Coherence 3.4 with new support for C++. Cameron tells us about important new features such as: * Cross-platform support for Java, .Net, and C++ objects * Data grid triggers * Event transformers Organizations where applications are developed on multiple platforms and programming languages benefit from the new API, which shares the same features and calls across Java, .Net, and C++. Multi-threading and event handling are built into the C++ API. Last, he talks about how the Coherence team built Java-like memory management for C++ and how they made Coherence 3.4 work on many of the operating systems running on Intel-like processors. (Click here if you can't see the video.) Playback time: 5'48" Cameron is Vice President of Engineering at Oracle and has over ten years of experience with Java and Java-related technology. He is a frequent presenter at industry conferences and has received a number of awards in recognition of his contribution to the Java community. Cameron regularly participates in industry standards development and is the specification lead for JSR 107 (jCache).

    Threaded Messages (22)

  2. Nice presentation. One question if I may: why there is no visible activity on JSR 107 since 2001, and is there any kind of downloadable documents produced by committee? Should we (community) consider JSR 107 dead? Thanks http://jcp.org/en/jsr/results?id=99
  3. One question if I may: why there is no visible activity on JSR 107 since 2001, and is there any kind of downloadable documents produced by committee?
    Such a spec or API would not be in the best interests of vendors, and could only cater to a very limited and simplistic functional subset. The biggest problem is that none of these caching products should exist in the first place - they are workarounds but not value-add per se, which only comes from their respective proprietary / distinguishing features.
  4. One question if I may: why there is no visible activity on JSR 107 since 2001, and is there any kind of downloadable documents produced by committee?


    Such a spec or API would not be in the best interests of vendors, and could only cater to a very limited and simplistic functional subset. The biggest problem is that none of these caching products should exist in the first place - they are workarounds but not value-add per se, which only comes from their respective proprietary / distinguishing features.
    that has got to be a joke. data grids have more than proved their value. peter
  5. that has got to be a joke. data grids have more than proved their value.
    I didn't claim otherwise. In fact, that was exactly my point.
  6. that has got to be a joke. data grids have more than proved their value.


    I didn't claim otherwise. In fact, that was exactly my point.
    my fault. I mis-interpreted the comment. it read the opposite to me at first. now I see you meat data grids proved their value and worked around existing limitations of other products. peter
  7. Such a spec or API would not be in the best interests of vendors, and could only cater to a very limited and simplistic functional subset.
    I disagree. Since the caching APIs would provide for faster adoption of advanced technology such as Data Grids, I think it is in our best interest to standardize caching features. I believe that it's even in our interest to open up the Data Grid APIs themselves, but that's obviously a much harder one to prove business-wise at this moment ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  8. I disagree. Since the caching APIs would provide for faster adoption of advanced technology such as Data Grids, I think it is in our best interest to standardize caching features.
    I understand the adoption rationale, but think that it is not of much use even to customers. The real adoption problems - APIs/configuratoin to access uncommon features, runtime properties, deployment, management, vendor dependability etc. are much more important. I mean, how helpful is it when you start using the common API, switch backends and realize you have to rewrite everything anyway because important features are not available anymore, or new ones are? My primary point was that nobody *wants* caching. People want access to their data (preferrably in the old DB that they already have), or messaging, or real-time notifications/event processing etc. They merely have to put up with a bunch of different products & vendors because of the technological realities of RDBMS and the amorphous constraints of all possible use cases.
    I believe that it's even in our interest to open up the Data Grid APIs themselves, but that's obviously a much harder one to prove business-wise at this moment ;-)
    Then how would a vendor differentiate? IMHO the end result would only be a conflation of the ecosystem into probably two vendors (to uphold the illusion of choice) and a great loss of architectural flexibility for customers at increased cost. Oh wait, I see. :->
  9. One question if I may: why there is no visible activity on JSR 107 since 2001, and is there any kind of downloadable documents produced by committee?
    There is an API available on java.net: https://jsr107.dev.java.net/ .. and Greg Luck has been working on EHCache to provide an RI. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  10. Your C++ API sucks[ Go to top ]

    Dear Oracle Coherence C++ developers, your C++ API sucks. Using Java-like API in C++ is NOT a good idea.
  11. Re: Your C++ API sucks[ Go to top ]

    Dear Oracle Coherence C++ developers, your C++ API sucks.

    Using Java-like API in C++ is NOT a good idea.
    Yes, far be it from us to make code readable and less error-prone ;-) Do you have any specific questions or concerns about the API? FWIW - The feedback that we've received so far from customers who are using the API has been very positive over all. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  12. Re: Your C++ API sucks[ Go to top ]

    Do you have any specific questions or concerns about the API?
    Yes. 1) Stop calling reference counting 'automatic memory management for C++'. It's not. 2) Stop writing YET ANOTHER smart pointer package. Use http://boost.org/ 3) While you're at it - look in Alexandrescu's 'Modern C++ Design' how to write good C++ strings. 4) Use more C++ capabilities - copy constructors and guaranteed destructors. "CacheFactory::shutdown()" is ABOMINATION. 5) I do not like the whole system of Managed objects and views/handles. And the main problem: please, please, please. Stop reinventing the wheel and just use Boost for serialization, containers, datetime packages, etc.
    FWIW - The feedback that we've received so far from customers who are using the API has been very positive over all.
    Yes, it's very Java-like, so it's a good fit for poor Java developers who are forced to write C++. But it does not feel like a good modern C++ library. PS: We use Coherence in Java with great success.
  13. Re: Your C++ API sucks[ Go to top ]

    2) Stop writing YET ANOTHER smart pointer package. Use http://boost.org/
    We wanted to use Boost, but there were a number of issues that prevented us from using it, including the lack of threading support in the library and a corresponding complete lack of thread safety. We could have probably implemented the "Data Client" functionality with it, but not the Real-Time Client (event handling threads etc.)
    FWIW - The feedback that we've received so far from customers who are using the API has been very positive over all.

    Yes, it's very Java-like, so it's a good fit for poor Java developers who are forced to write C++. But it does not feel like a good modern C++ library.
    I worked in C++ for 10 years and I never felt like I encountered a good C++ library ;-) Drop me an email (first name dot last name at oracle dot com). I'd love to get your feedback directly to a couple of the architects on the C++ project.
    PS: We use Coherence in Java with great success.
    That's great to hear! Let's see what we can do to achieve the same with C++ :-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  14. Re: Your C++ API sucks[ Go to top ]

    We wanted to use Boost, but there were a number of issues that prevented us from using it, including the lack of threading support in the library and a corresponding complete lack of thread safety.
    ???? http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety
    I worked in C++ for 10 years and I never felt like I encountered a good C++ library ;-)

    Drop me an email (first name dot last name at oracle dot com). I'd love to get your feedback directly to a couple of the architects on the C++ project.
    Sure.
  15. To Boost or not to Boost?[ Go to top ]

    Everyone has a favorite API/programming language/operating system/type of coffee (or tea for me). Everyone has their opinion on what they "feel" is good or bad about an API (and usually expresses it very vocally on TSS/slashdot etc.). In the end however, no matter how important we may feel these things are, commercial reality shows that neither of these things really have as big an impact as to what we personally think they do/should/could. The challenges when designing complex APIs (like Coherence C++ for example), and actually delivering an implementation (it took us a few years) is that they are often less technical than we think. That is, the majority of people don't care so much about the API (seriously), but it's the "other" challenges that must be addressed. Ok... API is certainly important up-front, but after that, it's everything else. For example, things like; is it easy to integrate, can be supported across a large variety of platforms, can it be supported 24x7x356 in multiple languages, are there resources to do this, does it interoperate with well-defined-semantics and other systems (without library compatibility problems), can it be used in production with potentially 1000's (or 10,000's) of people/organizations/projects for mission critical systems. API design is just one part of a huge array of challenges. That's not to "shrug it off", but it's just one part. As we understand from nearly 10 years of experience in this space, the most important part about providing products that manage mission critical data on a day-to-day basis is stability. People/organizations "at risk" will always adopt a stable solution over something that is moving. There's an appropriate religious concept here and regardless of all our religious beliefs it's simple: Build on a solid foundation and not on quicksand. Coherence C++ wasn't a rush job. Historically it's been in design for many years, much longer than we wanted and certainly longer than many of the capabilities of Boost have been around. Coherence C++ also wasn't designed in isolation and we involved as many customers as possible throughout the entire process (and also tried to avoid the "designed-by-committee" approach). We also produced many prototypes. We had many organizations (outside Oracle) participate in building prototypes for us (some very respected C++ shops). We even took (at lot of) time to look at what was internally available with in Oracle - ie: our own IP. At the end of the day we had some very clear feedback from our customers. 1. It had to be stable. People wanted the reliability they experienced with the other Coherence platforms - Java and .NET. 2. No third-party APIs. People wanted to avoid all dependencies on other third-party APIs. They were *sick* of having to a). upgrade/patch/fix solutions due to third-party libraries changing, b). being told that the development/production issue was with a third-party, and c). having to manage third-party runtime dependancies. They wanted a single library (like Java and .NET) and that's it. 3. It had to be feature-for-feature compatible with the other Coherence implementations. (unlike most of the other solutions in this space - Coherence C++ has all of the API features of the Java and .NET versions). Of course, there were a bunch of other requirements (like platforms etc), but the above three became mandatory requirements and essentially made it impossible (from a customer adoption point-of-view) to use any third-party library. Not a great place to be in trust me. But we listened to customers... they had seen other attempts at Data Grid C++ APIs and told us clearly - 1,2 and 3 are mandatory. So... it's nothing against Boost or any other API that could have made our lives easier. We would have adopted another solution if we could - instead of doing it ourselves. It wasn't our goal to build another framework, but it's clearly paying off as we don't have the kinds of stability issues customers are telling us about with other approaches (like embedding everything in a JVM, or embedding a JVM/CLR implementation in a C++ library). We also know every corner of the code, because it's all ours. We don't have to wait on other people (except compiler manufacturers) to fix defects... let's not mention how defective some C++ compilers are. I guess the things we've never heard (well I certainly haven't working directly with customers) are that "Coherence C++ should have more pointers, copy constructors, ". These have never been issues (so far). However, if they do become issues, guess what.... tell us. The fact is, every feature in Coherence (any edition) has been driven by customer demand. That's why Tangosol was so successful building a profitable company and why Coherence continues to be the market leader. It's based on real customers, real partners doing real things. Of course... there are still things I would like changed in Coherence (I was a customer of Tangosol for many years and yes, I too have my favorite APIs), but we do listen and take notice. As Cameron kindly suggests. Be involved. We want to hear from people like yourself that are actively using or want to seriously adopt Coherence C++. Design discussions for the next version or feature X of Coherence is not what TSS is meant for. We have Oracle Forums (and direct invited contact with our Product Management team) for this ;) Kindest Regards -- Brian Oracle Coherence Product Development Manager
  16. boost[ Go to top ]

    We wanted to use Boost, but there were a number of issues that prevented us from using it, including the lack of threading support in the library and a corresponding complete lack of thread safety.

    ????
    http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html
    http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety
    You're correct; I got confused. There were libraries that we wanted to use that did not include threading, but it wasn't Boost. As I understand it, having discussed this with the architect of the object model (dubbed "Sanka" .. you can figure out the origin ;-), the issue with Boost was that our customers already use it, and thus we were concerned over the possibility that our library (linked to Boost) would cause incompatibilities with the version of Boost in use by the customer's application(s). By way of example, many commercial applications use Boost, and many open source libraries use Boost, but not many commercial libraries use Boost. See: http://www.boost.org/users/uses_shrink.html Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  17. Re: Your C++ API sucks[ Go to top ]

    Drop me an email (first name dot last name at oracle dot com). I'd love to get your feedback directly to a couple of the architects on the C++ project.
    Do we need to kill an interesting debate on a public forum and take it private? I would continue to advocate usage of Coherence, even if it is found a bit wanting on use of modern C++. Please consider keeping the discussion public (or admit slashdot is better :)
  18. Re: Your C++ API sucks[ Go to top ]

    Do we need to kill an interesting debate on a public forum and take it private?
    No, definitely not. I still would like the opportunity to get the feedback directly to our engineering team though. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  19. Re: Your C++ API sucks[ Go to top ]

    Do we need to kill an interesting debate on a public forum and take it private?


    No, definitely not. I still would like the opportunity to get the feedback directly to our engineering team though.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, C++ and .NET
    Thanks - the next long response did explain the issues faced very well, we have all faced it. I do find the observation about commercial libraries not using boost very interesting. Can you please post link to Oracle forum (esp if it is reasonably public) here.
  20. Forums...[ Go to top ]

    Can you please post link to Oracle forum (esp if it is reasonably public) here.
    Here are a few links for you to take a look at: Coherence Support Forums The Coherence Incubator The Coherence Incubator Forum Rob Misek Senior Product Manager Oracle Coherence
  21. Cameron Firstly, congrats on the release. Secondly, you mentioned RIAA in the video. Did you not mean to say "RAII"? Thirdly, where was the interview? In some kind of canteen? Lovely sound effects in the background towards the end. Jason http://jasondchambers.com
  22. Secondly, you mentioned RIAA in the video. Did you not mean to say "RAII"?
    Oops, yup :-)
    Thirdly, where was the interview? In some kind of canteen? Lovely sound effects in the background towards the end.
    That was Mr. Stephens. He was apparently drying the trays in the canteen. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  23. Hello[ Go to top ]

    I am sure that the Oracle Coherence 3.4 with its new support for the C++ is really going to take the industry by storm!! I am sure that with it being able to work on many of the operating systems which run on Intel-like processors, it is really going to be a big hit in the IT industry because it will make work so much easier!!