Java SE 7 e o futuro da linguagem Java
Michael Nascimento Santos
Aviso
As informações nesta palestra correspondem a declarações de previsão baseadas em expectativas
atuais de eventos futuros que envolvem riscos e incertezas incluindo, sem limitação, riscos
associados a incertezas inerentes à adequação do momento e sucesso de pesquisas ...
Agenda
> Como o Java SE é definido
> Funcionalidades consideradas para inclusão
> Mudanças propostas na linguagem > O futuro da linguagem Java
Agenda
> Como o Java SE é definido
> Funcionalidades consideradas para inclusão
> Mudanças propostas na linguagem > O futuro da linguagem Java
Definição do Java SE
(Antigamente)
> Uma “umbrella” JSR é submetida ao JCP
> A JSR já menciona algumas funcionalidades propostas
> Escolhe-se o Expert Group
> O EG discute o que deve ou não ser incluído e
isso resulta na especificação
> JSRs para APIs/mudanças da linguagem
> Pequenos bugs/alterações listadas
> A Sun faz a implementação de referência, aka JDK
> A especificação passa por todo processo burocrático de votação e temos uma nova
Definição do Java SE hoje
> Java + YOU (por bem ou por mal)
> Apesar da burocracia, há grande influência da comunidade
> JSRs lideradas por indivíduos
> JSR-310 (Date & Time)
> Contribuições ao OpenJDK
> Closures prototype
> Kijaro, um projeto aberto > Blogs
> No entanto, ainda há dois grandes “guardiões”:
> Java SE: Danny Coward
Agenda
> Como o Java SE é definido
> Funcionalidades consideradas para inclusão
> Mudanças propostas na linguagem > O futuro da linguagem Java
Próximas releases: Java SE
> Java SE 6u10 (em breve)
> Java Kernel
> Applets e aplicações tratadas de forma unificada via JNLP com novo plugin
> Java Quick Starter
> Diversas melhorias para suportar o JavaFX
> Java SE 7 (2009?) - APIs
> Desktop (Swing Application Framework, Beans Binding, Validation)
> NIO 2 (JSR 203)
> JPA 2.0
> Date & Time
Swing Application
Framework (JSR-296)
> Suporte à aplicação como conceito e seu ciclo de
vida
> Application (launch, initialize, startup, ready, exit,
shutdown)
> Configuração externa de recursos (textos, cores,
ícones)
> Sendo reconsiderado no momento
> Ações (@Action)
> Tasks, com suporte à execução assíncrona,
indicação de progresso, interrupção e bloqueio da GUI
Swing Application
Framework (JSR-296)
public class M yApp extends SingleFram eApplication { @ O verride protected void startup() {
JLabel label = new JLabel("H ello W orld");
show (label);
}
public static void m ain(String[] args) {
Application.launch(M yApp.class, args);
} }
Swing Application
Framework (JSR-296)
ApplicationC ontext c = Application.getInstance().getC ontext(); ResourceM ap r = c.getR esourceM ap(M yForm .class);
r.getString("aForm at", "W orld") => " Hel l o Wor l d" r.getC olor("colorRBG A") => new Col or ( 5, 6, 7, 8)
r.getFont("aFont") => new Font ( " Ar i al " , Font . PLAI N, 12)
resources/M yForm .properties
aString = Just a string aForm at = H ello % s anInteger = 123 aBoolean = True anIcon = m yIcon.png aFont = Arial-PLAIN -12 colorRG BA = 5, 6, 7, 8
Swing Application
Framework (JSR-296)
public class M yApp extends SingleFram eApplication {
@ Action public void sayH ello() { JLabel label = new JLabel(); label.setN am e("label");
show (JO ptionPane.createD ialog(label)); }
@ O verride protected void startup() {
show (new JButton(getAction("sayH ello"))); }
public static void m ain(String[] args) {
Application.launch(M yApp.class, args); }
}
# resources/M yApp.properties
sayH ello.Action.text = Say& H ello
sayH ello.Action.shortD escription = say hello label.text = H ello W orld
Beans Binding (JSR 295)
> Cria o conceito de Property
> Infelizmente, não algo que faça parte da linguagem
> Interface com algumas implementações convenientes (BeanProperty, ELProperty etc)
> Permite expor “propriedades sintéticas”, como
JTextComponent.text
> Provê APIs para conversão e validação > Binding: liga duas propriedades
> Possui extensões para facilitar o suporte Swing:
> Lists/Maps “observáveis”
> JListBinding, JTableBinding
Beans Binding (JSR 295)
Property fnameP = BeanProperty.create(“firstName”); Property textP = BeanProperty.create(“text”);
Bindings.createAutoBinding(READ_WRITE,
person, fnameP,
textField, textP).bind(); Property oldP = ELProperty.create(“${age > 50}}”); Bindings.createAutoBinding(READ,
person, oldP,
Beans Binding (JSR 295)
Property fnP = BeanProperty.create(“firstName”); Property lnP = BeanProperty.create(“lastName”); JTableBinding tb = SwingBindings.createJTableBinding(READ, list, jtable); tb.addColumnBinding(fnP) .setColumnName(“First Name”) .setColumnClass(String.class); tb.addColumnBinding(lnP) .setColumnName(“Last Name”); .setColumnClass(String.class); tb.bind();Bean Validation (JSR-303)
> Permite restringir o valor das propriedades no
domínio através de anotações especiais (constraints)
> Define constraints básicas (@NotNull, @Length,
@Email)
> Permite criar suas próprias anotações de constraints
(@ConstraintValidator) e como validá-las (ConstraintValidator<A extends Annotation>)
> Permite validações de todo o bean, propriedades individuais ou grupos
> Geração de mensagens customizadas
Bean Validation (JSR-303)
public class Address {@NotNull
@Length(max=30, message="longer than {max} characters")
private String street1; ...
@NotNull @Valid
private Country country; }
public class Country {
@NotNull @Length(max=30)
private String name; ...
Bean Validation (JSR-303)
@ConstraintValidator(LengthConstraint.class)
public @interface Length {
String message() default "{beanckeck.length}"; String[] groups() default {};
int min() default 0;
int max() default Integer.MAX_VALUE;
}
public class LengthConstraint implements
Constraint<Length> {
public void initialize(Length annotation) { }
public boolean isValid(Object value) {
} }
NIO 2 (JSR-203)
> Nova API de suporte a filesystems
> FileSystem
> FileRef
> Path
> FileStore
> Suporte a symbolic links
> FileAttributeView > WatchService
> SeekableByteChannel > Nova API de Sockets > Asynchronous I/O
JPA 2.0 (JSR-317)
> Mapeamento mais flexível
> Collections de tipos básicos (wrappers, BigDecimal etc)
> Collections de tipos embeddables (Endereco, CPF etc)
> Listas ordenadas
> Melhor suporte a Maps
> Deleção de órfãos
> API para locks pessimistas
> Cache API
> Criteria API
Date & Time API (JSR-310)
Date date = new Date(2007, 12, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
Date date = new Date(2007, 12, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900;
Date date = new Date(year, 12, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900;
Date date = new Date(year, 12, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900;
int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/HongKong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(zone);
cal.setTime(date);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(zone); cal.setTime(date);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date calDate = cal.getTime();
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(zone); cal.setTime(date);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
Date calDate = cal.getTime();
Date & Time API (JSR-310)
int year = 2007 - 1900; int month = 12 - 1;
Date date = new Date(year, month, 13, 16, 40);
TimeZone zone = TimeZone.getInstance("Asia/Hong_Kong");
Calendar cal = new GregorianCalendar(zone); cal.setTime(date);
DateFormat fm = new SimpleDateFormat("HH:mm Z");
fm.setTimeZone(zone);
Date calDate = cal.getTime();
Date & Time API (JSR-310)
LocalDateTime dT = dateTime(2007, 12, 13, 16, 40); TimeZone zone = timeZone("Asia/Hong_Kong");
ZonedDateTime date = dateTime(dt, zone);
DateTimeFormatter fm = hourMinuteZoneFormatter(); String str = fm.print(date);
Date & Time API (JSR-310)
ZonedDateTime date = builder().year(2007).december(). dayOfMonth(13).hour(16).minute(40). timeZone("Asia/Hong_Kong").build();
DateTimeFormatter fm = hourMinuteZoneFormatter(); String str = fm.print(date);
Problemas da API atual
> Mutável
> Janeiro é 0, Dezembro é 11, mas os dias vão de 1 a 31...
> Date não é uma data
> Date usa anos a partir de 1900
> Calendar não pode ser formatado > DateFormat não é thread-safe
> DateFormat possui um TimeZone implícito
> java.sql.{Date, Time, Timestamp} estendem Date
Date & Time API (JSR-310)
> Modelo abrangente de data e hora > Type-safe
> Interoperável com Date e Calendar
> Vão poder ser convertidas para as novas interfaces
> Compatível com os padrões XML e SQL
> Princípios de design:
> Imutável
> Fluente
> Principle of Least Astonishment
Date & Time API (JSR-310)
> Científica (Instant, Duration, Interval) > Humana
> Tipos básicos
> LocalDate, LocalTime, LocalDateTime
> OffsetDate, OffsetTime, OffsetDateTime
> ZonedDateTime
> Campos
> Year, MonthOfYear, DayOfMonth, DayOfWeek etc.
> Regras extensíveis
> DateMatcher, TimeMatcher
> DateAdjuster, TimeAdjuster
Date & Time API (JSR-310)
> Solução para o problema do horário de verão! > Novo conceito de TimeZone
> Nome
> Offset base (ZoneOffset)
> Versão das regras de transição do offset
> (Se tudo der certo) permitirá atualização das
regras da JVM on-the-fly
> Sem quebrar objetos existentes
Date & Time API (JSR-310)
> Periods
> Years, Months etc.
> Composições dos valores
> Nova API de formatting & parsing
> Com builders
> Interoperável com API existente
> Suporte a outros sistemas de calendário
> Suporte aos existentes no JDK > Permitindo extensibilidade
> Nova classe para obter a hora atual: Clock
> Fácil de testar
Agenda
> Como o Java SE é definido
> Funcionalidades consideradas para inclusão
> Mudanças propostas na linguagem > O futuro da linguagem Java
A linguagem Java
> Como evoluir uma linguagem estabelecida? > Assume-se que adicionar features é algo bom
> Talvez seja para aplicações
> Linguagens precisam ser consistentes
> Se existe boxing/unboxing, por que não List<int>?
> Java tem como princípio ser backwards-compatible
> Ao mesmo tempo que permite que seu código
funcione, não permite que a evolução ocorra da forma mais elegante possível
Princípios de evolução
> Respeitar o passado
> Novas keywords quebram o código (assert, enum)
> Features removidas quebram o código
> “Consertar” pode quebrar código também
> Respeitar o futuro
> Features que complementam features podem ser postergadas
> Levar em conta outras potenciais adições ao definir a sintaxe
> Respeitar o modelo atual
> Manter o foco da linguagem
Princípios do modelo atual
> Linguagem de alto nível > Clareza
> Tipagem estática
Features e viabilidade
> Propriedades
> Reified generics
> Closures & extension methods
> Suporte XML > Módulos
> Melhorias nas anotações
Propriedades
> Diversos modelos propostos
> Alterando a linguagem
> Nova API
> Combinação de ambas
> Polêmica
> Poucas soluções concretas desenvolvidas
> Código teria que ser reescrito para tirar proveito
Reified generics
> Desejada por grande parte das pessoas > Poucas soluções propostas
> Nenhum protótipo concreto, nem especificação
> Requer muito esforço de implementação > Chances: baixíssimas
Closures
> Diversos modelos propostos
> BGGA
> FCM
> CICE
> NIPAD
> Muito polêmica na comunidade
> Para que código comum tirasse proveito, exigiria reescrita ou adoção de features como extension methods
Closures
> Diversos modelos propostos
> BGGA
> FCM
> CICE
> NIPAD (Não Implementem Pelo Amor de Deus!!!)
> Muito polêmica na comunidade
> Para que código comum tirasse proveito, exigiria reescrita ou adoção de features como extension methods
Suporte XML
> Extremamente polêmica! > Sem protótipo disponível
> Sem especificação
Módulos
> Duas JSRs inicialmente
> 277: API e modelo de execução
> 294: Mudanças na linguagem
> Unificada recentemente na JSR-277
> Introduz conceito de restricted keyword: module
> Declaração de classes e pacotes integrante do módulo > Declaração de dependências de outros módulos
> Novo formato de deployment (JAM)
> Potencial interoperabilidade com outros sistemas
de módulos (OSGi)
Módulos
// org/netbeans /core/Debugger.java module org.netbeans .core;
package org.netbeans .core; public clas s Debugger {
... new ErrorTracker() ... }
// org/netbeans /core/utils /ErrorTracker.java module org.netbeans .core;
package org.netbeans .core.utils ; module clas s ErrorTracker {
module int getErrorLine() { ... } }
// org/netbeans /core/module-info.java @ Vers ion("7.0")
@ ImportModule(name="java.s e.core", vers ion="1.7+") module org.netbeans .core;
Melhorias nas anotações
> Possui JSR
> Mais lugares para usar:
> List<@NonNull String>
> class UnmodifiableList<T> implements @ReadOnly
List<@ReadOnly T>
> @NonEmpty List<T> = // ...;
> Introduz a noção de tipo específico de processador de anotação: type checker
> Não tão polêmica (talvez por não estar tão difundida)
Pequenas features
> Multi-catches:
> } catch (AnException, AnotherException e) { tratar(e) }
> Safe-rethrow
> Permite fazer catch de super-tipo, mas lançar apenas
subtipos esperados
> Switch para Strings > Chances: muito altas
Agenda
> Como o Java SE é definido
> Funcionalidades consideradas para inclusão
> Mudanças propostas na linguagem > O futuro da linguagem Java
O futuro da linguagem
> Nunca vamos ter closures, reified generics ou... ? > A opinião está dividida:
> Alguns querem que a linguagem fique como está e a evolução ocorra em novas linguagens para a JVM
> Alguns temem o que as pessoas farão com features como generics
> Alguns querem que Java continue sendo uma linguagem viva e em constante evolução
Depende de nós
> A comunidade precisa decidir
> A decisão final a respeito da linguagem ainda não foi tomada
> E o melhor provavelmente deve ser um pouco da opinião de cada parcela da comunidade
> Colabore manifestando a sua opinião
> Blogs
> OpenJDK
> JUGs
Conclusão
> Diversas APIs estão cogitadas para inclusão > Nem tantas mudanças de linguagem assim
> Java vai manter suas características
> Há certas coisas que nós nunca vamos ver em
Java - operator overloading... :-)
> O quão longe a linguagem vai evoluir e até
quando vão haver novas versões depende da comunidade
