Linguagem para desenvoler aplicativos Linux / Windows

[msamsoniuk]

ok, para mostrar que eu nao guardo rancores vou ateh abrir a possibilidade de reimplementar um projeto meu em java!

eu tenho um software relativamente simples feito em C cuja unica funcionalidade eh abrir um arquivo S19 e descarregar ele pela serial para um HC908. atualmente eu rodo ele apenas no linux, gostaria de rodar ele tambem no windows e, eventualmente, adicionar funcionalidades graficas que eu vi em outro software similar, que alem da capacidade de descarregar software pela serial (para um DSP 320LF240x), implementar tambem um emulador de terminal texto e um scope.

eh possivel fazer facil em java ? eu andei estudando a possibilidade de usar um xterm para isso no linux, pois ele emula tanto o vt220 para texto quanto o tektronix 4014 para graficos, mas continuaria restrito ao linux, gostaria de uma alternativa para windows.

uma preocupacao minha: nao gostaria de obrigar o usuario a ter que baixar uma nova jvm inteira tamanho gigante! seria possivel usar a capacidade java jah disponivel nos browsers ? supostamente sao todos compativeis entre si e suportam todas as funcionalidades necessarias para o que eu preciso, nao eh ?

[Paulo]

ok, para mostrar que eu nao guardo rancores vou ateh abrir a possibilidade de reimplementar um projeto meu em java!

eu tenho um software relativamente simples feito em C cuja unica funcionalidade eh abrir um arquivo S19 e descarregar ele pela serial para um HC908. atualmente eu rodo ele apenas no linux, gostaria de rodar ele tambem no windows e, eventualmente, adicionar funcionalidades graficas que eu vi em outro software similar, que alem da capacidade de descarregar software pela serial (para um DSP 320LF240x), implementar tambem um emulador de terminal texto e um scope.

eh possivel fazer facil em java ? eu andei estudando a possibilidade de usar um xterm para isso no linux, pois ele emula tanto o vt220 para texto quanto o tektronix 4014 para graficos, mas continuaria restrito ao linux, gostaria de uma alternativa para windows.

uma preocupacao minha: nao gostaria de obrigar o usuario a ter que baixar uma nova jvm inteira tamanho gigante! seria possivel usar a capacidade java jah disponivel nos browsers ? supostamente sao todos compativeis entre si e suportam todas as funcionalidades necessarias para o que eu preciso, nao eh ?

Marcelo,

Com relação ao usuário não precisar baixar uma nova JVM, vc pode fazer a sua aplicação em Java e colocar junto com a sua aplicação uma JVM e configurar a sua aplicação para rodar a partir da sua JVM, dessa forma o usuário não necessita baixar uma JVM e nem ter uma instalada.
Quando vc gerar o instalador da sua aplicação vc embarca a JVM junto.
Não sei se isso te ajuda, espero que sim.


Até +...
Paulo D.

[polesapart]

Hmm eu fiz algo semelhante em gtk, usando C mesmo. Pras rotinas de comunicação serial eu já tinha implementado uma camada de abstracao tosca com rotinas tipo serial_{open,read,write,close}, aí só precisei fazer o port pra windows, que foi um ctrl+c/ctrl+v de exemplos de livros e funcionou.

O que vc descreve dá pra fazer em java sim, e como hj em dia aquelas jvm da micro$oft sao ilegais, normalmente o camarada já tem a jre (que é a jvm + as bibliotecas base) instaladas no computador, se ele instalou o plugin recomendado, que é o da sun. Se o cara ainda tem o plugin da microsoft (windows xp sem service packs), nao rola.

Isto tudo tou assumindo uma aplicacao em java normal, nao uma applet pra rodar em browser, pq aí a situacao complica um pouco: embora rodasse até na jvm da micro$oft (que cito mais por questoes historicas, acho que ninguem ainda tem isto), pra ter acesso as portas seriais é preciso rodar uma applet com assinatura digital, o que até onde lembro, é um pé no saco, desculpem a expressão.

[polesapart]

Marcelo,

Com relação ao usuário não precisar baixar uma nova JVM, vc pode fazer a sua aplicação em Java e colocar junto com a sua aplicação uma JVM e configurar a sua aplicação para rodar a partir da sua JVM, dessa forma o usuário não necessita baixar uma JVM e nem ter uma instalada.
Quando vc gerar o instalador da sua aplicação vc embarca a JVM junto.
Não sei se isso te ajuda, espero que sim.


Até +...
Paulo D.

Aí ele teria que embarcar uma jre pra windows, outra pra linux, e eventualmente outra pra outra coisa. Se for exclusivamente distribuir em CD não vejo problemas, mas não rola fazer um pacotão pra baixar pela internet. É o calcanhar de aquiles de muitos programas em java hj em dia, pq as opções mais "amigáveis ao usuário" são embutir a jre e auto-instalar, ou tentar ensinar até toupeiras a baixar e instalar a jre do site.

[ivan]

Se Java roda em celulares pq não vai rodar em 256 MB.
É muita distorção da realidade pro meu gosto.

Pouco importa para o mercado a completude de um recurso computacional, se êle depende de outras linguagens ou ambientes.
O que conta é qto se ganha com isso(lucro), qto tempo tem o retorno do investimento feito. E o desempenho se conquista, como na plataforma Web, com tecnologia moderna, diferente do CGI.

Como eu disse, é apenas uma ferramenta e a inteligência está nas pessoas.

ass,
Leigo51

[msamsoniuk]

Marcelo,

Com relação ao usuário não precisar baixar uma nova JVM, vc pode fazer a sua aplicação em Java e colocar junto com a sua aplicação uma JVM e configurar a sua aplicação para rodar a partir da sua JVM, dessa forma o usuário não necessita baixar uma JVM e nem ter uma instalada.
Quando vc gerar o instalador da sua aplicação vc embarca a JVM junto.
Não sei se isso te ajuda, espero que sim.

Até +...
Paulo D.

Aí ele teria que embarcar uma jre pra windows, outra pra linux, e eventualmente outra pra outra coisa. Se for exclusivamente distribuir em CD não vejo problemas, mas não rola fazer um pacotão pra baixar pela internet. É o calcanhar de aquiles de muitos programas em java hj em dia, pq as opções mais "amigáveis ao usuário" são embutir a jre e auto-instalar, ou tentar ensinar até toupeiras a baixar e instalar a jre do site.

nao tem CD nao, eh para ser distribuida gratuitamente via sourceforge e funcionar como aplicacao de apoio para o compilador SDCC, que possui licenca GPL e roda em uma infinidade de plataformas. incluir uma jvm para cada uma destas plataformas seria um total contra-senso! nao tem logica!

uma possibilidade seria explorar o fato de praticamente todas estas plataformas possuirem um browser compativel com java. por exemplo, o meu macintosh centris 650 possui um netscape 3.04 com suporte a java e possui uma porta serial, portanto deveria ser perfeitamente possivel acessar os microcontroladores atraves desta maquina, certo ?

sobre a historia dos rovers, olha que interessante o rover de 1997:

Código: Selecionar todos

The 'Sojourner' rover has only a single CPU used in its operation. The computer is an 80C85 with a 2MHz clock rated at 100KIPS. It can address 64K of memory. The computer uses, in a 16Kbyte page swapping fashion, the memory provided in 4 different chip types:

Size (Kbytes)    Type    Function
16    PROM, Harris 6617    Boot code and 'Rover-Lite' backup code
64    RAM, IBM 2586    Main memory
176    5, SEEQ 28C256 32Kbyte chips    Programs, patches and nonvolatile data storage
512    Micron MT1008 RAM    Temporary data storage


os rovers atuais seriam uma evolucao deste primeiro, e nao sao 256MB, mas sim 128MB (256MB ele possui de flash), dos quais quase 90MB sao reservados para buffers de imagem. segundo as informacoes, o software do rover mais moderno foi inteiramente desenvolvido pela lockheed martin em C. isso foi revelado justamente quando um reporter tentava verificar com Peter Gluck (engenheiro de software da nasa) a noticia de que os rovers rodavam java:

Código: Selecionar todos

R> The only reason I brought that up is because one of my editors said, Oh look, they have Java on this thing.

P> Oh, Java. Well, we have Java in the ground system not onboard the spacecraft.

R> Right. That's what it's starting to sound like.

P> That's right. Yeah. The spacecraft software is entirely in C.

R> C? Really? That surprises me a little bit.

P> Yes. It's entirely in C.

R> I thought Lockheed Martin was a big Ada shop for this sort of thing.

P> Ada is used largely in military applications, but JPL at any rate has moved away from Ada. Cassini, I believe, would be the last JPL mission that used Ada. And that was largely due to the success of the Mars Pathfinder in the mid-nineties. And as I said, these missions are to a large extent all derived from Mars Pathfinder.

R> After that successful mission, you say, Hey, we could do it in C now. That's not as scary as everybody thought?

P> Yeah. Right. And we've been running VxWorks as our real-time operating system. I believe they all run VxWorks. I couldn't speak for some of — let's see. We've been branching out in contractors a little bit. I believe — you know what? I'm not sure what Ball Aerospace is using in their spacecraft. And I am not sure what Orbital Science is using in their spacecraft. But the Lockheed Martin line does use VxWorks as the operating system. In addition to the six Mars missions we mentioned, we've done another half a dozen Lockheed Martin missions over the last 12-15 years.


bom, apesar disso agora estou tentando usar java! vamos ver o que acontece.

[chipselect]

Marcelo

Vc está utilizando Java RTS?

[xultz]

Marcelo, achei a idéia horrível. Na minha humilde e cretina opinião,é muito melhor gravar o micro a partir do makefile do que através de uma interface gráfica, pior ainda em Java.

Putz, falei mal do java, eu sou mais um na lista das pessoas que o chun odeia agora...

[ivan]

Calculando... 128 - 90 = 38 MB. Hummm.....

Dispositivos realmente pequenos:
Java Card - JCOP da IBM
http://safari.ibmpressbooks.com/0201703297

É claro, ainda existem não satisfeitos:
Java Ring
http://www.javaworld.com/javaworld/jw-0 ... vadev.html

iButton
http://digilander.libero.it/fabrob/java ... ngfaq.html

E finalmente, + um que literalmente "viajou na ma(rs)ionese".
http://www.apropos-logic.com/NASA.html


A JVM, que muitos críticos vêem como problema, na verdade é o pilar de uma plataforma de desenvolvimento, pois Java não é apenas uma linguagem.
A portabilidade de código "Ready 2 RUN" realmente existe, desde que não seja na GUI/UI.
Suponha que exista uma aplicação de acompanhamento de atendimentos de manutenção(helpdesk). Os usuários fazem as solicitações de atendimento via internet. O técnico de manutenção recebe as novas solicitações de atendimento no seu celular durante o dia-a-dia do trabalho e retorna as atualizações para o site.
Excluindo a interface com o usuário, uma vez construido o site, todas as classes necessárias a aplicação web são candidatas a serem utilizadas "as is" no celular, sem recompilação, com códigos já devidamente testados e aprovados, economizando tempo de desenvolvimento e dinheiro/investimento, graças a JVM!
Ah! O acesso aos dados... Bem, criando-se classes genéricas de acesso aos dados o resto é aplicar herança. (QQ linguagem com suporte OO faz!)
Em suma, de uma nova aplicação para um outro dispositivo escreve-se a especialização do acesso aos dados e a UI. Talvez, de 30% a 40% da aplicação para celular. (Isso não "c" consegue com outras plataformas)
Ainda, a aplicação teria que usar como BDs no servidor, pois o cliente queria vendê-la tb:
Oracle, MySql, Postgress além do SQL Server. (Hibernate salva!)

Ja sei! Isto é uma aplicação simples!
Depende... Se para a seleção do técnico que realizará o atendimento os critérios forem:
- a melhor aptidão técnica,
- a melhor rota e
- o escalonamento dos atendimentos para serem executados no menor tempo.
- E caso os atendimentos fiquem muito concentrados em um grupo de técnicos devido a sua especialização, o sistema poderia sugerir treinamentos para a requalificação do grupo remanescente. (Não é o caso de "c" preocupar com desempenho, alguns segundos para um acesso a internet é tolerável. Mas, para os purístas, ainda posso recorrer ao C/C++ se o desempenho ficar crítico JNI-Java Native Interface.)

Aí a coisa começa a ficar interessante...

Com Java alcanço todos os requisitos do projeto e, ainda, estabeleço o menor prazo de entrega do produto. (Obrigado JVM!)

Consigo fazer em C?
Claro! Os prazos de entrega serão maiores ou então aumento a equipe de desenvolvimento e consumo parte dos recur$o$ a receber, o preço cobrado tende a ser maior tb. Para usar C na Web, usaria CGI, onde cada conexão se traduz em um novo processo com todo o overhead oriundo da criação de processos. Teria que escolher um servidor com capacidade maior tb. (Com Java x Web, cada conexão cria uma nova "thread". O overhead de criar "processos x thread" não é coisa pra "leigos", logo no "posso" explicá-las)

