Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > REAL SSCCE of my graphical interface with memory leaks

Reply
Thread Tools

REAL SSCCE of my graphical interface with memory leaks

 
 
Sal
Guest
Posts: n/a
 
      10-30-2007
Hi All!
I've some problems with a java program and memory leaks.
I Export the classes in a jar file (with eclipse) and i run it with:
java -jar app.jar

If i see the memory occupation of the program (CTRL+ALT+CANC
java.exe application) i can see that the memory start from 14.600 KB
and then grows up...

Why it appends?

Best Regards

Sal

<MAIN CLASS>
package inter;

public class Principale {

public static void main(String[] args) {

try {
Interfaccia2 app = new Interfaccia2();
} catch (NullPointerException e) {}
}
}
</MAIN CLASS>

<INTERFACE CLASS>
package inter;

import javax.swing.*;
import java.util.*;
import java.awt.*;
import java.awt.event.*;

public class Interfaccia2 extends JFrame
{
JFrame f;
JLabel timeField;
int day = 0;
int mese = 0;
int anno = 0;
int h = 0;
int m = 0;
int s = 0;
Font fontlabel = new Font( "Verdana",Font.PLAIN,14);
Dimension screenSize =Toolkit.getDefaultToolkit().getScreenSize();
public Interfaccia2()
{
timeField = new JLabel("");
javax.swing.Timer t = new javax.swing.Timer(1000,
new ActionListener() {
public void actionPerformed(ActionEvent e) {
Calendar now = Calendar.getInstance();
day = now.get(Calendar.DAY_OF_MONTH);
mese = now.get(Calendar.MONTH)+1;
anno = now.get(Calendar.YEAR);
h = now.get(Calendar.HOUR_OF_DAY);
m = now.get(Calendar.MINUTE);
s = now.get(Calendar.SECOND);
timeField.setText("Data: "+ day + "-" + mese + "-" + anno + "
Ore: " + h + ":" + m + ":" + s);
}
});
t.start(); // Start the timer
timeField.setFont(fontlabel);
JPanel Panel_principale = new JPanel();
Panel_principale.setPreferredSize (new Dimension (screenSize.width-10,
screenSize.height-65));
Panel_principale.add (timeField);
f = new JFrame ("TK Data");
f.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);
f.getContentPane().add (Panel_principale);
f.pack();
f.setVisible (true);
f.repaint();
}
}
</INTERFACE CLASS>

 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      10-30-2007
Sal wrote:

> Dimension screenSize =Toolkit.getDefaultToolkit().getScreenSize();


The whole screen? Please don't do this. I changed it to:

// Dimension screenSize =
//Toolkit.getDefaultToolkit().getScreenSize();
Dimension screenSize = new Dimension( 300, 300 );


> timeField.setText("Data: "+ day + "-" + mese + "-" + anno + "
> Ore: " + h + ":" + m + ":" + s);


The String here is broken, doesn't compile. I fixed it, but please watch
this when you are posting code.

> If i see the memory occupation of the program (CTRL+ALT+CANC
> java.exe application) i can see that the memory start from 14.600 KB
> and then grows up...
>
> Why it appends?


Mine grows up to 60MB up from 55MB, then goes back down to 54MB and
starts growing again. This is normal for the JVM garbage collection.
Are you sure you have a leak?

Also:
public void actionPerformed(ActionEvent e) {
Calendar now = Calendar.getInstance();
day = now.get(Calendar.DAY_OF_MONTH);
mese = now.get(Calendar.MONTH) + 1;
anno = now.get(Calendar.YEAR);
h = now.get(Calendar.HOUR_OF_DAY);
m = now.get(Calendar.MINUTE);
s = now.get(Calendar.SECOND);
timeField.setText("Data: " + day + "-" + mese
+ "-" + anno
+ "Ore: " + h + ":" + m + ":" + s);
}

This strikes me as a really good way to have a serious problem. You're
updating a JComponent ("timeField") on a thread that is not the AWT
event thread. I think you should dump this whole method into an
invokeLater() method.
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      10-30-2007
On Tue, 30 Oct 2007 10:19:22 -0700, Sal <(E-Mail Removed)> wrote,
quoted or indirectly quoted someone who said :

>
>public class Principale {


You could have easily made this one class. Just move the main method
to intefaccia2. The fewer the classes the easier SSCCEs are to deal
with.

There is a stylistic problem with your code. Your constructor is full
of code nothing to do with constructing the Frame object. Even if
you called such code from the constructor, application logic sort of
code belongs in its own method.

The following code is traditionally never put in a constructor.
f.pack();
f.setVisible (true);
f.repaint(); /* not necessary */
You are supposed to do it in the code that calls new.
I am not sure if this is just considered good style, or if something
terrible happens if you do it your way. Consistent style is
sufficient reason for me to avoid doing what you did.

I consider it dangerous to set up a timer inside an partially
constructed frame. You want to wait until the frame is realised. This
timer-starting code then belongs in addNotify.

See http://mindprod.com/jgloss/addnotify.html

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-30-2007
Calendar now = Calendar.getInstance();
day =
now.get(Calendar.DAY_OF_MONTH);
mese =
now.get(Calendar.MONTH)+1;
anno =
now.get(Calendar.YEAR);
h =
now.get(Calendar.HOUR_OF_DAY);
m =
now.get(Calendar.MINUTE);
s =
now.get(Calendar.SECOND);
timeField.setText("Data: "+ day + "-" + mese + "-" + anno + "Ore: "
+ h + ":" + m + ":" + s);



This chunk of code is more slickly handled with a SimpleDateFormat.
See http://mindprod.com/jgloss/calendar.html#PRECISE
or with locale-dependence with DateFormat df =
DateFormat.getDateInstance();
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-30-2007
On Tue, 30 Oct 2007 19:08:08 GMT, Roedy Green
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>This chunk of code is more slickly handled with a SimpleDateFormat.
>See http://mindprod.com/jgloss/calendar.html#PRECISE
>or with locale-dependence with DateFormat df =
>DateFormat.getDateInstance();


The idea is to trim the code to the bone and still have it demonstrate
the problem. You can replace this with

setText( "Dummy" ); and see if it still fails.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-30-2007
On Tue, 30 Oct 2007 18:29:20 GMT, Mark Space
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone
who said :

>This strikes me as a really good way to have a serious problem. You're
>updating a JComponent ("timeField") on a thread that is not the AWT
>event thread. I think you should dump this whole method into an
>invokeLater() method.


He is ok. That is unnecessary because he used a Swing Timer not an
ordinary Timer.

quoting from the docs
"Although all Timers perform their waiting using a single, shared
thread (created by the first Timer object that executes), the action
event handlers for Timers execute on another thread -- the
event-dispatching thread. This means that the action handlers for
Timers can safely perform operations on Swing components. However, it
also means that the handlers must execute quickly to keep the GUI
responsive."

see http://mindprod.com/jgloss/timer.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      10-30-2007
Roedy Green wrote:

> He is ok. That is unnecessary because he used a Swing Timer not an
> ordinary Timer.
>


Cool! I didn' know about Swing timers, thanks for the info.
 
Reply With Quote
 
Sal
Guest
Posts: n/a
 
      10-30-2007
first of all thanks to all!

>Mine grows up to 60MB up from 55MB, then goes back down to 54MB and
>starts growing again. This is normal for the JVM garbage collection.
>Are you sure you have a leak?


This is a program that run for 24h and after some days i have this
problem of memory!

.... and what about the occupation memory of the others?
Have you seen it?
I use WinXP and you?

Sal


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2007
Sal wrote:
> This is a program that run for 24h and after some days i [sic] have this
> problem of memory!


What is the actual problem? In other words, what harm are you seeing?

> .... and what about the occupation memory of the others?
> Have you seen it?
> I use WinXP and you?


Are you certain that you have a problem? What evidence besides seeing a
number in the Task Manager do you have that there is a problem?

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2007
Roedy Green wrote:
> The following code is traditionally never put in a constructor.
> f.pack();
> f.setVisible (true);
> f.repaint(); /* not necessary */
> You are supposed to do it in the code that calls new.
> I am not sure if this is just considered good style, or if something
> terrible happens if you do it your way. Consistent style is
> sufficient reason for me to avoid doing what you did.


It is actually dangerous, not just stylistically. All that Swing stuff should
happen on the EDT, and you're not supposed to let thready things happen from
the constructor.

In general, there can be severe bugs from putting non-construction logic in a
constructor, especially where multi-threading is involved.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSCCE of my graphical interface with memory leak Sal Java 9 10-23-2007 08:24 AM
SSCCE Wojtek Java 32 08-29-2007 12:40 AM
The SSCCE is back! Andrew Thompson Java 0 08-05-2006 02:38 PM
memory leaks jboss-java with jni interface johan Java 2 03-02-2004 10:12 AM
SSCCE 1st draft.. Andrew Thompson Java 2 12-31-2003 09:10 AM



Advertisments