Hi,
Yes, should be able to use no-arg constructor with other visibility
than public. I believe that even if you don't declare one, or override
the default, most of the implementations will create one at enhance
time to be used. Note that you can also constructors with arguments
along with your non-public no-arg constructor.
You might want to take a look at the spec
<http://db.apache.org/jdo/specifications.html>, as is it might answer a
lot of your questions. This constructor question, for instance, is
clearly stated there:
"All persistence-capable classes must have a no-arg constructor. This
constructor might be a private
constructor, as it is only used from within the jdoNewInstance methods.
The constructor might be
the default no-arg constructor created by the compiler when the source
code does not define any
constructors."
Regards,
Renato
On 27/08/2010 11:22 PM, boegner-onl...@gmx.de wrote:
Thanks for answering. You are the first who replied.
I thought of making the constructors private, too. The question is
than: Is JDO able to use this constructor or it is not, because it is
private respective protected?
Actually such a class would not be a Java bean class. Every Java bean
class has to provide a public parameterless constructor, e.g. the
default constructor which is automatically there, if no other
constructors have been specified.
Can JDO handle those classes with private / protected constructors?
Does JDO work with reflection to instantiate classes for detachment?
I know it would be possible to use private class members, through
reflection, but this becomes a security issue. If JDO somehow can use
those private constructors, that would be the easiest solution.
However there are other approaches. It may be possible to configure
which attribute has to be injected with which constructor parameter.
This may be optional. Most constructors look simple like this one:
public MyPojo(int myAttribute) {
this.myAttribute = myAttribute;
}
It would be possible, to automatically analyze and use such
constructors by JDO. This would help users to write better code while
JDO stays easy in use.
Does JDO support anything in that direction? I am realistic enough,
that this won't be a new feature in acceptable time, if it is not
there, yet.
Actually this is an dependency injection issue. In this case, there
may be no global objects to inserts. Instead there may be individual
attributes taken from the datastore and injected into the object
during detachment. I am not sure if the new dependency injection API
supports anything like this. If I remember right, it can inject
references through constructors. I will read about this.
Thanks again for answering and thank in advance for any future
repliers. :D
Am 27.08.2010 08:33 schrieb Renato Garcia <renatao.gar...@gmail.com>:
> Hi,
>
>
>
> Did you get an answer for this yet? You could declare
protected/deafult constructors. Would that sovle?
>
>
>
> On 21/08/2010 2:38 AM, boegner-onl...@gmx.de wrote:
>
>
> Hello,
>
>
>
> I am new here. I looked at the archives but I did not find anything
related. Maybe a search function would be nice.
>
>
>
> Sometimes there are classes which need some other objects to work
well. When I write those classes I like to write a constructor with
those dependencies as parameters. So there is no default constructor
anymore. I think this is nice, because everyone who uses my class
can't do much wrong now. The instances are in a consistent state (at
least at initialisation time).
>
>
>
> Without a parameterless constructor the class is no bean anymore. I
can't use such classes with JDO, right? I see that it is much easier
for an persistence layer to deal with bean's parameterless constructor
instead of constructors with parameters. But I think it would be a
really nice feature of JDO to do so.
>
>
>
> Alternatively I thought about writing beans and using them as
attributes of my classes. Another alternative would be to use beans at
the persistence layer and my POJOs at application layer. In that case
there has to be an layer which converts between POJOs and beans. Both
approaches seem to work at a first look, but they require almost
double the code like a POJO only or bean only solution. For every POJO
there has a bean and maybe a converter be written. This is a huge
repetition.
>
>
>
> My questions are:
>
>
>
> - Is it right, that there is no way that JDO can deal with
parameterized constructors?
>
> - Is there a related feature at development or did you even think
about it?
>
> - Any other proposal?
>
>
>
> Thanks in advance
>
>
>
> c0d3x
<http://mail-archives.apache.org/mod_mbox/db-jdo-user/201008.mbox/%3c4c6eaf8b.7000...@gmx.de%3e>