Por isso, quem propuser Java para um cenário semelhante terá mais chance de superar os concorrentes em Preço e Prazo.
Não se esqueçam! Na minha solução proposta o C entra na JVM(Hu, hu!) e, somente se necessário, na parte AI.
Ou seja, linguagens? Plataformas de desenvolvimento?
Cada uma no seu quadrado! Pois são apenas ferramentas de trabalho.

OBS: GUI em Java e pior que escrever com MFC!

Ass:
Leigo51.

[msamsoniuk]

Marcelo

Vc está utilizando Java RTS?

precisa ser um java especial para ter acesso a porta serial ? para mim seria melhor se rodasse com o java do browser, afinal toda maquina que tem interface grafica tem um browser com java!

o conceito do programa eh bem trivial: abrir um arquivo S19, parsear byte a byte e ir enviando sequencias de ativacao para gravar pequenos blocos na flash. existe uma temporizacao minima durante o apagamento e gravacao, para nao estressar a flash do microcontrolador e preservar a vida util dela.

como adicional, gostaria que no mesmo programa tivesse um emulador de terminal VT220 e um emulador de terminal grafico TEK4014, para funcionar como terminal e scope para o microcontrolador. mas estao me falando que nao seria possivel fazer em java usando apenas os recursos do browser. o que vc acha ?

[msamsoniuk]

Marcelo, achei a idéia horrível. Na minha humilde e cretina opinião,é muito melhor gravar o micro a partir do makefile do que através de uma interface gráfica, pior ainda em Java.

Putz, falei mal do java, eu sou mais um na lista das pessoas que o chun odeia agora...

eu estou fazendo exatamente isso atualmente, mas soh funciona para computadores unix e eh necessario editar o Makefile para indicar a porta serial a ser utilizada (varia de unix para unix isso).

mas para o desenvolvedor windows fica muito complexo isso! entao eu estava querendo montar tipo uma IDE que integre um editor bom, chame o make para ele e faca a gravacao no microcontrolador, sem ser necessario digitar nenhuma linha de comando. no futuro eu poderia tambem incluir wizards para fazer auto-programacao, assim nao seria necessario digitar absolutamente nada para o cara programar tambem, bastaria ir clicando next no wizard e vc teria um codigo pre-fabricado para o microcontrolador.

eu tambem senti uma certa dificuldade por parte dos usuarios windows em usar o hiperterminal, entao gostaria de incluir um emulador de terminal e um scope integrado tudo no mesmo software.

[polesapart]

Marcelo

Vc está utilizando Java RTS?

precisa ser um java especial para ter acesso a porta serial ? para mim seria melhor se rodasse com o java do browser, afinal toda maquina que tem interface grafica tem um browser com java!

Ocorre o seguinte: no java tem os tais security profiles. No browser teu aplicativo (applet) roda como "intruso miseravel sem acesso a nada", a menos que ele tenha uma assinatura digital e que o usuario concorde pelo menos uma vez em deixar o bicho rodar como "intruso com permissoes totais".

Quando voce roda um aplicativo java fora do browser, o controlador de segurança costuma permitir por padrao acesso ao sistema de arquivos e coisas relacionadas, o que em geral inclui a serial.

Aí vem o truque: uma applet que acesse a porta serial pode ser feita, mas eu particularmente nao conheço uma forma gratuíta ou de baixo custo de obter uma assinatura digital de uma das empresas certificadoras aceitas pelos browsers (ou melhor, pela jvm) como confiaveis.

No netscape 4 tinha como a applet pedir ao usuario que confirmasse um dialogo mais ou menos como "eu aceito que esta applet suspeita acesse os recursos", nao sei se no mozilla isto ainda é assim, mas até a ultima vez que testei no internet exploder ele nao deixava uma applet anonima rodar com privilegios de jeito nenhum.

Questao de procurar por ai.

A api java para acessar a porta serial existe desde os tempos do netscape entao certamente nao vai ser este o problema, hehe.

[xultz]

Cara, se isso é complicado para um DESENVOLVEDOR Windows, fico imaginando o que um desenvolvedor de Mac acharia. Acho que ele nem conseguiria ligar o circuito...

[msamsoniuk]

Calculando... 128 - 90 = 38 MB. Hummm.....

encare os fatos, todo o software embarcado dos rovers eh feito em C.

Dispositivos realmente pequenos:
Java Card - JCOP da IBM
http://safari.ibmpressbooks.com/0201703297

tem que comprar o livro ?

