Re: [java-list] problema "renderizando" componentes swing -- ajuda !!!!

2002-12-02 Thread Edson Tirelli

   Thiago,

   Dificil responder com certeza sem ver o codigo, mas
um caso classico desse problema acontece quanto se
mistura componentes visuais de AWT com Swing.
   Por exemplo, usar Frame com JButton ou Button com
JFrame, etc. Normalmente os componentes AWT se
desenham por cima dos componentes Swing, causando
problemas na apresentacao da GUI. 
   Pode ser esse o seu problema?

   []s
   Edson

  --- 
  Edson Tirelli
  System Analyst
  Sun Certified Programmer for Java
  Nextel Telecom

 --- Thiago <[EMAIL PROTECTED]> escreveu: >
Pessoal,
>  
> Eu estou desenvolvendo uma aplicação, paginada, com
> componentes swing, é
> mais ou menos um relatório, só que não é
> "imprimível", acontece que logo
> quando abre uma página (e quando navega também) não
> aparece nada na
> tela, só depois de minimizar, ou maximizar, é que
> aparecem os
> componentes. Será que alguém ai sabe o que pode ser
> isso?
>  
> []'s,
>  
> Thiago
>  

___
Yahoo! Acesso Grátis
Internet rápida, grátis e fácil. Faça o download do discador agora mesmo.
http://br.acesso.yahoo.com/

-- LISTA SOUJAVA  
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED] 
-




Re: [java-list] Java Threads no linux

2002-04-29 Thread Edson Tirelli

  Emerson,

  Threads no linux sao implementadas como LWP (Light Weight Process), ou
seja, vc vai ver cada thread como um processo. Mais do que isso, pra cada
"programa multithread" com "n" threads, vc vai ter n+1 LWPs no linux. Essa
thread a mais que ele cria tem funcoes especificas dentro do SO, que nao
cabem ser discutidas aqui.
  Quanto a utilizacao de memoria, eh o q vc deve ter imaginado. Todos os
LWPs compartilham o mesmo espaco de enderecamento, ou seja, a sua aplicacao
estah usando 60 Mb de memoria no total. :)
  Quanto a implementacao da maquina virtual no linux nao tenho
competencia para discutir. :)
  Quanto a implementacao do gerenciamento de threads no linux, acho q eh
uma decisao de implementacao (deveria dizer de design?) do SO. Eh melhor ou
pior do que outros unix? Tem vantagens e desvantagens.
  Agora, off-topic, se alguem souber me responder, por favor me responda
em PVT: como faco pra, dada a lista de processos de um linux, saber quais
sao os LWPs (ou threads) q compoem cada "programa"?

  []s
  Edson

  ---
  Edson Tirelli
  System Analyst
  Microsoft Certified Professional
  Sun Certified Programmer for Java 2
  try Automatos @ www.automatos.com


- Original Message -
From: "Emerson Santana Pardo" <[EMAIL PROTECTED]>
To: "Java List" <[EMAIL PROTECTED]>
Sent: Thursday, April 18, 2002 10:21 AM
Subject: [java-list] Java Threads no linux


> Oi lista,
>
> Seguinte, desenvolvi um servidor java com um pool de conexões. O servidor
> aloca N threads que ficam em uma pilha para atender as requisições que
> chegam. Quando o executo no linux e dou o comando top aparece uma lista
> mostrando cada thread como se fosse um processo e cada uma ocupando mais
de
> 60 MB de memória.
>
> Bom, deve ter alguma coisa errada ou com 50 threads no pool meu servidor
> ocuparia mais de 3 GB de memória o que, neste momento, a máquina em
questão
> não tem disponível. :-P
>
> Algumas dúvidas:
>
> Será que cada thread está ocupando mesmo os 60 MB de memória? Ou este
> espaço de memória está sendo compartilhado por todas as threads?
> Será que a máquina virtual java (jre 1.3.1 da sun) do linux é tosca?
> Será que o gerenciamento de threads do linux é tosco?
>
> Agradeço antecipamente qualquer ajuda.
>
> []'s,
> Emerson
>
> Arquivo da java-list:
> [http://www.mail-archive.com/java-list%40soujava.org.br/]
>
>
>
>
> -- LISTA SOUJAVA 
> http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> historico: http://www.mail-archive.com/java-list%40soujava.org.br
> para sair da lista: envie email para [EMAIL PROTECTED]
> -
>


-- LISTA SOUJAVA  
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED] 
-




RES: [java-list] Basico de OO em JAVA - CUIDADO MESMO!!!!

2001-07-05 Thread Edson Tirelli


   Uuups... q viagem... foi mal por essa...
   Valeu pelo exclarecimento. Como vc pode ver, nunca tinha precisado disso
