Eu usava... até a vivo corta: Eu usava... até a vivo cortar o barato...
sacanagem... os gaúchos podem trocar SMS entre si,
gratuitamente pelo site da vivo, ou pelo jSMS...
Agora os paulistas (como eu) e o resto dos brasileiros
não podem. É muita sacanagem da vivo, algo que me fez
deixar de ser cliente deles, só de raiva. Outras
operadoras disponibilizam o serviço para outros estados,
só a vivo que fica com essa coisa... Sacanagem mesmo.
Mas para não fugir do assunto (ja fugi bastante né)
o jSMS é muito bom sim, para quem quer mandar SMS para
celulares Claro, Vivo(Somente RS), eu testei e funciona
muito bem. Recomendo.

melhor do gênero ...: Eu uso esse programa desde as primeiras versões. Sem dúvida é o melhor do gênero. Só não consigo enviar mensagens para os celulares da TIM, pois não sou usuário desta operadora e não tenho o código de acesso. Mas para as outras operadoras envio sem problema algum, inclusive para a VIVO (pois envio aqui do Rio Grande do Sul).

Está de parabéns o criador desse programa! Aguardo novas atualizações ;D

[]'s go go go!

Colaboradores: Pessoal, o Renato é o cabeça do projeto JSMS que ta ficando cada vez melhor, se não fosse algumas operadoras que tem colocado impecilhos ... falei com ele há alguns dias atrás e ele está pensando em aumentar a capacidade do JSMS para outras operadoras no Brasil todo.

Seria interessante quem estiver disposto a ajudar que possa entrar no portal do projeto e participar da lista, a fim de que possamos trocar idéias e consecutivamente, possamos aumentar a extensão do JSMS.

Segue o site do projeto:
http://jsms.com.br/index.php

--
Márcio Dantas
marcio@mdantas.com.br

Contribuição para o projeto: O projeto está precisando de pessoas interessadas em adicionar novas operadoras. Atualmente são suportadas Claro, Brasil Telecom, Oi, Vivo e TIM. Além disso, eu já implementei mais três para a próxima versão: CTBC, Telemig e Amazônia Celular. Para criar uma nova operadora não é necessário muito conhecimento... Se tiveres interesse em ajudar o projeto, por favor vá até o fórum do jSMS e se manifeste!
Além disso, a nova página do jSMS está precisando de um novo layout... ;-D

Obrigado a todos por utilizarem o jSMS!

Parabéns, projeto bem útil.: Parabéns, projeto bem útil.

Testei aqui com a Oi de Minas Gerais, e funcionou razoavelmente bem. Algumas vezes recebia "Conexão recusada...", ainda que o código de autenticação seguramente estava correto.

Havia um outro projeto nessa linha, o sms-br, mas foi descontinuado por falta de tempo do autor. O sms-br tinha uma interface parecida com a do licq, e usava o gocr para dar um palpite (não era 100% efetivo) no código de autenticação.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

Conexão recusada quer dizer: Conexão recusada quer dizer que a operadora recusou a sua conexão. Não tem nada a ver com o código de autenticação. Geralmente acontece quando a operadora está sobrecarregada (acontece muito com a Claro) e eles rejeitam novas conexões. Se você tentar pelo site, o mesmo acontecerá.

Atalho para "Limpar": O atalho Alt+L ("Limpar") não está funcionando. Enviar (Alt+E) e copiar (Alt+P) funcionam. Estou testando o "jSMS v2.20".

Uma sugestão, incluir um botão "Cancelar" na janela de autenticação. Atualmente para fazer isso só fechando a janela, o que é menos prático.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

Re: Atalho para "Limpar": Não existe tal atalho para limpar. Antigamente, não havia confirmação antes de limpar uma determinada lista. Sendo assim, se alguém pressionasse CTRL+L sem querer, acontecia porcaria. Vou colocar o atalho novamente.
Você pode remover a mensagem que está sendo enviada do histórico para efetuar o cancelamento também. Vou adicionar um botão de cancelar na janela de autenticação então.

Pois é, e a VIVO é o maior: Pois é, e a VIVO é o maior SPAMMER do meu celular e o pior é que nem dá condicoes de eu bloquea-lo assim como posso bloquear de outros.

Um colega meu do trabalho que tem cecular vivo bluetoth bloqueia ele enviar arquivos/fotos direto do celular para o computador e ele tem que enviar do cecular para a vivo e apanha-lo na internet. É mole ? Falando com alguns colegas na internet ele foi orientado a levar o celular numa asstec que eles removem o software da vivo e deixam apenas o software original do celular que por padrao nao vem nada bloqueado.

