E porque eu coloquei Java 7 e 8 numa tacada só? Bom, talvez você não tenha acompanhado a novela da estratégia da Oracle para o Java 7. Resumindo, em vez de fazer um Java 7 pela metade “agora” ou um Java 7 completo para sabe-se lá quando, optou-se por fazer um “Java 7″ em duas fazes. Uma primeira que será o 7 e não vai ter muitas das coisas complicadas de implementar, e a segunda será o 8 e aí sim vai ter tudo que era esperado para o 7. Bem melhor do que demorar tudo que já demorou até hoje e ainda fazer “de qualquer jeito”.

Mas o artigo não é sobre Java 7/8 (vou tratar como uma única versão mesmo), e sim sobre a gente precisar ou não desesperadamente da nova versão da linguagem, e não das evoluções na plataforma. O que vou mostrar é que praticamente tudo que esperamos da próxima versão do Java (linguagem) já temos pronto em outras duas das principais linguagens para a JVM: Groovy e Scala.

Para esse artigo não ficar muito longo vou assumir que você está familiarizado com o fato da plataforma Java ser mais do que a linguagem Java. Mas já deixo na gaveta um post sobre a plataforma para deixar isso mais claro depois.

Além disso meu objetivo aqui não é escrever um post que explique em detalhes cada uma das funcionalidades citadas em cada uma das linguagens, e sim mostrar rapidamente cada coisa. Sendo assim reservo-me o direito de citar referências externas em vez de criar código de exemplo próprio

Geral

Para as próximas versões do Java existe o projeto Coin que reúne diversas melhorias para as próximas versões da linguagem. Algumas dessas mudanças estão contempladas nos tópicos abaixo.

Mas o fato é que o objetivo do Java não é ser uma linguagem como Groovy ou Ruby que tem diversas facilidades como elvis operator, safe navigation, reflection super facilitado, invocação do método equals usando == entre dezenas de outras coisas.

Talvez o mais parecido com Java seja Scala. Não em sintaxe, pois nesse quisito Groovy é quase igual Java. Agora o que Scala tem de mais parecido é o fato de ser estaticamente tipada, mas com um sintaxe simplificada, com alto poder inferência de tipos, sem ponto e vírgula obrigatório e que você na maioria das vezes nem percebe que não está usando uma linguagem dita mais “flexível” ou “dinâmica”.

Na minha opinião a maioria não quer especificar tipos, mas isso não quer dizer que necessariamente quer uma linguagem sem tipos. Nos artigos que escrevi de Scala dá pra ver bem dessas facilidades.

Closures

Um dos principais pontos, ou pelo menos o “mais famoso” ponto do Java 7 é o suporte à closures. Suporte que esse que durante a novela Java 7 já foi cortado, reintroduzido “nas coxas” e por fim vai estar completo no Java 8. Mas e se olharmos para Groovy e Scala? O suporte à closures está lá.

Java 8

Referência

#int() fortyTwo = #()(42);
#int(int) doubler = #(int x)(x + x);
#int(int,int) multiplier = #(int x, int y)(x * y);

assert fortyTwo() == 42;
assert doubler(fortyTwo()) == 84;
assert multiplier(3, fortyTwo()) == 126;

Update: o Paulo Silveira, há um bom tempo já, postou um material bem bacana em português sobre isso no blog da Caelum.

Groovy

Referência

def printSum = { a, b -> print a+b }
printSum( 5, 7 )                       //prints "12"

Referência

def c = { arg1, arg2-> println "${arg1} ${arg2}" }
def d = c.curry("foo")
d("bar")

Referência

def x = 2

// define closure and assign it to variable 'c'
def c = { numberToSquare -> numberToSquare * numberToSquare }

// using 'c' as the identifer for the closure, make a call on that closure
def y = c(x)       // shorthand form for applying closure, y will equal 4
def z = c.call(x)  // longhand form, z will equal 4

Scala

Esse código de exemplo eu postei aqui (to meio sem criatividade hoje ). Nele temos um método chamado percorreLista e uma closure chamada imprimeElemento, que é passada como parâmetro para o primeiro.

object Main extends Application {
    def percorreLista[T](lista:List[T], funcao:(T) => Unit)= {
    for (elemento <- lista) {
      funcao(elemento)
    }
  }

  val imprimeElemento = (elemento: Any) => {
    println(elemento)
  }

