Calendar Issue

[jagadesh]

Hi Guys ,

Iam working with an DataBase Type of application. in every table is
store to database , i have 2 fields like
Created and Updated which takes calendar instances . so i used to
write like this

data.setCreated(Calendar.getInstance());
data.setUpdated(Calendar.getInstance());

iam creating a seperate instance of calendar for every created and
updated.
so i made a helper class in which i have a method like this ,


private static Calendar todaycalendar=Calendar.getInstance();

public static Calendar getCalendar(){
System.out.println(todaycalendar);
return todaycalendar;
}
i would have only one isntance right , now i would use this method
for Created and updated.

Now my question is does i would get a seperate Calendar instance for
every time i call the method.

 

[voorth]

Hi Guys ,

Iam working with an DataBase Type of application. in every table is
store to database , i have 2 fields like
Created and Updated which takes calendar instances . so i used to
write like this

data.setCreated(Calendar.getInstance());
data.setUpdated(Calendar.getInstance());

iam creating a seperate instance of calendar for every created and
updated.
so i made a helper class  in which  i have a method like this ,

private static Calendar todaycalendar=Calendar.getInstance();

        public static Calendar getCalendar(){
                System.out.println(todaycalendar);
                return todaycalendar;
        }
 i would have only one isntance right , now i would use this method
for Created and updated.

Now my question is does i  would get a seperate Calendar instance for
every time i call the method.

private static Date today = new Date();

public static Calendar getCalendar() {
Calendar calendar = Calendar.getInstance();
calendar.setTime(today);
return calendar;
}

 

[Lew]

Hi Guys ,

Iam working with an DataBase Type of application. in every table is
store to database , i [sic] have 2 fields like
Created and Updated which takes calendar instances . so i used to
write like this

data.setCreated(Calendar.getInstance());
data.setUpdated(Calendar.getInstance());

This creates two separate Calendar instances.

iam creating a seperate instance of calendar for every created and
updated.
so i made a helper class in which i have a method like this ,

private static Calendar todaycalendar=Calendar.getInstance();

Non-constant static variables are an antipattern.

In a multi-threaded application this could be very damaging.

public static Calendar getCalendar(){
System.out.println(todaycalendar);
return todaycalendar;
}

This would create only Calendar one instance initialized to the time the class
is initialized.

i would have only one isntance right , now i would use this method
for Created and updated.

Would you change the time of the Calendar instance between calls? You would
have to, but this introduces the multi-threaded danger alluded to. That would
be a problem even if the variable were an instance variable.

It's also not good to 'println()' the value every time you set it. That will
kill performance, and clutter your 'System.out' with stuff.

You buy nothing with your static method that 'Calendar.getCalendar()' doesn't
already provide, and you introduce problems by using the singleton. I
wouldn't recommend this approach.

 

[John B. Matthews]

Hi Guys ,

Iam working with an DataBase Type of application. in every table is
store to database , i [sic] have 2 fields like Created and Updated
which takes calendar instances . so i used to write like this

data.setCreated(Calendar.getInstance());
data.setUpdated(Calendar.getInstance());

This creates two separate Calendar instances.

iam creating a seperate instance of calendar for every created and
updated. so i made a helper class in which i have a method like
this ,

private static Calendar todaycalendar=Calendar.getInstance();

Non-constant static variables are an antipattern.

In a multi-threaded application this could be very damaging.

public static Calendar getCalendar(){
System.out.println(todaycalendar);
return todaycalendar;
}

This would create only Calendar one instance initialized to the time
the class is initialized.

i would have only one isntance right , now i would use this method
for Created and updated.

Would you change the time of the Calendar instance between calls?
You would have to, but this introduces the multi-threaded danger
alluded to. That would be a problem even if the variable were an
instance variable.

It's also not good to 'println()' the value every time you set it.
That will kill performance, and clutter your 'System.out' with stuff.

You buy nothing with your static method that 'Calendar.getCalendar()'
doesn't already provide, and you introduce problems by using the
singleton. I wouldn't recommend this approach.

If I may amplify, Joshua Bloch expands on this topic in his book,
_Effective_Java_, item 5: Avoid Creating Unnecessary Objects:

<http://www.ddj.com/java/210602264?pgno=2>

 

[Lew]

Hi Guys ,
Iam working with an DataBase Type of application. in every table is
store to database , i [sic] have 2 fields like Created and Updated
which takes calendar instances . so i used to write like this
data.setCreated(Calendar.getInstance());
data.setUpdated(Calendar.getInstance());

