On Jun 11, 2007, at 1:32 PM, Turadg wrote: > Not sure if this is of any use but I ran across it and though I'd > send it along. This is basically an alternative to EMF, right? Interesting, I was just thinking about EMF and using POJOs for doing the same thing.
Using POJOs with the Java persistence API could be an alternative to how EMf is used for sending data to the SDS. But in general it doesn't really solve the same things that EMF does. Persistence is just one part of EMF, perhaps the bigger part is the consistent model structure. Because the EMF uses something more than just "Class" like a POJO, (it uses EObject), it is possible traverse the model in a much more generic way. So even if your code knows nothing about an instance of an EObject it can introspect its meta model/class and find out a lot about it. It can find all the fields and their types, it can find out default values. And if it is a list it can find out the type of the objects in the list. In 1.4 the defaults and list types couldn't be specified, in 1.5 the list types can be specified with generics, but the defaults cannot easily be. (xmlencoder does a trick to get the defaults, but it makes the whole thing pretty complicated). With annotations a POJO can be marked up to include all this type of information. And that is what the Java Persistence API does. Then a library can be used which takes the POJO and uses the annotations to figure its "meta-model". The difference with EMF is that that meta- model is actually another model. So when you ask a EObject for its meta-model you typically ask it for its EClass and then you ask the EClass for its EStructuralFeatures (attributes and references). All of those things: EClass, EStructuralFeature are actually subclasses of EObject. So the same code you use for generically editing or persisting the model you invented is also used to edit and persist the definition of that model (meta-model). On a CS level this is very elegant. It is like a compiler that compiles itself, or a program which prints itself. But on a practical level, it isn't clear if this is a worthwhile approach. It has a lot of benefits for code reuse. But it hasn't caught on a whole lot outside of the eclipse community, so it isn't clear if it is an approach which resonates with developers. On a compatibility level, the EMF models that we are using for the SDS could be processed to create the correct POJOs so the Java Persistence API can use them. I wouldn't be surprised if someone hasn't already created an eclipse plugin to do this. And vice versa, I would expect there to be a plugin which can generate a EMF model from a set of POJO annotated for the Java Persistence API. Most likely though, any code that uses one or the other would have to also be slightly changed. Scott > > > > Sent to you by Turadg via Google Reader: > > > Using the Java Persistence API on the Desktop > via Java Technology Headlines on Jun 07, 2007 > > Learn how the Java Persistence API allows you to use POJOs in > desktop applications. > > > > Things you can do from here: > Visit the original item on Java Technology Headlines > Subscribe to Java Technology Headlines using Google Reader > Get started using Google Reader to easily keep up with all your > favorite sites > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