  percorreLista(List(2,3,4,5), imprimeElemento)
}

Automatic Resource Management (ARM)

Uma coisa chata de fazer em Java é trabalhar com IO. Vamos pegar como exemplo…

Java 6

Referências um e dois

Aqui temos que tratar as possíveis exceções todas na mão.

Lendo um arquivo

try
{
    String teamMember;
    FileReader fr = new FileReader("arquivo.txt");
    BufferedReader br = new BufferedReader(fr);
    while ((teamMember = br.readLine()) != null)
    {
        System.out.println(teamMember);
    }
}
catch (FileNotFoundException e)
{
    e.printStackTrace();
}
catch (IOException e)
{
    e.printStackTrace();
}
finally
{
    if (br!= null)
    {
        br.close();
        if (fr != null)
        {
            fr.close();
        }
    }
}

Agora um código JDBC

String connectionURL = "jdbc:mysql://localhost:3306/myDB";
Connection connection = null;
Statement st = null;
ResultSet rs = null;
try
{
    connection = DriverManager.getConnection(connectionURL, "root", "admin");
    st = connection.createStatement();
    rs = st.executeQuery("Select * from EMPLOYEE_SALARIES");
    while (rs.next())
    {
        System.out.println("EMPLOYEE_NAME/EMPLOYEE_SALARY");
        System.out.println(rs.getString(1) + "/" + rs.getString(2));
    }
}
catch (ClassNotFoundException ex)
{
    ex.printStackTrace();
}
catch (SQLException ex)
{
    ex.printStackTrace();
}
catch (InstantiationException ex)
{
    ex.printStackTrace();
}
catch (IllegalAccessException ex)
{
    ex.printStackTrace();
}
finally
{
    try
    {
        if (!rs.isClosed())
        {
            rs.close();
        }
        if (!st.isClosed())
        {
            st.close();
        }
        if (!connection.isClosed())
        {
            connection.close();
        }
    }
    catch (SQLException ex)
    {
        ex.printStackTrace();
    }
}

Java 8

Com o ARM ficaria bem mais simples.

Lendo um arquivo

String teamMember = null;
try (BufferedReader br = new BufferedReader(new FileReader("arquivo.txt")))
{
    while ((teamMember = br.readLine()) != null)
    {
        System.out.println(teamMember);
    }
}

Código JDBC com ARM

String connectionURL = "jdbc:mysql://localhost:3306/myDB";
try
(
    Connection connection = DriverManager.getConnection(connectionURL, "root", "admin");
    Statement st = connection.createStatement();
    ResultSet rs = st.executeQuery("Select * from EMPLOYEE_SALARIES");
)
{
    while (rs.next())
    {
        System.out.println("EMPLOYEE_NAME/EMPLOYEE_SALARY");
        System.out.println(rs.getString(1) + "/" + rs.getString(2));
    }
}

Groovy

Em Groovy fazer isso é extremamente simples

Lendo um arquivo

Referência

println new File('arquivo.txt').text

Lendo uma tabela com Groovy

Referência

import groovy.sql.Sql
sql = Sql.newInstance("jdbc:jtds:sqlserver://serverName/dbName-CLASS;domain=domainName", "username",
                     "password", "net.sourceforge.jtds.jdbc.Driver")
sql.eachRow("select * from tableName", { println it.id + " -- ${it.firstName} --"} );

Scala

Referências um e dois

Em Scala também é simples.

def using[T <: { def close() }]
    (resource: T)
    (block: T => Unit)
{
  try {
    block(resource)
  } finally {
    if (resource != null) resource.close()
  }
}

using(new BufferedReader(new FileReader("file.txt"))) { r =>
  var count = 0
  while (r.readLine != null) count += 1
  println(count)
}

Referência

val lines = for { file <- managed(new java.io.File("some.txt"))
       stream <- new java.io.FileInputStream(file)
       line <- makeLineIterator(stream) } yield line

Switch com String?

Sinceramente eu acho essa parte até meio brincadeira, pois é muito barulho para uma funcionalidade muito simples. Essa mudança faz parte do projeto Coin.

Java 7

A funcionalidade é simples, a única diferença é que agora suporta String.

Groovy

O suporte do Groovy é bem mais rico que o suporte à Strings. Claro que pode ser mais complicado num primeiro momento, cheio de possibilidades, mas para mim é só um comportamento mais completo, com tudo que se espera.