Re: Pois é, e a VIVO é o maior: Existe um programa chamado Diego, que funciona somente para celulares Nokia. Através desse software, é possível livrar o celular dos bloqueios feitos pela Vivo. Eu já fiz isso com o meu... é uma beleza! Mas é meio difícil encontrar o software para download, pois ele é utilizado pelas assistências técnicas.

VIVO: A VIVO é a M$ do mundo móvel... :-<

Parabéns!: Parabéns pelo projeto!

É importante que existam desenvolvedores livres que se interessam em produzir utilitários inteiramente portáveis como o JSMS, porque isso diminui a distância entre as plataformas e seus usuários, fortalece a comunidade do SL e sistemas operacionais alternativos como o Linux.

Dependência livre?: É possível rodar/compilar o jSMS em alguma alternativa livre à MV da SUN, como Kaffe ou GCJ?

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

Existem outros sim: Eu conheço mais dois projetos livres com o mesmo propósito:
- MensagemWeb, que por sinal é feito por mim ;-), veja http://mensagemweb.codigolivre.org.br/.
- fr0g::SMS, mas esse eu não sei se ainda é mantido ou se está funcionando, veja http://fr0gsms.codigolivre.org.br/.

Quando eu fiz o MensagemWeb eu não sabia que o jSMS existia, mas de qualquer forma eu prefiro a interface que eu fiz (pensando em simplicidade máxima) então eu não tive muitos motivos para bater a cabeça na parede =P.

Re: Dependência livre?: Não faço a menor idéia! Nunca tentei, mas teoricamente deve funcionar. Porém, a Swing ainda não é totalmente suportada no GCJ.

Da ultima vez que vi...: Da última vez que vi como está o progresso do GNU-Classpath (no qual a maior parte das VMs GPL são baseadas), a maioria das bibliotecas do próprio Swing são ditas como suportadas (faltam algumas APIs mais específicas como suporte avançado a tabelas, edição de texto RTF, etc), mas o "normal" deve funcionar.

Se vc. tem uma VM alternativa já instalada, faz esse favor pro pessoal! testa o JSMS nela, vê se funciona e posta o resultado :-P. Isso vai ajudar inclusive na adoção do GNU-Classpath.

Eu acredito que o processo evolutivo das VMs alternativas deve acelerar bastante agora. Isso pq foi liberada uma nova licença para o Java. Embora ainda não seja possível "copiar e colar" código da implementação da Sun em uma VM GPL (e nem será, pq o projeto Apache Harmony será a versão livre "oficial"), já é possível olhar o código da Sun, ver como funciona e implementar sua versão baseado nesse conhecimento (sem medo de se tornar "contaminado" com isso, como o pessoal da FSF temia).

> Se vc. tem uma VM alternati: > Se vc. tem uma VM alternativa já instalada, faz esse favor pro pessoal! testa o JSMS nela, vê se funciona e posta o resultado :-P. Isso vai ajudar inclusive na adoção do GNU-Classpath.

Removi o Kaffe da máquina depois que me frustrei ao tentar rodar o Azureus, que é a única aplicação Java que costumo usar. Quanto ao GCJ, a FAQ diz que não há suporte ao Swing.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

GJC: O GJC é um compilador estático, ou seja, ele transforma o código java em código nativo. Não é o mesmo que rodar seu aplicativo sob uma JVM.

Eu fiz o comentário acima baseado na seguinte documentação acessível pelo site do GNU-Classpath e pelo Kaffe:

http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html

Eu ainda não fiz uma pesquisa extensa sobre o suporte das APIs livres ao Swing (falta de tempo...), mas creio que vc. deva tentar o SableVM. Há algumas demonstrações com Swing em:

http://sablevm.org/screenshot.html

O assunto swing parece ser bem "quente" em suas listas de discussão, o que deve garantir bom suporte. Para quem usa aplicativos em Java e faz verdadeira questão do uso de JVMs alternativas, vale a pena experimentar.

Claro, dá um pouco de trabalho. Quem não quiser esquentar a cabeça testando, resolvendo bugs e aprimorando, não trabalha com implementações livres: instala a JVM da Sun e vive feliz.

Se vc. obtiver alguma mensagem de erro java e tiver algum problema, talvez eu possa ajudar, no que estiver ao meu alcance: copernico.vespucio.publico@gmail.com.

[]s

> O GJC é um compilador est: > O GJC é um compilador estático, ou seja, ele transforma o código java em código nativo. Não é o mesmo que rodar seu aplicativo sob uma JVM.

