NetBeans 7.0 Beta

mit vielen Neuerungen, einige rund um die Sprachmöglichkeiten von Java 7. Von http://netbeans.org/community/releases/70/:

JDK 7

  • Project Coin support
  • Editor enhancements: Code completion, hints

WebLogic Server

  • Streamlined and faster deployment to WebLogic
  • New server runtime node displaying deployed applications and resources
  • JSF integration with server libraries

Oracle Database

  • Simplified connection wizard
  • Guided installation to JDBC driver
  • Editing and deployment of stored procedures

JDK 7 switch
WebLogic
Oracle DB

GlassFish

  • GlassFish 3.1 support
  • Domain restart and log viewer for remote GlassFish
  • Enable and disable deployed applications

Java

  • Maven 3 support
  • JUnit 4.8.2 integration and various JUnit improvements
  • Remote HTTP URLs supported for Javadoc in libraries and Java platforms
  • New improved visual customizer for GridBagLayout

Java EE

  • Improved support for CDI, REST services and Java Persistence
  • New support for Bean Validation
  • Support for JSF component libraries, including bundled PrimeFaces library
  • Improved editing for Expression Language in JSF, including code completion, refactoring and hints

GlassFish remote view
GridBag designer
JavaEE code completion

Web Languages

  • HTML5 editing support
  • JSON formatter

PHP

  • Generate PhpDoc
  • Rename refactoring, Safe Delete Refactoring
  • PHP 5.3 – Support for aliases

C/C++

  • Easy import of project from user’s existing binary
  • New Project type where user’s source files are located on remote system

NetBeans Platform

General

  • Word wrap in Editor
  • Enhanced Profiler integration
  • Less intrusive checking for external changes when switching between the IDE and other programs.

HTML5 code completion
php
C/C++
Platform annotation action

28. Juli 2011

Das ist das Datum, an das wir Java 7 erwarten dürfen. Naja, unter Sun klappte das mit den Zusagen nicht so ganz, aber Oracle ist da ganz anders durchorganisiert.

Der Zeitplan im Einzelnen:

  • 2010/12/16
    Feature Complete
  • 2011/04/12
    Rampdown start: P1-P3 bugs only
  • 2011/04/28
    API/interface changes: Showstoppers only
  • 2011/05/11
    All targeted bugs addressed
    First release candidate built
  • 2011/05/18
    Bug fixes: Showstoppers only
  • 2011/06/08
    Final test cycle starts
  • 2011/07/28
    General Availability

Ein halbes Jahr also für Bugs fixen usw. Das sollte mal jmd. bei Kundenprojekten tun …

JSRs für Java 7 und Java 8 wurden dem JCP übergeben

Im Moment sind folgende Neuerungen im JSR 336 für Java 7 beschrieben:

The following JSRs will be proposed for inclusion as components of the Java SE 7 Umbrella JSR. The final Java SE 7 Platform Specification might not include all of these JSRs, and it might include some JSRs not listed here.

  • JSR 203: More New I/O APIs for the Java Platform ("NIO.2")
  • JSR 292: Supporting Dynamically Typed Languages on the Java Platform
  • JSR 334: Small Enhancements to the Java Programming Language (OpenJDK Project Coin)

The following core JCP specifications will be enhanced under the auspices of the Java SE 7 Umbrella JSR:

  • JSR 901: Java Language Specification — Maintenance Review to incorporate fixes since Java SE 5.0 and changes from the above JSRs
  • JSR 924: JVM Specification — Maintenance Review to incorporate changes made in Java SE 6.0 and JSR 292
  • Java SE APIs — Maintenance Review to incorporate changes made by routine maintenance and small-scale enhancement

Changes defined in Maintenance Reviews of various bundled stand-alone JSRs will also be included:

  • JSR 199: Java Compiler API
  • JSR 206: Java API for XML Processing (JAXP)
  • JSR 222: Java Architecture for XML Binding (JAXB)
  • JSR 224: Java API for XML-Based Web Services (JAX-WS)
  • JSR 269: Pluggable Annotation-Processing API