Referência

def x = 1.23
def result = ""

switch ( x ) {
    case "foo":
        result = "found foo"
        // lets fall through

    case "bar":
        result += "bar"

    case [4, 5, 6, 'inList']:
        result = "list"
        break

    case 12..30:
        result = "range"
        break

    case Integer:
        result = "integer"
        break

    case Number:
        result = "number"
        break

    default:
        result = "default"
}

assert result == "number"

E podemos ainda sobrescrever o método isCase(valor), que por default chama equals(valor)

class Estado{
    String uf
    def isCase(valor){
        uf == valor
    }
}

def estado = new Estado(uf: "MS")

switch ( estado ) {
    case "MS":
        println "Mato Grosso do Sul"
        break

    case "SP":
        println "São Paulo"
        break

    default:
        println "Sei lá..."
}

Scala

Scala assim como Groovy tem um mecanismo bem interessante que pode ser usado num switch, o Pattern Matching. Como isso vale um artigo a parte, recomendo a leitura desse post. Mas para exemplificar vou colocar um exemplo:

def checkPrime(number:Int) = number match {
  case 1 => true
  case 2 => true
  case 3 => true
  case 5 => true
  case 7 => true

  case _ => false
}

Comparando pelo tipo

var obj = performOperation()
var cast:Color = obj match {
  case x:Color => x
  case _ => null
}

Em Java o equivalente seria

Object obj = performOperation();
Color cast = null;
if (obj instanceof Color) {
    cast = (Color) obj;
}

E em Scala temos ainda as case classes, que são tipos especiais de classes, que dentro outras coisas não precisamos de new para instanciá-las e podem ser usadas direto com pattern matching.

Referência

case class Number(value:Int)

def checkPrime(n:Number) = n match {
  case Number(1) => true
  case Number(2) => true
  case Number(3) => true
  case Number(5) => true
  case Number(7) => true
  case Number(_) => false
}

checkPrime(Number(12))

Outro exemplo

class Color(val red:Int, val green:Int, val blue:Int)

case class Red(r:Int) extends Color(r, 0, 0)
case class Green(g:Int) extends Color(0, g, 0)
case class Blue(b:Int) extends Color(0, 0, b)

def printColor(c:Color) = c match {
  case Red(v) => println("Red: " + v)
  case Green(v) => println("Green: " + v)
  case Blue(v) => println("Blue: " + v)

  case col:Color => {
    print("R: " + col.red + ", ")
    print("G: " + col.green + ", ")
    println("B: " + col.blue)
  }

  case null => println("Invalid color")
}

printColor(Red(100))
printColor(Blue(220))

printColor(new Color(100, 200, 50))
printColor(null)

Saída

Red: 100
Blue: 220
R: 100, G: 200, B: 50
Invalid color

Properties

Suporte à properties é bem esperado mas já foi praticamente “limado” da lista de features que vão entrar nas próximas versões de Java. Na verdade o suporte à properties é mais do que vamos ver aqui. Um suporte completo permitiria a gente ter type safe criteria na JPA2 sem necessidade de geração de código. Mas com certeza esse suportezinho simples, à la Groovy, já ajuda bastante.

Java

Sem suporte. Getters and Setters

public class Pessoa{
  private String nome;
  private String endereco;
  private String nome;

  //getters e setterss gerados pela IDE.
  //Vocês já devem estar enjoados de ver, então vou economizar espaço e nem colocar esse código aqui

Groovy

Em Groovy fazer isso é extremamente simples. O compilador gera altomaticamente os getters e setters para atributos não privados. Depois de compilado fica igualzinho um “bean” java, atributos privados e métodos de acesso públicos.

class Pessoa{
  String nome
  String endereco

  //para essa propriedade não teremos getters e setters gerados
  private Integer idade

  //aqui fica igual os getters e setters gerados para nome e endereco.
  //Só lembrando que a tipagem em groovy é opcional
  def Integer getIdade(){ idade }
  def void setIdade(Integer idade){ this.idade = idade }
}

Scala

Em Scala também é simples.

class Pessoa(var nome:String,
             var localidade:String,
             private var _idade:Int) {
  //assim como no exemplo em Groovy, quando marcamos um atributo como privado os métodos de acesso não são gerados
  def idade = _idade
  def idade_=(idade:Int) = _idade = idade
}

val pessoa = new Pessoa("Gilliard", "Campo Grande/MS", 26)
pessoa.nome = "Gilliard Cordeiro"
pessoa.idade = 27
println( pessoa.localidade )

Performance

Tem mais um monte de coisas que eu poderia comentar mas essas são as primeiras que me ocorreram. Mas para finalizar, pelo menos por enquanto, vamos falar de performance.

Não encontrei nenhum benchmark atualizado para linkar aqui, mas no geral Java e Scala estão bem próximos em performance, com mais vantagem para o Java e em alguns casos Scala na frente. Já o Groovy é meio patinho feio nessa comparação entre as três linguagens, mas ainda assim – com base em benchmarks um pouco antigos – ele ainda é mais performático que PHP por exemplo. E eu nunca ouvi ninguém dizer que deixaria de usar PHP por causa de performance, mas quando se fala de Groovy esse assunto sempre surge.

Sobre Java e Scala nem vale muito a pena falar, mas os benchmarks envolvendo Groovy tem que ser encarados com cautela. Primeiro porque se o benchmark for meio antigo é bem possível que de lá pra cá a performance já melhorou bastante. Até porque quanto mais lento, mais espaço para melhorar um ambiente de execução tem. O segundo ponto é que em todos os comparativos sempre vejo código 100% linguagem A contra código 100% linguagem B. Já na prática dificilmente a gente vai ter uma aplicação com código 100% Groovy. Vamos pegar como exemplo uma aplicação feita em Grails. Minha bola de cristal diz que no total de código da aplicação (bibliotecas incluídas) nem 30% é Groovy.

Para complicar ainda mais a conta, você já viu o tamanho da StackTrace quando executamos nosso código num servidor de aplicações? O tanto de AOP, interceptors e outros serviços rodando ao mesmo tempo com certeza vai levar mais tempo do que a diferença entre a execução de duas linguagens diferentes. Por fim a maioria dos problemas de performance não é culpa do que se usa, e sim de como se usa uma ferramenta.

Update: Só mais uma “coisinha” sobre performance do Groovy. Existe também o Groovy++, que compila estaticamente partes do código Groovy (depende do que você anotar com @Typed) aumentando assim a performance consideravelmente pelo que li, mas não conheço na prática. Quando eu já tiver mexido com isso eu posto, mas até lá vocês podem ver alguma coisa aqui, aqui e aqui.

(Minha) Conclusão

Terminado então esse post, acho que ficou claro que, pelo menos para mim, sentimos falta de um ou outro recurso da linguagem mas, ou praticamente não vamos usar a função quando ela sair (pois não faz falta de verdade hoje), ou não conhecemos as outras opções que a plataforma, e não a linguagem Java nos dá. Pois se conhecermos as opções e realmente quisermos usar essas funcionalidades, não faz muito sentido não usar o que se tem.

Implicit Converters

Outra funcionalidade para os implicits são os conversores implicitos. Essa funcionalidade permite adicionarmos características super dinamicas mas sem deixar que fiquemos com a sensação de não sabermos de onde vem as coisas. O que o compilador do Scala faz é olhar se estamos tentando usar um objeto de um determinado tipo como se fosse de um outro tipo, e então procura uma função que converta um objeto do primeiro tipo para o último.

Por exemplo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Vaca {
    def mugir() = "muuuuuuu"
}
//...
class Cachorro {
    def latir() = "au!"
}
 
//...
 
var mimosa = new Vaca
 
def passearComCachorro(toto: Cachorro) = {
    toto.latir()
}
 
passearComCachorro(mimosa) // isso vai dar erro?!
 
//a não ser que eu tenha algo assim
class Vacachorro(vaca: Vaca) extends Cachorro {
    override def latir() = "Antes eu fazia " + vaca.mugir() + ", mas agora eu sei latir!"
}
 
//e esse método converte
implicit def funcaoQueConverteVacaEmCachorro(vaca: Vaca) = new Vacachorro(vaca)

Esse código parece bem esquisito mas funciona. Eu dei um exemplo bem esdrúxulo apenas para mostrar a possibilidade que o Scala dá. Obviamente os conversores geralmente são usados para converter um tipo numérico em outro, ou coisas do genero, mas dei um exemplo pouco convencional propositalmente.
Na linha 17 o compilador do Scala procura por uma função que receba uma Vaca e devolva um Cachorro, porque é o tipo de conversão que ele percebe que precisa acontecer. Entao o compilador faz algo assim:

passearComCachorro(funcaoQueConverteVacaEmCachorro(mimosa))

Agora caso o compilador não encontrasse nenhuma, ou mais de uma função desse tipo, ele daria erro de compilação.
Mas fora converter ao chamar uma função, o Scala permite também fazer isso:

mimosa.latir()

Que em tempo de compilação o Scala vai transformar em

funcaoQueConverteVacaEmCachorro(mimosa).latir()

Novamente gostaria de frisar que esse exemplo é mais didático do que funcional. Na prática poderíamos criar um conversor assim

1
2
3

implicit def conversorQualquer(objeto: Any) = new {
        def latir() = "Um objeto qualquer agora passou a latir"
}

Ou então poderíamos ter esses conversores em alguma outra classe e usar “static imports” para importar esses conversores para nosso código.

Lembrando sempre que se se não houver, ou haver mais de um conversor compatível, o compilador vai dar erro de compilação.

Conversores implicitos dão a mesma facilidade de “open classes” com a vantagem que essa conversão só terá efeito no trecho de código onde a função de conversão está visível. Não acontece de adicionarmos uma função em um objeto num canto do sistema e a mesma estar visível em outro, o que é uma desvantagem em potencial das open classes.

Esses conversores são usados muitas vezes pela pelo próprio Scala. Vejam por exemplo a documentação da classe Int onde é dito que existe um conversor implícito que converte uma instancia de Int para RichInt.

Num próximo post vou comentar sobre mixins classes com Scala.

Functions

Em Scala, uma função é “first-class value”, isso que dizer que assim como qualquer outro valor elas podem ser passadas como parametro para outras funções e serem valores de retorno de funções.

object Main extends Application {
    def percorreLista[T](lista:List[T], funcao:(T) => Unit)= {
    for (elemento <- lista) {
      funcao(elemento)
    }
  }
 
