O objetivo é escrever código java que detecta a versão da JVM confiando em alterações de compatibilidade, efeitos colaterais, bugs e / ou comportamento indefinido que funcionam de uma maneira em uma versão e outra em outra versão. Além disso, o código deve ser pelo menos um pouco legível, sem sacrificar espaços em branco e nomes de variáveis ​​legíveis.

Para garantir esse objetivo, as regras formais exatas são:

1. O código deve ser escrito em java e deve gerar a versão do JRE na qual está sendo executado.

2. O código não deve usar nenhuma API JDK ou JRE fornecida especificamente para detectar a versão java ou que fornece a versão JDK ou JRE gratuitamente.

3. O código não deve usar reflexão.

4. O código é necessário apenas para funcionar no Hotspot Java SE 5, 6 e 7, mas pode funcionar em outras JVMs.

5. O código não deve usar nenhuma biblioteca de terceiros no caminho de classe.

6. O código não deve iniciar nenhum outro processo, java ou não.

7. O código não deve usar variáveis ​​de ambiente.

8. O código não deve procurar no sistema de arquivos procurando arquivos ou pastas preexistentes.

9. O código deve estar contido em um único arquivo e ser chamado via public static void main(String[] args)ou public static void main(String... args).

10. O código não deve usar nenhuma API não pública presente no JRE.

11. O código não deve gerar nenhum NoClassDefFoundError, NoSuchMethodError, ClassNotFoundException ou NoSuchMethodException durante sua execução.

12. O código deve ser executado em um sistema desconectado da Internet ou de qualquer rede local.

13. Você deve fornecer uma explicação de por que ele se comporta de uma maneira em uma versão e de outra maneira em outra versão.

Pontuação

O método usado para medir a melhor solução é max (n / s), em que n é o número de versões java diferentes detectadas sem violar nenhuma dessas regras (pelo menos as versões 5, 6 e 7) e s é o número de tokens lexicais na solução.

6/102 = 0,0588

Detecta 6 versões. Tem 102 símbolos lexicais (para baixo de 103, depois de ter suprimido publicem public class).

import java.security.Signature;

class GuessVersion {
        public static void main(String[] args) {
                String version = "Java 1.1";
                try {
                        "".getBytes("ISO8859_13");
                        version = "Java 1.3";

                        "".getBytes("ISO8859_15");
                        version = "Java 1.4";

                        Signature.getInstance("SHA256withRSA");
                        version = "Java 5";

                        "".getBytes("KOI8_U");
                        version = "Java 6";

                        Signature.getInstance("SHA256withECDSA");
                        version = "Java 7";
                } catch(Exception e) {}
                System.out.println(version);
        }
}

O Java 1.1 introduziu codificações de caracteres e algoritmos criptográficos no Java. Versões posteriores adicionaram mais codificações e algoritmos. Este programa tenta usar codificações e algoritmos até capturar uma exceção. Espero que uma codificação ausente seja lançada java.io.UnsupportedEncodingExceptione um algoritmo ausente seja lançado java.security.NoSuchAlgorithmException.

Eu tinha um Macintosh PowerPC antigo com quatro versões antigas de Java. Minha máquina OpenBSD tem mais duas versões, então testei estas seis versões:

• Java 1.1.8 no MRJ 2.2.6 para Mac OS 9.2.2
• Java 1.3.1_16 para Mac OS X Panther
• Java 1.4.2_21 para Mac OS X Tiger
• Java 1.5.0_19 para Mac OS X Tiger
• OpenJDK 1.6.0_32 para OpenBSD 5.5
• OpenJDK 1.7.0_21 para OpenBSD 5.5

Este programa também pode ser executado no JamVM 1.5.4 e gcj 4.8.2 para OpenBSD, mas não os identifica como implementações diferentes. Ele imprime apenas "Java 5".

Tempo de execução do Mac OS para Java

Graças a "Escreva uma vez, execute em qualquer lugar!", Posso escrever este programa uma vez, compilá-lo uma vez e executar uma GuessVersion.class nas oito máquinas virtuais. Eu preciso de um compilador para Java 1.1, a versão mais antiga da minha coleção.

Meu compilador é a javacferramenta do MRJ SDK 2.2. Como o Mac OS clássico não tinha linha de comando, javacé uma ferramenta gráfica bastante bonita, onde seleciono arquivos e opções e clico em "Do Javac". Depois de editar meu código, basta clicar em "Do Javac" novamente.

A maneira mais fácil de executar o GuessVersion.class é abri-lo no JBindery, outra ferramenta do MRJ SDK 2.2. O tempo de execução é MRJ 2.2.6, uma implementação do Java 1.1.8.

Não tenho certeza de qual é minha pontuação, porque depende do que você considera um símbolo lexical, mas estou tentando abusar do sistema de contagem o máximo possível com uma longa sequência ...

Também depende se você conta isso como identificando 7 versões diferentes ou 16 ... (Poderia ser estendido trivialmente até 190).

class V extends ClassLoader
{
    public static void main(String[]args)
    {
        for(byte b=60;;)
            try {
                byte[]buf="\u00ca\u00fe\u00ba\u00be\u0000\u0000\u00002\u0000\u0005\u0007\u0000\u0003\u0007\u0000\u0004\u0001\u0000\u0001A\u0001\u0000\u0010java/lang/Object\u0006\u0000\u0000\u0001\u0000\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000".getBytes("ISO-8859-1");
                buf[7]=b--;
                new V().defineClass(buf,0,53);
                System.out.println(b-43);
                break;
            }
            catch(Throwable t){}
    }
}

Ele funciona ao tentar definir uma interface em um carregador de classe personalizado com números de versão principais decrescentes do formato de classe. O primeiro que não lança um java.lang.UnsupportedClassVersionErrorcorresponde à versão da VM.

class Evil {
    public static void main(String... args) {
        String s1 = "Good";
        s1 += "morning";
        int a = 7;
        if (s1 != s1.intern())
            try {
                a--;
                javax.xml.datatype.DatatypeFactory.newInstance().newXMLGregorianCalendar().equals(null);
            } catch (Throwable e) {
                a--;
            }
        System.out.println(a);
    }
}

O algoritmo de internação mudou entre Java 6 e 7. Consulte /programming//a/7224864/540552

XMLGregorianCalendar.equals (null) usado para lançar NullPointerException no java 5, mas isso foi corrigido no java 6. Consulte http://bugs.sun.com/view_bug.do?bug_id=6285370

100 96 92 87 85 tokens aqui. Agradecemos a Peter Taylor por reduzir 7 tokens.