In addition to the JSRs listed above, a number of smaller enhancements are planned:

  • Thread-safe concurrent class loaders
  • Unicode 6.0
  • Enhanced locale support (IETF BCP 47 and UTR 35)
  • TLS 1.2
  • Elliptic-curve cryptography
  • JDBC 4.1
  • Translucent and shaped windows
  • Heavyweight/lightweight component mixing
  • Swing Nimbus look-and-feel
  • Swing JLayer component

Eclipse TPTP wird eingestellt

Sehr schade, denn TPTP fand ich als freie Profiling-Umgebung ganz cool (wenn auch nicht besonders performant). Die Testumgebung habe ich nie benutzt…

http://www.eclipse.org/tptp/home/project_info/devplans/EclipseTPTPProjectPlan2010.htm schreibt:

The Eclipse Test and Performance Tools Platform (TPTP) Project provides an open platform supplying powerful frameworks and services that allow software developers to build unique test and performance tools, both open source and commercial, that can be easily integrated with the platform and with other tools.

After many successful releases of TPTP, the project has evolved and matured. However, participation in the project has dwindled over time. TPTP has been in maintenance mode since TPTP 4.5.0 and at this point of the project cycle, the PMC has decided that TPTP 4.7 will be the last major release of TPTP (part of the Eclipse Helio release). We will be participating in the upcoming Helios services releases (TPTP 4.7.1 for Helios SR1 and TPTP 4.7.2 for Helios SR2) but will not be part of the next major Eclipse release (Eclipse 3.7, a.k.a. Indigo).

Once TPTP 4.7.2 is released in February 2011, we plan to follow the Eclipse archiving process to archive the remaining TPTP projects, which means that the mailing lists, newsgroups, website, and completed CVS/SVN repository will be stored in an archive (a zip or tar.gz) on the eclipse.org servers. The projects to be archived include:

· Platform

· Testing Tools

· Trace & Profiling Tools

· Monitoring Tools (archiving already approved by the EMO in May 2010)

Und warum also die Einstellung? Open Source funktioniert eben nur, wenn viele mitmachen.

Frage: Was benutzt ihr zum Profilen? Freie Tools (NetBeans, …) oder kommerzielle wie JProfiler, JProbe, … ?

Europcar und Webformulare 0.0001

Was ist an folgendem Text falsch?

Don’t do it!

Nichts, oder? Doch! Denn gibt man den Text in ein Formularfeld bei Europcar ein, bekommt man die Meldung:

forbidden character was entered (< > “ & | ; $ % ‚ + \) please amend.

Das ist echt schwach, denn natürlich möchte man das statt dont richtig don’t schreiben… Moderne Web-Frameworks maskieren Sonderzeichen automatisch aus. Die Europcar-Seiten enden auf .do — das riecht nach Struts und stinkt nach schlechten Entwicklern.

Wer’s selbst ausprobieren will: http://www.europcar.com/EBE/module/footer/ContactUs.do

Doug Lea tritt aus dem JCP aus

Here is the promised explanation for why I am not seeking another term
on the JCP Executive Committee: I believe that the JCP is no longer a
credible specification and standards body, and there is no remaining
useful role for an independent advocate for the academic and research
community on the EC.

Some have argued that JCP was never a credible standards body.  I once
disagreed: Sun initially placed in the JSPA and Process documents
enough rules to ensure that the JCP could foster innovation, quality,
and diversity, independent of that from Sun, with few enough (albeit
annoying) exceptions to allow JCP to drive consensual progress more
successfully than seen in most standards bodies.  However, some of
these rules, and violations of rules, have been found to be the source
of stalemates and lost technical ground. Rather than fixing rules or
ceasing violations, Oracle now promises to simply disregard them.  If
they indeed act as they have promised, then the JCP can never again
become more than an approval body for Oracle-backed initiatives.
(Oracle's choice of timing submission of SE release JSRs forced me to
decide not to stand for another term based only on those promises, not
on the actual actions.)  I urge other EC members to consider whether
short term "pragmatism" in voting outweighs such consequences.

So, what are the alternatives?

For the core Java platform (which these days roughly corresponds to
Java SE), the only existing vehicle for which I can foresee a useful
role for the academic and research community is OpenJDK.  OpenJDK is a
shared-source, not shared-spec body, so is superficially not an
alternative at all. But at this point, a Linux-style model for
collaboratively developed common source is likely to be more effective
in meeting upcoming challenges than is the JCP.  (In which case, of
course, the main role of JCP is only to approve specs for various
freeze-points that represent releases.) For this reason, I've
volunteered to continue and increase involvement to better establish
the reincarnated OpenJDK as such a body.

For other efforts, I cannot recommend to anyone that they use the JCP
JSR process, as opposed to some other group/organization/body, to gain
consensus for proposed specifications. So I expect to see fewer
submissions as people begin to realize that other venues provide
better opportunities. I suppose there is some possibility that I
will help improve support for such standards elsewhere, but I don't
have any immediate plans.

I could of course be wrong about all this, and hope that other EC
members try hard to prove me wrong.

I am sending this to the EC, to make sure you all hear this
from me directly first. But feel free to distribute. For simplicity,
I placed a copy at http://gee.cs.oswego.edu/dl/html/jcp22oct10.html.

Mal sehen wer folgt, und welchen Einfluss das auf die Java 7, Java 8 und die Familie der Concurrency Utilities hat.

Weiterhin ist folgende Bemerkung lesenswert: http://java.dzone.com/news/dear-oracle-get-clue.

Apple beendet Java-Unterstützung, so Nokia für Java ME

Apple wird Java SE nicht mit unterstützen. Die alte Version bleibt bestehen doch wird vielleicht bei neuen OS nicht mehr mit angeboten.

http://news.ycombinator.com/item?id=1814613

Nokia lizensiert Java ME nicht mehr und ist damit einer der großen, die bei den Milliarden von Phones auf Java verzichten.

http://www.nokia.com/press/press-releases/showpressrelease?newsid=1453894

GWT 2.1 RC1

Die Version 2.1 nimmt Neuerungen, die für 2.2 geplant waren, vorweg. Die Änderungen in Kürze:

  • Neue sogenannte Cell Widgets. Gedacht sind sie für große Datenmengen. Sie verbrauchen wenig Speicher.
  • Safe-HTML-Funktion, die böse HTML-Injektionen verhindert.
  • GWT-Applikationen können auf den Server loggen.

InfoQ (http://www.infoq.com/news/2010/10/GWT-2.1) stellt die Neuerungen kurz vor.

Ich würde mich noch wünschen, dass GIN in den Core aufgenommen wird.

IBM und Oracle arbeiten am OpenJDK, das Ende von Harmony

IBM hat bisher immer zu Harmony gehalten – das ist nun Verhangenheit: http://www-03.ibm.com/press/us/en/pressrelease/32708.wss.

Bin gespannt, was das für Google und Android bedeutet. IBM geht nun zu OpenJDK, was interessant ist, da die Lizenzform auch eine ganz andere ist.

Mehr http://java.dzone.com/articles/rip-harmony-0 und http://www.theserverside.com/discussions/thread.tss?thread_id=61081.

Amino: Ein neues Gui-Framwork

Josh stellt in seinem Blog-Beitrag http://weblogs.java.net/blog/joshy/archive/2010/10/09/announcing-amino-new-ui-toolkit-desktop-java ein neues Gui-Framwork Amino (http://leonardosketch.org/amino/) vor.

Amino is a next generation graphics library and UI toolkit. Though originally built as support for Leonardo Sketch it is now it’s own incubator project.  Amino is a 100% open source Java library that provides:

  • a 2D/3D scenegraph with multiple backends (Java2D, JOGL, and more coming).
  • a set of UI controls, skinnable with CSS.
  • Utility classes to help you build desktop apps quickly.
  • is extremely testable.
  • 100% open source (BSD), redistributable, and embeddable.
  • 100% Java, ready for use by any JVM dynamic language (Groovy, JRuby, Jython, JavaScript, JavaFX Script, etc.)

Erweiterungen von Swing sind:

    • Uses an event bus instead of listeners on each component, enabling better separation of model and view
    • A background task API to handle threading for you.
    • Mixes a retained mode scenegraph with immediate mode paint APIs so you can work at the abstraction level you prefer.
    • There are no Look & Feel classes. All UI skinning is done directly with CSS 3, even the default L&F.
    • If you use the (experimental) JOGL backend you can directly mix 2D graphics with OpenGL code.
    • All controls can be referenced by ID, similar to JavaScript libs, enabling further separation of concerns.
    • Amino has a tool called AppBundler which generates Mac OSX .app bundles as well as JNLP builds. The user should never know that your app is written in Java, or any other language. They will just love your app.

Noch sehen die Gui-Componenten gammelig aus aber es kann was werden (ist ja alles “nur” CSS).

Ant-Skripte für die Android-Entwicklung (AndCooperANT)

Der Build-Prozess für Android-Programme nimmt durch die Obfuscation einen Extra-Schritt. Das Projekt http://github.com/shareme/AndCooperANT von Fred Grott stellt Ant-Skripte bereit, die helfen, ProGuard richtig einzubinden, sodass die Entschlüsselung von Android-Programmen erschwert wird. Insbesondere mit der Anbindung an den Lizenzserver ist das zentraler Schritt – einige gehackte Programmen haben genau darauf nicht geachtet.

Das zentrale Ant-Skript ist http://github.com/shareme/AndCooperANT/blob/master/add-proguard-release.xml mit den Anpassungen in http://github.com/shareme/AndCooperANT/blob/master/proguard_android_config.txt.

<path id="android.modified.classpath">

            <fileset dir="${external.libs.dir}">

                 <include name="**/*.jar"/>

            </fileset>

            <path refid="android.target.classpath"/>

</path>

 

<property name="obfuscate.dir" value="obf" />

<property name="obfuscate.absolute.dir" location="${obfuscate.dir}" />

<property name="android-jar-preobfuscate" value="${obfuscate.absolute.dir}/original.jar" />

<property name="android-jar-postobfuscate" value="${obfuscate.absolute.dir}/postobf.jar" />

<property name="out.dex.input.absolute.dir" value="${android-jar-postobfuscate}" />

 

<!-- replaces the post-compile step from ant_rules_r3 -->

<target name="-post-compile" depends="-dex-obfuscate,-dex-no-obfuscate">

</target>

 

<target name="-dex-no-obfuscate" unless="build.mode.release">

  <mkdir dir="${obfuscate.absolute.dir}" />

  <jar basedir="${out.classes.dir}" destfile="${android-jar-postobfuscate}" />

</target>

 

<!-- Converts this project's .class files into .dex files -->

<target name="-dex-obfuscate" if="build.mode.release">

  <property name="proguard-jar" value="${proguard.dir}/proguard.jar" />

  <property name="proguard-conf.dir" value="" />

  <property name="proguard-conf.absolute.dir" location="${proguard-conf.dir}" />

  <property name="proguard-conf" value="${proguard-conf.absolute.dir}/procfg.txt" />

  <property name="libraryjarpath" refid="android.modified.classpath"/>

  <!-- Add Proguard Task -->

  <taskdef resource="proguard/ant/task.properties" classpath="${proguard-jar}" />

 

  <mkdir dir="${obfuscate.absolute.dir}" />

  <delete file="${android-jar-preobfuscate}"/>

  <delete file="${android-jar-postobfuscate}"/>

  <jar basedir="${out.classes.dir}" destfile="${android-jar-preobfuscate}" />

  <proguard>

    @${proguard-conf}

    -injars ${android-jar-preobfuscate}

    -outjars ${android-jar-postobfuscate}

    -libraryjars ${libraryjarpath}

    -dump ${obfuscate.absolute.dir}/dump.txt

    -printseeds ${obfuscate.absolute.dir}/seeds.txt

    -printusage ${obfuscate.absolute.dir}/usage.txt

    -printmapping ${obfuscate.absolute.dir}/mapping.txt

  </proguard>

</target>