iSoron

Que erro seria esse? Na verdade, o Tomcat nem deveria saber q o MySQL tá rodando. No pior das hipoteses, os dois estão usando um mesmo recurso, mas eu acho dificil... []'s

Script? Movendo...

Ok, respondendo melhor, o que acontece é o seguinte: Em algumas maquinas virtuais java, todas as strings iguais são na verdade, uma unica string, localizada em apenas um lugar na memória, gastando bem menos espaço (e isso explica a imutabilidade das strings!) Quando você usou o operador ==, por sorte, a tua maquina decidiu deixar todos os "0"s como a mesma String, e deu certo. Como a gente não deve usar a mesma versão, o tratamento da memoria foi diferente. Aqui, as strings são separadas. Aí, elas são uma só. De qualquer forma, é melhor usar o equals, q funciona em todo lugar, sempre. []'s

A comparação deve ser feita com o metodo .equals(""). Esse == compara na verdade muito mais que o conteudo. Ele olha diretamente o endereço na memória. []'s

Porque length é uma função. Basta trocar por length(). []'s

Boa pergunta! Mas realmente, as coisas só param de funcionar quando a gente vai mostrar pros outros. []'s

O erro é que você está comparando strings com o operador ==, quando o correto seria com a função .equals( .. ) ou .equalsIgnoreCase( ... ). Esses são os trechos corrigidos: public void mudaValor(JButton botao, int pos1, int pos2) { if (botao.getText().equals("0")) { jogo.setPosicao(pos1, pos2, jogadorAtual); botao.setText(Integer.toString(jogadorAtual)); } } public void incrementaContador(JButton b) { if (b.getText().equals("0")) { contador++; } } Depois disso, funcionou ok! Só um detalhe pro layout.. Eu usei outro tamanho e os botoes apareceram deslocados, sem a forma clássica do jogo da velha. Pra corrigir isso, você pode usar o GridLayout, por exemplo. []'s

Será que o seu código não está lançando alguma exceção pra quem não deve? Coloca um try/catch ali na parte da consulta, pra testar. []'s

você pode colocar o link das classes? (se fosse só um jar seria mais facil baixar e testar) []'s

Bem, para atualizar o ComboBox, ou você usa XHTML, ou um Refresh. O pessoal do HTML/CSS pode te ajudar mais com isso, se precisar. Eu nunca usei XHTML, mas com refresh seria assim: você, ao escolher, envia para o servidor a requisição de que carros listar (pelo metodo POST). Este, de posse dessa informação, prepara a lista e já monta a página com as opções corretas. No caso de nenhum filtro ser mencionado (como é o caso de quem abriu a página pela primeira vez), você não mostra o segundo combobox. Uma terceira opção seria fazer com JavaScript. No caso, então, os vetores dentro do script seriam montados dinâmicamente pelo JSP com os dados recebidos do bd. ps.: O seu código está com alguns problemas bem visiveis. Não chegam a atrapalhar agora, mas, em um futuro próximo, podem te dar muita dor de cabeça. Primeiro: SQL dentro do código nunca é uma coisa boa. Se você mudar de banco de dados, precisará recompilar as classes. Isso se você ainda lembrar aonde estavam as consultas. O ideal é criar um objeto que gerencie todas as conexões e devolva as listas prontas. Esse objeto leria as consultas SQL de um arquivo XML, por exemplo, bem como os parametros de conexâo. Assim, se você mudar o BD, basta editar o XML. Segundo: O objeto que instancia um outro objeto não deve saber nada do seu funcionamento interno, deve apenas receber o resultado dos seus serviços. Fazendo como você fez (construtor vazio + javaBeans), o seu código está quebrando o encapsulamento e, portanto, violando um importante principio da OOP. Pra corrigir isso, basta colocar todos esses sets aí dentro do proprio construtor. Se houver mais de um tipo de carro, então você pode criar um Factory (se quiser, explico melhor). []'s

Movendo mais um..

Pra fazer qualquer coisa relacionada a Desktop você só precisa do JDK. Claro que uma boa IDE (editor + interface pro depurador + etc) também ajuda muito. Pelo visto você está usando o JCreator pra isso. É um bom começo, pois ele é bem simples. Quanto à versão, você está usando uma desatualizada. Estamos hoje no Java 5 (ou j2sdk 1.5.0 pros intimos). É melhor você usar esse e já ir se aucostumando com as novidades que ele introduziu. []'s

Movendo!

Você precisa do JDK e de um editor, pra escrever os fontes. Se quiser links pros programas, dá uma olhada nessa lista que eu fiz: http://foo.com.br/viewtopic.php?t=97 []'s