antes. Vou passar a testar o codigo antes de enviar. :P

   Quanto a minha certificacao, garanto q vale tanto quanto a de qq um. Eh
um pedaco de papel q diz q passamos numa prova. Agora na hora do trabalho
serio, nao eh ela q vai entregar o sistema funcionando e dentro do prazo...
erro de compilacao se resolve em 30 segundos... erro de logica e modelagem,
eh outra historia...

   Abraco,
  Edson

 ---
 Edson Tirelli
 System Analyst
 Microsoft Certified Professional
 Sun Certified Programmer for Java 2 Platform
 try Automatos @ www.automatos.com


> -Mensagem original-
> De: Michael Santos [mailto:[EMAIL PROTECTED]]
> Enviada em: quinta-feira, 5 de julho de 2001 16:45
> Para: [EMAIL PROTECTED]
> Assunto: RES: [java-list] Basico de OO em JAVA - CUIDADO MESMO
>
>
> Acho q seu compilador foi escrito pela Microsoft, meu camarada... :-P
> Isto nao compila nem aki nem na China, tenho certeza absoluta...
> Nao preciso
> nem testar, se vc tem:
>
> public class A {
>   private int x;
> }
>
> public class B extends A {
>   public B() {
>  x = 1;
>   }
> }
>
> e tentar compilar, vc vai receber ou "undefined variable: x" ou
> "variable x
> is not visible to B" ou alguma coisa assim...
> A resposta anterior eh correta...
>
> Qdo vc se certificou?
>
> 
> Michael Nascimento Santos
> Sun Certified Programmer for the Java 2 Platform
> Analista/Consultor
> Moderador SouJava - www.soujava.org.br
> CPM Sistemas - www.cpm.com.br
>
> From: "Edson Tirelli" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: <[EMAIL PROTECTED]>
> Subject: RES: [java-list] Basico de OO em JAVA - CUIDADO
> Date: Thu, 5 Jul 2001 11:49:59 -0300
>
>
> Amigos,
>
> Este assunto inclusive circulou aqui na lista a um tempo atras. Eh um
> erro comum q eu tambem cometia no inicio, mas eh importante exclarecer: os
> modificadores de acesso limitam o ACESSO EXTERNO aos atributos  da classe,
> mas NAO LIMITAM A HERANCA.
> Isso quer dizer q se uma classe eh FILHA de outra, ela vai HERDAR TUDO
> da classe MAE, podendo eventualmente sobrescrever algumas coisas (por
> exemplo, o q NAO estiver definido como "final" na classe mae).
> Assim, no exemplo citado pelo colega:
>
> public class Mae {
> private   int x;
> protected int y;
> }
>
> public class Filha extends Mae {
> // A FILHA HERDA O ATRIBUTO PRIVADO "X" E O ATRIBUTO PROTEGIDO "Y"
> public Filha() {
>x = 50;  // PERFEITAMENTE CORRETO
>y = 100; // PERFEITAMENTE CORRETO
> }
> }
>
>  Pra tentar exclarecer o modificador private, observe essa nova
> implementacao abaixo:
>
> public class Filha extends Mae {
> // A FILHA HERDA O ATRIBUTO PRIVADO "X" E O ATRIBUTO PROTEGIDO "Y"
> public Filha() {
>x = 50;  // PERFEITAMENTE CORRETO
>y = 100; // PERFEITAMENTE CORRETO
> }
>
> public void m() {
> Mae amae = new Mae();
> amae.x = 30; // ERRO DE COMPILACAO -> x eh atributo privado de
> Mae
> amae.y = 20; // CORRETO -> y eh atributo protegido de Mae
>
> this.x = 50; // CORRETO -> atributo x herdado
> this.y = 60; // CORRETO -> atributo y herdado
>     }
> }
>
>  Observe q a diferenca entre atributos privados e protegidos eh q os
> atributos protegidos permitem o ACESSO EXTERNO quando o objeto q estiver
> fazendo o acesso for de uma classe FILHA ou DO MESMO PACOTE q a classe q
> contem o atributo.
>
>  Espero ter exclarecido, mais do que complicado... :)
>
>  Abraco,
>  Edson
>
> ---
> Edson Tirelli
> System Analyst
> Microsoft Certified Professional
> Sun Certified Programmer for Java 2 Platform
> try Automatos @ www.automatos.com
>
>
>
> -Mensagem original-
> De: Alexandre Nóbrega Duarte [mailto:[EMAIL PROTECTED]]
> Enviada em: quinta-feira, 5 de julho de 2001 08:10
> Para: [EMAIL PROTECTED]
> Assunto: Re: [java-list] Basico de OO em JAVA
>
>
> Acho que o que voce quer fazer e isso.
>
>
> public class Mae {
>
> private int atributo;
>
> public Mae(){
>
> }
>
> }
>
>
> public class Filha extends Mae {
>
> public Filha() {
> atributo = 0;
> }
> }
>
> Se for isso, eh impossivel, mas voce pode contornar este problema
> fazendo o
> atributo protected ao inves de private. Dessa forma ele continua a ser
>

