Just testing the old blog. Since you stopped by, some links:
Web Apps are applications that run on any device, and can be distributed through any store or directly by the developer.
The future of Javascript (as visualized by Brendan Eich):
How the iPad can revolutionize music notation software
Here's a nice overview of new language features coming in JDK 7. Good stuff but nothing most other popular languages haven't had for years. Add type inference and you could have:
ages = {"Arthur" : 42};
ArthursAge = ages["Arthur"];
with type safety intact. Kinda looks like Javascript doesn't it? It's valid python too (sans semicolons). But it could have all the static type goodness of Java with that syntax. Other languages do it.
In addition to the features in that post, a couple of weeks ago Mark Reinhold announced that closures will also be included in JDK 7. After all the wars over closures in Java two years ago and three proposals that went nowhere, this was a big surprise. It turns out that closures are being added to prevent some particularly nasty syntax that would be required for using parallel arrays. Java's ceremonial boilerplate syntax is forcing it to adapt some features that are common in most other popular languages. It's welcome, but too little, too late for some folks. Others would rather that Java not evolve much. Relative stability has served Java well.
Other languages on the JVM already have the features that will be in Java 7 and likely Java 8 and Java 9 too. You could just get on with those if you need those features. That has been my approach, when possible, but at least I know that Java will be moving forward, albeit slowly, when I do have to use it.
JDK 7 has also slipped to later in 2010 so don't expect to be using this stuff in your projects until 2011.
I really like the new features. A function type in Java...never thought I'd see the day.
IBM voted "no" due to lack of decimal arithmetic support. The rest of the planet voted "yes" except for Intel, who didn't have take enough time to review IP issues. The two thirds necessary to approve the spec was achieved along with fast track to ISO. Fortunately, voting "no" doesn't mean that IBM can't implement the new spec in their own Javascript implementation.
The gory details for my fellow language geeks:
http://www.ecma-international.org/publications/standards/Ecma-262.htm
This will make it easy for Eclipse and/or any Equinox, RCP, or
RAP-based application to interoperate with other Google Wave
applications.
Google Wave and ECF
Google announced a personal communication and collaboration application today called Wave. It is also a platform for collaborative applications. Here's some links:
Live Notes from the announcement
Update:
I recently read an article that resonated with me titled "Killing Innovation with Corner Cases and Consensus". Key point:
A corner case is an objection that may be:
Check out Atlas from 280 North. Watch the video. Then have a look at 280 Slides, a Keynote clone built on the underlying Cappuccino platform. Awesome. Just awesome.
There's a lot of noise flying around about the future of Lotusscript (again). Here's my take.
Lotusscript the language as implemented by the Lotusscript compiler has been near-dead for years. NOT dead in the sense that it will be removed from the product but in the sense that there have been so few significant enhancements since R4. There have been some library additions but the language itself has changed less than any other langauge that I use.
What does this mean for the Eclipse Lotusscript editor? Not much. The editor still sends the code as text through JNI to the same old compiler. Don't expect language enhancements just because there are newer and better tools. While I welcome the new tools, I would rather have a better language. Unfortunately, that ship has sailed for Lotusscript.
What I'd like to see but was convinced in Orlando will not happen: Use one or more of existing langauge implementations for the JVM. I'd like to see IBM work through the Not Invented Here and intellectual property issues. IBM uses Jython as a scripting language for Websphere. Groovy is one of the two languages used to build applications with Websphere SMash. The other is IBMs own implementation of PHP for the JVM.
Speaking of IBMs own implementations of languages for the JVM, we have XPages javascript, which is a good example of why I would like to see IBM use existing implementations and STOP building everything in house. XPages javascript is years behind the Javascript in your browser, especially if you use Firefox. (see javascript 1.6/E4X, 1.7, 1.8)
These languages allow you to leverage Java to any extent needed such as domain objects, performance, APIs for third parties, etc. What about "just learn Java"? Yes, by all means..I did, but just as with XPages, a JVM hosted scripting language is often the right tool. (see Ola Bini on Fractal Programming).
Having a powerful, class-based OO scripting language would also reduce the class->prototype->class impedance mismatch that developers moving to Java from Lotusscript have to deal with when using Javascript. I'm not arguing against Javascript, I love the language, but it would be nice to have a class-based OO option (OOption :-?).
The APIs to integrate these language implementations with Java are in Java 6. A tutorial on how to use the Dynamic Language Toolkit Framework to build Eclipse tooling for them was recently published on developerWorks.
XPages for the client may surprise me. I hope so. And for web apps, the browsers are moving toward other language implementations. Imagine the Run On Server/Client option for Ruby or Python.
This really wan't much about Lotusscript. That's because there's not much to say except "Thanks for the Eclipse tools, they're sorely needed and appear to be very well done".
For a glimpse of the future, have a look at the first milestone of the Eclipse E4 project. Two goals of the project are:
Would you like to use CSS to style SWT? What if you could cross-compile SWT to Flex or Dojo?
For working examples of these and more see Eclipse E4 M1 New and Noteworthy.
E4 is an incubator project. The features developed in E4 are not targeted for any specific Eclipse release.