Oi kitsune. As classes String e StringBuffer servem basicamente pra mesma coisa: guardar uma sequencia de caracteres e oferecer métodos úteis. A classe String, porém, é totalmente imutável. Sempre que você concatena duas Strings, o compilador instancia uma StringBuffer e trabalha com ela. Depois, ele devolve pra String original. O resultado é o mesmo no final. Então, como se pode ver, objetos StringBuffer devem ser usados sempre que a sequencia de caracteres estiver sujeita a mudanças. Além de ter uma performance muuuito melhor, ainda é thread-safe. []'s

Como isso aí é só um teste mesmo, você pode escrever "\n" varias vezes até a tela limpar. Acho que você nem devia perder muito tempo com Console. Tem tanta coisa mais interessante pra estudar. []'s

E ae kabelera. O comando import só tem utilidade para o compilador. Quando ele não consegue achar uma classe no pacote padrâo, ele examina cada um dos imports procurando a tal classe. No momento que ele acha e consegue pegar a estrutura da classe, os imports perdem a utilidade. Assim, na versão final do bytecode, não há nenhuma referencia aos pacotes importados. Sendo assim, não há perda nenhuma de performance. Claro que, havendo muitos pacotes com wildcards (asteriscos) o compilador vai levar um tempo maior pra achar as classes. Supondo que você tenha vários e vários arquivos, cada um importando pacotes grandes, pode ser que voce chegue a notar esse atraso. No fim das contas, a perda de performance só se dá durante a compilação. Mesmo assim, é melhor usar os specifics imports para se ganhar clareza no código e evitar ambigüidades. Por exemplo, se dois pacotes têm a classe Map e você faz: import foo.*; import bar.*; então não tem como saber qual dos dois será aproveitado. Mas tudo bem, vamos supor que o Map só existia no pacote bar. Acontece que, um belo dia, o programador do pacote foo resolve fazer uma classe Map também. Misteriosamente, o seu programa para de funcionar. Se você não se lembrar mais qual Map era, fica (quase) impossivel corrigir o problema. Se você usar eclipse, basta apertar Ctrl+Shift+O e seus imports serão organizados automaticamente. Acredito que outras IDEs também tenham função parecida. ps.: escrevi demais de novo. []'s

Bem, teu código tá com serios problemas de escrita. Um deles é o causador do erro. 1 - Os pacotes influenciam sim na localização real dos arquivos. Sendo assim, o pacote deveria ser, no mínimo, empresa. Além disso, o pacote java já existe, e foi criado pela Sun. Se você quer fazer o seu, nomeie-o como br.org.alexandre.projeto ou algo assim, bem especifico. Na maioria das vezes, quando o projeto já tem um site, esse é o nome utilizado. 2 - Por que essa classe herda Object? Todo e qualquer objeto já é objeto, por padrão. 3 - Classes devem ter a primeira letra maiuscula, sempre e sempre. 4 - Nunca use import pacote.*, pois isso dificulta saber que classe você está utilizando. Ao invés disso, cite cada classe: import pacote.Listener, por exemplo. Seria bom você estudar e seguir as convenções de código. Pode parecer besteira no começo, mas logo logo o projeto vai crescendo e você vê a importancia. http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html []'s

Por alguma razão ele não está localizando as classes do pacote sun. De qualquer forma, por que usar MS Access? Ainda que seja só para fins didáticos, acho que vale muito mais a pena você estudar a integração Java + MySQL através de JDBC mesmo. []'s iSoron.

Movendo...

Movendo..

É até dificil responder isso, pois seria como comparar um navio com uma laranja. Não tem nada a ver. Se você estudar a tecnologia Java, vai ver que tem muita coisa por trás das JSPs. Há um comparativo de Java contra CGI (asp, php, etc) no tutorial J2EE da Sun. Se for possível, sugiro que você faça uma leitura. Dá pra entender bem do que se trata. []'s iSoron.

Acho melhor você conseguir um bom livro de UML. Deve ter muitos artigos bons pela internet, também, mas especificamente sobre isso, nunca pesquisei nenhum. Já tentou o Google? []'s iSoron.

Você pode usar a função getProperty(), da classe System: System.getProperty("os.name") Aí você faz a lista de Unix-like ou Windows-like. Lista completa das propriedades: http://java.sun.com/j2se/1.4.2/docs/api/já...getProperties() []'s iSoron.

Já procurou no Google? Nem precisa adivinhar o que pesquisar. Basta "Netbeans 4.1 download". De qualquer forma, você acha no site: http://netbeans.org/ []'s iSoron.