RES: [java-list] Basico de OO em JAVA - CUIDADO

2001-07-05 Thread Edson Tirelli


Amigos,

Este assunto inclusive circulou aqui na lista a um tempo atras. Eh um
erro comum q eu tambem cometia no inicio, mas eh importante exclarecer: os
modificadores de acesso limitam o ACESSO EXTERNO aos atributos  da classe,
mas NAO LIMITAM A HERANCA.
Isso quer dizer q se uma classe eh FILHA de outra, ela vai HERDAR TUDO
da classe MAE, podendo eventualmente sobrescrever algumas coisas (por
exemplo, o q NAO estiver definido como "final" na classe mae).
Assim, no exemplo citado pelo colega:

public class Mae {
private   int x;
protected int y;
}

public class Filha extends Mae {
// A FILHA HERDA O ATRIBUTO PRIVADO "X" E O ATRIBUTO PROTEGIDO "Y"
public Filha() {
   x = 50;  // PERFEITAMENTE CORRETO
   y = 100; // PERFEITAMENTE CORRETO
}
}

 Pra tentar exclarecer o modificador private, observe essa nova
implementacao abaixo:

public class Filha extends Mae {
// A FILHA HERDA O ATRIBUTO PRIVADO "X" E O ATRIBUTO PROTEGIDO "Y"
public Filha() {
   x = 50;  // PERFEITAMENTE CORRETO
   y = 100; // PERFEITAMENTE CORRETO
}

public void m() {
Mae amae = new Mae();
amae.x = 30; // ERRO DE COMPILACAO -> x eh atributo privado de
Mae
amae.y = 20; // CORRETO -> y eh atributo protegido de Mae

this.x = 50; // CORRETO -> atributo x herdado
this.y = 60; // CORRETO -> atributo y herdado
}
}

 Observe q a diferenca entre atributos privados e protegidos eh q os
atributos protegidos permitem o ACESSO EXTERNO quando o objeto q estiver
fazendo o acesso for de uma classe FILHA ou DO MESMO PACOTE q a classe q
contem o atributo.

 Espero ter exclarecido, mais do que complicado... :)

 Abraco,
 Edson

 ---
 Edson Tirelli
 System Analyst
 Microsoft Certified Professional
 Sun Certified Programmer for Java 2 Platform
 try Automatos @ www.automatos.com



-Mensagem original-
De: Alexandre Nóbrega Duarte [mailto:[EMAIL PROTECTED]]
Enviada em: quinta-feira, 5 de julho de 2001 08:10
Para: [EMAIL PROTECTED]
Assunto: Re: [java-list] Basico de OO em JAVA


Acho que o que voce quer fazer e isso.


public class Mae {

private int atributo;

public Mae(){

}

}


public class Filha extends Mae {

public Filha() {
atributo = 0;
}
}

Se for isso, eh impossivel, mas voce pode contornar este problema fazendo o
atributo protected ao inves de private. Dessa forma ele continua a ser
privado para quem esta de fora da classe mas fica publico para as classes
filhas.



public class Mae {

protected int atributo;

public Mae(){

}

}

Alexandre Nóbrega Duarte
Pós-Graduação em Informática
Departamento de Sistemas e Computação
Universidade Federal da Paraíba
- Original Message -
From: Fabio Ferreira
To: [EMAIL PROTECTED]
Sent: Wednesday, July 04, 2001 5:13 PM
Subject: [java-list] Basico de OO em JAVA


Como se "seta" um atributo (private) herdado da classe mae no construtor da
classe filha ?

Fabio Ferreira


-- LISTA SOUJAVA  
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-




RES: [java-list] AWT x SWING

2001-07-05 Thread Edson Tirelli


   Augusto,

   Esse eh um tema para muita discussao. Soh um detalhe rapido e importante:
"NUNCA, EM HIPOTESE ALGUMA, MISTURE COMPONENTES >>>>VISUAIS<<<< DE AWT COM
SWING!". Os componentes do AWT ("heavyweight") vao sempre se desenhar sobre
os componentes do Swing ("lightweight"). O problema q vc relatou com o
"JInternalFrame" (q eh do Swing) e o "TextField" (que eh AWT) decorre de vc
ter misturado os 2 tipos de interface.
   Vc pode identificar a origem de um componente pelo pacote, ou mais
