isaac…
nao to falando de Tomcat nao…isso eh facil embutir numa ferramenta de desenvolvimento…
falo de servidor interno proprio…o JEdit nao tem…
nao adianta resmungar, cara…
websphere eh a MELHOR ferramenta de desenvolvimento e ponto-final…
Pessoal,
Cada um tem sua preferencia, a minha voces podem notar no meu avatar qual é.
Todas os IDEs atualmente tentam otimizar ao maximo o desenvolvimento. Embora para isso seja necessario um desenvolvedor que saiba conceitos, particularidades, estruturas e etc…
Oq adiantaria dar uma maquina com WebSphere para um Jardineiro? Nada.
A questao nao é ser escravo de IDE algum, e sim saber aondi se pode chegar com as “vantagens” que essas ferramentas trazem para o desenvolvedor.
Isso nao é ser escravo ou acomodado, apenas evolucao tecnologica!
[]´s
[quote=“isaac”]rbarioni
O JEdit tem plugim pra tudo que você precisa… só não tem o IDE que na verdade não tem muita necessidade…[/quote]
tem um plugin DECENTE pra usar CVS?
nao
eh rapido?
nao
tem um refactoring absurdo?
nao
tem plugin para desenhar o UMl das suas classes?
nao
Eclipse tem
Ja fui usuario Jedit, o duke sabe. E adorava demais da conta. MAs o eclipse detona. Tipo, eh animal demais.
Um tempo atrás, eu conheci um cara que era fã do vi (aquele suposto editor de texto).
Nossos diálogos eram assim:
(duke) - Putz, vi não!!
- Meu, Vi rules!
- Fala sério, usa pelo menos o emacs
- o vi cabe num disquete de 5 1/4
- e daí?
- todo o UNIX tem vi, até os podres. Se vc sabe usar o vi, vc nunca vai ficar sem editor de texto.
- e daí? Eu nunca vou precisar saber mexer no VI porque UNIXes toscos já eram.
Errei feio. Aqui na empresa, fizemos uma distribuição Linux que ocupa 30Mb de memória para rodar numa maquininha. O único editor que tem lá é o vi.
Hoje eu sei que tem milhares de plugins pro vi, de forma que dá pra fazer code completion de java e tudo.
Quando vc trabalha numa fábrica de software, onde vc não tem tempo para raciocinar sobre o seu código, beleza. Mas se você tem tempo…
O que o “mágico” Websphere usa quando vc escreve List? Ele te pergunta ou escolhe uma aleatoriamente?
Isaac, a hora que eu tiver tempo vou testar pra ver. Como vc mediu o tempo??
caro Paulo…
se vc adora o Eclipse, entao vai amar o Websphere…
sugiro q vc experimente codificar nele…
ate mais.
[quote=“rbarioni”]se vc adora o Eclipse, entao vai amar o Websphere…
[/quote]
WSAD eh a versao PAGA do eclipse
eu falei PAGA? hegehehhehe. TO FORA!
prefiro o VI que um editor PAGO que vai me deixar na mao quando outra empresa falar que eu nao posso usar tal editor.
verdade Paulo…
mas vale a pena tentar conseguir uma versao crack do websphere…ele eh fantastico…
eu tive acesso ao websphere 5.0…simplesmente demais…
precisa de maquina, mas compensa…
Com certeza Paulo…coisa PAGA tem que cair fora…mas tb ja vi o WebSphere e vale a pena…o Eclipse tb eh bom, free…existem as opções…é só escolher!!!
Ate mais…
Viu no que da?? vc falou em CRACK!! e ja comecou a pirataria…
Rafael
Coloque o codigo das aplicacoes em algum lugar ( nao esta mensagem, se tiver muitas linhas ), para que possamos testar tambem.
Rafael
Bem… Infelismente não tenho permissão para passar todo o código fonte da aplicação…
Sobre o tempo de execução dos programas… bem, eu já formei minha opinião em cima de meus testes… não estou dizendo pro pessoal usar assim… apenas coloquei minha opinião baseada em fatos… como já disse o fonte não posso passar… mas se quiserem perguntar algo ou alguma dúvida…
A respeito dos editores… respeito a opinião de todos… cada um programa na ferramenta que se sentir mais avontade e mais agil… quem programa com Websphere e acha que desenvolve rápido… tudo bem, qume usa Jedit e acha que programa rápido tudo bem… que usa VI tudo bem… acho que somos todos adultos…não precisamos agora ficar brigando por questão de editor de texto… a única filosofia que deve ser levada em consideração neste caso é a do Software Livre… Assim penso eu…
T+
Pessoal o que acontece é o seguinte.
Quando se usa o “*” nas cláusulas de import, o compilador ficara mais lento sim, e quem quiser ter uma idéia real basta testar isso:
javac MyClass -verbose
Dessa forma, durante a compilação, serão exibidas as classes que foram referenciadas no byteCode da MyClass e o tempo total de compilação.
Entretanto, durante o Runtime, o tempo de carga ou execução da aplicação não será alterado. Provavelmente a medida de tempo adotada esta errada e precisa ser refeita.
Uma observação. Na JDK 1.4, a API do SWING é carregado INTEIRO na memoria da JVM mesmo se não estiver em uso, pois ela usa um novo conceito de “Shared Libraries”, para diminuir o consumo de memória quando se tem mais de uma JVM sendo executada ao mesmo tempo na mesma máquina, o que pode interferir na medição de tempo de execução.
isaac
agora voce nao tem como contestar
quem acaba de te responder essa mensagem eh o Oziel Neto, instrutor dos instrutores da SUN
Oziel, a gente fica MUITO contente que voce esteja participando do forum!
é isso mesmo ozielNeto…como eu ja havia colocado em uma msg anterior neste tópico e voltando a colocar minha opinião, e pelo que vejo está certo, nas clausulas import, acredito que deve ser importando apenas as classes que usamos…se vamos usar, por exemplo, somente a JOptionPane do swing, pra que fazer isso…
import javax.swing.*;É muito mais simples vc importar somente a classe que vai usar…as vezes, usamos varias classes e dai usamos o * para nao ficar importando uma a uma, mas acho que se for uma aplicação grande, e no caso, o amigo ozielNeto disse, e como ele é instrutor dos instrutores da SUN, pode haver mudança na performance na compilação…fico com essa idéia mesmo…economia de imports…vamos importar apenas o que usamos…é melhor, mesmo que na hora da execução nao mude, mas acredito que um código mais enxuto é sempre bem vindo não é mesmo!!! 
Essa é minha opinião!! 
Ate mais amigos…
Srs. Para não ficarmos com esse assunto indefinido, sugiro o seguinte:
1 - Usar sempre os imports específicos, salvo alguma orientação sobre padronagem adotada dentro da fábrica de software.
Prós: Facilita o entendimento do código.
Diminui o tempo de compilação.
Contras:
Torna a codifição mais complexa, pois a cada nova classe referenciada, é necessário rever os imports.
2 - Independente da JVM, o import java.util.*; não vai forçar a carga de todo o pacote util, e suas dependências. Isso acontece somente com o SWING e somente na JDK 1.4.
Vale lembrar que a linguagem Java foi criada com o intuito "de ser facilmente inteligível".
Eu, por "prequiça e facilidade de uso", prefiro import java.util.*, até porque dentro das IDEs, elas costumam usar essas clausulas para os serviços de "Code Assistance", e etc.
[]´s
Eu decompilei um .class com o Jade e adivinha o que eu vi??
:shock:
import java.util.*;Será que isso tava no bytecode ou o Jade que fez isso na hora de descompilar??
[]s
O “*” foi o JAD que arbritrariamente colocou, pois provavelmente ele encontrou classes que ele não consegui indetificar pos estão fora do CLASSPATH.
EX:
Código original…
package com.cpqd.util.nameservices;
import javax.ejb.;
import java.util.;
import javax.naming.;
import java.rmi.;
import javax.rmi.;
import javax.sql.;
import javax.mail.*;
Código descompilado com a m… do JAD.
// Decompiled by DJ v3.2.2.67 Copyright 2002 Atanas Neshkov Date: 24/3/2003 17:37:16
// Home Page : http://members.fortunecity.com/neshkov/dj.html - Check often for new version!
// Decompiler options: packimports(3)
// Source File Name: NameService.java
package com.cpqd.util.nameservices;
import java.util.Hashtable;
import javax.ejb.EJBHome;
import javax.mail.Session;
import javax.naming.*;
import javax.rmi.PortableRemoteObject;
import javax.sql.DataSource;
Bom estudo a todos.
[quote=“ozielneto”]O “*” foi o JAD que arbritrariamente colocou, pois provavelmente ele encontrou classes que ele não consegui indetificar pos estão fora do CLASSPATH.
// Decompiled by DJ v3.2.2.67 Copyright 2002 Atanas Neshkov Date: 24/3/2003 17:37:16
// Home Page : http://members.fortunecity.com/neshkov/dj.html - Check often for new version!
// Decompiler options: packimports(3)
// Source File Name: NameService.java
[/quote]
Acho que na verdade, aquela opção “packimports(3)” diz pra ele usar * quando tiver 3 ou mais classes do mesmo pacote na lista de imports…
O que é, na minha opinião, ótimo! Mais de 10 entradas numa lista de imports é ridículo, a menos que vc esteja mesmo usando 10 pacotes. Por exemplo, uma GUI normal de swing bem feita poderia incluir:
import javax.swing.JPanel;
import javax.swing.JButton;
import javax.swing.JTable;
import javax.swing.JOptionPane;
import javax.swing.JComponent;
import javax.swing.JRadioButton;
import javax.swing.ButtonGroup;
import javax.swing.BorderFactory;
import javax.swing.border.EtchedBorder;
import javax.swing.border.TitledBorder;
import java.awt.BoderLayout;
import java.awt.GridLayout;
import java.awt.Container;
import java.awt.Color;
import java.awt.Rectangle;
import java.awt.event.ActionEvent;
import java.awt.event.MouseEvent;
import java.awt.event.ItemEvent;
import java.awt.event.WindowEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.MouseAdapter;
import java.awt.event.ActionListener;
// agora exagerando:
import java.util.List;
import java.util.Map;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Collections;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeEvent;Graças a Deus não temos que importar as classes do java.lang!! Esse não é um exemplo real, mas poderia ser. Repare que eu só coloquei coisas relevantes, e não estou imaginando uma interface gerada com NetBeans ou outro editor de GUI (pois nesse caso eu recomendo usar sempre GridBagLayout).
Em vez de 28 linhas de import, eu poderia escrever:
import javax.swing.*;
import javax.swing.border.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import java.beans.*;Imagine a confusão pra saber se uma classe está importada ou não se eu não tivesse, de cara, organizado os imports por pacote. Pra quem usa Eclipse, blz, é só mais um ícone no gutter. Os outros precisam recorrer a recursos de busca.
[]s!
P.S.: estou procurando alguém que me ensine a escrever mensagens pequenas. Pago em latas de Coca-cola (cheias, claro). :roll: