An interpreted language that stays very close to Java,
and which is reported to have settled down to the point
that it has become usable.
JRuby
A very cool implementation of Ruby on the Java platform.
Starts up Java apps without VM-initialization overhead,
provides access to Java classes, installs with ease,
and provides strong thread support:
http://www.artima.com/weblogs/viewpost.jsp?thread=205140
JavaFX Script
A brand new language that aims to make it easy to
develop dynamic web pages that run using the JVM in
the browser.
Sun's Ethan Nicholas gave a talk on upcoming improvments
in the JRE installation and startup process. They were
extensive:
A new installer program with more graphics, way
less text, and fewer clicks to get things done.
It will be a lot less threatening to the average user.
Updates will no longer create a new copy of the JRE,
but will instead patch the existing version--so update
releases will stop hogging all of the disk space in sight.
Updates will happen much faster, as a result. But the
initial install has been streamlined to go faster, as
well, with a small initial module that downloads immediately
and subsequent modules that download on demand or in the
background.
A toolkit for JRE deployment that includes a javascript
file, browser plugins, and a standalone version, where
the Javascript contains APIs useful for deployment:
getJREs(): find out which JREs are present
versionCheck(pattern): Use regular expressions to
test for the existenc of some set of versions
installLatestJRE(): to "git 'er done"
The javascript code also contains APIs to launch applets,
test for the presence of Java Web Start, and create a
Java Web Start launch button.
The current versions of the JRE support minimal versions of
the useful behaviors. So today, you can only detect major
versions (e.g. version 5). But starting in early 2008, the
APIs will be fully supported, so you can determine exactly
which version is on the end user's system.
When the JVM is already in memory (a warm start), it starts in
a tenth of a second. Plenty fast. The problem is when it has to be
read in from disk (a cold start). And reading the JVM into memory
before you need it doesn't help--you make the user's system
begin paging sooner than it otherwise would have, and it's
likely to be paged out by the time you need it--so you're
back to reading from disk.
The Java Quick Start service solves the problem by implementing
a background process that reads from the disk every so often.
That process puts the files in the disk cache, so that when the
JVM is launched, it's doing a warm start. (But if memory is
constrained, it disables itself so it does cause thrashing.)
It may be, too, that the same modularization that improves
download speeds can be used to improve startup speed. With that
system, the Java Kernel is just big enough to run HelloWorld,
and other modules are brought in as needed or in a background
process.
Speaking of modules, the new module system for Java
will be pretty cool. A module will be a collection
of packages in a "super jar", but:
Some packages are public, others can be private
Public packages can be public only in their jar
Dependencies wil be managed, so there are no cyclic
dependencies
Different versions of a library can co-exist in the
same VM
They'll separate APIs from SPIs
A Service Provider Interface (SPI) is something the
framework calls. It adds capabilities to the framework
in the same way that an API adds capabilities to your
application.
Interestingly, adding to an API preserves compatibility
(the application never calls it), while removing from an
SPI also preserves compatibility (the SPI doesn't see it,
so it doesn't provide the additional functionality).
So if SPIs and APIs both exist in the same class, there
are no provably compatible changes you can make.
Best practice therfore suggests that APIs and SPIs
should not only be in separate classes, they should
be in separate packages. That way, users don't see
things they don't care about, and they can more easily
learn the interface by way of the IDE's code completion.
The module system aids and abets that separation, making
it possible to expose module P to users, without exposing
sub-package P.Q.
Peter von der Ahe, Jonthan Gibbons, and Alex Buckley
held on BOF on Java 7 language features. The goal
was to present a few ideas, gather some, and
generally invite discussion.
As guideline for possible changes, Peter listed
core language principles that are unlikely to
change:
Reading is more important than writing
Simplicity matters
One language, spoken the same everywhere
Compatibility matters
Some of the possible features included:
Abstraction:
Something like closures that would keep you
having nested try/finalies, for example when
writing I/O code. The syntax might look like
this:
with (InputStream is: ... )
with (OutputSrream os: .... ) {
...
}
Enhanced Switch Statement:
Make it work with strings, and a coverage
check when using enums, to identify gaps.
Reified Generics:
Getting rid of type erasure is on the table,
so that types can be tested at runtime, and
allowing arrays to safely use generic types.
It would also allow for accurate reflection
and serialization. The big issue for all that
is retaining back compatibility.
The new workflow paths for the language now
look like this (all three will be available through
Mercurial):
Stable Branch: Major releases like 5, 6, 7 (bug fixes)
Development Branch: IDEs, GlassFish, JDK 7 until freeze (features)
KSL branch: Kitchen Sink Language (experiments)
Some ideas were specifically disallowed for Java 7.
They are features that may well be in the scripting
languages that run on the Java platform, but they
are inconsistent with the "prime directives" that
Peter listed, so they are not on the table for the
Java language:
Dynamic typing
Mixins / traits / multimethods / macros
Personal Note:
Once a decade, I think it's time to cut the anchor
cable and move forward without dragging all of the
old stuff behind you. But there are many enterprises
that would no doubt disagree with that idea, but the
Java platform developers seem to have found ways to
achieve similar objectives while still retaining
compatibily. (One heck of an achivement, that.)
My list of desirable changes includes:
A smaller JVM, minus the deprecated APIs, that starts
faster and takes less memory. (But with the Quick Start
option loading APIs in the background, the goal is
achieved in a way that retains compatibility.)
If arrays aren't type safe, I figured, toss them!
Use the syntax for something like Ruby lists, instead.
(But modifying the VM to support runtime types, while
at the sam preserving compatibility (!) makes it possible
to eliminate type erasure, make arrays safe, and still
keep old apps running.)
I'd also toss primitives, go with a pure OO syntax,
and elminate the dozens of duplicate APIs that use them.
(But auto-boxing means you no longer have to write them,
at least. So maybe the background-loading principle of
the Quick Start option and the API-separation principle
of modules could be applied to classes--so you never have
to load the code for those APIs, or even see them???
Probably not. But it seemed like a good thing to ask...)
Anyway, it looks as though the platform developers are
figuring out ways to achive very important goals in ways
that also preserver compatibility. Pretty darn clever.
The language features session covered autmented tools
capabilities, as well:
JSR 199: Compiler API
The compiler modifications let you use the javax.tools
library to:
invoke compilers and tools
control how files are found
give you access to diagnostics
JSR 269: Annotation Processing
With this JSR, APT is deprecated. You now get to use
javac instead, which gives a full semantic model of
a Java program (but not a syntactic one). The packages
are:
javax.lang.model.*
javax.annotation.processing.*
Tree API
When you want a full syntactic model, the Tree API gives
you the parse tree you need. It combines with compiler API
and semantic model to give you access to the full source
tree. The package isn't part of the standard, but it is a
public API and use of it is encouraged:
com.sun.source.*
For someone who has been using the JavaDoc program as
a poor man's parse-tree generator for quite a while
now, the really good news from this session was:
The new APIs designed to be very similar to the JavaDoc APIs
The hope is that it will be possible to deprecate JavaDoc
(A little bit of work still needs to be done, but's close.)
To take advantage of the new capabilities, Peter suggested
that it would be a COOL PROJECT to use JackPot to transform
a JavaDoc app into one that uses the new APIs. I couldn't agree
more. (Race you!)
The library is designed for functional testing of
Swing apps. It presents a "fluent interface" that
lets you write readable test, like:
xxx.shouldShowErrorMessage()
It's object oriented, so you're interating with a GUI
object rather than poking an x,y location on screen
real estate. That way, the tests are more robust--they
don't suddenly start to fail when the layout changes--
something that can be a major problem when you're using
test recorders that record your gestures.
Possibly the nicest thing about the system is that it
takes a screenshot when a test fails--so if something
failed because an Antivirus dialog popped up, for
example, it would be easy to see that.
One of the Sun pods on the show floor was focused on
identity management: "a decentralized, web-friendly single
sign-on mechanism that allows consumers to reuse a single
login across different websites."
Another pod at the conference centered around support for
the DITA format on the JVM. I'm intrigued by the possibility
of using DITA to carry on a structured discussion over the web,
so it was interesting to find so many different content
management systems, development frameworks, editors, and
production systems running in the JVM.
Finally, there was a great session on writing DSLs in Ruby.
(Coupled with the description of how to make a web app in
Rails, that made two of the best tutorial-talks I've seen
for Rails and Ruby, both at JavaOne!)
The talk listed all of the Ruby idioms that make it
possible to construct a DSL. I was surprised to find that
even with my limited use of the language, I was already
familiar with them. So it seems that I do know enough
to construct a DSL. But the bad news was that even after
listening to the talk, I still didn't see how they all
fit together.
So I've got some more work to this area. But at least now
I can be confident that I'm prepared to tackle it. I'll get
back to you when I've made some more progress.
:_)
Vector instruction set Let's face it, your are not going anywhere on the desktop without proper support for audio and video. And you are not going to get that without vector processing instructions. Even an mp3 decoder is hard to write efficiently without using vector instruction for transform kernels.
Previous Topic
