| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | A acrescentar que, durante esta conferência, precisamente entre os dias 11 e 13 de Junho falou-se da implementação de tecnologias Java, algo que tem vindo a ser feito ultimamente, como as tecnologias Bluetooth. Ou seja, o planeamento desta tecnologia supõe controlarmos, por exemplo, toda a casa recorrendo apenas a um relógio (que actualmente existe, recorrendo a outras tecnologias)! Um excerto..
This topic will cover a variety of advanced networking technology topics, including JiniTM, "Project JXTA", JAINTM, and OSS/J. APIs such as the JAIN specification and OSS/J support the use of JavaTM technology within emerging feature rich communications networks and allow applications to take advantage of location, voice, presence, messaging, payment, billing and many more services. The applications may run in a wide variety of device and server environments. Technologies such as Jini and "Project JTXA" allow developers to build adaptive systems that improve current business processes and open new market opportunities today. Here you will discover how to create distributed systems that can automatically adjust to accommodate changes to the set of components that compose them.
E já agora, espantem-se, já existe uma máquina de lavar com Bluetooth! :-) Quando encontrar o link coloco aqui!
|
| |
| | Uma notícia interessante do Wireless dos telemóveis, Bluetooth, e controlo do carro por telemóvel, tudo apresentado na JavaOne de 2003:
na ZDNet
|
| |
| |
| | controlo do carro por telemóvel Tipo: "Kit, sem me ouve, me vem buscar!" ???
Jazzy |
| |
| | Lembro-me de ler algures que o uso de Java não era aconselhado para sistemas críticos.
Em caso de apuros não é "aconselhável" equipar o Kitt com Java :D ou então ele pode responder:
"... java.lang.NullPointerException ".
Nada do que foi escrito deve ser levado em consideração... |
| |
| | Uma das razões é que sistemas críticos exigem um tempo máximo de resposta. Ora, como a linguagem é interpretada por uma máquina virtual não há garantias de tempos de execução. E com GC, não há garantias de ele ser activado durante uma parte crítica.
hugs
Strange |
| |
| | | Factos: Java != interpretada e interpretada != previsivel. É também um facto que julgar que previsivel == rápido é o erro numero 1 dos principiantes em RT... Mais factos: GC != imprevisivel. Podes começar por aqui. E o que é que te garante que o malloc()/free() em C compilado te respondem adequadamente? (Relembra aqui: rápido != previsivel). Pensa em fragmentação e travessia de listas arbitrariamente longas. E mesmo que o malloc responda em tempo util, convém que responda != NULL. Se calhar até dava jeito ter um GC para garantir que não há leaks a encher a memória toda e a compactar o espaço livre em blocos suficientemente grandes para serem usados... *suspiro*
|
| |
| | | actos: Java != interpretada e interpretada != previsivel. Factos: Java == Interpretada. javac -> compilacao p/ uma maquina virtual. maquina virtual -> interpretacao do codigo gerado. *algumas* maquinas virtuais -> JIT. É também um facto que julgar que previsivel == rápido é o erro numero 1 dos principiantes em RT... E onde raios me refiro a rapidez?? Mais factos: GC != imprevisivel. Podes começar por aqui. Well, duh! O que raios tem esse GC a ver com o de Java? Eu falo das limitações de Java, não de GCs em geral. Afinal, um método mais simples seria apenas desligá-lo. E o que é que te garante que o malloc()/free() em C compilado te respondem adequadamente? Talvez o simples facto de não os usar?? Se calhar até dava jeito ter um GC para garantir que não há leaks a encher a memória toda e a compactar o espaço livre em blocos suficientemente grandes para serem usados... Mas GCs também não podem resolver o problema de fragmentação de memória (Se a linguagem usa endereços de memória). *suspiro* Bem, também eu! Uma pessoa responde porque Java não é ideal para sistemas embebidos e obtém como resposta que existem GCs orientados para sistemas embegidos e mallocs/free não-orientados para sistemas embebidos...
hugs
Strange |
| |
| | Bom... aquela boca era suposto ter piada e não dar origem a este tipo de discussões... :\
Nada do que foi escrito deve ser levado em consideração... |
| |
| | | E teve piada. A boca seguinte é que precisava de um :-). :-)
|
| |
| | Acho todas estas medidas tardias. Lembra-me também dos planos deles para fazer pequenas alterações de cosmética no compilador para a versão 1.5
Entre outras coisas fascinantes vão inventar o foreach() e o boxing/unboxing automático de tipos base (embora ainda não saibam como fazer unbox do null mas estão a trabalhar nisso :))
Enfim, espero que sejam rápidamente (e sem dor) chacinados pelo superior .NET
|
| |
| |
| | | Exacto, e também convém lembrar que as gaijas curtem mais o ppl que usa .NET Enfim, espero que sejam rápidamente (e sem dor) chacinados pelo superior .NET Onde é que eu já ouvi isto?... Sei que foi há muito tempo... Mas onde? Cirruz
|
| |
| | O rapaz tem razão. A API de base do .Net é muito, mas mesmo muito, completa especialmente no que toca a Web Services... e a interfaces para dados...
Se me permitem, como disse um colega meu há uns tempos, "é uma tecnologia para século XXI" e não um legado sobre o qual vão acrescentando retalhos.
Nada do que foi escrito deve ser levado em consideração... |
| |
| | Pede às tuas amigas para fazerem deploy de um webservice em java e outro em .net
Depois diz-me quem é mais sexy
|
| |
| | | Se uma das amigas só tivesse servidores a correr HP-UX, era capaz de ficar chateada com a cena da Microsoft... Cirruz
|
| |