facilmente pela letra inicial. Os componentes do Swing comecam por "J".
   Assim: um botao AWT se chama "Button" e um botao Swing se chama
"JButton", e por aih vai.
   Observe q LayoutManagers por exemplo, nao sao "componentes visuais" e
portanto vc pode usar normalmente tanto em AWT, quanto Swing.

   Abraco,
   Edson

 ---
 Edson Tirelli
 System Analyst
 Microsoft Certified Professional
 Sun Certified Programmer for Java 2 Platform
 try Automatos @ www.automatos.com


> -Mensagem original-
> De: Augusto Cesar Castoldi [mailto:[EMAIL PROTECTED]]
> Enviada em: quarta-feira, 4 de julho de 2001 08:45
> Para: [EMAIL PROTECTED]
> Assunto: [java-list] AWT x SWING
>
>
> Pessoal,
>
> tem uma dúvida que está me incomodando. Já me disseram que a SWING é uma
> interface mais avançada/nova que a AWT.
>
> Mas eu pergunto, quais são as reais diferenças entre as duas?
>
> Eu fiz uns testes, e por exemplo, um menu em AWT rodando no windows 98 é
> mais rápido que um menu em SWING.
>
> Porém, se eu usar um textfield da AWT, quando eu coloco um JInternalFrame
> em cima do outro, o textfield da tela de baixo aparece na tela de cima!
>
> Aparentemente a é melhor a SWING... (embora seja mais lenta)
>
> Se alguém puder me explicar isso seria interessante, ou simplesmente um
> artigo ou coisa parecida...
>
> valeu,
>
> Augusto Cesar Castoldi
>
>
> -- LISTA SOUJAVA 
> http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> para sair da lista: envie email para [EMAIL PROTECTED]
> -
>


-- LISTA SOUJAVA  
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-




RES: [java-list] Estranho que isso compila

2001-06-08 Thread Edson Tirelli

Olah lista,

Como curiosidade, essa discussao eh ateh interessante...
Na verdade, como o Rogerio jah havia comentado anteriormente, o q
acontece eh q existe diferenca entre "palavra reservada" e "identificador".
O compilador soh indica um erro quando uma palavra reservada eh utilizada
como nome de identificador. Quando existem nomes de identificadores iguais
para referencias diferentes, o compilador resolve isso pelo escopo.
O nome desse conceito, nao lembro direito, mas acho q eh "shadowing".
Isso permite q o codigo abaixo seja valido, e comumente utilizado:

class X {
   private int a;
   public X(int a) {
  this.a = a;
   }
}

Observe q existem 2 variavies diferentes, mas referenciadas pelo mesmo
nome. Acontece q a variavel mais "interna" ao escopo eh sempre a primeira a
ser referenciada, porque ela faz "sombra" ("shadow") na outra. Observem q
para refenciar o atributo "a", foi necessario usar "this.a".
Da mesma forma, vc pode fazer:

Bar Object = new Bar();

No entanto, boas praticas de programacao em java, aconselham a usar
nomes de classe com inicial em maiuscula e nomes de instancias com inicial
em minuscula... assim:

Bar object = new Bar();

Isso jah ajudaria a diferenciar a Classe "Object" da instancia "object".
Ainda assim pode ser confuso do ponto de vista "humano". E aih, eh como o
Sven disse... use nomes mais significativos e diferentes dos utilizados
pelas classes da API do java, para evitar dores de cabeca na hora de debugar
codigo...

[]s
Edson

 ---
 Edson Tirelli
 System Analyst
 Microsoft Certified Professional
 Sun Certified Programmer for Java 2 Platform
 try Automatos - The Automatic MSP
 @ www.automatos.com


-Mensagem original-
De: Roberto Tatemoto [mailto:[EMAIL PROTECTED]]
Enviada em: sexta-feira, 8 de junho de 2001 11:32
Para: [EMAIL PROTECTED]
Assunto: Re: [java-list] Estranho que isso compila


Isso também compila. Nos testes que eu fiz, qualquer nome de classe pode se
tornar nome de variável. Isso não estaria dentro do conceito de
encapsulamento?

--

public class Foo {
 public Foo() {
  Bar Integer = new Bar();
   System.out.println(Integer.parseInt());
 }

 public static void main(String[] args) {
  Foo foo1 = new Foo();
 }
}

class Bar {
 public Bar() {}

 public String parseInt() {
  return "Helloowwzz... Que loucura !!!";
 }
}

---


Roberto Tatemoto
Na minha opinião isso não deveria compilar ja que Object é uma das classes
base da Java (Extensão na java.lang). Assim não teria muito diferença de:
Bar Object = new Bar();
ou
String String = new String();


-- LISTA SOUJAVA  
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-