In 25 years or so, we'll look at the current morass as only a small step above assembly-language programming.

An interesting way to look at this is to think back to the state of programming 25 years ago, in 1985. If you take that state, compare it to today's state, then "project" linearly into the future, maybe you can guess what programming witll be like in 2035. Well, certainly you can guess, but is it likely that you'd be right?

A thought experiment: pretend it's 1985, and think about what programming was like in 1960 (impossible even for me to accomplish except by referencing historical documents). What would someone in 1985 have thought programming would be like in 2010, by thinking back to the state of programming in 1960? Or, go back even further, with the aid of something like the Wikipedia's History of programming languages, and see if any longer term trends seem to remain approximately constant.

Let's try this, just for fun!

Figure 1. An artistic representation of a Turning machine (from the Wikipedia)

• 1935 - predates electronic computers; Alan Turing was thinking about the Turing Machine: "an infinite memory capacity obtained in the form of an infinite tape marked out into squares on each of which a symbol could be printed. At any moment there is one symbol in the machine; it is called the scanned symbol. The machine can alter the scanned symbol and its behavior is in part determined by that symbol, but the symbols on the tape elsewhere do not affect the behavior of the machine. However, the tape can be moved back and forth through the machine, this being one of the elementary operations of the machine. Any symbol on the tape may therefore eventually have an innings" (see Figure 1)
• 1960 - FORTRAN, LISP, and COBOL in use
• 1985 - C, C++, SQL
• 2010 - Java, .NET, Web Scripting, RIA

What is the trend? Clearly, as time progresses we work "farther away" from the hardware. Also the relation between code and memory becomes further abstracted over time. And, changes in hardware are related to changes in programming languages: the languages adapt to the available resources that new hardware provides, such as electronic memory, graphics, the Web, etc.

So, what does this point to for 2035? Thinking about hardware, many core processors should be the norm. Another clear hardware trend: hardware that can perform the same functionality (or much greater functionality) gets smaller over time. And, computers "disappear" into devices, which are no longer considered to be computers, even though they are actually computers that perform a single, specific task (mobile phones, for example). Will there still be desktop PCs in 2035? Perhaps only programmers will have them.

I'm not much for prognosticating myself. I once spent quite a lot of time coming up with some decent stock market models, but I was never able to successfully predict the longer-term future.

What are some of Bruce Eckel's predictions for Programming in the Mid-Future? He predicts that 25 years from now, the programming environment will include these features:

• Extremely dynamic
• Stupidly parallel objects
• Persistent diskless environment
• Transparency between local and cloud
• Swarm testing
• Security via suspicious systems
• Effortless data stores
• Query-based data
• Reusability on a vast scale
• Effortless system integration
• Reusable UIs
• Effortlessly scalable
• Built-in evolvability
• Big talk

See the full article for details, and to post your own predictions and/or hopes for programming in 2035.

In Java Today, Shai Almog reports on LWUIT On Nexus One (Android) Device:

A lot of people experiment GlassFish for the first time via an IDE (most A colleague of ours just got a new Nexus One device and I just had to try LWUIT on it... I used Thorsten's port to get started and made some minor UI tweaks using the resource editor. In the process I also added a new LWUIT feature (pure touch) to make the UI behave closer to the way it does on Android/iPhone devices (show focus only when using the keypad and hide it when not using the touch screen). The result is...

Tyler Ballance reports on One month of Continuous Blog:

It's been a little over a month since I pinged Kohsuke about an "official Hudson blog"; my role has been nothing more than writer and editor of a community resource, while I have invested a lot of time in Continuous Blog it is not "mine" so much as it is "ours." I feel I have a responsibility as the current maintainer of this resource to be as open as possible about what's going on with CB. When I sat down to write the inaugural post...

Bruce Eckel looks into his magic crystal ball in Programming in the Mid-Future:

In 25 years or so, we'll look at the current morass as only a small step above assembly-language programming. Here's what I think programming will be like then...

In the Weblogs, Christian Bryant describes How the UCLA JUG was Born:

After a long hiatus from UCLA, Duke returned in the form of the UCLA Java User Group. I'm not sure how long it has really been since a Java User Group haunted the halls of UCLA. Some say it's been between five and ten years which, in Java terms, is quite some time. I found a great archived news item here at UCLA about the UCLA Java Campus from 2000. I like that idea. Maybe we can see it come around again...

Marc Hadley talks about Declarative Hyperlinking in Jersey:

One of the areas I'm keen to improve in the next version of JAX-RS is link creation. JAX-RS already offers UriBuilder but I think an annotation driven approach could save a lot of repetitive coding. I've been experimenting with a couple of annotations that I think would be useful and I just checked in an experimental extension that partially implements what I have in mind. Suppose you have a resource like this...

Jean-Francois Bonbhel presents a JUG-AFRICA Cooperation plan and agenda:

There is my proposal for JUG-AFRICA agenda. Everyone is free to comment and add interesting ideas. I will detail each point in my blog later. * Continue to affiliate JUGs and share our experience with new JUGs; * Elect a president and a vice president (last week of april 2010); * Increase our visibility by both ways internal and external (very important)...

In the Forums, sgnl19 is working on Testing JAX-WS based SOAP Services with SOUP UI: We're trying to test our webservices with the SoapUi Testingtool. The tool normally sends the requests formatted with whitespaces. The effect occurs, that if we send the request without using the strip whitespace function only the first parameter...

sargue has a problem with GlassFish v3 valve not found (cnfe): I have a problem trying to configure a custom valve on glassfish v3. I've coded the class (attached) and generated the jar file (attached). I put the jar file inside the lib directory (where I put for example jdbc drivers). That's...

In the JavaFX forum, lordoffriends says Help !! please: I m new to javafx..and i want to integrate my java project with javafx.and i m using Eclipse with JAVA FX SDK 1.2.1. Here is the code of Java file : public class JavaTest { public static void main (String[] args) { ...

Our Spotlight this week is the work of our friend Felipe Gaúcho, who suddenly passed away on Friday, March 5. Felipe was a CEJUG founder and leader, a Java evangelist, and a long-time java.net collaborator. The self-description he wrote for java.net: "Felipe Gaúcho works as senior software engineer at Netcetera AG in Switzerland. He is a well known Brazilian JUG leader and open-source evangelist. Felipe works with Java since its early versions and has plans to keep that Java tradition as it is. When he is not coding, he prefers to listen reggae and travel around with his lovely wife Alena and his son Rodrigo."

Our current java.net Poll asks What's your view of Scala's future? Voting will be open until Friday.

We just published a new java.net Feature Article, Dibyendu Roy's Rethinking Multi-Threaded Design Principles; in the emerging multicore/multiprocessor world, multi-threaded programming is critical, in my view. We're also featuring Has JDBC Kept up with Enterprise Requirements? by Jesse Davis; in the article, Jesse invites us to look beyond Type 4 architecture to address the latest requirements of the enterprise Java ecosystem. And, Adhir Mehta's Java Tech article, Web Service Simulatino Using Servlets also remains in the Featured Articles section of the java.net home page.

Current and upcoming Java Events:

• March 8-13: JavaEE Training Philippines
• March 16-19: Java Posse Roundup 2010
• March 17-19: TheServerSide Java Symposium 2010
• March 24-25, Hyderabab, India: Tech Days | Hyderabad, India
• March 25-26: Agile Testing for Java Developers
• March 29-31, Pasig City, Philippines: Spring Training Philippines
• April 5, Dallas, TX, US: Java EE6 Road Show: Free EE6 and Glass Fish V3 Seminar
• April 8-9, St. Petersburg, Russia: Tech Days | St. Petersburg, Russia
• April 12-16, Pasig City, Philippines: Java Training Philippines
• April 26-30, Pasig City, Philippines: JavaEE Training Philippines
• April 30 - May 2, Reston, VA, US: 2010 Northern Virginia Software Symposium: Spring Edition
• May 3-8: JAX 2010
• May 10-14, Redwood City, CA, US: Android Training
• May 21-23, St. Louis, MO, US: 2010 Gateway Software Symposium
• June 4-5, Dallas, TX, US: 2010 Lone Star Software Symposium: Dallas Edition
• June 14-17, Denver, CO, US: UberConf 2010

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

-- Kevin Farnham
O'Reilly Media
Twitter: @kevin_farnham

 We use the Java programming language. If you want to do a similar task, have a closer look at our work. Since ODT is part of the ODF  standard, which is well defined, XML-based and easy, this task should not be that complex - an so it is.

The work was done by Tim Schäfer, he used the ODFDOM API  as an abstraction layer for ODF.

Have a look at our work at http://labs.micromata.de/display/odt/Home 

Thomas Landgraf

 http://www.micromata.de

I wrote about Magnolia cache few times already since it have been re-implemented for Magnolia 3.6. And it seems like with Sprint 4 of Magnolia 4.3 it came back to bite me.

There was a bunch of tickets related to various aspects of the cache. Most of it was related to the fact that the default cache key (only URI) was not enough for many installations which were using multiple domains (and customizing output based on the domain) or multiple languages and changing content based on the user locale (set in http header). This on its own was not a problem, since you could just re-implement cache policy, executors and flush policy, but since it was so wide spread we decided Magnolia Cache Module should support such use cases by default.

The changes necessary to fix issues described above actually fit nicely with the goals for Magnolia 4.3 release which was all about making multi domain and multi lingual configurations easier to use and more user friendly. And on top of that, I don't think that many people ventured into extending the cache and writing their own keys, policies and executors that would be more specific. Most of them just switched the caching off altogether and took the performance hit. Well that was fine as long as they could manage, but now there is a better way.

With the finalization and refining of multi domain support and with extensions to i18n, the structure of the key just was not enough anymore. The key need to be aware of the domain all the time as well as of the user locale no matter whether it was encoded in the URI or not. 

The cache key was also ignorant of the request parameters. Arguably not a problem, because the caching of dynamic content is not desired in most of the cases, and was switched off by default anyway. While this configuration stays, the key is now aware of the parameters and their values and such request can be cached now (of course only as long as the output produced by such queries is intended to be always the same, but the choise is now on the user).

Another weak point of current cache key have been its binding to the user generated content (UGC), such as page comments. Since page comments are rendered as part of the page and not retrieved via AJAX calls, UGC related features need to be able to flush the specific pages from the cache (those that have been commented upon). To do so, up until now the UUID have been used to get the page handle and the page handle have been assumed to match URI 1:1. This works for a simple case such as commenting, but not in general so the stronger cache key and mapping between key and UUID at the time of creation is necessary to make that feature work universally and irrespective to various content mappings.

Improvements to the cache key are visible also in this area. Magnolia now persists binding between cache key and UUID of the main content used to generate cache entry. This means one can now request all the content created from given resource to be flushed from the cache explicitly and cache will cleanup all the entries created from such resource, no matter with what domain, locale or parameters were used in the request when the keys and entries have been generated.

While testing the cache and various configurations and functions, I have also ran in the need to observe and tweak what is happening, so Cache Module in Magnolia 4.3 comes with own MBean and you can observe cache behavior via JMX console. And not only observe, you can also flush whole cache or specific entries using this managed bean. (Just to put this in perspective, there is of course also the MBean from the underlying cache engine itself - ehCache, but that is at a bit different level and is not aware of bypasses and various cache behaviors.)

As if all that was not enough, while writing flushing functions for managed bean, I thought I better extract that in separate commands and did so. The extraction happened for two reasons really, first it is no business of the managed bean to know the internals of calling various cache functions when they can be hidden elsewhere, and second such functionality might be useful elsewhere and there is no better way to expose it in reusable fashion then by putting it into the command. So Magnolia 4.3 also comes with 2 new commands for flushing either whole cache or specific keys, based on content UUIDs. This way if someone want to cache say output of dynamic queries and flush that content from the cache every 30 minutes or so, they can just configure scheduled job to invoke the command periodically without need to write a single line of code.

 Just to describe various attributes you can see from the MBean:

• Bypasses - Count of all the requests deemed as not cacheable by the current cache policy
• Puts - Count of all the requests deemed as cacheable by the very same cache policy
• Hits - Count of all the requests already found in the cache
• All - Just list of the above. Since it is possible to configure custom policies and custom behaviors, this value is here to show such extra behaviors (if any)
• CachedKeysCount - Count of all the cache keys associated with some UUID (not all the cache entries need to have such association)
• CachedUUIDsCount - Count of all unique UUIDs associated with some existing cache key. The difference between this number and the one above gives an indication of how many entries there might be originated from single page
• DomainAccesses - Amount of requests coming from different domains
• Flushes - Number of times cache was flushed since the server restart
• StartCalls - Number of times the cache module have been started since the last server restart
• StopCalls - Number of times the cache module have been stopped since the last server restart

In 2009 I attended the UCLA Clinical and Translational Science Institute (CTSI) Enterprise-Level Research Informatics in the Health Sciences Symposium at the California NanoSystems Institute (CNSI). There were many speakers there from institutions like Johns Hopkins University, Stanford University School of Medicine, as well as Harvard University School of Medicine. However, the presentation that caught my ear the most was that of Isaac S. (Zak) Kohane, MD - co-Director of the i2b2 (Informatics for Integrating Biology and the Bedside) project based at Partners HealthCare System in Boston, Massachusetts. The websites states:

"The key challenge that i2b2 is designed to address is that of creating a comprehensive software and methodological framework to enable clinical researchers to accelerate the translation of genomic and “traditional” clinical findings into novel diagnostics, prognostics, and therapeutics. Conversely, it provides a collaborative organizational and software infrastructure to allow basic researchers to leverage insights arising from clinical studies."

Written in Java, i2b2's Hive and associated Workbench are great examples of concepts like persistent storage and service wrappers. Described as a "hive" of interoperable cells, web services couple these cells and allow intercommunication (yes, via SOAP). Of course, all these functional cells can be separated from each other, yet use the same persistent storage without ever being aware of what data another cell is accessing, or allow shared use of the data interactively. It all depends on what permissions the "bee" - the user - has, each user login allowing predefined visibility to parts of, or to the whole, of the hive.

Developed specifically to answer a need in clinical research, the model offered by i2b2 also reminds us of the power of modular and permissions-based applications architecture, and access by users to vast amounts of data. i2b2 can connect multiple persistent data sources and use this pool to inform the functional cells, thus providing a larger subject sampling for cases in clinical studies, though the implementation could be molded for other purposes, such as marketing constructs for surveys, or other polling data analysis.

i2b2 is another great example of the power and diversity of the Java programming language, and it is open source (i2b2 Open Source License) to boot! I suspect this application will find a life outside of the health sciences field as open source Java hackers mold it to their own needs.

I don't have the time I used to for reading stacks of magazines and journals. However, thanks to the UCLA kitchen magazine pile, I happened to pick up an issue of the IBM Systems Journal, Real-Time and Event-Based Systems, Volume 47, Number 2, 2008. I'd been thinking about real-time systems lately since so many production systems are still surviving on an ancient model of two non-load-balanced, manual failover application servers. A recent race to bring a standby server up-to-date with code from the primary server in time for a forced failover brought me to my wit's end with this outdated architecture.

Now this all may be a bit deceiving. Real-time isn't necessarily a guarantee of persistent service from an architecture standpoint. A server is a server, real-time or not, and requires redundancy planned for it. But as I read an article in the journal by D. Hart, J. Stultz, and T. Ts’o, "Real-time Linux in real time", some ideas started to percolate regarding my Java application servers and the problem of persistent service. Not only did it discuss real-time Linux, a topic close to my heart, but the latest IBM offering, WebSphere Real Time (WRT), a real-time Java virtual machine (JVM) utilizing Metronome, a real-time garbage collector created by the IBM Research Division.

If I had my way, all my servers would be enterprise real-time OS-based application servers. I do run WebSphere, but would there be a major difference if I took our WebSphere/SUSE model and switched to a WRT/RTLinux? From a cost perspective, probably; yet the cost in loss-of-service from latency issues on the old architecture compared to the new would likely offset that, perhaps making it nominal or even saving cost. An RT JVM comes with issues of its own, but with the right training, the same engineers that handle the WebSphere/SUSE combination could feasibly handle the WRT/RTLinux combination. This is all assuming the RTLinux described by IBM's paper sees a full production-ready release, of course. Imagine that! Real-time Linux with real-time Java. Now, all we'd need is a multicast cluster of redundant systems spread across two or three networks to completely eliminate downtime.

I have my eye on WRT now because this opens up a few areas of question, namely how to code in real-time (or maybe more accurately, code with "real-time awareness") and how these systems change the way we'll deploy our code. All those Ant scripts out there comprising a framework of deployment functions, from source collection to build to release to test, will likely have to be revised to attack systems that exist in real-time and deploy code to them while retaining the same low-latency model the users expect. Invisible deployments? That will be the day. At least the promise of meeting every service level agreement and never facing loss of life is a little closer.

After a long hiatus from UCLA, Duke returned in the form of the UCLA Java User Group. I'm not sure how long it has really been since a Java User Group haunted the halls of UCLA. Some say it's been between five and ten years which, in Java terms, is quite some time. I found a great archived news item here at UCLA about the UCLA Java Campus from 2000. I like that idea. Maybe we can see it come around again...

However long it's been, I was proud to announce the UCLA JUG was online in May 2008. Membership started building slowly after the announcement went out to UCLA campus and affiliates. Here's the blurb written to announce the group:

"Java technology is widely deployed at UCLA. The UCLA Java User Group brings together the campus Java community to share experiences and promote best practices for the effective use of Java technology. It does so through meetings, presentations by experts from on and off campus, open-environment "code on the lawn" sessions and more. Faculty, students and staff are all welcome and encouraged to actively participate. Whatever the venue, members can expect their technical boundaries to be pushed and their knowledge of the Java language expanded, and to be challenged to create and innovate."

I think that says it all, honestly. My thanks to Kent Wada at UCLA for reviewing the language over the week before I sent it out and whittling my original epic text to a blurb. Oliver Li did a great job bringing in speakers during 2009, and now I'm also working on gathering speakers and setting an agenda for the rest of 2010. Since this group is limited to the UCLA community, it has taken a more research-oriented tone. We do have plenty of business enterprise members as well (I'm a Project Manager working with J2EE) so there will be a benefit to seeing real-world problems discussed by students and staff alike with a fresh outlook.

To everyone that helped in the execution of the group and as a research resource, many thanks!

Almost three years, now! Now, let's get to coding...

UCLA's Visualization Portal is truly remarkable. Equally remarkable is one of its primary developers and managers, Kejian Jin. Among his projects are vrNav, a 3D VR simulation program, and the UCLA Grid Portal. I had the pleasure of meeting with Kejian and Jackie Reynolds (Director of Campus Services) some time ago at UCLA's Visualization Portal to discuss his acting as co-chair of the UCLA JUG. The Portal was the perfect example of why I knew he'd make an excellent co-chair.

Java is the core component of the VR GUI used by the Visualization Portal. As described by the UCLA website for the portal:

"The Visualization Portal and facilities like it are commonly referred to as virtual reality rooms or immersive environments. The term 'virtual reality' was coined in 1989 by Jaron Lanier (founder of VPL Research) and referred to the ability to immerse a person in an artificial, computer-generated, three-dimensional world. A variety of methods of achieving immersion have been developed, each with inherent strengths and weaknesses. The spherical screen used in the Portal offers a good balance between immersion (it provides a moderate amount) and visibility for a larger audience (up to 45 people)."

Upon leaving the meeting at the Visualization Portal, I had a slew of ideas for future meetings and ideal presentations. Jaron Lanier came to mind, of course, as did Project Looking Glass and Second Life. I'm getting ahead of myself, but there is obviously more to come...

In the Overview and Frequently Asked Questions for the Developer Community located on the Oracle website, there rests the following statement (as of Feb. 23, 2010):

"Yes, Oracle will indeed enthusiastically support the Java User Groups, OpenSolaris User Groups, and other Sun-related user group communities (including the Java Champions), just as Oracle actively supports hundreds of product-oriented user groups today. We will be reaching out to these groups soon."

Having seen the incredible support and community bonds present before Oracle took ownership of Sun Microsystems, yes, I was sad to see many key members of that community move on to other companies, and some to other technologies. Those who were in the JUG world for years and many who founded the User Groups initiative through Sun took a dim view of the merger. Others simply woke up the next morning and said "business as usual".

Watching the JUG Leaders lists, I see sadness at the demise of Kenai (though Java.net will move to Kenai as its backend) and that has translated to some badmouthing of Oracle. Now, I think the question among many is "how long" before Oracle reaches out to the UGs and makes an effort at solidifying their roadmap for Java? Do we really need to wait for Oracle to reach out to us, and to the JUGs in particular? I say "no".

Maybe I'm getting old and I no longer have the hair-trigger reaction I once had when it comes to technology, but who are we kidding? There's a reason all these great minds got together and started the first JUGs. And the latest JUGs, and all those in between; it's Java. Is Java disappearing? Do we pack up our Duke gear and trudge off because we may not get the freebies we once did, or because our beloved blue and grey Sun colors are replaced by Oracle red and grey? Of course not. Nothing's changed, really. The code is still the code. And the support system for Java out there is so vast, beyond Sun and Oracle, and it's not going away anytime soon.

So, I for one am going to breathe, crack my knuckles, and plan the next speaker for my UCLA JUG with my co-chairs as if nothing has happened. And yes, we're supporting Oracle fully. We can't predict the future any better than the next geek, and as long as we still believe in the code that brought us together, I see no reason we even need to.

Cheers.

One of the areas I'm keen to improve in the next version of JAX-RS is link creation. JAX-RS already offers UriBuilder but I think an annotation driven approach could save a lot of repetitive coding.

I've been experimenting with a couple of annotations that I think would be useful and I just checked in an experimental extension that partially implements what I have in mind. Suppose you have a resource like this:

@Path{"widgets"}
public class WidgetsResource {
  ...
}

and you want to include a URI to this resource in a representation. Using the new extension you can just annotate a field in your representation class like this:

@Link(resource=WidgetsResource.class)
URI link;

and then Jersey will build the appropriate URI and inject it into the representation before the representation is serialized by a message body writer.

If the URI template contains parameters, their values are obtained by looking for a bean property or field by the same name in the representation. E.g. consider the following representation class:

public class WidgetRepresentation {
  @Link("widgets/{widgetId}")
  URI link;
  
  String getWidgetId() {...}
}

After processing by the extension, if the getWidgetId method returned "abc123", the value of the link field would be /context/widgets/abc123 where context is the deployment context.

The optional style property of the @Link annotation can be used to select between absolute URIs, absolute path and relative path depending on requirements.

Using the Extension

In order to try out the extension you have to:

• Declare a dependency on the new jersey-server-linking module which is available in Jersey trunk under the experimental directory.
• Install the response filter in your application using an init-param in the web.xml like this:

  <servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
      <init-param>
          <param-name>com.sun.jersey.config.property.packages</param-name>
          <param-value>your application packages here</param-value>
      </init-param>
      <init-param>
          <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
          <param-value>com.sun.jersey.server.linking.LinkFilter</param-value>
      </init-param>
      <load-on-startup>1</load-on-startup>
  </servlet>

Next Steps

The Javadoc of the @Link annotation describes a couple of things that I plan to implement next:

• Support for the @Binding annotation already sketched out in the code. This will allow the values of template parameters to be pulled from alternate sources including differently named properties of the representation and resource.
• Support for EL expressions in link templates. This will allow a little more expressivity for templates that don't already exist as values of @Path annotations.

Entry posted to my new blog.