choosing EclipseLink over TopLink/TopLink Essentials

[Giovanni Azua]

hi all,

I was playing a bit with these three implementations in order to provide
another Generic Dao implementation other than Hibernate for the next release
of perfectjpattern. My conclusion was to go for EclipseLink rather than the
other two and the reasons are the following:

1-. EclipseLink has a open source friendly license (Eclipse Public License)
2-. EclipseLink has internal support for JPA API whereas pure TopLink does
not support some of the JPA API's e.g.

a) Creating explicit DatabaseQuery out of aSqlString corresponding to JPA
EntityManager.createQuery(aSqlString) API, you are kind of responsible to
create the appropriate DatabaseQuery subclass according to the aSqlString
e.g. new ReportQuery, ReadAllQuery or any of the other which is kind of
awkward, you would be doing a parser's job here ...
b) Pure TopLink seems not to support JPQL e.g. I tried many of its API e.g.
UnitOfWork.executeQuery and does not recognize entity names
c) Did not find any implementations of EntityManager in TopLink's source
code.

3-. EclipseLink ReadAllQuery supports the required "setExampleObject" for
implementing the DAO's findByExample.
4-. EclipseLink releases have a proper Maven 2 repository while
TopLink/TopLink Essentials do not really (they are outdated or require
manual installations)
5-. EclipseLink offers a superset of both TopLink and TopLink Essentials
e.g. OR mapping using the Workbench and TableCreator whereas Essentials does
not.

TopLink and TopLink Essentials seem two parallel branches of the same thing
but Essentials is hardly a subset of the full TopLink product:

- TopLink has support for findByExample but not a full JPA implementation
- Essentials implements JPA but does not offer findByExample neither support
for integration with TopLink Workbench e.g. TableCreator functionality.

Any advice or feedback about this would be nice.

Thanks in advance,
Best regards,
Giovanni

PS: I did not consider OpenJPA for a GenericDao implementation because it
seems not to support the functionality needed for findByExample. On the
other hand OpenJPA can be directly plugged into the BaseDao implementation.

 

[Arne Vajhøj]

I was playing a bit with these three implementations in order to provide
another Generic Dao implementation other than Hibernate for the next release
of perfectjpattern. My conclusion was to go for EclipseLink rather than the
other two and the reasons are the following:

1-. EclipseLink has a open source friendly license (Eclipse Public License)
2-. EclipseLink has internal support for JPA API whereas pure TopLink does
not support some of the JPA API's e.g.

> TopLink and TopLink Essentials seem two parallel branches of the same thing
> but Essentials is hardly a subset of the full TopLink product:

EclipseLink is also based on TopLink.

TopLink Essentials is a subset of TopLink.

EclipseLink is EPL while TopLink Essentials is CDDL - both
are valid open source licenses - and I can not see why EPL
should be more open source friendly than CDDL.

Arne

 

[Giovanni Azua]

Hi Arne,

EclipseLink is also based on TopLink.

I knew this bit ...

TopLink Essentials is a subset of TopLink.

After two days digging the source code of the two I think not e.g. TopLink
does not seem to support JPQL neither some of the JPA facilities whereas
Essentials does, therefore Essentials is not a subset of TopLink strictly
speaking.

EclipseLink is EPL while TopLink Essentials is CDDL - both
are valid open source licenses - and I can not see why EPL
should be more open source friendly than CDDL.

You are right, sorry I meant more EclipseLink compared to the "full"
TopLink.

Best regards,
Giovanni

 

[Lew]

The word "these" lacks an antecedent in this context.

provide another Generic [sic] Dao [sic] implementation other than Hibernate for
the next release of perfectjpattern. My conclusion was to go for
EclipseLink rather than the other two and the reasons are the following:

1-. EclipseLink has a [sic] open source [sic] friendly license (Eclipse Public
License)
2-. EclipseLink has internal support for JPA API whereas pure TopLink
does not support some of the JPA API's e.g.

TopLink and TopLink Essentials seem two parallel branches of the same thing
but Essentials is hardly a subset of the full TopLink product:

EclipseLink is also based on TopLink.

TopLink Essentials is a subset of TopLink.

EclipseLink is EPL while TopLink Essentials is CDDL - both
are valid open source licenses - and I can not see why EPL
should be more open source [sic] friendly than CDDL.