  def imprimeElemento[T](elemento:T) = {
    println(elemento)
  }
 
  percorreLista(List(2,3,4,5), imprimeElemento)
}

Aqui definimos uma função chamada percorreLista que faz o que o nome diz e para cada elemento ela invoca uma outra função passada como parametro, no caso a função imprimeElemento. Reparem na linha 2 a definição dos tipos dos parametros. O primeiro é uma lista do tipo T, nada demais. O segunda parametro é um pouco mais interessante. Definimos uma variável chamada funcao que é do tipo “função void que recebe T como parametro”. Então na linha 12 passamos a função imprimeElemento como parametro para a função percorreLista. A saída desse trecho de código é a seguinte

2
3
4
5

Da mesma forma que passamos uma função como parametro, poderíamos retornar uma também. Mas para não alongar muito isso fica como tarefinha

O caracter _

Uma das coisas que eu mais estranhei nos códigos feitos com Scala, foi a constante aparição de um “_”, geralmente sendo passado como argumentos de funções. Isso causou mais estranheza pois em Java quase não temos esse caracter. Mas vamos a mais um exemplo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

object Main extends Application {
 
    def escreveString(s:String) = {
    println("Escrevendo->"+s)
  }
 
  def somatorio(i:Int*) = {
    "Soma=" + i.reduceLeft((a: Int, b: Int) => b + a) // executa mas nao faz efeito
    "Soma=" + i.reduceLeft((a,b) => a + b) //executa mas nao faz efeito
    "Soma=" + i.reduceLeft(_+_) //executa mas nao faz efeito
    "Soma=" + i.foldLeft(0)(_+_) //executa mas nao faz efeito
    "Soma=" + (0 /: i)(_+_) // executa e retorna
  }
 
