Archive for category Java
EricDaugherty.com: Does Write Once Run Anwhere Work?
Eric Daugherty:
Realistically, I think tools like GWT are the future. As a Flex developer, I enjoy the ability to quickly and easily create rich applications that will render the same on ever user's machine. But I would prefer that the Flex applications would compile to HTML and JavaScript, so they could be run native in the browser.
Kindle Development Kit to use Java
Amazon has unveiled the details of its development kit for its Kindle e-book reader.
The so called “Kindle development kit for active content” (or KDK) will be based on Java 1.4 Personal Basis Profile (JSR 217); custom additional APIs will be available for networking, local storage, specific UI components, etc. (see javadoc).
As strongly as I feel about not actually owning what’s on your Kindle, this comes as a good news for Java when its future is being questioned after the Oracle merger.
You can read the KDK FAQ there.
Google Collections Library 1.0 final
The Google Collections Library 1.0 is a set of new collection types, implementations and related goodness for Java 5 and higher, brought to you by Google. It is a natural extension of the Java Collections Framework.
We have finally (Dec 30, 2009) released version 1.0-final! The API is now frozen: there will be no more source- or binary-incompatible changes, except those that can be performed via a minimum 18-month-long deprecation window.
Support the Elvis proposal for Java !
Are you tired of writing
(x != null) ? x.getThis() : null
Would you rather write something like
x?.getThis()
If so, support the Elvis proposal for Java !
Interesting alternative notations can be found here.
Mark Reinhold’s proposal for Java closures
I believe this proposal, although incomplete, to be much more acceptable to the current Java community than existing BGGA or FCM.
Most proposals state that it’s not the syntax that matters, it’s the semantics. While this is undoubtedly true, syntax is the first thing a programmer will see and judge the feature by. If the syntax isn’t self-explanatory enough, it will be a cause of rejection, and the feature will not be used as it could have been. So I do believe syntax is a key point of the future Java closures feature, and in this respect I tend to favor Mak Rheinhold’s proposal or the FCM proposal rather than BGGA.
lambdaj – easy collection manipulation
LambaJ is quite an interesting project. How many times did you write the same loop, with only a few differences that were impossible to factor out because of the lack of closures in Java?
LambdaJ partially alleviates the need for closures by allowing the manipulation of Collections in a way that doesn’t require iterating through the items. For example you could write
forEach(personInFamily).setLastName("Fusco");
with personInFamily being a List of Person, and setLastName being a method on the Person class. Actually, forEach returns a proxy that implements both the Iterable interface and the methods of the collection items’ class (Person in this case). A call to any of these methods is then propagated to each member of the collection.
As you can see, LambdaJ uses the DSL-style notation that mock frameworks introduced, which I’m not particularly fond of; but I must say that in this case it produces quite elegant and readable code.
As a bonus, LambaJ also offers its own flavor of closures…
“Is Oracle Good for Java?”
Continuing the series, here’s Bert Ertman’s opinion after Oracle’s OpenWorld :
(…) To sum things up so far, Oracle’s message is about integrating everything into a single (bright red colored) solution. They deserve credit for the way their current stack seems to deliver to that promise. However, Java’s promise has always been about opening everything up for innovation and boldly go where no-one has gone before (lame quote alert, but it holds the truth). I don’t see where the latter fits in within Oracle. (…)
Oracle-Sun acquisition: update
I have already commented on this subject, and nothing much has changed since then… the acquisition is still pending regulatory issues, and Larry Ellison is trying to put pressure on the EU by saying everywhere that every day until the deal closes, he loses 100.000 dollars, a figure that can’t be confirmed of course.
Anyway, a few days ago Oracle updated its web page dedicated to the acquisition, and we can now find there a document named “Oracle and Sun overview and FAQ“. In summary, this is what we can retain from this document regarding Java-related issues:
- Java: Oracle plans to “accelerate investment on the Java platform”.
- DBs: Oracle claims it will spend more money then Sun does now developing MySQL.
- IDEs: JDeveloper, NetBeans and Oracle’s own flavor of Eclipse will coexist… for now.
- Application servers: Oracle will continue evolving Glassfish as JEE reference implementation, and also work towards “aligning common infrastructure components“ between Glassfish and WebLogic. Does this sound like a step to merging both products?
Other announcements include increased funding for Solaris and SPARC, continued support for virtualization products, and a few other things.
Overall this is obviously meant to be reassuring to everyone: there is no intention to drop any product, most of them will get increased investment, Oracle now has the best hardware and software combination, etc. But until we know what “accelerate investment on the Java platform” exactly means, there’s still a lot of room for speculations.
Rant: don’t name interfaces like ISomething
I see a trend lately in Java libraries and code that I thought was only plaguing Microsoft developers: naming interfaces like ISomething. I find this very disturbing so I thought I had to react.
First thing: an interface is a type just like a class. What a type does is mainly to define the set of operations (methods) that are applicable to an instance of a class that implements this type. When dealing with references, the only thing the Java compiler cares about is the type of the reference, so that is knows if a method call is licit or not. It does not care if the type is a class or an instance. Think about the instanceof operator: despite what the awkward name suggests, it works with interfaces as well as classes, because what it actually tests is whether a given reference is of a particular type.
So, why shouldn’t you name your interfaces beginning with the letter I?
- it breaks a fundamental OO rule, which is that you should let the users of your code know as little as possible about the implementation. If a method returns a object of type Foo, it doesn’t make any difference to the caller of this method if Foo is actually a class or en interface.
- it is redundant. If you really need to know, the documentation (written or Javadoc), or your IDE’s lookup mechanism, will tell you if it’s an interface or not
- it makes code harder to read. Which one do you prefer:
IFoo foo = getFoo();
IBar bar = (IBar) foo.getStuff();
or
Foo foo = getFoo();
Bar bar = (Bar) foo.getStuff();
I understand that developpers are often tempted to name interfaces like that because they know there will likely ever be only one implementation of this interface. So they have a Foo class, and it needs to implement an interface, why not name it IFoo?
Two points here:
- You don’t always need to define an interface for such a class. If you are configuring Spring beans for example, your bean references don’t need to be an interface type. Even if it is good practice to do so, there are cases (such as the one above) where it’s a perfectly valid case to use the class directly.
- Why not name your interface Foo, and your implementation something else, like DefaultFoo or SimpleFoo or BaseFoo or whatever. Or maybe just Foo, provided it’s not in the same package! If you are using a factory, no-one will ever know or care how the concrete class is named anyway.
Naming interfaces like ISomething is similar to including type name or scope in your variables names. Yuck… Please don’t bring this to Java.
WebDriver: automated web UI testing
Automating UI testing is not a trivial task, yet it is highly desirable as part of a complete non-regression test suite, which is (as everyone knows by now) a must-have for any project claiming to be agile. This is how I came across WebDriver while looking for ways to automate testing a GXT-generated frontend.
While being quite similar in its goals to Selenium, WebDriver takes a different approach: instead of interacting directly with the application’s JavaScript, it runs totally external to the browser and “drives” it, a bit like SeleniumRC.
Yes, it introduces a platform dependency, but this is mitigated by 2 points: the FirefoxDriver is available on all platforms, and you also have a HtmlDriver which is not platform-dependant, but unfortunately cannot work with JavaScript interfaces.
On the other hand, piloting the browser means you test exactly what the user will see. And depending on the browser is also a good thing because the browser is part of what you want to test! if your application has a glitch on IE which does not exist on Firefox (this is just an example of course…), then you want your tests to find out.
Writing a WebDriver test can be done in minutes. It’s simpy an API, so you can integrate it in any kind of Java code, including a JUnit test suite.
For example:
import ... public class TestWebDriver { public static void main(String[] args) { WebDriver driver = new FirefoxDriver(); driver.get("http://localhost:8080/myApp/MyHostPage.html"); WebElement checkbox = driver.findElement(By.xpath("//div[@id='checkbox-id']/input")); checkbox.setSelected(); WebElement element = driver.findElement(By.id("submit-button-id")); element.click(); System.out.println("Page title is: " + driver.getTitle()); } }
Can’t imagine much simpler than that. Want to test with IE ? Use InternetExplorerDriver instead of FirefoxDriver. Checking iPhone compatibility? Try IPhoneDriver.
As I’m working with GXT, there are a few things to be aware of. You will most often look for elements by ID, but of course the ID you set with GXT’s setId() is not always where you expect it to be. For example, if you set it on a Checkbox, it’s actually attached to the DIV that surrounds the INPUT element, not the INPUT element. This is why, in the example above, I used XPath to select the element, rather than direct selection by ID. When you want to access an element, the best is to have a look at the HTML by using an inspection tool such as Firebug or similar; then you can easily write an XPath expression that will select just the element you need.
WebDriver will eventually be integrated into Selenium 2.0.
-
You are currently browsing the archives for the Java category.