And there's Apache OpenJPA, also open source, though what constitutes "open
source [sic] friendly" mystifies me as much as it does Arne.

Some open-source licenses are more commercially exploitable than others, e.g.,
Apache vs. GPL.

 

[Lew]

And vice versa. TopLink *includes* EclipseLink.

I knew this bit ...

TopLink Essentials is the predecessor to EclipseLink.

After two days digging the source code of the two I think not

Hmm, how is that possible if TopLink is not "open source [sic] friendly"?

Oracle's web site clearly states that TopLink includes EclipseLink (which
replaced TopLink Essentials). Therefore, modulo the brand name, Arne is correct.

e.g. [sic] TopLink does not seem to support JPQL neither some of the JPA facilities whereas

Then why does it provide a "JPQL parse cache"?

Since EclipseLink is the subset of TopLink that provides those facilities, why
would they redundantly code those facilities in other subsets of TopLink?

Essentials does, therefore Essentials is not a subset of TopLink strictly
speaking.

You are mistaken. Oracle's web site clearly states that TopLink includes
EclipseLink (which replaced TopLink Essentials).

TopLink includes EclipseLink which is fully compliant with
the JPA 1.0 specification.

I wonder how they could claim full compliance without JPQL. Perhaps you're
mistaken?

TopLink Essentials has been replaced with EclipseLink JPA.
EclipseLink JPA implements JPA 1.0 and is responsible for
delivering the persistence framework.

Ergo, when you review the source code for EclipseLink, you review that portion
of TopLink that "is responsible for delivering the persistence framework."
Perhaps those features are not in the other sections of TopLink because those
are not the sections so responsible?

EclipseLink is EPL while TopLink Essentials is CDDL - both
are valid open source licenses - and I can not see why EPL
should be more open source friendly than CDDL.

You are right, sorry I meant more EclipseLink compared to the "full"
TopLink.

TopLink is open source, so how is it less "open source [sic] friendly" than
the others?

TopLink includes EclipseLink, therefore any statements you make about
EclipseLink apply as well to TopLink.

Conclusion: EclipseLink is a subset of TopLink. Since EclipseLink is the
subset of TopLink that is responsible for implementation of JPA, one can
hardly expect other subsets also to implement that specification.

 

[Giovanni Azua]

Hi Lew,

And there's Apache OpenJPA, also open source, though what constitutes
"open source [sic] friendly" mystifies me as much as it does Arne.

I meant EclipseLink is open whereas the full TopLink is not:
http://www.orafaq.com/wiki/TopLink#License

Yet EclipseLink offers the same, if not more functionality than TopLink e.g.
JPA.

I know Essentials is also open source but it lacks too much e.g.
- Integration with the Workbench i.e. TableCreator etc
- ReadAllQuery does not offer the "setExampleObject" functionality which is
the building block needed for implementing "findByExample"

Using perfectjpattern BaseDao (pure JPA) implementation you can plug
whatever JPA provider you want:

- OpenJPA
- TopLink Essentials
- Hibernate
etc.

Now, to exploit non-JPA features e.g. findByExample there is the GenericDao
which can only be implemented for those JPA providers who offer Query
Builders or any means to do the findByExample, AFAIK this is only offered
by:

- Hibernate
- TopLink (full product)
- EclipseLink

and not by:

- TopLink Essentials
- OpenJPA

Some open-source licenses are more commercially exploitable than others,
e.g., Apache vs. GPL.

Yep I know, in fact the next release 1.0.3 of perfectjpattern is LGPL v3 to
make it more so commercially exploitable:
http://www.gnu.org/licenses/lgpl-java.html

I preferred the LGPL over Apache because I would like to have
perfectjpattern benefit from possible improvements, extensions, etc the
"take back from the community" and LGPL officially offers this advantage.
AFAIK with the Apache license anyone could create e.g. patterns2 and publish
a rework of the same code ...

Best regards,
Giovanni

 

[Giovanni Azua]

Hi Lew,

Then why does it provide a "JPQL parse cache"?

Maybe my bad, researching latest TopLink's source code I could not find the
TopLink API accepting JPQL statements ...
http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html
Indeed, here goes the answer to my OP, I could not find this bit. So I'm
implementing the next GenericDao for EclipseLink.

