I had an interesting thought the other day for a project I'm helping a friend with. Many things we deal with come in key/value pairs (URL parameters for instance). Why not immediately work with objects instead? There's a simple way...
Here is a simple pattern which you can use to make your APIs extensible, even by third parties, without sacrificing your ability to keep backward compatibility.
Where's the state? This is a small but useful question when
deciding how a problem domain gets carved up into objects:
What things have state? What things have values that
can change? When and how can they change? Can the changes be
observed? Who needs to observe changes in state?
One thing which I think about often is the design of code,
and APIs. I've been working on
deriving some principles from the things I do intuitively based on
experience. Whether those are useful to anyone else is an open question.
Peer review is the best tool for figuring
out if these really make sense or not, so I'd appreciate
feedback on my next few blogs - hopefully one day they can
make up some articles or a book or similar.
The Java Module System with the new module keyword support in the Java language will be ready to integrate to the OpenJDK Modules project in a week or two. This blog hopes to provide a simple tutorial to help you get started developing, building and using JAM modules.
I needed to load the classes from the dt.jar archive on the fly. The path to the archive was generated automatically based on the "java.home" system property. The original idea was to use the URLClassLoader, but it could not find classes. I had to write a custom class loader which read an archive and loaded classes on demand. At that instant I realized why the URLClassLoader did not work: I had incorrectly generated the path to the archive and the URLClassLoader for a wonder provided no warning that the archive was not found.
A prototype of the OSGi repository for supporting OSGi bundles in the Java Module System is now available in the OpenJDK Modules project. Looking for feedback and contribution from the community.
On May 23, I gave a presentation at Sun about computer science students, and how a company can engage with them. Here are some of the questions that I was asked, and the answers that I gave (or wish I had given), and a question that I wish I had been asked.
Day 4 of Java One is over. Even without huge announcements or great
surprises, it was a great conference. Here are my impressions from the cool
stuff keynote and my takeaway what it all means.
My day 3 at Java One ranged from the Nimbus UI and the future of JSF to interesting discussions about closures and Scala. Details below.
What, if anything, talked about on Day 1 of JavaOne 2008 was of any import to Java developers?
Last year, Java One Day 0 was Netbeans Day, in a cozy hotel. This year, the Java One week started much more grandly, with Community One, at the Moscone Center. My mind wandered during the keynote speech, but I was enchanted by the enigmatically named EclipseLink and robots that had cockroach reflexes and were programmed in GreenFoot.
What sort of JavaOne will this be?
A recent column on Java generics drew a collection of decidedly blue-collar comments, which made me think how hard it is to design a blue-collar language.
Yesterday, Apple released
Java SE version 1.6.0_05 for 64-bit Intel-based Mac OS X 10.5.2 or
It's restricted to 64-bit machines and Charles
is unhappy about it. Hopefully, they'll release a 32-bit
version as well.
Type "sw_vers" in a terminal to check the Mac OS X version as shown
ProductName: Mac OS X
Today my MacBook's Software Update alerted me to very happy news: Java SE 6 ready to be installed! I knew that Apple was closing in on the release but to achieve this milestone just the week before JavaOne is great!
The first of hopefully many articles detailing little-known facts about the inner workings of the JRE. In this episode: Java Plug-In vs. Java Web Start; Class Data Sharing.
A draft specification for supporting OSGi bundles in the Java Module System is made available to the JSR 277 Expert Group to continue the OSGi interoperability discussion.
I recently take on a new challenge and am working on the JSR 277 and OSGi interoperability.....
One of the significant features in the new Java SE 6u5 release is the ability to register the JDK installations through Sun Connection. You will learn more about this new JDK registration feature in this blog.