|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 21
Messages: 21
Messages: 21
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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).
|
|
|
Message #271804
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #271837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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.
|
|
|
Message #271838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #271839
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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.
|
|
|
Message #271841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #271847
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #271852
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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. :->
|
|
|
Message #271871
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Your C++ API sucks
Dear Oracle Coherence C++ developers, your C++ API sucks.
Using Java-like API in C++ is NOT a good idea.
|
|
|
Message #271936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Your C++ API sucks
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
|
|
|
Message #271995
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #271996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Your C++ API sucks
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.
|
|
|
Message #271999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java, .Net and C++ Objects in Coherence 3.4: A Tech Brief
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
|
|
|
Message #272000
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Your C++ API sucks
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
|
|
|
Message #272055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Your C++ API sucks
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 :)
|
|
|
Message #272068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To Boost or not to Boost?
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, <insert C++ favorite feature here>". 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
|
|
|
Message #272136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
boost
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
|
|
|
Message #272191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Your C++ API sucks
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
