Mensagens enviadas por: cv
Índice dos Fóruns » Perfil de cv » Mensagens enviadas por cv
Autor Mensagem
Curioso como tem pouco software 3.0 por aí...parece um número místico
J3EE? Que tal algo no estilo do JBoss AOP? Não tem EJB, tem POJOs sendo aspectados pra cima e pra baixo e *virando* EJBs no meio do caminho... outra ideia legal ia ser repensar a coisa toda com mais enfoque aos Message-Driven Beans, dando mais facilidade ao desenvolvimento de webservices e similares...
Scrabby wrote:pq pelo o que eu saiba não se pode instanciar uma interface.


Ele não está instanciando uma interface, ele está instanciando a classe MyArrayList, e atribuindo uma referência da instância à variável ar, do tipo List, que é uma interface. É o bê-a-bá do polimorfismo
Uma coisa legal seria desmembrar a classe System... ela fere bastante a orientação a objetos, fazendo uma mistureba geral de coisas mais-ou-menos relacionadas ao sistema. System.out, .in e .err poderiam muito bem ir para a classe Console ou algo do gênero, depois de toda a repensada no sistema de IO do Java...
Anonymous wrote:Uma outra proposta que eu faria ao Java3 é tornar o JDO uma core API da plataforma e a maneira padrão para se fazer persistência de objetos (chega de ficar criando código para JDBC).


Tanta gente querendo tirar aquele monte de core APIs desnecessarias em muitos casos (inclusive a propria JDBC), e vc falando de adicionar o JDO!? Putz!

Diz a lenda que perguntaram ao James Gosling uma vez se tinha alguma coisa que ele tiraria do Java, e a resposta dele foi "A JDBC. Eu não uso pra nada, não me faria falta, mas eu sei, é claro, que muita gente depende disso.", e eu concordo com ele: foi um erro colocar a JDBC no pacote java.sql - no Java 3, ela poderia ser toda colocada no pacote javax.sql sem maiores problemas.
Bom, vamos por partes...qual(is) os problemas que vc está tendo ao gravar arquivos?
http://java.sun.com/j2se/vb.development.center.html

Boa leitura!

[]'s
-cv
Se tudo mais falhar, leia o XML pra dentro de um StringBuffer (usando StringWriter/OutputStreamWriter), e aí sim chame o UmMetodo() então...
Completando, o mesmo exemplo que o dango mandou, só que convertido pra Collections:



[]'s
-cv
Hmmm...é mesmo...sorry
smota wrote:
Tenho que desenvolver uma aplicação para PALMOS (virtualmente qq versão) , a aplicação terá um bocado de entrada de dados (a principio simples, apenas numeros e algumas seleções em listas), manipulação básica de bytes e então tenho que conectar a um sistema via cabo para troca de dados ...


Show, J2ME faz isso numa boa, mas vc precisa de um Palm que rode PalmOS versão 4 ou superior - os anteriores não têm implementação da KVM disponível, se me recordo bem. Mas dê uma conferida, não tenho certeza disso.

As conexões de comunicação dos Palms variam entre USB, Serial (RS232) e infra-vermelho, mas tem alguns palms frescos com bluetooth, cartões de expansao 802.11b, e por aí vai. Mas pode confiar que vai ter um protocolo serial (seja ele USB, RS232 ou infra) disponível, e você vai poder fazer conexões HTTP ou sockets nele através da J2ME.

Quanto às GUIs, a J2ME tem seu próprio toolkit, que é uma baba de usar, mesmo que vc não esteja acostumado a Swing, AWT ou SWT.

HTH!
-cv
Não ao nome? Ué, iriamos chamar do que? Java TNG? Java++?
Régis Steigleder wrote:
Se eu gostasse tanto de SQL puro que resolvesse utilizar apenas Session Bean com JDO, por exemplo, eu teria como demarcar minhas transações? E mais, estaria fazendo a coisa corretamente escolhendo esta opção?
Quer dizer, do seu ponto de vista, não utilizar Entity (BMP ou CMP) seria um pecado mortal em termos de projeto???
Um abraço.


Po, se vc gostasse tanto de SQL puro, vc usaria JDBC, não JDO

Creio que seria impossível, ou bem complicado, o controle transacional dos SFSBs... Uma opção mais viável seria usar SFSBs+SLSBs+Hibernate (hibernate.sf.net). Tem até uns tutoriais sobre isso, e sobre como funciona o controle transacional no site do Hibernate.

Sobre ser um "pecado" ou não, bem, isso quem vai dizer é o sucesso do seu projeto (tanto em implementação quanto em tempo de manutenção) ... adiantando a resposta: não é pecado, e é bem útil em alguns casos raros, mas fazer isso "por esporte" é burrada
Algumas dúvidas que podem te ajudar:

- Acontece só com o SAX? Já tentou ler o arquivo, simplesmente, sem parsear?

- Funciona se vc colocar o JAR no Classpath e der um this.getClass().getResourceAsStream("TEMP/x.xml")?

[]'s
-cv
Bom, impacto zero, e é exatamente pra isso que os BLOBs servem: pra permitir que vc guarde arquivos grandes sem se preocupar muito com performance. Num BLOB, o que fica gravado dentro da tabela é só uma referência ao arquivo, que é guardado externamente (sorry, nao me lembro o nome do diretorio onde os BLOBs ficam). O unico limite é que, se vc estiver usando plataforma x86, não dá pra gerenciar arquivos > 2gb, pelo menos por enquanto -- nao sei se o MySQL tem alguma gambiarra contra isso, no entanto.

[]'s
-cv
 
Índice dos Fóruns » Perfil de cv » Mensagens enviadas por cv
Ir para:   
Powered by JForum 2.1.8 © JForum Team