This creates two separate Calendar instances.

Non-constant static variables are an antipattern.

In a multi-threaded application this could be very damaging.

This would create only Calendar one instance initialized to the time
the class is initialized.

Would you change the time of the Calendar instance between calls?  
You would have to, but this introduces the multi-threaded danger
alluded to.  That would be a problem even if the variable were an
instance variable.

It's also not good to 'println()' the value every time you set it.  
That will kill performance, and clutter your 'System.out' with stuff.

You buy nothing with your static method that 'Calendar.getCalendar()'
doesn't already provide, and you introduce problems by using the
singleton.  I wouldn't recommend this approach.

If I may amplify, Joshua Bloch expands on this topic in his book,
_Effective_Java_, item 5: Avoid Creating Unnecessary Objects:

<http://www.ddj.com/java/210602264?pgno=2>

The problem here is more of failure to create necessary objects.

 

[jagadesh]

Thanks Lew ,

I was Expecting This Type Of Solution .

so now how can i do this . i want only one Calendar instance and that
too sholud be filled with new instance every time i use that . i dont
wnat to create a new instance for every Created and Updated fields,
so even we will come into problems if we use Singleton . so any
alternate


thank u.

 

[Lew]

so now how can i do this . i want only one Calendar instance and that
too sholud be filled with new instance every time i use that . i dont
Why?

wnat to create a new instance for every Created and Updated fields,
so even we will come into problems if we use Singleton . so any
alternate

You can make a singleton work, but it has risks. In that it is similar to
many decisions in programming. My recommendation to use multiple instances is
to simplify the programming and reduce the risk of incorrect results, without
having to do a lot of extra work to keep things synchronized.

In practice one has to strike a balance between creating too many objects and
not creating enough objects. Sometimes it is difficult to know which way to
go. In those cases, it is often best to use the approach that creates correct
answers with the least work.

Why do you want only a single Calendar object?
What is the problem with using multiple instances?

 

[Arne Vajhøj]

Iam working with an DataBase Type of application. in every table is
store to database , i have 2 fields like
Created and Updated which takes calendar instances.

Why ?

java.util.Date or one of the subclasses in java.sql seems
much more suited to be stored.

Arne

 

[jagadesh]

Lee,

I am just applying my taughts of using single instance . I was in my
Development Phase. i Observed when i am going to save an Object To The
DataBase , iam creating a new Calendar instance for every time i call
save to an object.i want to eliminate them so that only one instance
is to be used for all the objects who are going to be saved so that i
can eliminate the number of instances created on server side . though
my application is fast enough i am looking at the performance now .

is there any performance tips about this issue .

java.util.Date even works fine , but it is up my framework which used
this Calendar , so i cannot change it now.

so how can i rebuild this situation so that i can use less number of
calendar instances .

thanks,

 

[Lew]

so how can i rebuild this situation so that i can use less number of
calendar instances .

Don't bother. Just use as many Calendars as you need. Hanging on to instances
for too long can interfere with garbage collection. Just create a new
instance at need for each new date/time. If you need to re-use a particular
time, for example, to enter the same exact time into different structures or
database rows, then keep the same instance that represents that moment. When
you need to create a new moment, use a new Calendar (or Date).

 

[jagadesh]

Thanks For The Reply , Lee

Lets Think In A Other Way .

private Static Calendar cal=Calendar.getInstance();

