EJP is the next major release/fork of jPersist, and is a Java persistence framework. It is a trouble free, configuration and annotation free, framework based (as they all are) on JDBC. It is not a JPA implementation. It is much simpler and smaller (< 200K). The reason for the split is that EJP is not backwards compatible with jPersist, as EJP is far more advanced
and able to handle everything automatically. The good news is jPersist users will find switching trivial.

As most programmers realize, the definitions (xml/annotations) required of JPA/Hibernate are mostly needed for the purpose of schema generation, and not for mapping (even though both JPA and Hibernate require definitions for mapping). Since JDBC provides all the necessary metadata needed to figure out the mapping between objects and the database, these definitions aren’t actually needed unless in-code schema generation is needed.

Most of the time databases are created independent of the running application. In other words, the database team creates the database and/or you create the database, but you don’t create the database by running your application. This is also known as a separation of concerns, and is considered by many to be the best case.

If generating a schema “in-code” is what you need, then EJP is probably not going to work for you, since EJP doesn’t create the schema. However, If you simply want to connect to and use your database, EJP is perfect for you.

Connecting to your database with EJP is as simple as:

Go to rest of article

and what has it got when compared to MyBatis, SpringJDBC ? because after all that is more an apples to apples comparison.

and what has it got when compared to MyBatis, SpringJDBC ? because after all that is more an apples to apples comparison.

 

Here's a thought...read the blog post and find out.

Here's a thought...read the blog post and find out.

Here's a thought. I did and it makes no reference to iBatis/MyBatis/SpringJDBC. It only refers to JPA. If you are trying to convince people to use a product you need to make it clear what it offers over those alternatives.

I purposly don't refer to other projects to keep from starting a war, and because JPA/Hibernate is what everyone looks to as the standard.

What's so hard to understand about this:

dbm = new DatabaseManager("mydb", 5, "com.mysql.jdbc.Driver", "jdbc:mysql://localhost/mydb");

customer = dbm.loadObject(new Customer("userid"));

I don't get why you're upset.  And you commented without even looking at it.

I don't get why you're upset.  And you commented without even looking at it.

Nobodys upset sir, unless you are?. I scanned down it before posting anything here. I simply pointed out that you make a big thing about comparing with JPA like it is the most meaningful comparison and I asked a simple question ... what are its benefits relative to MyBatis, and why should I use it if I want simple JDBC-style persistence ? If you have some point where you're better then it can ease my reading and I can give it a try. If you don't, or don't have time to convince people to use it then I'll use what I know.

Again, I can simply get a connection to the database with:

dbm = new DatabaseManager(); // several methods for connecting to a database

and start using dbm methods with any java object that has corresponding database tables.  I don't have to define anything:

dbm.loadObject(new Customer("userid")); // load by userid

Customer is just a normal class.  EJP is jPersist, which has been around for more then 6 years.

and where is the primary key mapping?

Handled automatically.  JDBC database metadata tells everything about the tables and relationships, always has.  EJP simply matches that information to an object.

After reading the blog post, I think EJP is a case of JPA where the table name == the class name, the column names = the class property names ... So EJP doesn't need annotations (while JPA still needs @Table, @Entity ...).

First, EJP's syntax seems to be very close to Hibernate/JPA (judging from the examples given).

Second, the general problem of ORM is that it's necessarily a leaky abstaction. Database logic (queries, ...), implementation details (caching, ...), user configuration (propagation, ...) and user code (entities, ...) are hopelessly intermingled.

bad name and oplus create more confusion in the market full of spring JDBC, other ORM tools and JDO, JPA and what not.

this is what is bad about java.  Now a days there is just too many crazy projects out there

I started using Versant object DB three years ago. Haven't looked back since.

Frankly speaking, EJP may not meet my needs. However, I think we should support such project. Please remind that we always need some new idea for the growth of java community. EJP may inspire the next.

With the exception of schema generation, which EJP does not generate (a good thing), EJP can handle anything you would need with a relational database.  EJP is a connect and use persistence framework, where you don't have to define entities, keys, or anything else.

How does it not meet your needs (provided your needs are RDBMS related), is there something we can address?

You are introducing a tool for data persistence. In fact, JDBC can handle anything I need with a relational database.

Besides technical need, we should also consider product support, management concerns, code maintainability and so on. Technial concern is just a small part of our needs/concerns.

Anyways, thanks for your inputs!

Not new, it's a code base that has been around since 2004.  You can also think of it as a JDBC utility.  EJP generates JDBC prepared statements from your objects. That along with several JDBC helper classes makes using JDBC a lot easier.

