Java Persistence API allows mapping an entity class to a table with no primary
key.  This is currently supported in JavaEE SDK 5, SJSAS 9.0 PE, Glassfish,
Toplink, and Hibernate Entity Manager.  But in NetBeans 5.5 beta 2
entity-class-from -db wizard, all tables without primary keys are grayed out, so
users can't use this feature.

Some glassfish users reported this problem at forum (in Chinese):
http://gceclub.sun.com.cn/NASApp/sme/jive/thread.jsp?forum=22&thread=39131

The reason he/she is asking this question is, his company used C and Informix 7
before, and it has been working pretty well for 7 years. They don't know why
these tables have no primary key (most only have unique index), since original
developers have left.

Now they are working on a new project, and evaluating EJB 3 (persistence) for
possible use.  They need to use these legacy data, but don't want change the
database structure.  They have hundreds of tables like this and some talbes
contain several million records. 

Some more info from discussion on dev@glassfish.dev.java.net around August 1, 2006:
[Marina Vatkina]
NetBeans will have hard time distinguishing between unique keys for
the purpose of PK and for e.g. 1-1 relationship (or any other unique
key for that matter). But NetBeans should allow (if it doesn't) to map
existing classes to existing tables with entity PKs mapped to unique
keys. 

[Gordon Yorke]
NetBeans could let the user specify the unique columns on the table before
generation if the are no PK's defined in the table Metadata, or generate the
tables and allow the user to add the @Id annotation to the code at a later stage.

[Craig Russell]
I was one of the people with input to the original design decision (5  years
ago) to disallow generation of persistent classes where there  was no primary
key column in the table. We did not try to guess if  the user intended that one
of the unique constraints was supposed to  map to an identity field.

As I understand it, during generation of the class, the wizard needs  additional
user input or needs to take a guess as to which unique  constraint should map to
@Id. It's not clear what a rational default  should be in the case that there
are multiple unique constraints that  might be mapped. And since the Id field is
immutable after persist,  it's not clear that you would have a usable class by
mapping such a  table.

A feature in the wizard to guess the Id of a table without a primary  key can be
added but wasn't part of the original design specification.

I'd suggest filing a feature request in Glassfish/Netbeans so we can  track it
formally.