Dear Nikolaos,
What about doing it lazily yourself?
public Long getCreated() {
if(this.created==null) {
this.created = System.currentTimeMillis();
}
return this.created;
}
Kind regards,
Egon.
-----Oorspronkelijk bericht-----
Van: stripes-users-requ...@lists.sourceforge.net
[mailto:stripes-users-requ...@lists.sourceforge.net]
Verzonden: maandag 5 juli 2010 5:12
Aan: stripes-users@lists.sourceforge.net
Onderwerp: Stripes-users Digest, Vol 50, Issue 3
Send Stripes-users mailing list submissions to
stripes-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/stripes-users
or, via email, send a message with subject or body 'help' to
stripes-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
stripes-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Stripes-users digest..."
Today's Topics:
1. Re: Model Initialization: Action Bean Populate vs. JPA Load
(Rick Grashel)
2. Re: Model Initialization: Action Bean Populate vs. JPA Load
(Thomas Menke)
3. Re: Model Initialization: Action Bean Populate vs. JPA Load
(Nikolaos Giannopoulos)
4. Re: Model Initialization: Action Bean Populate vs. JPA Load
(Nikolaos Giannopoulos)
----------------------------------------------------------------------
Message: 1
Date: Sun, 4 Jul 2010 14:33:40 -0500
From: Rick Grashel <rgras...@gmail.com>
Subject: Re: [Stripes-users] Model Initialization: Action Bean
Populate vs. JPA Load
To: nikol...@brightminds.org
Cc: Stripes Users List <stripes-users@lists.sourceforge.net>
Message-ID:
<aanlktik2xwkmkzuzhsaroeghpmp6gi4c1sc2ojtsm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Nik,
If you truly want to eliminate unneeded instantiation, then I would promote
the "created" variable into a first-order entity. Have its fetch type be
set to lazy.
But I personally think all this is a little overkill. I would say that if
you are concerned about adding a simple long... you have other problems.
So following your first instinct, why not do it the simplest way and then
load test it? If it truly represented a problem, it wouldn't be hard to
refactor. The workarounds you are discussing are bound to make the code
ugly and not easy to understand or maintain.
It really sounds like you are trying to solve a problem that may not exist
at all. Over-optimization is as bad of an anti-pattern as any.
-- Rick
On Jul 4, 2010 1:31 PM, "Nikolaos Giannopoulos" <nikol...@brightminds.org>
wrote:
Rick,
Thanks for the response. That is a great idea "except" that once again it
results in: Unnecessary object creation and unnecessary garbage collection.
Imagine having say 6-12 of these types of things and logging in say a 100
users... thats an extra 600-1200 "unnecessary" objects that get created and
discarded immediately. Now imagine logging in a 1000 users... 6000-12000
"unnecessary" objects created and discarded.
And in our case it is even worse as we have several Embedded objects in each
model... so you are "unnecessarily" creating the Embedded object wrapper as
well e.g. we have a TimestampDetails class that retains "created" and
"updated" times so even if we init only the "created" then we have 2 objects
getting created there... so the 6-12 objects per model is quite "real".
Some might try to argue that I am trying to prematurely optimize and that is
bad but "unnecessary" and moreover in this case pointless object creation
should always be avoided in any system as these types of oversights always
seem to bite back when in Production.
Any other ideas? Thoughts???
--Nikolaos
Rick Grashel wrote:
>
> Nikolaos,
>
> Why not simply initialize the variable in the User class ...
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Sun, 04 Jul 2010 21:40:26 +0200
From: Thomas Menke <stripe...@cipher-code.de>
Subject: Re: [Stripes-users] Model Initialization: Action Bean
Populate vs. JPA Load
To: nikol...@brightminds.org, Stripes Users List
<stripes-users@lists.sourceforge.net>
Message-ID: <4c30e3aa.5060...@cipher-code.de>
Content-Type: text/plain; charset=ISO-8859-1
Nikolaos Giannopoulos wrote:
> Hi,
>
>
> Unfortunately we can't have the same zero argument constructor coded 2
> different ways...
Yes, you can: If you derive from your class
class UserInitialized extends User
{
public UserInitialized() { super(); /* Do some initialization */}
}
That might be an option depending on your requirements. Just need to use
the UserInitialized class in your jsp's.
Or you could have a a bean that does the initialization:
class UserInitializer
{
User getInitializedUser() {User u = new User(); u.setFoo("bar");
return u; }
}
How do you load your user bean in the first place? If you use a getter
method of an action bean you could to the initialization in that getter
method.
>
> --Nikolaos
Yannik
------------------------------
Message: 3
Date: Sun, 04 Jul 2010 22:54:47 -0400
From: Nikolaos Giannopoulos <nikol...@brightminds.org>
Subject: Re: [Stripes-users] Model Initialization: Action Bean
Populate vs. JPA Load
To: Rick Grashel <rgras...@gmail.com>
Cc: Stripes Users List <stripes-users@lists.sourceforge.net>
Message-ID: <4c314977.6080...@brightminds.org>
Content-Type: text/plain; charset="iso-8859-1"
Rick,
Comments in-line... .
Rick Grashel wrote:
>
> Nik,
>
> If you truly want to eliminate unneeded instantiation, then I would
> promote the "created" variable into a first-order entity. Have its
> fetch type be set to lazy.
>
I honestly don't see how setting fetch type to lazy resolves the issue.
This is not a complex graph or something that needs to be loaded or
anything. This is about initialization of a Data / Model Object... I
don't see how delayed reloading will help... if anything if there are
enough small objects lazy loaded then this only degrades performance.
> But I personally think all this is a little overkill. I would say
> that if you are concerned about adding a simple long... you have other
> problems.
>
Please read my reply. It's not a simple Long. 100 user log-ins results
in 600-1200 OBJECTS needlessly getting created. 1000 user logins
results in 6000-12000 "objects" needlessly getting created. And that is
for 1 type of object... there are literally 2 dozen other model
objects... all but the simplest object face this issue i.e. any Data /
Model Object that requires some sort of implicit initial value has this
issue.
Objects in Java that are not referenced are automagically GC'd but that
has a price in a) unnecessarily consuming more Java Heap than is
necessary and b) in CPU resources to do so. So NO this is a very real
problem in the real world. What I gave you was a rudimentary example of it.
> So following your first instinct, why not do it the simplest way and
> then load test it?
>
Because that wasn't what I said - I said: "_Some might try to argue_
that I am trying to prematurely optimize and that is bad, but
"unnecessary" and moreover in this case pointless object creation should
always be avoided in any system, as these types of oversights always
seem to bite back when in Production."
> If it truly represented a problem, it wouldn't be hard to refactor.
>
So an analogy of this would be to say - in your home - produce a lot of
extra garbage not because you have to but just because you can - and
then do a study to see if you produced a significant amount of garbage.
Isn't it better to not unnecessarily inflate the amount of garbage you
are going to produce? It is going to end up somewhere? It may not tip
the tide or cause an environmental catastrophe but if the unnecessary
extra garbage can be avoided... wouldn't it be preferable to avoid
producing the extra garbage.
Refactor what? Yes that is a wonderful canned answer but I'm not sure
you clearly understand what I am trying to do here. This is a "general"
problem in this space and in this age of automagically constructed Data
/ Model objects where in in some cases intialization is required and in
other cases because the data will be overloaded it is not wanted.
<rant>
I don't think enough developers have the opportunity to work as system
admins OR performance tune existing systems... to see the challenges
that some Java systems have with tons of unnecessary object creation,
continuous garbage collection, CPU spikes, processes falling over, and
horizontally and vertically adding servers or upgrading hardware to
accommodate until systems / software can be re-written... is a very
common occurrence.
</rant>
> The workarounds you are discussing are bound to make the code ugly and
> not easy to understand or maintain.
>
Your assumption is that there is no elegant solution to this problem.
Just because the problem appears difficult to solve does not mean that
the code will be ugly and not easy to understand or maintain. I don't
see the basis for such an argument when nothing beyond a trivial
solution has been explored i.e. the solution of attribute assignment vs.
an initialize method called automatically from the constructor are
pretty much the same.
> It really sounds like you are trying to solve a problem that may not
> exist at all. Over-optimization is as bad of an anti-pattern as any.
>
So you "never" have had a case where a Data / Model object requires
implicit initialization... e.g. a creation time stamp, a score that must
start at 0, an embedded object, etc... . I guess it is quite entirely
possible and if so you are correct then I guess there really is no
problem...
Please read the above and my original post and replies. This is not
premature over-optimization... this is prudent development... and there
is a huge difference IMO. Over-optimization is in making an algorithm
or an architecture far more flexible or robust than it need be... this
is about building an architecture were I don't have to compensate by
tossing in extra hardware / servers because the developers didn't have
the sense to implement with some basic foresight. Algorithms should be
well written and that is not to be confused with over-optimization.
Cheers,
--Nikolaos
> -- Rick
>
>> On Jul 4, 2010 1:31 PM, "Nikolaos Giannopoulos"
>> <nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
>>
>> Rick,
>>
>> Thanks for the response. That is a great idea "except" that once
>> again it results in: Unnecessary object creation and unnecessary
>> garbage collection.
>>
>> Imagine having say 6-12 of these types of things and logging in say a
>> 100 users... thats an extra 600-1200 "unnecessary" objects that get
>> created and discarded immediately. Now imagine logging in a 1000
>> users... 6000-12000 "unnecessary" objects created and discarded.
>>
>> And in our case it is even worse as we have several Embedded objects
>> in each model... so you are "unnecessarily" creating the Embedded
>> object wrapper as well e.g. we have a TimestampDetails class that
>> retains "created" and "updated" times so even if we init only the
>> "created" then we have 2 objects getting created there... so the 6-12
>> objects per model is quite "real".
>>
>> Some might try to argue that I am trying to prematurely optimize and
>> that is bad but "unnecessary" and moreover in this case pointless
>> object creation should always be avoided in any system as these types
>> of oversights always seem to bite back when in Production.
>>
>> Any other ideas? Thoughts???
>>
>> --Nikolaos
>>
>>
>>
>> Rick Grashel wrote:
>> >
>> > Nikolaos,
>> >
>> > Why not simply initialize the variable in the User class ...
>>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Sun, 04 Jul 2010 23:12:04 -0400
From: Nikolaos Giannopoulos <nikol...@brightminds.org>
Subject: Re: [Stripes-users] Model Initialization: Action Bean
Populate vs. JPA Load
To: Thomas Menke <stripe...@cipher-code.de>
Cc: Stripes Users List <stripes-users@lists.sourceforge.net>
Message-ID: <4c314d84.1060...@brightminds.org>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Thomas and Levi for your suggestions. I'll answer you together... .
Levi - I'm not really looking for a JPA solution. In fact, if the
approach of having no implicit initialization and the boolean argument
constructor fully satisfies the JPA side... the issue that remains is on
the Stripes Action Bean population side where by no implicit
initialization is a problem.
Thomas - inheritance could work but it amounts to a lot of skeletal
concrete subclasses... also the initialization is outside the class
itself and although not a problem in itself as you could set attributes
to be protected or simply accept calling setters on parent attributes I
think there is a more elegant approach.
Before you both replied I had an idea which I am going to try out and
come back and explain... .
Thanks Everyone. Cheers,
--Nikolaos
Levi Hoogenberg wrote:
> You could probably hook into Stripes' population strategy (and set new
> objects' /created/ property), but it sounds like you would much rather
> like a JPA solution (some kind of interceptor).
Thomas Menke wrote:
> Nikolaos Giannopoulos wrote:
>
>> Hi,
>>
>>
>> Unfortunately we can't have the same zero argument constructor coded 2
>> different ways...
>>
>
> Yes, you can: If you derive from your class
> class UserInitialized extends User
> {
> public UserInitialized() { super(); /* Do some initialization */}
> }
> That might be an option depending on your requirements. Just need to use
> the UserInitialized class in your jsp's.
>
> Or you could have a a bean that does the initialization:
> class UserInitializer
> {
> User getInitializedUser() {User u = new User(); u.setFoo("bar");
> return u; }
> }
>
> How do you load your user bean in the first place? If you use a getter
> method of an action bean you could to the initialization in that getter
> method.
>
>
>> --Nikolaos
>>
>
> Yannik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
End of Stripes-users Digest, Vol 50, Issue 3
********************************************
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