public static Calendar getCalendar() {

if(cal.get(Calendar.DATE) >
Calendar.getInstance().get(Calendar.DATE)) {

Use The Calendar Instance "cal"

} else {

Other Wise Create a new Calendar Instance and use That

}

so that i will check the EveryTime i Made a call to this method. i
would get the correct instances if date changes ,

is it a good one [ JUST A TAUGHT ]

Thank u.

 

[Lew]

Thanks For The Reply , Lee

Lets Think In A Other Way .

private Static Calendar cal=Calendar.getInstance();

public static Calendar getCalendar() {

if(cal.get(Calendar.DATE) >
Calendar.getInstance().get(Calendar.DATE)) {

Use The Calendar Instance "cal"

} else {

Other Wise Create a new Calendar Instance and use That

}

so that i will check the EveryTime i Made a call to this method. i
would get the correct instances if date changes ,

is it a good one [ JUST A TAUGHT ]

Why don't you try it in your Java environment first, make sure that it works,
then post working code?

 

[jagadesh]

Oh Sure , But Thanks For The Reply
Very Much

 

[Lew]

Oh Sure , But Thanks For The Reply
Very Much

Good. Looking forward to the code sample.

You were off to a good start with your pseudocode description. That is a
popular and effective way to get the logic of your program before messing with
details of language syntax. All you have to do is translate your pseudocode
example into Java and compile it.

Whether it runs successfully or not at that point, post the code for the group
to comment on it and assist you. I know I said "working code", but in this
context it's enough to get a first try and just compile it. If you get
compiler errors, that's all right. It still means progress. We can help from
there.

 

[jagadesh]

Hi Guys ,

What i Did is ,

//Method To Get Today Calendar
public static Calendar getCalendar(Calendar calendar) {

Calendar todaycalendar=(Calendar)calendar;
todaycalendar.set(Calendar.DATE,todaycalendar.getTime().getDate());
todaycalendar.set(Calendar.AM_PM,Calendar.PM);
todaycalendar.set(Calendar.HOUR,00);
todaycalendar.set(Calendar.MINUTE,00);
todaycalendar.set(Calendar.SECOND,00);
return todaycalendar;
}

when calling this method ,

Calendar todayCalendar = HelperClass.getCalendar(Calendar.getInstance
());


so that i would use only one Calendar instance. at least i can cut one
more instance.

thank u.
suugest me if we modify this any more

 

[Lew]

What i [sic] Did is ,

//Method To Get Today Calendar
public static Calendar getCalendar(Calendar calendar) {

Calendar todaycalendar=(Calendar)calendar;

This cast casts a Calendar to a Calendar. Not necessary. It also points
'todaycalendar' (you should follow the naming conventions, btw) to the same
object as 'calendar'. Useless, here.

todaycalendar.set(Calendar.DATE,todaycalendar.getTime().getDate());

Now you are setting the day of the month to the day of the month that it
already had, using a deprecated method at that.

This whole conversion from 'Calendar' to 'Date' back to 'Calendar' is a long
and winding road back to where you started.

todaycalendar.set(Calendar.AM_PM,Calendar.PM);

Why? You want to set 'calendar' to represent noon?

todaycalendar.set(Calendar.HOUR,00);
todaycalendar.set(Calendar.MINUTE,00);
todaycalendar.set(Calendar.SECOND,00);

OK, now 'calendar' represents noon of the day it already represented.

return todaycalendar;
}

when calling this method ,

Calendar todayCalendar = HelperClass.getCalendar(Calendar.getInstance
());

It is not good practice to include the word part 'Class' in a type name.

so that i [sic] would use only one Calendar instance. at least i [sic] can cut one
more instance.

What do you mean "cut one more instance"? You aren't changing the number of
instances in any way. You get a new instance from 'Calendar.getInstance()'
each time and return it to 'todayCalendar'. It is also bad practice to
include the type of a variable in its name.

thank u.

The word is "you".

suugest me if we modify this any more

If all you want to do is set a Calendar to represent noon on the day of its
creation, then you only have to clean that method up a little to remove the
redundancies.

 

[jagadesh]

Thanks Lew ,
Thanks For The Response .
The Rules By You Are Usefull To Me.

Thanks A Lot.

 

[RedGrittyBrick]

It is also bad practice to include the type of a variable in its
name.

I'm ready to listen but am unsure what you propose.

Say I have

JTextField customerNameField;
...
String customerName = customerNameField.getText();

What variable naming convention would you use instead?

 

[Martin Gregorie]

At a guess Lew is talking about naming conventions, of which the so-
called Hungarian Notation beloved by Microsoft C programmers is the most
obnoxious, e.g

unsigned int *puiAccountTotal;

the points being that:
- it makes the variable name less readable
- if you change the variable's data type you must also change its
name, thus forcing a search&destroy mission across the entire
program.

In my example changing the variable to a signed long requires it to be
renamed to lAccountTotal.

 

[Lew]

Why do you think I would propose a different name?

That variable doesn't have its type in its name, so does not violate the
convention I proposed.

At a guess Lew is talking about naming conventions, of which the so-
called Hungarian Notation beloved by Microsoft C programmers is the most
obnoxious, e.g

unsigned int *puiAccountTotal;

the points being that:
- it makes the variable name less readable
- if you change the variable's data type you must also change its
name, thus forcing a search&destroy mission across the entire
program.

In my example changing the variable to a signed long requires it to be
renamed to lAccountTotal.

Precisely. RGB's example does not have 'JTextField' in the variable name, but
is named by its function in the program, an input "Field". That makes it a
correct name.