  escreveString(somatorio(1,4,6))
}

Saída

Escrevendo->Soma=11

Como sempre eu já apriveitei o mesmo exemplo para mostrar várias coisas. Só vou falar da função domatorio, já que o resto só usa o que nós já vimos antes. A começar pelo parametro, é assim que definimos varargs em Scala. Então temos uma função que recebe uma lista de Int de tamanho variável. Na prática i é do tipo Seq[Int]. update: A partir varsão 2.8 varargs são do tipo scala.collection.mutable.WrappedArray, nesse caso mais especificamente do tipo scala.collection.mutable.WrappedArray$ofInt.

No corpo dessa função eu coloquei de formas diferentes a mesma coisa, porém parti do mais legível para o mais ilegível. As funções reduceLeft e foldLeft trabalham de formas diferentes, mas nesse caso o resultado é o mesmo. Olhando o exemplo da documentação fica fácil entender como elas funcionam.

Como eu já disse antes, o retorno de uma função é sua última instrução. Nesse exemplo da função somatório, apenas a linha 12 retorna, as demais efetuam a mesma operação mas o valor é perdido por ninguem usar. A idéia é mostrar as formas diferentes de fazer a mesma coisa, e assim facilitar o entendimento do uso do caracter “_”.

Da linha 8 até a linha 10 usamos a função reduceLeft, e de cima para baixo eu fui reduzindo a especifidade dos parametros. Na linha 8 eu deixei totamente especificado e inverti o ordem ao somar a e b. Não que isso faça diferença no resultado, mas só para exemplificar que a vantagem de se ter as duas variáveis explicitas é poder saber “quem é quem”. Na linha seguinte eu não informei mais o tipo das variáveis a e b pois o Scala consegue perceber isso pra mim, mas continuo podendo brincar com a ordem os parametros pois ainda sei quem é quem.

A partir da linha 10 eu comecei a usar o caracter “_”. Veja que da linha 9 para a 10, olhando o código nós conseguimos perceber que não é tão útil ter as duas variáveis ali pois simplesmente repassamos elas para a expressao a + b. Olhando dessa forma a sintexe da linha 10 parece fazer mais sentido, pois nessa linha nós dizemos que tanto faz quais são as variáveis, eu só quero somá-las. O problema de usar isso é que a legibilidade do código começa a piorar um pouco.

Agora vamos ver as linhas 11 e 12. Olhando a documentação da função foldLeft vemos que ela recebe mais um parametro que o ponto de partida. Como estamos trabalhando com uma soma, passamos o 0, se fosse uma ultiplicação passaríamos 1, pois queremos que esse parametro não influencie no resultado. Mas apesar de mudarmos de função a sintaxe usada las linhas 10 e 11 são equivalentes. Agora na linha 12 bagunçamos de vez e usamos /:, um alias para a função foldLeft. Novamente o problema do código dessa linha é que fica muito ilegível. Olhando para ela, a sintaxe das linhas 10 e 11 até parece mais simpática

Múltiplas listas de argumento

Em Scala uma função, diferente do que acontece no Java, pode ter diversas listas de argumentos

object Main extends Application {
    def imprimeStrings(s:String)(s2:String) = {
        println(s2 + "-->" + s)
    }
    imprimeStrings("A", "B")

Saída

B-->A

Pode parecer meio estranho, mas essa sintaxe permite que façamos algo interessante com esse último parametro. A seguir continuamos o código de cima.

    def funcaoQueDevolveString(i:Int) = {
        "Número:" + i
    }
    imprimeStrings("A") {
        funcaoQueDevolveString(5)
    }
}

Saída

A-->Número:5

A funcaoQueDevolveString é só para ilustrar que dentro do bloco de código da chamada da função imprimeStrings eu posso fazer qualquer coisa, desde que o retorno desse corpo seja do tipo do parametro que ele substitui.

Implicit parameters

Outra aplicação para mais de uma lista de argumentos é quando queremos ter uma lista de argumentos implicita. Vamos ao exemplo.

object Main2 extends Application {
    implicit var user = "Gilliard"
 
    def executaOperacao(f:()=>Unit)(implicit usuario:String) = {
        println(usuario + " vai executar uma operação")
        f()
        println(usuario + " executou uma operação")
    }
 
    def operacao() = println("Executando operação")
 
