MiddleHeaven e Java 8
O projeto Middleheaven nasceu como uma biblioteca auto-suficiente para criar qualquer tipo de programas em java. A experiencia mais interessante do projeto o design. O design começou quanto estavamos no java 1.4 , e nessa época a API padrão do java era bem pobre em certos aspectos. Ao longo do tempo as APIs JSE e JEE eoluiram muito e hoje muitas as coisas que o middleheaven oferece já estão na api padrão. Exemplos são um codificador de base 64 , api de temos e datas, api de arquivos, entre outras.
Eu sabia que chagaria o tempo em que as apis do middleheaven poderiam ficar obsoletas, mas tendo em consideração a primeira diretiva que é fazer o programa depender exclusivamente do middleheaven de forma a encapsular toda a tecnologia, a api do middleheaven teria que evoluir junto com a api padrão. Por exemplo, agora que o java 8 contém um codificador base 64, a api do middleheaven pode simplesmente delegar as funcionalidades e não ter que implementar esse recurso por si mesma. A api de arquivos se integra com a api de servelets para manipular arquivos obtidos por upload do usuário , a api padrão do java faz isso. A api de datas e tempos pode agora confiar todos os calculos à nova api de datas e tempos mantendo apenas os objetos . O plano funcionou.
Muito da API do middleheaven foi construida com base no conceito de lambda, mesmo quando ele ainda era só um rumor. Agora, graças à funcionalidade do java 8 de entender lambdas como SAM types podemos usar lambdas com a API de enumerable. Um recurso que muito provavelmente será útil é o recurso de virtual extension methods quando formos para a versão 2.
Pois, é isso ai. Embora a versão 1 não seja usada cabe transformá-la para tirar proveito do java 8 e como tal é preciso renomeá-la para versão 2.
Uma das dificuldades do projeto é a parte de UI. Existe alguma integração como algumas ferramentas como Freemarker e Vaadin, mas não ha um modelo coeso para a UI. Isto principalmente se deve ao problema do modelo 2 (action based) vs modelo 3 (event based) . O modelo 2 é completamente suportado , mas o modelo 3 não.
Em alguns pontos ha que se afastar da api do java pelo menos enquanto não existirem extensiom methods verdadeiros como em C#. Um desses exemplos é o conceito de Optional / Maybe. O Maybe do middlheaven pode ser estendido pelo middleheaven enquanto o Optional está nas mãos da Oracle que não o levou muito longe. Sim, ambos partilham problemas – como o fato de que a linguagem não garante que a própria variável to tipo maybe/optional não será nula – mas a api de maybe pretende fazer uso extensivo de lambdas e se integrar com a api de enumerab le para permitir um código mais simples e direto.
Depois de investir tanto tempo no projeto middleheaven é custoso pensar em investir ainda mais para o manter a par com o java 8 quanto na realidade ele não é um framework tão usado quanto outros, contudo depois de muito pensar chego à conclusão que o investimento já foi feito, mais vale tirar partido dele. Tal vez programando o framework em outra linguagem ou usando outra linguagem durante o uso serviria para desacoplar ainda mais o framework e realmente fazer as aplicações não dependerem da linguagem ou plataforma subjacente. Depois de procurar não achei uma linguagem que pudesse permitir isto e minha conclusão se aproxima mais e mais da conclusão que para dar certo deveria existir uma “middleheaven language” em que o framework serve como a API que desacopla a tecnologia. Contudo esta conclusão levaria ainda a mais trabalho que não é compensado pelo numero de usuários do framework. Portanto continuarei nos passos de manter o middleheaven desacoplado da teclogia subjacente, mas ainda sendo programado e usado via linguagem java e correndo na plataforma java. Contudo cada vez mais tentando se afastar de algumas falhas que existem na api padrão e que outras linguagens/apis fizeram melhor.
