| Autor |
Mensagem |
|
|
Mais um capítulo da lendária discussão GPL vs BSD. Os argumentos do pessoal da liberdade absoluta são impraticáveis de são românticos.
Concordo com a Oracle por esse lado mas acho extremamente bizzaro que em 2005, quando a ASF levantou essa bola da licença do TCK para a SUN, a Oracle simpatizou e apoiou.
|
 |
|
|
|
A única coisa que interessa do java7 é o aumento de performance. Quanto a closures, super switch, dinamismo, etc, já tenho no groovy desde 2006.
|
|
|
|
|
Mais alguém interessado?
|
|
|
|
A microsoft está preparando o VS para desenvolvimento para o iphone, desenvolvimento esse que só pode ser feito em c, c++ e objective-c de acordo com a licença do SDK da Apple.
Provavelmente não será c# e muito menos .net.
|
|
|
|
Se a Oracle der um passo em falso pode ter certeza que no dia seguinte as comunidades de Python, Go e Postgres vão aumentar 10000% com pessoas que não tem sindrome de Estocolmo.
Uma Microsoft já é suficiente.
josenaldo wrote:Sair do Java pro C# é largar o cão pra abraçar o capeta.
Genial. 
|
|
|
|
C, Smalltalk, Haskell, Prolog, Erlang.
Depois Java, C#, php, ruby, python.
Nessa ordem.
|
|
|
|
|
Dá um olhada: http://www.grailsbrasil.com/blogs/
|
|
|
|
|
http://repository.jboss.com/maven2/org/hibernate/hibernate-core/3.5.0-Beta-3/
|
|
|
|
pcassiano wrote:
marcosalex wrote:...Enquanto isso, os desenvolvedores estão tendo que fazer praticamente um programa para cada plataforma mobile que querem suportar...
Isso é, IMHO, o grande problema, motivo pelo qual o desenvolvimento mobile é o que é...
Será que o JavaFX vai conseguir "resolver" este problema?
Qualquer solução que peça um plugin externo ao browser vai ser sempre um empecilho. Java tem uma boa prenetração em diversas plataformas moveis, mas nao esta presente nas plataformas que mais crescem como IphoneOS e Android. Isso é um problema para o JavaFX, assim com Silverlight e Flash também.
Por outro lado Apple, Google, Mozilla e Opera(Todas as software-houses competentes  avançam seus browsers muito rápido, ao ponto do Flash, Silverlight e JavaFX perderem muitas das suas vantagens sobre o DHTML.
|
|
|
|
O mais notável na minha opinião que é Spring 3.
A DSL de integração com Apache Ivy no core também é bem interessante.
|
|
|
|
Filipe Chagas wrote:
Só completando, alguém aí já viu uma aplicação web desenvolvida em HTML+CSS+Javascript que proporcione uma experiência ao usuário sequer comparável a esta: http://blip.tv/file/2835432 ??? Agora reflita um pouco e tente imaginar a quantidade de código Javascript você teria que escrever pra fazer algo do tipo...
Atualmente muito. Com HTML5, CSS3, Canvas, WebSocket API, webstorage, WebGL, video e audio tags, etc, muito pouco.
Com a evolução do DHTML o flash vai ter que competir nas ferramentas de produtividade, onde atualmente tem a vantagem. A Enorme desvantagem é que sempre será um plugin externo.
|
|
|
|
Legal vi no twitter do Rod Johnson de manhã.
E algumas horas depois a SpringSource já liberou o Grails 1.2 RC2 com Spring 3.
Suporte a REST e SpEl são as novidades mais interessantes.
|
|
|
|
Wow, muito bom.
Parabéns pelo release.
|
|
|
|
Groovy não é cópia do Ruby. Groovy foi inicialmente inspirado pelo python. Depois teve influencia de muitos outros incluindo Ruby.
Falar que o Grails é uma cópia do Rails é mostrar total desconhecimento do funcionamento interno de rails, grails ou ambos.
Grails copia muito da DSL, da filosofia, o nome , mas a implementação é absurdamente diferente. O objetivo do groovy e do grails é deixar o java produtivo não substitui-lo.
Groovy foi feito com o objetivo de ser confortável, produtivo e compativel para programadores Java. JRuby não. Java é muito mais que a Jvm, são as bibliotecas, frameworks, a linguagem, ferramentas, servidores, etc...
De qualquer maneira, o Play var ser totalmente compativel com java e vai ser muito mais rapido que grails, groovy ou jruby por usar muito java estaticamente. O gargalo de produtividade vai ser o java talvez, mas os caras ja estao integrando scala para resolver esse problema. Parece que tem futuro.
|
|
|
|
javamaniaco wrote:
xymor wrote:O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
Durante o boot nada. Fica monitorando 24 horas e você perceberá que um CRUD besta fica alocando memória que o mesmo com até o JSF + Hibernate e Spring não ocorre. E é apenas um CRUD. Quando você começa a manipular o danado, mexer mesmo, a memória vai comendo, sem dó. Depois os objetos demoram mais para serem desalocados. Mais pesado que Grails até hoje que vi só o JRuby com Rails e o Seam.
O consumo é maior que uma app em java puro, claro, mas não identifiquei tanto esse problema talvez por estar usando o G1GC.
O problema com do consumo excessivo por um CRUD pode ser devido a um bug na validação. Qual a versão testada?
|
|
|
|