Ergo, when you review the source code for EclipseLink, you review that
portion of TopLink that "is responsible for delivering the persistence
framework." Perhaps those features are not in the other sections of
TopLink because those are not the sections so responsible?

Then it is not a subset but ok I agree with you. It is confusing
specially if you look at the source code mismatches e.g. in the TopLink
source code downloaded from the link below you can't find any
implementations of EntityManager nor JpaEntityManager:
http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html

The conclusion I can make is that to take advantage of the promised
super-duper caching etc they expect you to use both deliveries EclipseLink
and the complementary TopLink together somehow ... or?

Best regards,
Giovanni

 

[Giovanni Azua]

The conclusion I can make is that to take advantage of the promised
super-duper caching etc they expect you to use both deliveries EclipseLink
and the complementary TopLink together somehow ... or?

Yes ... found the info here:

http://www.oracle.com/technology/pr...11110/relnotes/toplink-relnotes.html#BABHEEEB

http://www.oracle.com/technology/pr...11110/relnotes/toplink-relnotes.html#CHDGAEDJ

Best regards,
Giovanni

 

[Arne Vajhøj]

I knew this bit ...

After two days digging the source code of the two I think not e.g. TopLink
does not seem to support JPQL neither some of the JPA facilities whereas
Essentials does, therefore Essentials is not a subset of TopLink strictly
speaking.

http://www.oracle.com/technology/products/ias/toplink/jpa/index.html

<quote>
TopLink Essentials is the open-source community edition of Oracle's
TopLink product.
</quote>

http://www.oracle.com/technology/products/ias/toplink/jpa/resources/faq.html#2

<quote>
TopLink Essentials is the open-source community edition of Oracle's
TopLink product. It is derived from Oracle TopLink providing core
Object-Relational Mapping (ORM) functionality necessary for the
reference implementation of JPA in EJB 3.0.
</quote>

http://www.oracle.com/technology/products/ias/toplink/jpa/resources/faq.html#13

<quote>
TopLink Essentials is a subset of the functionality available in Oracle
TopLink. The initial goal of TopLink Essentials is to provide a
commercial quality reference implementation of JPA. They share the same
core Object-Relational Mapping capabilities that have been key
infrastructure of many enterprise Java application for over a decade.

Oracle TopLink offers additional functionality beyond TopLink Essentials
and the JPA specification.
</quote>

I do not have a clue about what the two TopLink versions does and
does not.

But I will assume that Oracle does.

Arne

 

[Lew]

Maybe my bad, researching latest TopLink's source code I could not find the
TopLink API accepting JPQL statements ...
http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html

Did you find it in the EclipseLink source?

Then it is not a subset but ok I agree with you. It is confusing

Wha...?

It is a subset. It is part of the larger project, contained within it and
delivered with it.
If the subset of TopLink that is EclipseLink contained code that was in other
subsets, then it would be a redundant subset.

Consider a set of features: { JPA, JDBC, HELPER, PUBLICAPI }.

Suppose that the names represent the contents, so that the {JPA} set contains
all the JPA implementation including , the {JDBC} set contains all the JDBC
implemenation, the {HELPER} set contains helper class implementations, and
{PUBLICAPI} contains the interfaces for the public API. {JPA} is a (proper)
subset of { JPA, JDBC, HELPER, PUBLICAPI }. None of the other subsets contain
JPA implementation. That does not alter a jot that {JPA} is a subset of {
JPA, JDBC, HELPER, PUBLICAPI }.

What is your definition of "subset"?

specially if you look at the source code mismatches e.g. in the TopLink
source code downloaded from the link below you can't find any
implementations of EntityManager nor JpaEntityManager:
http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html

Is that the subset of TopLink that constitutes EclipseLink?

The conclusion I can make is that to take advantage of the promised
super-duper caching etc they expect you to use both deliveries EclipseLink
and the complementary TopLink together somehow ... or?

The Oracle web site clearly states that TopLink includes EclipseLink, the
latter being the part that implements JPA.

 

[Lew]

Yes ... found the info here:

http://www.oracle.com/technology/pr...11110/relnotes/toplink-relnotes.html#BABHEEEB

This web page contains the information:

This release includes the following new features:
* Includes EclipseLink, which provides JPA, SDO, and JAXB support

This confirms what I said, that EclipseLink is the subset of TopLink that
provides JPA support.

http://www.oracle.com/technology/pr...11110/relnotes/toplink-relnotes.html#CHDGAEDJ

This is just a link further down the same page.

You receive these libraries not with "both deliveries EclipseLink and the
complementary TopLink together somehow", but with the single download of
TopLink that happens to include the JPA libraries, just as documented in the
Oracle links that you and I both provided.
<http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html>

I really don't understand your issue. The products are not "complementary";
one is included in the other as part of the standard download in a single ZIP.

 

[Giovanni Azua]

Did you find it in the EclipseLink source?

yep

Wha...?

Consider a set of features: { JPA, JDBC, HELPER, PUBLICAPI }.

[snip]
What is your definition of "subset"?

That's it. If you open the download toplink_111101_en.zip and extract
"toplink-src.zip" you will find e.g.

{ HELPER, PUBLICAPI, XXX }

If you extract "eclipselink-src.zip" you will find e.g.

{JPA, YYY}

is {JPA, YYY} subset of { HELPER, PUBLICAPI, XXX } ??? ehhhh no!

But I finally got it looking at the release notes, the full download of
TopLink includes several separate jars that build up the full TopLink, I
assumed before that the toplink.jar was the full "TopLink" and that
assumption was wrong.

Many thanks for the clarifications ok I admit I was a bit confused

Best regards,
Giovanni

 

[Lew]

I meant EclipseLink is open whereas the full TopLink is not:

The full TopLink includes EclipseLink. And the TopLink download includes its
source, at least. Given that the product is free and the source freely
available, I'm not very concerned with whether the license is technically open
source unless I'm foolish, er, brave enough to want to modify the source.

http://www.orafaq.com/wiki/TopLink#License

They seem to describe the license only for the old version of TopLink, not the
current version, given that they only mention TopLink Essentials and not its
replacement, the EclipseLink subset of TopLink.

06-MAR-2007 10:15 AM Today, at the EclipseCon Conference, Oracle,
a newly appointed Eclipse Board Member and Strategic Developer,
announced it will donate its award winning Java persistence framework,
Oracle® TopLink, to the open source community.

Yet EclipseLink offers the same, if not more functionality than TopLink
e.g. [sic] JPA.

How can EclipseLink offer more than or even the same functionality as TopLink
when it's a proper subset of TopLink? Your statement makes no sense. Since
EclipseLink is the subset of TopLink that provides JPA, it would be redundant
for other subsets of TopLink to do so.

I note that in my download of TopLink the EclipseLink JARs are included as a
subset of the installation.

I know Essentials is also open source but it lacks too much e.g.
- Integration with the Workbench i.e. TableCreator etc
- ReadAllQuery does not offer the "setExampleObject" functionality which is
the building block needed for implementing "findByExample"

Using perfectjpattern BaseDao (pure JPA) implementation you can plug
whatever JPA provider you want:

- OpenJPA
- TopLink Essentials
- Hibernate
etc.

Now, to exploit non-JPA features e.g. [sic] findByExample there is the GenericDao
which can only be implemented for those JPA providers who offer Query
Builders or any means to do the findByExample, AFAIK this is only offered
by:

- Hibernate
- TopLink (full product)
- EclipseLink

EclipseLink replaces TopLink essentials.

and not by:

- TopLink Essentials

EclipseLink is the new version of TopLink Essentials. It rather makes sense
that new features might be added in a new version of a product, don't you
agree? I don't think it's a valid criticism of a product that earlier
versions lacked something that they later added. If you need a feature that
only exists in a more recent version, use the more recent version.

- OpenJPA

First you complain that TopLink doesn't support JPA (which it does, via its
EclipseLink subset), then you complain that other JPA providers don't
implement non-JPA features.

In any event, it seems that TopLink, its proper subset EclipseLink, and
Hibernate meet your needs.

 

[Lew]

Did you find it in the EclipseLink source?

yep

Wha...?

Consider a set of features: { JPA, JDBC, HELPER, PUBLICAPI }.

[snip]
What is your definition of "subset"?

That's it. If you open the download toplink_111101_en.zip and extract
"toplink-src.zip" you will find e.g. [sic]

