| Autor |
Mensagem |
|
|
Alguns CDs de instalação do Oracle (e do Sybase) tinham uma JVM meio velha, que dava problemas em máquinas Pentium IV mais novas ( o famigerado problema com symcjit.dll ).
Ainda acho que é melhor usar o Flash (como é o caso da própria Oracle, naqueles CDs que demonstram GRID computing que ela andou distribuindo faz pouco tempo), ou então mandar um DVD com um filminho para demonstração (só de DVDs da Sun com baboseiras eu tenho uns três: dois com o próprio big boss, Jonathan Schwartz, e outro só sobre 'Java Economy' (ainda não tive a paciência de assistir).
Filmes impressionam, e não precisam de computador (só de um aparelho de DVD, que tem em qualquer barraco na favela...). Dependendo saem até mais baratos que fazer um "flash", mas é claro que precisam de produção e de alguém que prenda a atenção - uma moça bonita para fazer a apresentação e um cara bom de marketing para fazer a demonstração ajudam...
|
 |
|
|
|
Obrigado pela dica.
|
|
|
|
|
Nunca sei direito se o Sun Provider está ou não implementando tal algoritmo na tal versão. Como eu tenho de escrever software que funcione na versão 1.3, 1.4.0, 1.4.1, 1.4.2, e se é Sun, ou IBM (como é o caso do Websphere que usa a JVM da IBM ), ou BEA etc. e não quero quebrar a cabeça com isso, simplesmente uso o BouncyCastle http://www.bouncycastle.org e fixo uma versão (por exemplo, 1.24). Aí sei exatamente o que está suportado ou não. ( http://www.bouncycastle.org/specifications.html diz exatamente o que está suportado na 1.24 )
|
|
|
|
|
Bom eu aprender a mexer direito com esse forum. Primeiro foram os \ que ele interpretou em vez de "passar batido" e agora aquela palavra de nove letras que começa com M, termina com T, tem um S no meio e ficou com um estranho $ automaticamente... Uma hora eu me acostumo. Que outros truques o fórum tem?
|
|
|
|
|
Primeiro - onde é que você está hospedando o seu WML: num servidor IIS (Microsoft), num Apache, num Sun Web Server, onde mesmo? Se for num IIS, depende da versão do Windows - consulte o MSDN se for o caso, http://msdn.microsoft.com. Por isso é que ele fala em consultar o seu administrador de rede - cada ambiente é diferente.
|
|
|
|
|
Mais um motivo para eu não ficar usando java.nio a torto e a direito. Além de ela não estar disponível em JDK 1.3, parece que para certas coisas ela não é muito fácil de usar - ver a thread "Taming the NIO Circus" no forum.java.sun.com, Java Programming.
|
|
|
|
Droga, apertei o botão errado ... o botão de criar nova mensagem deveria ser mais escondido que o botão de reply.
É mais fácil fazer o benchmark do que falar, mas estou chutando que teríamos a seguinte situação:
Tempo gasto:
FileChannel.transferTo < NIO Buffers < BufferedXStream+FileXStream < FileXStream puro
Consumo de memória:
FileChannel.transferTo < FileXStream < BufferedXStream + FileXStream < NIO Bufffers
Consumo de CPU (supondo que, se você tiver um disco ATA, que esteja configurado para usar DMA para reduzir o consumo de CPU em I/O):
FileChannel.transferTo < NIO Buffers < BufferedXStream + FileXStream < FileXStream
É estranho que eu esteja chutando que BufferedXStream + FileXStream consuma menos CPU que FileXStream sozinho (afinal, está executando mais código), mas é que BufferedXStream evita que FileXStream esteja constantemente acessando o sistema operacional via JNI, o que consome um monte de CPU.
Obviamente é necessário fazer o teste, porque na prática aparecem coisas que não são esperadas só pela teoria. (Para explicar os resultados, é preciso mudar a teoria...)
|
|
|
|
É mais fácil fazer o benchmark do que falar, mas estou chutando que teríamos a seguinte situação:
Tempo gasto:
FileChannel.transferTo < NIO Buffers < BufferedXStream+FileXStream < FileXStream puro
Consumo de memória:
FileChannel.transferTo < FileXStream < BufferedXStream + FileXStream < NIO Bufffers
Consumo de CPU (supondo que, se você tiver um disco ATA, que esteja configurado para usar DMA para reduzir o consumo de CPU em I/O):
FileChannel.transferTo < NIO Buffers < BufferedXStream + FileXStream < FileXStream
É estranho que eu esteja chutando que BufferedXStream + FileXStream consuma menos CPU que FileXStream sozinho (afinal, está executando mais código), mas é que BufferedXStream evita que FileXStream esteja constantemente acessando o sistema operacional via JNI, o que consome um monte de CPU.
Obviamente é necessário fazer o teste, porque na prática aparecem coisas que não são esperadas só pela teoria. (Para explicar os resultados, é preciso mudar a teoria...)
|
|
|
|
Em Linux:
transferTo chama a API sendfile. Como quase todas as APIs do Unix podem ser interrompidas (errno = EINTR), acho que dá para interromper sem problemas, mas isso é o caso de testar.
Em Solaris:
transferTo chama a API sendfilev, carregada dinamicamente de /usr/lib/libsendfile.so.1. Fora isso, é igual ao Linux.
Estou falando baseado apenas no código fonte da 1.4.2 do JDK da Sun, fonte j2se/src/solaris/native/sun/nio/ch/FileChannelImpl.c, função Java_sun_nio_ch_FileChannelImpl_transferTo0().
Não sei se o JDK da IBM, ou da BEA, implementam FileChannel.transferTo dessa maneira.
|
|
|
|
Discordo um pouco sobre pôr ou não imagens na base.
Dependendo do número de imagens, e do banco de dados que você tem, é realmente melhor ter as imagens na base.
Se você tem mais de 1000 (ou 3000, depende do filesystem) arquivos em um diretório, seu desempenho fica realmente sofrível, e você precisa usar um monte de truques (como criar um monte de sub-sub-sub-diretórios para colocar os arquivos).
Na verdade há dois problemas com imagens na base:
- campos BLOB não são muito bem suportados em diversos drivers JDBC. Por exemplo, o driver JDBC para o Oracle não suporta direito o tipo java.sql.Blob, você precisa usar oracle.sql.BLOB. Não sei como é o caso do FireBird, provavelmente não deve ter problemas.
- se você vai deletar e inserir um monte de imagens, você pode ter de dar uma olhada como é que o seu banco lida com a reutilização do espaço usado. Normalmente não deve ter problemas, mas alguns bancos são bem bobinhos e o que ocorre é que de vez em quando você precisa usar um utilitário para "compactação".
|
|
|
|
Uma mania (ou vício, ou bitola, ou "deformação profissional", ou sei lá o quê...) que os desenvolvedores J2EE têm depois de algum tempo é achar que tudo é MVC (Model/View/Controller) e Frameworks.
A sua aplicação é um caso clássico para o uso de MVC; um monte de telas (V = View) que devem ter navegação (C = Controller) e acessam algum dado (M = Model).
Deve ter alguém que sabe de um "framework" MVC para aplicações desktop, que é o que o jfnando quer fazer. Alguém pode procurar isso, para informar o OP ("Original Poster" em inglês, não sei qual é o termo em português...)?
|
|
|
|
ou melhor,
Sutilezas do Bourne Shell...
|
|
|
|
É bom ler a mensagem de erro.
Na linha 44 está o seguinte comando:
O que está ocorrendo aqui? É legal ler a documentação do Bourne Shell (leia a do bash). Não li a documentação - estou respondendo sem ler, mas provavelmente ele está entendendo como um comando. Para evitar isso (provavelmente a variável JAVA_OPTS já tem algum valor que pode dar problemas),
mude a linha para:
e veja o que ocorre.
|
|
|
|
|
Se não me engano, alguns application servers, como o WebSphere 5.1, suportam isso, mas isso não está definido na especificação EJB 2.0, portanto não vai funcionar em qualquer lugar. Melhor tentar não usar o que você sabe que não funciona em todos os lugares, para evitar "ficar amarrado" ao fornecedor.
|
|
|
|
- A sua aplicação tem frames?
- Como é o link (se for relativo você obviamente vai continuar em https. Você deve pôr o link absoluto http://seusite/suaaplicacao/suaacao.do, por exemplo.)
|
|
|
|