    executaOperacao(operacao)
}

Saída

Gilliard vai executar uma operação
Executando operação
Gilliard executou uma operação

Como isso funciona? Definimos uma função executaOperacao que recebe como primeiro parametro uma função. Até aqui nada de novo. Porém definimos uma segunda lista de argumentos com implicit. A palavra reservada implicit deve ser aplicada no início de uma lista de argumentos, e afeta todos os argumentos dessa lista. Além disso essa lista de argumentos deve ser a última. Então caso eu queira ter argumentos “normais” e argumentos implicitos, eu precisaria ter duas listas de argumentos como no exemplo.

Quando o compilador do Scala encontra uma função com parametros implicitos, ele busca por objetos implicitos que sejam compatíveis com esses parametros. Caso encontre, como no nosso exemplo, tudo bem, agora se não houver nenhum objeto implicito compatível teremos um erro de compilação. Mas isso é bem flexível, se eu não tivesse um objeto implícito e quisesse invocar uma função com parametros implícitos é só eu passar explicitamente esses parametros. Um parametro implícito se torna opcional, mas não é proibido colocar um valor explícito. Agora se mais de um valor explícito compatível estiver disponível o compilador não vai tentar adivinhar qual usar, vai dar erro de compilação.

No próximo post vou falar de implicit converters, que na minha opinião é uma das coisas mais bacanas e simples de usar do Scala. Aí sim a gente começa a ver o poder de uma linguagem escalável, com muito dinamismo mas sem deixar que “vire zona”.

Há algum tempo, pesquisando sobre Groovy, encontrei este post que fala sobre Scala. Depois disso me interessei e pesquisei um pouquinho sobre Scala mas não evoluí muito no assunto.Porém depois da apresentação feita pelo Michael Nascimento no JJ08, me animei a brincar com Scala mais um pouco e, agora que já tinha um norte, ficou muito mais fácil conseguir fazer algumas coisas com essa linguagem.

Primeiramente gostaria de dizer que não sou um expert em Scala, só estou compartilhando o que tenho aprendido nos últimos dias. Como já disse, esse post foi basicamente inspirado na apresentação do Mr. M no JJ, e assim que as apresentações estiverem disponíveis vou colocar um link aqui. Outras fontes para esse artigo (e os próximos) é a série Roundup: Scala for Java Refugees, além da própria documentação do Scala.

Scala é um “mix” de linguagem OO e linguagem funcional. Em Scala tudo é objeto, não há primitivos, mas isso a gente ve mais pra frente. O nome Scala vem de “scalable language”. A idéia foi projetar uma linguagem que service bem para trabalhos simples como um pequeno script, até o desenvolvimento de grandes aplicações como fazemos hoje em Java com a “segurança de uma linguagem fortemente tipada”. Hoje em dia se fala muito sobre linguagens dinamicas que rodam na JVM, mas apesar de não parecer (pois olhando o código realmente as vezes não parece), Scala é fortemente tipada assim como Java. A diferença é que pelo fato do Scala usar de forma muito eficiente a inferencia de tipos, acabamos nao tendo aquela sintaxe carregada do Java onde temos que dizer o tipo em todos os lugares e ainda algumas vezes de forma repetida.

Entes de continuar, só para convencionar (mas não quero gerar polemica), chamei de dinamica uma linguagem não tipada.

Para os exemplos, eu usei o plugin do eclipse, mas voces podem ver os plugins disponíveis e usar sua IDE preferida.

Agora um exemplo das diferenças na hora da tipagem

List<String> lista = new ArrayList<String>();

em Java temos que informar duas vezes que estaremos trabalhando com uma List que guarda Strings.

var lista = List("A", "B")
 
//ou para ficar mais parecido com Java...
 
var lista = new ArrayBuffer[String]

Note que nao foi necessário delarar a variável lista como uma coleção de Strings, isso porque o compilador do Scala, assim como nós, ao ler essa linha percebe que a lista referencia uma coleção de Strings. E se eu tentar adicionar qualquer outra coisa que não seja uma String vou ter um erro de compilação. Além disso como Scala não nos obriga a usar ‘;’ (ponto e vírgula) no final das intruções. Então olhando um código sem definições de tipos em muitos casos, e sem ‘;’, às vezes da a impressão que estamos trabalhando com uma “linguagem dinamica” como Groovy por exemplo, já que tem o “estilão” Java de nomearmos as coisas.

Para rodar um código Scala podemos começar de tres formas:

1 – script:

scala> println("Olá mundo!")
Olá mundo!

2 – extendendo a “classe” Application (mais pra frente explico melhor porque coloquei classe entre aspas, mas basicamente é porque Application não é de um tipo Java como class ou interface)

object Main extends Application {
    println("Olá mundo!")
}

3 – ou ainda usando o já conhecido método main

object Main2 {
    def main(args:Array[String]) = {
        println("Olá mundo!")
    }
}

Com esses exemplos ja podemos perceber muitas diferenças em relação ao Java. Talvez a primeira coisa seja o object antes de Main e Main2. Em Java não temos como definir diretamente um object, apenas podemos declarar class e interface. Mas object nada mais é do que uma forma que a própria linguagem nós de definirmos um singleton. Na prática, todos os métodos de um object são acessíveis como métodos estáticos, mas internamente a execução é delegada para um singleton dessa “classe”. Por isso mesmo no exemplo 3 não precisamos definir o método main como estático.

Outra coisa que percebemos é que primeiro declaramos a variável, e depois (se for necessário) informamos o tipo. Isso não tem nada demais mas para quem está acostumado com Java como eu vai querer declarar “String s” algumas vezes antes de acostumar com “s : String”

Outra coisa que pode ter passado batido no exemplo 2 é que o println está no corpo do nosso objeto, sem nenhum método em volta dele. Isso acontece porque Application tem um método main que nesse caso serve apenas para podermos executar nossa Main, mas na verdade quem executa o println da linha 2 do segundo exemplo é o contrutor do nosso objeto. Vamos a outro exemplo para ficar mais claro.

object Main3 {
    println("antes")
    def main(args:Array[String]) = {
        println("durante")
    }
    println("depois")
}

A saída do código acima é

antes
depois
durante

Isso se deve ao fato de em Scala, o contrutor padrão de um objeto ser o corpo da classe (obviamente declaracoes de métodos não entram aqui). É como a inicialização estatica em java, que executa antes do contrutor, a diferença é que aqui o que seria essa inicliazação estatica é o contrutor. Mas vamos entrar mais a fundo nisso depois.

Vamos a mais um exemplo

object Main4 {
    def main(args:Array[String]) = {
        def éPar(i : Int) = {
            i % 2 == 0
        }
        println( éPar(10) )
    }
}

A saída do trecho de código acima é true. Mas nesse exemplo podemos ver muitas outas coisas interessantes. Primeiramente dentro de um método podemos declarar outro método (além de diversas outras coisas, inclusive fazer imports visíveis dó naquele escopo). Em Java também podemos fazer algo parecido, usando uma classe interna anonima. Inclusive é isso que o Scala vai gerar no bytecode, mas isso já é outra história.
Só abrindo um parenteses, eu falo muito em método pois sou um programador Java, falando pra outros programadores Java, mas muita gente pode achar ruim pois talvez o correto seria eu falar function, lembrando que Scala é uma linguagem funcional. Fecha parenteses
Também não precisamos declarar o tipo de retorno do nosso método pois o Scala consegue inferir isso pra gente. Assim como eu posso olhar e perceber que isso vai retornar um Boolean, o compilador do Scala também pode.

Essa delcaracao seria o mesmo de

def éPar(i : Int) : Boolean = { ... }

Assim como na definição da main eu poderia colocar asssim

def main(args:Array[String]) : Unit = { ... }

Em Scala, o correspondente para o void do Java é Unit.

Outra coisa que não precisamos colocar explicitamente é o return, poi o Scala considera como o retorno de um método a sua última linha. No entanto em alguns casos, como no uso de recursão ou quando descobrimos antecipadamente o que deve ser retornado, acabamos precisando explicitar o return, aí nesse caso precisamos deixar explicito também o tipo de retorno do método.

Como a maioria das linguagens de script, Scala permite que chamemos um método de uma forma diferente, sem o ‘.’ e os “(…)” o que possibilita que possamos usar

i % 2 == 0

em vez de usar o equivalente

(i.%(2)).==(0)

Isso mesmo, pode parecer meio estranho mas isso é assim. Em Scala não existem primitivos, e também não existe sobrecarga de operadores (o que seria dos professores de POO com C++ que só sabiam dar isso de matéria se o Scala virasse padrão nessas instituições hein….). O que ocorre é que em Scala “%” e “==” são nomes válidos para métodos. Assim como praticamente qualquer coisa que podemos escrever como <<, >;=, +=, *, etc.

Esse primeiro post foi mais para dar uma idéia de como começar a brincar com Scala, mas nos próximos vou entrar em mais aspectos da linguagem como objetos imutáveis, traits, closures, etc.

Qualquer gafe minha voces postem um comentário que eu corrijo ok? Até o próximo.