Versão 20

Novidades

Suporte a outros runtime Java além do Oracle Java SE

A partir de Janeiro de 2019, a Oracle passará a exigir uma licença comercial para que as empresas possam obter suporte e atualizações do Oracle Java SE 8. Mais detalhes da nova política podem ser obtidos no documento Oracle Java SE Releases FAQ.

Além das opções de subscrição da licença comercial ou da atualização para o Oracle Java SE 11, também há a possibilidade de utilizar outros runtimes Java que implementem a especificação do Java SE 8, como:

Para dar suporte aos novos runtime Java, foi alterado o mecanismo de detecção do diretório de instalação do Java, que antes considerava apenas o registro do Windows. Agora passam a ser consideradas as seguintes configurações, por ordem de prioridade:

  1. Parâmetro JavaHome informado na linha de comando. Ex: engine64.exe --JavaHome="C:\JavaPath"
  2. Variável de ambiente NGIN_JAVA_HOME
  3. Registro HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
  4. Variável de ambiente JAVA_HOME

Apesar da maioria dos runtimes Java serem originados a partir do mesmo projeto, o OpenJDK, é recomendado que os códigos Java sejam validados para o novo runtime, caso deixe de ser utilizado o Oracle Java SE 8.

Melhorias

Engine

  • A IDE passa a preservar o histórico das expressões avaliadas e os breakpoints no depurador JavaScript após o reinício do Engine.
  • O Engine passa a realizar uma verificação adicional antes de reutilizar conexões inativas com o servidor. Essa verificação minimiza os erros de desconexão introduzidos por softwares intermediários na comunicação com o servidor, como balanceadores de carga.
  • O método ArrayBuffer.slice e uma implementação parcial do objeto Uint8Array passam a estar disponíveis no runtime JavaScript padrão do Engine. Foram implementadas as propriedades buffer, length, byteLength, byteOffset e os métodos slice, fill, includes, indexOf e subarray da classe Uint8. Essas APIs fazem parte da especificação ECMAScript 2015 e foram disponibilizadas com o objetivo de tornar a manipulação de conteúdos binários no Engine mais aderente ao padrão adotado na linguagem JavaScript.

REST Framework

  • A documentação do REST Framework para desenvolvedores foi revista e disponibilizada em https://nginstack.com/pt/docs/rest-framework/overview. Lembramos que o REST Framework ainda é uma funcionalidade experimental e que possui restrições de uso indicadas na documentação.

Defeitos corrigidos

Desenvolvimento

  • O tipo de dados usado na definição dos campos de agregação na tabela de soma não suportavam o armazenamento de valores fracionários no Microsoft SQL Server.
  • A rotina de atualização das tabelas de soma sempre falhava no Microsoft SQL Server.
  • Falhas na execução dos arquivos de x-class que definem uma tabelam, durante uma atualização do sistema, poderiam provocar a remoção do registro de definição dessa tabela, impedindo que o Engine a carregasse no cache local após o seu reinício.
  • A Atualização do Sistema poderia criar um registro duplicado de chave positiva na classe Tabelas do Sistema para as tabelas definidas por produtos do sistema. Foi criada uma rotina de pós-upgrade que eliminará automaticamente as inconsistências introduzidas por esse defeito no passado.

Web Framework

  • O navegador do usuário do Web Framework poderia entrar em um laço de processamento intenso, consumindo 100% da CPU, caso a conexão com o servidor Engine fosse interrompida.
  • Ao instalar as dependências de desenvolvimento do Web Framework ocorria um aviso de segurança crítico emitido pelo npm. O risco apontado não se aplicava ao uso do sistema em produção e tinha relação apenas com o ambiente de desenvolvimento da plataforma, mais especificamente no uso do WebPack. As dependências afetadas foram atualizadas para versões sem a falha observada.
  • Ao efetivar as alterações de um registro de uma grade mestre poderia ocorrer a efetivação de um registro de uma grade detalhe sem a validação dos campos requeridos. Esse problema ocorria quando o registro da grade deixava de ser visível logo após a efetivação, como nos casos em que o DataSet estava filtrado e o registro alterado passava a não satisfazer mais o filtro configurado.
  • Processos que executam programaticamente o evento onMasterScroll de grades detalhes poderiam provocar a gravação de registros sem a validação dos campos requeridos, caso esse evento fosse chamado enquanto o registro estivesse em edição. A regra padrão do sistema para esse evento passa a ser proteger contra esse mau uso, tentando efetivar a gravação do registro com todas as validações configuradas ou cancelando a edição caso o registro não satisfaça as regras. Em ambos os casos será gerado o alerta “A edição da grade detalhe Grade_X foi [confirmada/cancelada] de forma forçada, pois a grade Grade_Y foi reposicionada”, deixando claro para o usuário o que ocorreu com o registro que estava em edição. Processos que gerem esse alerta devem ter as suas lógicas de manipulação de grades detalhes revistas, preferencialmente para utilizar o método Grid.scroll em vez de executar diretamente os eventos da grade.
  • Ao retirar o foco de um campo do tipo time poderia ocorrer a perda da precisão de segundos do valor, mesmo quando ele não era alterado pelo usuário.

Engine

  • Ao ser persistido, pelo Engine 32 bits, um DataSet com campos do tipo number, tendo o conteúdo de dois registros consecutivos valores muito próximos, mas não idênticos, ocorria eventualmente de o campo do segundo registro ficar nulo, quando esse DataSet era restaurado no Engine 64 bits.

Outras alterações

Desenvolvimento

  • A API de manutenção do esquema da base de dados utilizada pelos processos Atualização Sistema e Atualizar Esquema passa a gerar erro caso o usuário tente excluir uma tabela que contenha registros. Essa é uma medida de segurança que visa evitar a perda de dados que poderia ser provocada por uma falha temporária nas definições das tabelas do sistema e leva em consideração que a remoção de uma tabela da base de dados é incomum. Caso seja necessário remover uma tabela em uso, deverá ser criada uma rotina de pós-upgrade que remova o conteúdo da tabela, levando em consideração os impactos dessa ação.