I've been doing open-source for more than 10 years, and have answered every support request sent.  I've been supporting this project since 2004. Many other projects as well, including the MemSL since 1990.

Thanks

Good job but did somebody need to pay for a ORM library? Good attempt to obtain support with the documentation, and I suppose that is almost impossible to do serious things without ebook manual

I agree, it's impossible to fund anything via open-source, but I will continue to try.

There is a get started manual and the javadocs.  If you are in financial need, we can also be talked into giving the manual for free.

Thank you.

Yet another persistence project that doesn't offer anything besides the standard, else than... not being standard.

JPA isn't difficult and schema generation is quite easy. You can make complex models, but I guess you can do that with any tool.

"Yet another persistence project that doesn't offer anything besides the standard."

I don't understand you folks?  The first paragraph explains it is not a JPA implementation.  It would be nice if programmers at least gave a cursory review before commenting.

Thanks

"Yet another persistence project that doesn't offer anything besides the standard."

I don't understand you folks?  The first paragraph explains it is not a JPA implementation. 

One of the problems, to me, is just that: it's not standard, and it doesn't promise anything that I can't find in JPA. When I can choose between one of the 4 billion look-my-lib-is-so-much-better and a standard way to cover the same features, I definitively go for the standard way of doing things. Really, I don't even want to try. There is room enough at apache for that ;-)

It would be nice if programmers at least gave a cursory review before commenting.

To me, it's an experiment. No offence, but I'll do mine when I have too much time, and stick with JPA when I need a serious persistence framework with multiple implementations.

You're talking about something you haven't even looked at.

what I dont like about frameworks like this one is claims like "trouble free". If programming was "trouble free", I'd probably be looking for some better-paid job. And programming databases will never be trouble free, just because of the complexity of the issues involved.

Another questionable thing, IMO, are these examples "look how simple it is to connect to the db and load an object". Of course, with JPA/Hibernate this can be just as simple. But OTOH, JPA/Hibernate offer solutions for the most complex scenarios as well, and decade-long proven solutions at that.

Chris

Software development is what it is.  If you look at the Javadocs you too will see that there are several ways to obtain a connection.  Once you have a connection it's objects and SQL.  Well, since 2004, not quite a decade, but close.  As many here have, you're commenting and making assumptions about something you don't know.  If you gave it a try you would find that it will handle any case youu can through.  The reason is that you can override at many levels.  You can even do a JDBC query outside EJP, and send the result set to EJP and use it for mapping your objects.  But, there's no need to do this as EJP will handle any query.  But, I'm not going to sit here and say it's perfect.

Thanks.

+1

For example Hibernate/JPA provide inheritance mapping, with 3 different strategies in mapping. Is it possible to have them without any metadata?

Everybody seems so cranky.

Unfortunately, there's not to many compelling reasons to do open source anymore.  There's no money in it, and everyone wants to shoot you down.  I've spent the weekend answering people's comments, and they haven't even tried it.  And, I've been fighting the battle for years.

Most of these newbies on TSS still have diaper rash, don't pay them much attention. I checked out your project among other ORMS many months ago - yours was in the top tier of my list.  I was very impressed with it's simplicity although you have couple of serious issues, the first is, there's no product branding. The name of your project along with it's URL doesn't stand out from the rest; simply querying for your product returns junk. The second is, the target audience that might have been interested in something like this have left the language java for awhile. My suggestion is to migrate it to clojure or scala, they might appreciate something like this. 

Awesome, you made my day

Thank you!

For a possibly limited time, the documentation is now available.  If you support open-source software, please consider helping us.

For a possibly limited time, the documentation is now available.  If you support open-source software, please consider helping us.

I wanted to try EJP and this docs can help me! thank you.

I have been looking for such a product for a long time, one that does not fall into the obvious trap that other ORMs fall into.

I love the resembelance to Gemstones objectdb functionality for smalltalk, where persistable objects are handled completely automatically and with no fuzz. I will look more into it, and I will try to use it in a project I will be doing during the next couple of weeks. Then I can get back to you with more specific feedback on improvements and so on.

I salute your effort. Glad to see when people are thinking outside the traditional java comfort zone.

I am using EJP in my Eclipse RCP application right now, it works very well. thanks. by the way are you Chinese ?

Hi Guogang,

Thanks for your support.  Glad you like it.  I'm not Chinese, but like them very much.  I have worked with many in the U.S., and I know you are a great people.

Thank you

You may want to think about the adroid also, I think your framework is a better fit than this:

http://ahmetalpbalkan.com/blog/introducing-orman-framework/