É claro, ainda existem não satisfeitos:
Java Ring
http://www.javaworld.com/javaworld/jw-0 ... vadev.html

iButton
http://digilander.libero.it/fabrob/java ... ngfaq.html

sim sim, me pareceu incrivelmente util no nosso dia a dia, acho que todos deveriamos ter um destes:

http://www.maxim-ic.com/products/ibutton/ibuttons/

francamente...

E finalmente, + um que literalmente "viajou na ma(rs)ionese".
http://www.apropos-logic.com/NASA.html

encare os fatos, o software que roda nos rovers eh feito em C

A JVM, que muitos críticos vêem como problema, na verdade é o pilar de uma plataforma de desenvolvimento, pois Java não é apenas uma linguagem.

sim sim, java parece uma religiao! o dureza eh aguentar essa gente cantando a noite inteira hahaha

A portabilidade de código "Ready 2 RUN" realmente existe, desde que não seja na GUI/UI.
Suponha que exista uma aplicação de acompanhamento de atendimentos de manutenção(helpdesk). Os usuários fazem as solicitações de atendimento via internet. O técnico de manutenção recebe as novas solicitações de atendimento no seu celular durante o dia-a-dia do trabalho e retorna as atualizações para o site.
Excluindo a interface com o usuário, uma vez construido o site, todas as classes necessárias a aplicação web são candidatas a serem utilizadas "as is" no celular, sem recompilação, com códigos já devidamente testados e aprovados, economizando tempo de desenvolvimento e dinheiro/investimento, graças a JVM!

pois eh, eu estava imaginando isso, mas tem uns caras anti-java no forum que me falaram que nao tem como. estou quase desistindo de java pq disseram que a aplicacao nao vai funcionar se nao colocar no CD uma JVM especifica para cada sistema operacional e plataforma

Ah! O acesso aos dados... Bem, criando-se classes genéricas de acesso aos dados o resto é aplicar herança. (QQ linguagem com suporte OO faz!)
Em suma, de uma nova aplicação para um outro dispositivo escreve-se a especialização do acesso aos dados e a UI. Talvez, de 30% a 40% da aplicação para celular. (Isso não "c" consegue com outras plataformas)
Ainda, a aplicação teria que usar como BDs no servidor, pois o cliente queria vendê-la tb:
Oracle, MySql, Postgress além do SQL Server. (Hibernate salva!)

eu nunca tive problemas de acesso aos dados em C. por sinal uma vez alguns desenvolvedores java me pediram um gateway universal para integrar umas databases em mysql, postgres, sql server, ldap e yp. eles conseguiam acessar apenas o postgres, entao eu fiz um gateway universal em C, eles mexiam no postgres e eu replicava de/para os outros sistemas.

Ja sei! Isto é uma aplicação simples!
Depende... Se para a seleção do técnico que realizará o atendimento os critérios forem:
- a melhor aptidão técnica,
- a melhor rota e
- o escalonamento dos atendimentos para serem executados no menor tempo.
- E caso os atendimentos fiquem muito concentrados em um grupo de técnicos devido a sua especialização, o sistema poderia sugerir treinamentos para a requalificação do grupo remanescente. (Não é o caso de "c" preocupar com desempenho, alguns segundos para um acesso a internet é tolerável. Mas, para os purístas, ainda posso recorrer ao C/C++ se o desempenho ficar crítico JNI-Java Native Interface.)

aplicacao de atendimento de manutencao eh trivial, foi uma das primeiras que eu fiz apos aprender C. o codigo nao estava assim tao bem escrito, mas era eficiente e depois de debugado ficou relativamente isento de falhas. dois anos depois do sistema estar rodando, jah apareceram propostas para refazer o sistema em VB e delphi, mas aparentemente nao vingou e o velho sistema em C rodando em DOS entrou na era da internet sem substituto ateh crashear em funcao do bug do milenio, quase 10 anos depois de ser desenvolvido.

eu fiquei realmente abismado.

Aí a coisa começa a ficar interessante...

Com Java alcanço todos os requisitos do projeto e, ainda, estabeleço o menor prazo de entrega do produto. (Obrigado JVM!)

Consigo fazer em C?

Claro! Os prazos de entrega serão maiores ou então aumento a equipe de desenvolvimento e consumo parte dos recur$o$ a receber, o preço cobrado tende a ser maior tb.

