We Keep Coding

use Jinq for hibernate

I would like to be able to write linq-style specific queries in java using jinq (http://www.jinq.org/index.html) and the java 8 streams. However, in the set-up section it says you need to use the JPA entityManagerFactory (http://www.jinq.org/docs/queries.html#N65755). In my project I am using hibernate and the sessionFactory. Does that mean that I cannot use jinq at all or there's some workaround?

Simple viewing of the javadoc for "JINQ" shows very clearly that they take in a JPA "EMF", so you have to use JPA to use it.
I see no downside of using JPA. You can easily enough dip in to vendor specifics when you really need to and still use JPA for the majority

Difference between Hibernate library and Hibernate JPA library

In the screen where you can add the Hibernate library to a project, there are two options, Hibernate and Hibernate JPA.
What is the difference between the 2? Googling did not provide an explanation.

I found this to provide a good explanation.
http://elope.wordpress.com/2007/09/06/difference-between-jpa-and-hibernate/
From the above blog:
So if i need to put in Concise words:
a) JPA is Persistence Api which your code should use.
b) JPA Api will pass on the call to actual peristence provider (ex:Hibernate/TopLink) to do the actual work.
c) If you are looking from Performance prespective ,it will be dependent on actual peristence provider (Hibernate/TopLink) and not on JPA as its just a wrapper layer.
d) If you are looking from code dependency prespective ,JPA makes more sense as your code is dependent on standard Java Api.
e) If you have used Hibernate then you will find that certain features are missing in JPA like criteria queries etc.This does not mean that you can’t write criteria query in your application, you need to get Session object from JPA Entity manager and now you are as good as in hibernate project.
But now your code is dependent on Specific impl (Hibernate),going forward you can see more things getting added in JPA (2.0)
f) Should you use JPA: My take is you should ,API is clean and although not everthing you need is their but is a good step forward.

I don't know what "screen" you mean, but in general you can use Hibernate directly (Hibernate API) or as a JPA provider. As JPA is a standard API one can code against this API and switch between implementations (Hibernate, EclipseLink, OpenJPA, ...). When using Hibernate API you are tied to this but you can utilize features that are not standardized by JPA.

Hibernate or JPA?

With Spring 3.0 is it recommended to use hibernate or JPA.What are the advantages and disadvantages of both of them when used with Spring 3.0 ?
Note : We are also suppose to use it with Spring Data Access.

I would say, JPA implementation provided by Hibernate. Why? Because
It would be easier to switch to some other JPA implementation later, if you you ever need to
Hibernate is the one of the major and most popular ORM around
Lot of books available
Extensive documentation, awesome reference material
Easy to get support on SO, and elsewhere
Actually, I don't mind to use Hibernate exclusive features too. I don't see any problem in sticking with Hibernate, just because its not an standard. And by the way, what makes you think Spring is standard. Its not, and you are fine with it, because it works. Similar thing can be said for Hibernate. Hibernate sometimes get hairy, if you don't know well what you are doing.

My preference is JPA with EclipseLink. Reasons:
JPA is standard, Hibernate is not
Use EclipseLink because JPA with Hibernate has some weird implementation. EclipseLink is also the reference implementation for JPA 2.0
Bozho: there are some that I found, unfortunately it is not so obvious because it only happens in some extreme cases. Some that I can think:
Convert JQL to CriteriaBuilder
ElementCollection works fine with JoinTable, which is wrong! ElementCollection should be accompanied by CollectionTable.

To be precise, you should use the Java Persistence API, and then you can use Hibernate as an implementation.
JPA without an implementation isn't worth anything.
JPA is a standard, so if you only use it's API, you can substitute Hibernate with some other JPA implementation. If you use some of Hibernate's specific API because you need functionality not provided with plain JPA, you'll have a vendor lock-in scenario, so you'll have to be careful about this.

It depends on our application.
If you are not sure that you will never need to change your persistence provider, it is strongly recommended to use JPA (2.0)
If you are sure that you never will change your persistence provider, than I recommend using JPA (2.0) too. But (only) in this case you have the possibility to use a proprietary feature of you choosen JPA-Provider, if you have a problem not solved by standard JPA. -- But use it wise, if you choose this way once, it is hard to go back!
Of course JPA is just an API - so you need an implementation of it. -- I used Hibernate as JPA provider, but mainly because I am allways in the second scenario (will never change it), and I needed additional features like Hibernate-Search and Envers.

JPA w/o application server

I'm just writing a small java application and I would like to be able to persist the data model in a database. So I was wondering if I could use JPA for this. I used JPA some time ago, but as far as I remembered it required an application server. So I'm wondering can I just JPA to persists my classes w/o using an application server.

Yes, you can use JPA without an application server. Here's a tutorial which may help you: TopLink JPA: How to use JPA with Java SE

Yes, you can use JPA without any application server. Look at section 2.4 in this tutorial for Hibernate.

JPA is, umm, "traditionally" associated with application servers because JPA is part of the Java EE spec. However, that doesn't mean individual implementations of JPA can't work outside of an app server.
I've personally done this with Hibernate, which is perhaps the most popular JPA implementation. The Hibernate documentation gives you some tips about how to run Hibernate in a standalone application.

You're probably better off using Hibernate standalone; it's a bit easier to manage without the extra JPA layer on top. There isn't that much difference anyway.

No J2EE server present in this tutorial
http://www.datanucleus.org/products/accessplatform/guides/jpa/tutorial.html

JDO integration with hibernate

in JPA, to use hibernate, the only thing need to do is moodify persitence.xml and add in hibernate configuration. May i know with JDO, can just by modifying jdoconfig.xml, able to integrate with hibernate? any reference or example on this?

No, the reason it works on hibernate+JPA is the JPA specification was developed to be "compatible" with hibernate since hibernate is the dominant persistence API. The tech leads wished that people could move to JPA from hibernate easily.
Furthermore, the JPA specification is not as rigorous or detailed as JDO and thus it is a little more onerous to support JDO (This applies on JPA 1.0, don't know if later versions of JPA bring it more into line with JDO).
The JDO specification was developed independently of hibernate and thus cannot be switched onto JDO.
One obvious difference between hibernate/JPA and JDO is that JDO does not support annotations (it's a pre java 5 specification).

You can explore this through ObJectRelationalBridge:
http://db.apache.org/ojb/docu/tutorials/jdo-tutorial.html
Also, I am sure hibernate shall support JDO once JDO gets accepted as the primary way to do things.
JDO is Object Abstraction and it can be supported on any kind of database, however its implementation on Object Data Bases, it is more natural. Google App engine supports JDO since many years.