Sim, embora possa compilar em bytecode para rodar sob a JVM. A compilação direta em código de máquina nativo tende a baixar os requisitos de memória ao dispensar a máquina virtual, o que pessoalmente seria mais interessante.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

mas...: A compilação direta em código de máquina nativo tende a baixar os requisitos de memória ao dispensar a máquina virtual, o que pessoalmente seria mais interessante.

Mas porém:

1- Ao compilar estaticamente para código nativo uma aplicação que utilize grande quantidade de classes da API (principalmente desktop), vc. tem duas opções:

a)Compilar estaticamente *todas* as dependências, o que criaria um arquivo bastante grande cujo conteúdo não pode ser compartilhado por outras aplicações.

b)Manter as dependências em bytecode. Nesse caso vc. não dispensa a JVM. Apenas uma parte da aplicação roda em código nativo.

Adicionalmente, perceba que os dispositivos normalmente utilizados pela máquina virtual continuam sendo usados após a compilação estática: espaço heap, namespaces seguros, coleta automática de lixo, etc.). Vc. elimina apenas a verificação de bytecodes (e isso torna tão perigoso distribuir seus binários como em qualquer tecnologia nativa, derrubando uma das vantagens do java), talvez o carrgamento dinâmico de classes (outra opção ruim), etc.

2- Aprendi que compilação estática não é sinônimo de desempenho. O compilador estático, por melhor que seja (e o GJC não é um primor), não tem como ter informações reais sobre o ambiente de execução para decidir quais otimizações vale a pena utilizar. Em ambiente de execução, o compilador JIT (Just In Time) pode avaliar as melhores opções e compilar para cache vários blocos de código crítico (hot spots), acessados frequentemente, para linguagem nativa. Na maior parte das situações, o resultado é bem melhor do que código compilado estaticamente. É o JIT que faz com que o desempenho do Java alcance o C++ em muitas aplicações.

Na minha opinião, usar compiladores estáticos como o GJC não tem uma boa relação custo-benefício.

Se vc. quer *realmente* sua aplicação desktop em Java "voando baixo", deixe a ideologia temporariamente de lado e instale (por enquanto) a JRE 1.5 (Java 5) da Sun. Assim que o Harmony sair (eu participo da lista de discussão e ela é extremamente ativa), substitua seu JRE por essa opção livre.

Uso compartilhado da API (as classes da API são carregadas apenas uma vez, não importa quantas JVM ativas vc. tenha), um dos melhores compiladores JIT da atualidade para desktop, auto-tuning (a JVM usa apenas a memória que precisa a cada momento)... A relação custo benefício dessa versão em particular é boa demais para ser ignorada.

> b)Manter as dependências: > b)Manter as dependências em bytecode. Nesse caso vc. não dispensa a JVM. Apenas uma parte da aplicação roda em código nativo.

E por que não compilar nativamente também as dependências (ligação dinâmica), assim como os aplicativos em C/C++ e outros? Há algum impedimento técnico para tal?

> 2- Aprendi que compilação estática não é sinônimo de desempenho. O compilador estático, por melhor que seja (e o GJC não é um primor), não tem como ter informações reais sobre o ambiente de execução para decidir quais otimizações vale a pena utilizar. Em ambiente de execução, o compilador JIT (Just In Time) pode avaliar as melhores opções e compilar para cache vários blocos de código crítico (hot spots), acessados frequentemente, para linguagem nativa. Na maior parte das situações, o resultado é bem melhor do que código compilado estaticamente. É o JIT que faz com que o desempenho do Java alcance o C++ em muitas aplicações.

Bom, existe a técnica do Profile-Guided para compiladores de código de máquina nativo. O GCC (que inclui o GCJ) não tem, mas pode vir a ter algo semelhante. Ademais, se como você mesmo diz o "JIT equipara-se ao desempenho do C++ em muitas aplicações", a ténica de compilação nativa, mesmo sem o uso de profile ainda é melhor, ao menos para C++. É claro que o Java, com coleta de lixo e outros "overheads", que são intrínsecos à linguagem, não deve permitir o mesmo desempenho que os compiladores para C/C++, mas dizer quão perderá é meramente especulativo.

O que de fato é sabido perder na compilação nativa é a portabilidade do binário. Dentro do software livre, no entanto, esta perda é abafada em decorrência do acesso ao código-fonte.

> Se vc. quer *realmente* sua aplicação desktop em Java "voando baixo", deixe a ideologia temporariamente de lado e instale (por enquanto) a JRE 1.5 (Java 5) da Sun. Assim que o Harmony sair (eu participo da lista de discussão e ela é extremamente ativa), substitua seu JRE por essa opção livre.