isso eh obvio, realmente eh muito mais facil encontrar web designers que entendem algo de java do que de C e eles cobram muito mais barato. pelo preco de um desenvolvedor C eu posso ter 20 desenvolvedores java e terminar o projeto em 1/20 do tempo.

vai ficar uma bosta, mas eu posso comprar 4 servidores quad-xeon com 20GB de ram e fica tudo bem. ah sim, isso nao eh uma citacao aleatoria e hipotetica, aconteceu comigo!

Para usar C na Web, usaria CGI, onde cada conexão se traduz em um novo processo com todo o overhead oriundo da criação de processos. Teria que escolher um servidor com capacidade maior tb. (Com Java x Web, cada conexão cria uma nova "thread". O overhead de criar "processos x thread" não é coisa pra "leigos", logo no "posso" explicá-las)

obviamente vc nao precisa forkar se vc tiver um servidor web multithread integrado a aplicacao. isso eh verdadeiro em java tanto quanto eh verdadeiro em C. o fato do apache usar cgi ou ssi nao quer dizer que eu seja obrigado a utilizar, muito pelo contrario, em C eh tenho liberdade de usar qq artificio ou mecanismo, inclusive os mesmos que se usa em java.

mas existem casos e casos: o apache forka, o ftpd forka, o sshd forka, o sendmail forka, o mysql usa threads, etc. porem, o daemon com maior performance no unix, o squid, usa uma solucao muito mais simples: ele nao forka e nao usa threads, ele simplesmente multiplexa requisicoes com select.

Por isso, quem propuser Java para um cenário semelhante terá mais chance de superar os concorrentes em Preço e Prazo.
Não se esqueçam! Na minha solução proposta o C entra na JVM(Hu, hu!) e, somente se necessário, na parte AI.
Ou seja, linguagens? Plataformas de desenvolvimento?
Cada uma no seu quadrado! Pois são apenas ferramentas de trabalho.

java obviamente custa mais barato pq jah esta semi-pronto e nao requer muita inteligencia. para um cliente padrao com necessidades padrao, vc pode usar uma solucao padrao... realmente eh dificil para C competir, a menos que a solucao padrao jah esteja disponivel em C: squid, mysql, apache, etc. cada vez que surge um aplicativo realmente bom feito em C e se consolida no mercado, eh uma coisa a menos que precisa ser feito em outras linguagens. eh como pensar sobre editor de texto e planilha: hoje ninguem faz um editor de texto e planilha em java, pq jah existem editores e planilhas suficientes escritas em C. portanto, eh tudo uma questao de tempo.

OBS: GUI em Java e pior que escrever com MFC!

isso significa q o unico projeto que visualizei a possibilidade de usar java nao vai funcionar com java ? que diabo ?!

[msamsoniuk]

Marcelo

Vc está utilizando Java RTS?

precisa ser um java especial para ter acesso a porta serial ? para mim seria melhor se rodasse com o java do browser, afinal toda maquina que tem interface grafica tem um browser com java!

Ocorre o seguinte: no java tem os tais security profiles. No browser teu aplicativo (applet) roda como "intruso miseravel sem acesso a nada", a menos que ele tenha uma assinatura digital e que o usuario concorde pelo menos uma vez em deixar o bicho rodar como "intruso com permissoes totais".

Quando voce roda um aplicativo java fora do browser, o controlador de segurança costuma permitir por padrao acesso ao sistema de arquivos e coisas relacionadas, o que em geral inclui a serial.

Aí vem o truque: uma applet que acesse a porta serial pode ser feita, mas eu particularmente nao conheço uma forma gratuíta ou de baixo custo de obter uma assinatura digital de uma das empresas certificadoras aceitas pelos browsers (ou melhor, pela jvm) como confiaveis.

No netscape 4 tinha como a applet pedir ao usuario que confirmasse um dialogo mais ou menos como "eu aceito que esta applet suspeita acesse os recursos", nao sei se no mozilla isto ainda é assim, mas até a ultima vez que testei no internet exploder ele nao deixava uma applet anonima rodar com privilegios de jeito nenhum.

Questao de procurar por ai.

A api java para acessar a porta serial existe desde os tempos do netscape entao certamente nao vai ser este o problema, hehe.

pow, que desanimo

estou chegando a conclusao que nao dah para fazer nada em java! onde vou arranjar uma jvm para cada plataforma que o SDCC suporta ? e eh um software opensource, nao posso ficar pagando por certificados ou exigir que as pessoas q usam paguem, nao tem logica! sera que os caras do java mentiram para mim ?