{ HELPER, PUBLICAPI, XXX }

That's one subset of TopLink.

If you extract "eclipselink-src.zip" you will find e.g.

{JPA, YYY}

That's a distinct subset of TopLink.

is {JPA, YYY} subset of { HELPER, PUBLICAPI, XXX } ??? ehhhh no!

No, but both are proper subsets of TopLink, {JPA, YYY, HELPER, PUBLICAPI, XXX,
ZZZ }. Ehhhh, yes.


Your argument is specious. You show that each subset is distinct, and not
redundant with the other. Both are subsets of the overall product, which is
the point. Each subset is resonsible for a different, non-overlapping part of
the overall functionality. That's just how the product is organized. It
proves my point.

You kept referring to the "full" TopLink. I note that both of the ZIPs you
mentioned are included in toplink_111101.zip, a fact you conveniently omit
from your discourse, and that there are other subsets of TopLink not included
in either of those sub-ZIPs: xml.jar, glassfish.jaxb_2.1.6.jar,
coherence-eclipselink-src.zip, and more.

Showing that a proper subset of the full product doesn't include everything in
the full product, as you did, is a rather trivial point.

 

[Giovanni Azua]

Hi Lew,

You kept referring to the "full" TopLink. I note that both of the ZIPs
you mentioned are included in toplink_111101.zip, a fact you conveniently
omit from your discourse, and that there are other subsets of TopLink not
included

I got into this confusion because I initially did not fetch the zip from
Oracle download page but from Maven repositories, therefore EclipseLink was
one module distributed from Eclipse repos and TopLink a separate one. It was
then not obvious at all.

Now that I finally understood and it all makes sense.

regards,
Giovanni

 

[Giovanni Azua]

They seem to describe the license only for the old version of TopLink, not
the current version, given that they only mention TopLink Essentials and
not its replacement, the EclipseLink subset of TopLink.

All these just added up to my full confusion

How can EclipseLink offer more than or even the same functionality as
TopLink when it's a proper subset of TopLink? Your statement makes no
sense. Since EclipseLink is the subset of TopLink that provides JPA, it
would be redundant for other subsets of TopLink to do so.

It is indeed redundant in a way and that also added up to my confusion, both
modules TopLink and EclipseLink contain many overlapping class definitions
(not interfaces) e.g. ReadAllQuery exists in both jars toplink.jar and
eclipselink.jar but supporting mismatching functionality. I guess they have
not pruned the jars completely and some redundancy still exists.

EclipseLink is the new version of TopLink Essentials. It rather makes
sense that new features might be added in a new version of a product,
don't you agree? I don't think it's a valid criticism of a product that
earlier versions lacked something that they later added. If you need a
feature that only exists in a more recent version, use the more recent
version.

I was not criticizing but asking which product to use I looked at the
separate distributions coming from Maven repositories, noticed the
differences and was puzzled by it.

This proofs once more that when everything else fails ... one must read the
documentation

First you complain that TopLink doesn't support JPA (which it does, via
its EclipseLink subset), then you complain that other JPA providers don't
implement non-JPA features.

I did not complain, I just stated a fact. The findByExample is a nice
feature to have which is not part of the JPA standard, some vendors support
it, some not. This is the reason why perfectjpattern can't offer a
GenericDao implementation of OpenJPA.

In any event, it seems that TopLink, its proper subset EclipseLink, and
Hibernate meet your needs.

Agreed

Best regards,
Giovanni

 

[Lew]

Agreed

I am pleased and relieved to see all this straightened out.

It is interesting that you got your TopLink build from a Maven repository.
Isn't that generally indicative of an open-source nature to the project, or do
you have a special licensing agreement with Oracle?

In general, when I'm a mere user of a software package such as TopLink, I
prefer binary builds when available, from the standard download link. I
rarely if ever do repository downloads unless I'm either going to work on the
package or there is no other way to get it. I hope that means that I'm
usually getting the most stable available build.

With respect to TopLink (for Oracle 11g), Oracle's verbiage on the web site
and the materials in the downloaded ZIP provide a consistent view. I did have
trouble determining what part(s) of it are open source and which aren't, but
the fact that it's free and includes source code is a plus.

I'm pretty impressed with Oracle, both its products and the company.