Mas eu tenho instalado o JRE 1.5, embora seja por contragosto --basicamente para rodar o Azureus e os applets. Bom, com o Azureus, o applet do BB e o jSMS, três aplicativos Java, o Exmap me informa o consumo total de 98MB (62M+20M+16M). Isso, naturalmente, eliminando as partes compartilhadas pelas aplicações Java.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

compilação estática: >E por que não compilar nativamente também as dependências (ligação dinâmica), assim como os aplicativos em C/C++ e outros? Há algum impedimento técnico para tal?

Compilar tudo para código nativo tem duas conseqüências possíveis:

1- Vc. compila todas as dependências para um único executável. Ele vai ficar muito grande e, sem o suporte da VM e carregamento dinâmico, ocupar memória Stack sem necessidade. Adicionalmente, cada aplicativo compilado terá sua própria cópia das dependências, o que seria redundante.

2- Vc. compila as dependências como bibliotecas separadas. Aí vc. possivelmente vai ganhar de presente a confusão entre bibliotecas e versões característica de outras linguagens.

A maioria dos compiladores estáticos que conheço usam a primeira opção. É como gravar em arquivo o cache do JIT.

>Bom, existe a técnica do Profile-Guided para compiladores de código de máquina nativo. O GCC (que inclui o GCJ) não tem, mas pode vir a ter algo semelhante.

O problema dessa opção é que vc. de qualquer maneira vai ter um binário compilado estático no final. Por mais afinadas que sejam as otimizações no momento da compilação, qualquer mudança no ambiente pode mudar esse cenário.

mas dizer quão perderá é meramente especulativo Não exatamente, existem profiles nesse sentido. Se vc. se interessa pelo assunto, procure pelos artigos do Osvaldo Doerdlein na web.

Mas eu tenho instalado o JRE 1.5, embora seja por contragosto --basicamente para rodar o Azureus e os applets. Bom, com o Azureus, o applet do BB e o jSMS, três aplicativos Java, o Exmap me informa o consumo total de 98MB (62M+20M+16M). Isso, naturalmente, eliminando as partes compartilhadas pelas aplicações Java.

Eu uso um simples top para essas coisas! ;-P.
Bom, não uso o Azureus nem sou cliente do BB, mas tô achando estranho o consumo de 16Mb pro JSMS. Que eu me lembre ele não chega a isso na minha máquina não... Vou dar uma testada e te informo, pra gente comparar.

O que dá pra adiantar é o seguinte, a respeito do compartilhamento de classes do Java5: Por motivos de segurança, por enquanto ele é só para as classes da API do java (J2SE). Isso significa que, quanto mais bibliotecas de terceiros uma aplicação usa, menos ela se beneficiará com o compartilhamento. Suponho que seja esse o caso do Azureus.

Mas se vc. quer um bom candidato para profiling, eu sugiro http://javaboutique.internet.com/J-Cad/. Dá uma olhada! :-D

Qual a Vantagem?: N]ão estou vendo muita vantagem nesse programa, pois se tenho que pagar para enviar as mensagens posso faze-lo do meu celular mesmo, as operadoras que aceitam o envio gratuito, tem sites que o fazem, como Claro e Brasil Telecom, só pela comodidade de usar um teclado?

Imagine quando o backup falha: Imagine quando o backup falhar voce poder receber uma mensagem no seu celular relatando isso. As possibilidades são muitas.

Primeiro, se você paga, é m: Primeiro, se você paga, é muito mais confortável redigir uma mensagem usando um teclado padrão de PC --claro, se você estiver acesso ao computador.

Segundo, sendo gratuito e a operadora oferecendo site: 1) o acesso é muito mais rápido e prático eliminando-se o browser; 2) as informações do remetente (nome) e do receptor (telefone) são guardadas, isto elimina a necessidade de redigitar o telefone de destino e assinatura do remetente; 3) é guardado um histórico de mensagens, com o browser não.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

Não creio que este seja o pr: Não creio que este seja o propósito de programas como o jSMS, mesmo porque acredito que não seja possível enviar mensagens SMS via linha de comando. Ademais, algumas operadoras usam autenticação por captcha, que inviabiliza a automação da tarefa.

Para o fim de alerta e avisos, como você propôs, existem planos que permitem enviar e-mails para algo do tipo DDXXXXXXXX@sms.operadora.br, que é muito mais cômodo e seguro para scripts.

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.