math geek with no social life, Code Samples: Riemann-Siegel formula

Java implementation of the Riemann-Siegel Formula used to find non-trivial zeros of the Riemann Zeta Function

import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;


public class RiemannSiegel {

  private static final double twopi = 2.0 * StrictMath.PI;
  
  private RiemannSiegel () {
    // prevent instantiation
  }
  
  /**
   * Reimann-Siegel Z(t) function with additional parameter
   * for number of R terms to add
   * @param t
   * @param r
   * @return
   */
  public static double Z (double t, int r) {
    
    // t/2pi^1/2
    double t2 = StrictMath.sqrt(t/twopi);
    double N = functions.fabs(t2);
    double p = t2 - N;
    int k = 0;
    double R = 0.0;
    double tt = theta(t);
    
    double sum = 0.0;
    for (int n = 1; n <= N; n++) {
      sum += 
        (StrictMath.pow(n, -0.5) * 
            StrictMath.cos(tt - (t * StrictMath.log(n))));
    }
    sum = 2.0 * sum;
    // add remainder R here
    double piot = StrictMath.PI/t;
    while (k <= r) { 
      R = R + C(k,2.0*p-1.0) 
        * StrictMath.pow(2.0 * piot, 
            ((double) k)*0.5); 
      ++k; /* */ 
    } /* */ 
    R = functions.even((int) N-1) * StrictMath.pow(2.0 * StrictMath.PI / t,0.25) * R; /* */
    
    return sum + R;
  }
  
  /**
   * C terms for Riemann-Siegel
   * coefficients of remainder terms
   * @param n
   * @param z
   * @return
   */
  public static double C (int n, double z) {
    if (n==0) 
      return(.38268343236508977173 * StrictMath.pow(z, 0.0) 
      +.43724046807752044936 * StrictMath.pow(z, 2.0) 
      +.13237657548034352332 * StrictMath.pow(z, 4.0) 
      -.01360502604767418865 * StrictMath.pow(z, 6.0) 
      -.01356762197010358089 * StrictMath.pow(z, 8.0) 
      -.00162372532314446528 * StrictMath.pow(z,10.0) 
      +.00029705353733379691 * StrictMath.pow(z,12.0) 
      +.00007943300879521470 * StrictMath.pow(z,14.0) 
      +.00000046556124614505 * StrictMath.pow(z,16.0) 
      -.00000143272516309551 * StrictMath.pow(z,18.0) 
      -.00000010354847112313 * StrictMath.pow(z,20.0) 
      +.00000001235792708386 * StrictMath.pow(z,22.0) 
      +.00000000178810838580 * StrictMath.pow(z,24.0) 
      -.00000000003391414390 * StrictMath.pow(z,26.0) 
      -.00000000001632663390 * StrictMath.pow(z,28.0) 
      -.00000000000037851093 * StrictMath.pow(z,30.0) 
      +.00000000000009327423 * StrictMath.pow(z,32.0) 
      +.00000000000000522184 * StrictMath.pow(z,34.0) 
      -.00000000000000033507 * StrictMath.pow(z,36.0) 
      -.00000000000000003412 * StrictMath.pow(z,38.0)
      +.00000000000000000058 * StrictMath.pow(z,40.0) 
      +.00000000000000000015 * StrictMath.pow(z,42.0)); 
    else if (n==1) 
      return(-.02682510262837534703 * StrictMath.pow(z, 1.0) 
      +.01378477342635185305 * StrictMath.pow(z, 3.0) 
      +.03849125048223508223 * StrictMath.pow(z, 5.0) 
      +.00987106629906207647 * StrictMath.pow(z, 7.0) 
      -.00331075976085840433 * StrictMath.pow(z, 9.0) 
      -.00146478085779541508 * StrictMath.pow(z,11.0) 
      -.00001320794062487696 * StrictMath.pow(z,13.0) 
      +.00005922748701847141 * StrictMath.pow(z,15.0) 
      +.00000598024258537345 * StrictMath.pow(z,17.0) 
      -.00000096413224561698 * StrictMath.pow(z,19.0) 
      -.00000018334733722714 * StrictMath.pow(z,21.0) 
      +.00000000446708756272 * StrictMath.pow(z,23.0) 
      +.00000000270963508218 * StrictMath.pow(z,25.0) 
      +.00000000007785288654 * StrictMath.pow(z,27.0)
      -.00000000002343762601 * StrictMath.pow(z,29.0) 
      -.00000000000158301728 * StrictMath.pow(z,31.0) 
      +.00000000000012119942 * StrictMath.pow(z,33.0) 
      +.00000000000001458378 * StrictMath.pow(z,35.0) 
      -.00000000000000028786 * StrictMath.pow(z,37.0) 
      -.00000000000000008663 * StrictMath.pow(z,39.0) 
      -.00000000000000000084 * StrictMath.pow(z,41.0) 
      +.00000000000000000036 * StrictMath.pow(z,43.0) 
      +.00000000000000000001 * StrictMath.pow(z,45.0)); 
    else if (n==2) 
      return(+.00518854283029316849 * StrictMath.pow(z, 0.0) 
      +.00030946583880634746 * StrictMath.pow(z, 2.0) 
      -.01133594107822937338 * StrictMath.pow(z, 4.0) 
      +.00223304574195814477 * StrictMath.pow(z, 6.0) 
      +.00519663740886233021 * StrictMath.pow(z, 8.0) 
      +.00034399144076208337 * StrictMath.pow(z,10.0) 
      -.00059106484274705828 * StrictMath.pow(z,12.0) 
      -.00010229972547935857 * StrictMath.pow(z,14.0) 
      +.00002088839221699276 * StrictMath.pow(z,16.0) 
      +.00000592766549309654 * StrictMath.pow(z,18.0) 
      -.00000016423838362436 * StrictMath.pow(z,20.0) 
      -.00000015161199700941 * StrictMath.pow(z,22.0) 
      -.00000000590780369821 * StrictMath.pow(z,24.0) 
      +.00000000209115148595 * StrictMath.pow(z,26.0) 
      +.00000000017815649583 * StrictMath.pow(z,28.0) 
      -.00000000001616407246 * StrictMath.pow(z,30.0) 
      -.00000000000238069625 * StrictMath.pow(z,32.0) 
      +.00000000000005398265 * StrictMath.pow(z,34.0) 
      +.00000000000001975014 * StrictMath.pow(z,36.0) 
      +.00000000000000023333 * StrictMath.pow(z,38.0) 
      -.00000000000000011188 * StrictMath.pow(z,40.0) 
      -.00000000000000000416 * StrictMath.pow(z,42.0) 
      +.00000000000000000044 * StrictMath.pow(z,44.0) 
      +.00000000000000000003 * StrictMath.pow(z,46.0)); 
    else if (n==3) 
      return(-.00133971609071945690 * StrictMath.pow(z, 1.0) 
      +.00374421513637939370 * StrictMath.pow(z, 3.0) 
      -.00133031789193214681 * StrictMath.pow(z, 5.0) 
      -.00226546607654717871 * StrictMath.pow(z, 7.0) 
      +.00095484999985067304 * StrictMath.pow(z, 9.0) 
      +.00060100384589636039 * StrictMath.pow(z,11.0) 
      -.00010128858286776622 * StrictMath.pow(z,13.0) 
      -.00006865733449299826 * StrictMath.pow(z,15.0) 
      +.00000059853667915386 * StrictMath.pow(z,17.0) 
      +.00000333165985123995 * StrictMath.pow(z,19.0)
      +.00000021919289102435 * StrictMath.pow(z,21.0) 
      -.00000007890884245681 * StrictMath.pow(z,23.0) 
      -.00000000941468508130 * StrictMath.pow(z,25.0) 
      +.00000000095701162109 * StrictMath.pow(z,27.0) 
      +.00000000018763137453 * StrictMath.pow(z,29.0) 
      -.00000000000443783768 * StrictMath.pow(z,31.0) 
      -.00000000000224267385 * StrictMath.pow(z,33.0) 
      -.00000000000003627687 * StrictMath.pow(z,35.0) 
      +.00000000000001763981 * StrictMath.pow(z,37.0) 
      +.00000000000000079608 * StrictMath.pow(z,39.0) 
      -.00000000000000009420 * StrictMath.pow(z,41.0) 
      -.00000000000000000713 * StrictMath.pow(z,43.0) 
      +.00000000000000000033 * StrictMath.pow(z,45.0) 
      +.00000000000000000004 * StrictMath.pow(z,47.0)); 
    else 
      return(+.00046483389361763382 * StrictMath.pow(z, 0.0) 
      -.00100566073653404708 * StrictMath.pow(z, 2.0) 
      +.00024044856573725793 * StrictMath.pow(z, 4.0) 
      +.00102830861497023219 * StrictMath.pow(z, 6.0) 
      -.00076578610717556442 * StrictMath.pow(z, 8.0) 
      -.00020365286803084818 * StrictMath.pow(z,10.0) 
      +.00023212290491068728 * StrictMath.pow(z,12.0) 
      +.00003260214424386520 * StrictMath.pow(z,14.0) 
      -.00002557906251794953 * StrictMath.pow(z,16.0) 
      -.00000410746443891574 * StrictMath.pow(z,18.0) 
      +.00000117811136403713 * StrictMath.pow(z,20.0) 
      +.00000024456561422485 * StrictMath.pow(z,22.0) 
      -.00000002391582476734 * StrictMath.pow(z,24.0) 
      -.00000000750521420704 * StrictMath.pow(z,26.0) 
      +.00000000013312279416 * StrictMath.pow(z,28.0) 
      +.00000000013440626754 * StrictMath.pow(z,30.0) 
      +.00000000000351377004 * StrictMath.pow(z,32.0) 
      -.00000000000151915445 * StrictMath.pow(z,34.0) 
      -.00000000000008915418 * StrictMath.pow(z,36.0) 
      +.00000000000001119589 * StrictMath.pow(z,38.0) 
      +.00000000000000105160 * StrictMath.pow(z,40.0) 
      -.00000000000000005179 * StrictMath.pow(z,42.0) 
      -.00000000000000000807 * StrictMath.pow(z,44.0) 
      +.00000000000000000011 * StrictMath.pow(z,46.0) 
      +.00000000000000000004 * StrictMath.pow(z,48.0));
  }
  
  /**
   * Riemann-Siegel theta function
   * theta(t) approximation using Stirling series
   * @param t
   * @return
   */
  public static double theta (double t) {
    return (t/2.0 * StrictMath.log(t/2.0/StrictMath.PI) - t/2.0
        - StrictMath.PI/8.0 + 1.0/48.0/t + 7.0/5760.0/t/t/t);
  }

}

ref:

H. M. Edwards, Riemann’s Zeta Function, Academic Press, 1974.

E. C. Titchmarsh, The theory of the Riemann Zeta-function, Oxford Science publications, second edition, revised by D. R. Heath-Brown (1986).

ZetaGrid project code

via cab1729.tumblr.com

Code Samples

Core Java - Models

DirectedWeightedGraph.java

Edge.java

GraphSearch.java

TestGraphSearch.java  (JUnit Test Case)

Core Java - Math Functions

functions.java

RiemannSiegel.java

gram.java

Complex.java

ComplexFunctions.java

JavaEE

GetEmpInfoRS.java  - RESTful web service with JAXB example

GetEmpInfo.java  - session bean with SOAP service interface

GetEmpInfoJSPPortlet.java  - JSP portlet using eclipse generated web service client

GetEmpInfoServlet.java  - servlet interface to session bean

Employee.java  - JPA entity bean

via http://dl.dropbox.com/u/10988984/code/index.html

Hilbert’s 10.5th Problem

via rjlipton.wordpress.com

Hilbert’s Tenth Problem (HTP) is the question raised by David Hilbert at his famous 1900 Paris lecture on whether or not there is an algorithm to decide whether a Diophantine equation has a solution over the integers:

Java Code examples - Bernoulli polynomial function

 /**
   * return nth Bernoulli polynomial of x using Fourier expansion
   * ref: Abramowitz & Stegun 23.1.16 pp 805
   * @param n
   * @param x
   * @return
   */
  public static double BernoulliP (int n, double x)
  {
    // for n>1, 1>=x>=0
    // for n=1, 1>x>0
    
    // for x=0 return the nth Bernoulli number
    if (x==0.0) {
      return BernoulliB(n);
    }
        
    double K = -2*(factorial(n))/StrictMath.pow((2*StrictMath.PI), n);
    
    double S = 0.0;
    for (int k=1; k<100001; k++)
    {
      S += 
        StrictMath.cos((2*StrictMath.PI*k*x)-(.5*StrictMath.PI*n))/
          StrictMath.pow(k, n);
    }
    
    return K*S;
  }

Extend Java EE containers with cloud characteristics

via ibm.com

"The Java Enterprise Edition (JEE) architecture is based on components with features that effectively manage application transactions and statefulness, multi-threading, and resource pooling. A JEE application is easier to write even with complex requirements since the business logic is organized in reusable components and the server provides the underlying services — in the form of a container — for each component type."

via ibm.com

Brewer's CAP Theorem

Brewer's CAP Theorem

The kool aid Amazon and Ebay have been drinking

By Julian Browne on January 11, 2009. Filed Under architecture, business, strategy

On Friday 4th June 1976, in a small upstairs room away from the main concert auditorium, the Sex Pistols kicked off their first gig at Manchester's Lesser Free Trade Hall. There's some confusion as to who exactly was there in the audience that night, partly because there was another concert just six weeks later, but mostly because it's considered to be a gig that changed western music culture forever. So iconic and important has that appearance become that David Nolan wrote a book, I Swear I Was There: The Gig That Changed the World, investigating just whose claim to have been present was justified. Because the 4th of June is generally considered to be the genesis of punk rock⁶.

Prior to this (in fact since around 1971) there had been a number of protopunk bands, such as the New York Dolls and the Velvet Underground, but it was this one set by the Sex Pistols that in music folklore started the revolution that set in motion the driving guitars of the Buzzcocks, the plaintive wailing of The Smiths, the eclectic syncopations of the The Fall, the rising majesty of Joy Division and Simply Red (I guess you can't have everything).

Wednesday 19th July 2000, may not go down in popular culture with quite the same magnitude but it's had a similar impact on internet scale business as the Sex Pistols did on music a quarter of a century earlier, for that was the keynote speech by Eric Brewer at the ACM Symposium on the Principles of Distributed Computing (PODC).

The Sex Pistols had shown that barely-constrained fury was more important to their contemporaries than art-school structuralism, giving anyone with three chords and something to say permission to start a band. Eric Brewer, in what became known as Brewer's Conjecture, said that as applications become more web-based we should stop worrying about data consistency, because if we want high availability in these new distributed applications, then guaranteed consistency of data is something we cannot have, thus giving anyone with three servers and a keen eye for customer experience permission to start an internet scale business. Disciples of Brewer (present that day or later converts) include the likes of Amazon, EBay, and Twitter.

Two years later, in 2002, Seth Gilbert and Nancy Lynch of MIT, formally proved Brewer to be correct and thus Brewer's Theorem was born.

Brewer's (CAP) Theorem

So what exactly is Brewer's Theorem, and why does it warrant comparison with a 1976 punk gig in Manchester?

Brewer's 2000 talk was based on his theoretical work at UC Berkley and observations from running Inktomi, though Brewer and others were talking about trade-off decisions that need to be made in highly scalable systems years before that (e.g. "Cluster-Based Scalable Network Services" from SOSP in 1997 and "Harvest, yield, and scalable tolerant systems" in 1999) so the contents of the presentation weren't new and, like many of these ideas, they were the work of many smart people (as I am sure Brewer himself would be quick to point out).

What he said was there are three core systemic requirements that exist in a special relationship when it comes to designing and deploying applications in a distributed environment (he was talking specifically about the web but so many corporate businesses are multi-site/multi-country these days that the effects could equally apply to your data-centre/LAN/WAN arrangement).

The three requirements are: Consistency, Availability and Partition Tolerance, giving Brewer's Theorem its other name - CAP.

To give these some real-world meaning let's use a simple example: you want to buy a copy of Tolstoy's War & Peace to read on a particularly long vacation you're starting tomorrow. Your favourite web bookstore has one copy left in stock. You do your search, check that it can be delivered before you leave and add it to your basket. You remember that you need a few other things so you browse the site for a bit (have you ever bought just one thing online? Gotta maximise the parcel dollar). While you're reading the customer reviews of a suntan lotion product, someone, somewhere else in the country, arrives at the site, adds a copy to their basket and goes right to the checkout process (they need an urgent fix for a wobbly table with one leg much shorter than the others).

• Consistency

  A service that is consistent operates fully or not at all. Gilbert and Lynch use the word "atomic" instead of consistent in their proof, which makes more sense technically because, strictly speaking, consistent is the C in ACID as applied to the ideal properties of database transactions and means that data will never be persisted that breaks certain pre-set constraints. But if you consider it a preset constraint of distributed systems that multiple values for the same piece of data are not allowed then I think the leak in the abstraction is plugged (plus, if Brewer had used the word atomic, it would be called the AAP theorem and we'd all be in hospital every time we tried to pronounce it).

  In the book buying example you can add the book to your basket, or fail. Purchase it, or not. You can't half-add or half-purchase a book. There's one copy in stock and only one person will get it the next day. If both customers can continue through the order process to the end (i.e. make payment) the lack of consistency between what's in stock and what's in the system will cause an issue. Maybe not a huge issue in this case - someone's either going to be bored on vacation or spilling soup - but scale this up to thousands of inconsistencies and give them a monetary value (e.g. trades on a financial exchange where there's an inconsistency between what you think you've bought or sold and what the exchange record states) and it's a huge issue.

  We might solve consistency by utilising a database. At the correct moment in the book order process the number of War and Peace books-in-stock is decremented by one. When the other customer reaches this point, the cupboard is bare and the order process will alert them to this without continuing to payment. The first operates fully, the second not at all.

  Databases are great at this because they focus on ACID properties and give us Consistency by also giving us Isolation, so that when Customer One is reducing books-in-stock by one, and simultaneously increasing books-in-basket by one, any intermediate states are isolated from Customer Two, who has to wait a few milliseconds while the data store is made consistent.

• Availability

  Availability means just that - the service is available (to operate fully or not as above). When you buy the book you want to get a response, not some browser message about the web site being uncommunicative. Gilbert & Lynch in their proof of CAP Theorem make the good point that availability most often deserts you when you need it most - sites tend to go down at busy periods precisely because they are busy. A service that's available but not being accessed is of no benefit to anyone.

• Partition Tolerance

  If your application and database runs on one box then (ignoring scale issues and assuming all your code is perfect) your server acts as a kind of atomic processor in that it either works or doesn't (i.e. if it has crashed it's not available, but it won't cause data inconsistency either).

  Once you start to spread data and logic around different nodes then there's a risk of partitions forming. A partition happens when, say, a network cable gets chopped, and Node A can no longer communicate with Node B. With the kind of distribution capabilities the web provides, temporary partitions are a relatively common occurrence and, as I said earlier, they're also not that rare inside global corporations with multiple data centres.

  Gilbert & Lynch defined partition tolerance as:

  No set of failures less than total network failure is allowed to cause the system to respond incorrectly

  and noted Brewer's comment that a one-node partition is equivalent to a server crash, because if nothing can connect to it, it may as well not be there.

The Significance of the Theorem

CAP Theorem comes to life as an application scales. At low transactional volumes, small latencies to allow databases to get consistent has no noticeable affect on either overall performance or the user experience. Any load distribution you do undertake, therefore, is likely to be for systems management reasons.

But as activity increases, these pinch-points in throughput will begin limit growth and create errors. It's one thing having to wait for a web page to come back with a response and another experience altogether to enter your credit card details to be met with "HTTP 500 java.lang.schrodinger.purchasingerror" and wonder whether you've just paid for something you won't get, not paid at all, or maybe the error is immaterial to this transaction. Who knows? You are unlikely to continue, more likely to shop elsewhere, and very likely to phone your bank.

Either way this is not good for business. Amazon claim that just an extra one tenth of a second on their response times will cost them 1% in sales. Google said they noticed that just a half a second increase in latency caused traffic to drop by a fifth.

I've written a little about scalability before, so won't repeat all that here except to make two points: the first is that whilst addressing the problems of scale might be an architectural concern, the initial discussions are not. They are business decisions. I get very tired of hearing, from techies, that such-and-such an approach is not warranted because current activity volumes don't justify it. It's not that they're wrong; more often than not they're quite correct, it's that to limit scale from the outset is to implicitly make revenue decisions - a factor that should be made explicit during business analysis.

The second point is that once you embark on discussions around how to best scale your application the world falls broadly into two ideological camps: the database crowd and the non-database crowd.

The database crowd, unsurprisingly, like database technology and will tend to address scale by talking of things like optimistic locking and sharding, keeping the database at the heart of things.

The non-database crowd will tend to address scale by managing data outside of the database environment (avoiding the relational world) for as long as possible.

I think it's fair to say that the former group haven't taken to CAP Theorem with quite the same gusto as the latter (though they are talking about it). This is because if you have to drop one of consistency, availability, or partition tolerance, many opt to drop consistency which is the raison d'être of the database. The logic. no doubt, is that availability and partition-tolerance keep your money-making application alive, whereas inconsistency just feels like one of those things you can work around with clever design.

Like so much else in IT, it's not as black and white as this. Eric Brewer, on slide 13 of his PODC talk, when comparing ACID and it's informal counterpart BASE even says "I think it's a spectrum". And if you're interested in this as a topic (it's slightly outside of what I want to talk about here) you could do worse than start with a paper called "Design and Evaluation of a Continuous Consistency Model for Replicated Services" by Haifeng Yu and Amin Vahdat. Nobody should interpret CAP as implying the database is dead.

Where both sides agree though is that the answer to scale is distributed parallelisation not, as was once thought, supercomputer grunt. Eric Brewer's influence on the Network of Workstations projects of the mid-nineties led to the architectures that exposed CAP theorem, because as he says in another presentation on Inktomi and the Internet Bubble the answer has always been processors working in parallel:

If they're not working in parallel you have no chance to get the problem done in a reasonable amount of time. This is a lot like anything else. If you have a really big job to do you get lots of people to do it. So if you are building a bridge you have lots of construction workers. That's parallel processing also. So a lot of this will end up being "how do we mix parallel processing and the internet?"

The Proof in Pictures

Here's a simplified proof, in pictures because I find it much easier to understand that way. I've mostly used the same terms as Gilbert and Lynch so that this ties up with their paper.

The diagram above shows two nodes in a network, N₁ and N₂. They both share a piece of data V (how many physical copies of War and Peace are in stock), which has a value V₀. Running on N₁ is an algorithm called A which we can consider to be safe, bug free, predictable and reliable. Running on N₂ is a similar algorithm called B. In this experiment, A writes new values of V and B reads values of V.

In a sunny-day scenario this is what happens: (1) First A writes a new value of V, which we'll call V₁. (2) Then a message (M) is passed from N₁ to N₂ which updates the copy of V there. (3) Now any read by B of V will return V₁.

If the network partitions (that is messages from N₁ to N₂ are not delivered) then N₂ contains an inconsistent value of V when step (3) occurs.

Hopefully that seems fairly obvious. Scale this is up to even a few hundred transactions and it becomes a major issue. If M is an asynchronous message then N₁ has no way of knowing whether N₂ gets the message. Even with guaranteed delivery of M, N₁ has no way of knowing if a message is delayed by a partition event or something failing in N₂. Making M synchronous doesn't help because that treats the write by A on N₁ and the update event from N₁ to N₂ as an atomic operation, which gives us the same latency issues we have already talked about (or worse). Gilbert and Lynch also prove, using a slight variation on this, that even in a partially-synchronous model (with ordered clocks on each node) atomicity cannot be guaranteed.

So what CAP tells us is that if we want A and B to be highly available (i.e. working with minimal latency) and we want our nodes N₁ to N_n (where n could be hundreds or even thousands) to remain tolerant of network partitions (lost messages, undeliverable messages, hardware outages, process failures) then sometimes we are going to get cases where some nodes think that V is V₀ (one copy of War and Peace in stock) and other nodes will think that V is V₁ (no copies of War and Peace in stock).

We'd really like everything to be structured, consistent and harmonious, like the music of a prog rock band from the early seventies, but what we are faced with is a little bit of punk-style anarchy. And actually, whilst it might scare our grandmothers, it's OK once you know this, because both can work together quite happily.

Let's quickly analyse this from a transactional perspective.

If we have a transaction (i.e. unit of work based around the persistent data item V) called α, then α₁ could be the write operation from before and α₂ could be the read. On a local system this would be easily be handled by a database with some simple locking, isolating any attempt to read in α₂ until α₁ completes safely. In the distributed model though, with nodes N₁ and N₂ to worry about, the intermediate synchronising message has also to complete. Unless we can control when α₂ happens, we can never guarantee it will see the same data values α₁ writes. All methods to add control (blocking, isolation, centralised management, etc) will impact either partition tolerance or the availability of α₁ (A) and/or α₂ (B).

Dealing with CAP

You've got a few choices when addressing the issues thrown up by CAP. The obvious ones are:

1. Drop Partition Tolerance

   If you want to run without partitions you have to stop them happening. One way to do this is to put everything (related to that transaction) on one machine, or in one atomically-failing unit like a rack. It's not 100% guaranteed because you can still have partial failures, but you're less likely to get partition-like side-effects. There are, of course, significant scaling limits to this.

2. Drop Availability

   This is the flip side of the drop-partition-tolerance coin. On encountering a partition event, affected services simply wait until data is consistent and therefore remain unavailable during that time. Controlling this could get fairly complex over many nodes, with re-available nodes needing logic to handle coming back online gracefully.

3. Drop Consistency

   Or, as Werner Vogels puts it, accept that things will become "Eventually Consistent" (updated Dec 2008). Vogels' article is well worth a read. He goes into a lot more detail on operational specifics than I do here.

   Lots of inconsistencies don't actually require as much work as you'd think (meaning continuous consistency is probably not something we need anyway). In my book order example if two orders are received for the one book that's in stock, the second just becomes a back-order. As long as the customer is told of this (and remember this is a rare case) everybody's probably happy.

4. The BASE Jump

   The notion of accepting eventual consistency is supported via an architectural approach known as BASE (Basically Available, Soft-state, Eventually consistent). BASE, as its name indicates, is the logical opposite of ACID, though it would be quite wrong to imply that any architecture should (or could) be based wholly on one or the other. This is an important point to remember, given our industry's habit of "oooh shiny" strategy adoption.

   And here I defer to Professor Brewer himself who emailed me some comments on this article, saying:

   the term "BASE" was first presented in the 1997 SOSP article that you cite. I came up with acronym with my students in their office earlier that year. I agree it is contrived a bit, but so is "ACID" -- much more than people realize, so we figured it was good enough. Jim Gray and I discussed these acronyms and he readily admitted that ACID was a stretch too -- the A and D have high overlap and the C is ill-defined at best. But the pair connotes the idea of a spectrum, which is one of the points of the PODC lecture as you correctly point out.

   Dan Pritchett of EBay has a nice presentation on BASE.

5. Design around it

   Guy Pardon, CTO of atomikos wrote an interesting post which he called "A CAP Solution (Proving Brewer Wrong)", suggesting an architectural approach that would deliver Consistency, Availability and Partition-tolerance, though with some caveats (notably that you don't get all three guaranteed in the same instant).

   It's worth a read as Guy eloquently represents an opposing view in this area.

Summary

That you can only guarantee two of Consistency, Availability and Partition Tolerance is real and evidenced by the most successful websites on the planet. If it works for them I see no reason why the same trade-offs shouldn't be considered in everyday design in corporate environments. If the business explicitly doesn't want to scale then fine, simpler solutions are available, but it's a conversation worth having. In any case these discussions will be about appropriate designs for specific operations, not the whole shebang. As Brewer said in his email "the only other thing I would add is that different parts of the same service can choose different points in the spectrum". Sometimes you absolutely need consistency whatever the scaling cost, because the risk of not having it is too great.

These days I'd go so far as to say that Amazon and EBay don't have a scalability problem. I think they had one and now they have the tools to address it. That's why they can freely talk about it. Any scaling they do now (given the size they already are) is really more of the same. Once you've scaled, your problems shift to those of operational maintenance, monitoring, rolling out software updates etc. - tough to solve, certainly, but nice to have when you've got those revenue streams coming in.

References

1. HP's take on CAP Theorem, a white paper entitled "There is no free lunch with distributed data"

2. Computer Science Notes on Distributed Transactions and Network Partitions from University of Sussex

3. Nice post by Jens Alfke on databases, scaling and Twitter.

4. Pat Helland's Microsoft paper on distributed transactions and SOA called Data on the Outside versus Data on the Inside, which he later related to CAP Theorem here

5. Another set of Computer Science course slides, this time from George Mason University in Virginia, on Distributed Software Systems and particularly CAP Theorem and the clash between ACID and BASE ideologies.

6. The 4th June 1976 is considered to be the birth of Punk Rock in the UK. Thanks to Charlie Dellacona for pointing out that the Ramones take credit for starting the movement in early 1974 in the US, though their official punk recordings are more or less contemporaneous.

7. Thanks to Hiroshi Yuki, a Japanese translation of this article is available.

8. Thanks to Daniel Cohen, a two part Hebrew translation of this article is available.

9. Thanks to Wang Qi, a Chinese translation of this article is available.

via julianbrowne.com

IBM Watson - How to build your own "Watson Jr." in your basement

via ibm.com

Having worked with the UIMA technology on several projects, I find this very cool.

Unix

Note: This wasn't written by me, but I touched up a bit of the English.

A UNIX wizard hears cries of torment from his apprentice's computer room where the apprentice is studying, and goes to investigate.

He finds the apprentice in obvious distress, nearly on the verge of tears. "What's the problem?" he asks. "Why did you cry out?"

"It's terrible using this system. I must use four editors each day to get my studies done, because not one of them does everything."

The wizard nods sagely, and asks, "And what would you propose that will solve this obvious dilemma?"

The student thinks carefully for several minutes, and his face then lights up in delight. Excitedly, he says, "Well, it's obvious. I will write the best editor ever. It will do everything that the existing four editors do, but do their jobs better, and faster. And because of my new editor, the world will be a better place."

The wizard quickly raises his hand and smacks the apprentice on the side of his head. The wizard is old and frail, and the apprentice isn't physically hurt, but is shocked by what has happened. He turns his head to face the wizard. "What have I done wrong?" he asks.

"Fool!" says the wizard. "Do you think I want to learn yet another editor?"

Immediately, the apprentice is enlightened.

Evan Martin, martine@danga.com

via neugierig.org

The Quantum Conspiracy: What Popularizers of QM Don't Want You to Know

LHC plans extra year for Higgs hunt : Nature News

Published online 10 December 2010 | Nature | doi:10.1038/news.2010.667

News

LHC plans extra year for Higgs hunt

Collider may run right through 2012 to find elusive particle.

Geoff Brumfiel

The extra year could be enough for the ATLAS detector to spot the Higgs particle.Claudia Marcelloni / CERN

Scientists are preparing to run the world's largest particle accelerator for an extra year in a bold bid to find the Higgs particle, part of the mechanism that is thought to endow other particles with mass.

If the plan is implemented, the Large Hadron Collider (LHC), located at CERN, near Geneva, Switzerland, will run until the end of 2012 — rather than 2011 — before entering a year-long shutdown for a major upgrade. Preparations for the extended run, which would see the 27-kilometre circular collider operating over three continuous years, are being finalized and are likely to be agreed to by CERN's management and council in January.

The decision comes with the belief that new discoveries may be just around the corner. "It would be a shame to stop," says Steve Myers, who is responsible for maintaining and upgrading the accelerator.

“It would be a shame to stop.”

Steve Myers
CERN

At stake is the particle many physicists see as the LHC's raison d'être: the Higgs. Theorists believe that the Higgs particle, together with its associated field, create a sort of cosmic molasses that endows other particles with mass. The mechanism is seen as a necessary extension to the 'standard model' of particle physics, which presently struggles to explain the origins of mass, and why some particles are heavy whereas others weigh nothing at all.

Higgs hunt

Initially, there were doubts about whether the LHC would be able to find the Higgs at the machine's current energies. Since a major accident in 2008, the LHC has been running at half its design energy. CERN managers had planned a 15-month pause in data collecting at the start of 2012, which would allow the machine to be upgraded to full power.

But now there is a growing consensus that the LHC will be able to cover most of the territory in which a standard Higgs particle might be found, even if it isn't upgraded. The best guess of most physicists is that the Higgs weighs somewhere between 114 and 600 gigaelectronvolts (10⁹ electronvolts), according to Sergio Bertolucci, CERN's director for research and computing. Its mass will determine how the particle decays — and how easily it can be detected.

“If we stop the machine with 3,000 people apiece in the experiments waiting for data, there is no way we could get home at night without having slashed tyres on our cars.”

Sergio Bertolucci
CERN

Paradoxically, a heavier Higgs might be easier to spot, Bertolucci says. That's because the heavy Higgs is likely to decay into pairs of rare, heavy particles known as W and Z bosons. Pairs of Ws or Zs would stand out sharply against the other particles created in LHC collisions. If the Higgs were lighter, its signature would blend into the background, making it much harder to detect and requiring physicists to amass and filter through data from months of collisions.

Despite the challenge, Bertolucci says that he is "very optimistic" that the LHC can cover most of the ground over which the Higgs is expected to be found. The machine has performed exceptionally well since the 2008 accident, and he thinks that it will be able to deliver the quantities of data needed over the 2011-12 running period. In addition, he says, managers think that they can collide particles at 8 teraelectronvolts (TeV; 10¹² electronvolts), up from the current 7-TeV energies, but still well below the machine's 14-TeV design energy.

Pushing it

Physicists working on the detectors built to find the Higgs are backing the plan. "My personal opinion is that we should put all the cards on the table," says David Francis, a physicist on the ATLAS detector, one of two giant detectors primarily designed to spot the elusive particle. "The experiments are going well, the accelerator is going well," adds Joe Incandela, a physicist at the University of California at Santa Barbara and deputy spokesman for the CMS detector, the second main detector for Higgs hunting. "Let's really push it to where we can get a meaningful data set to do lots of physics."

ADVERTISEMENT

'); document.write(''); } //-->

Bertolucci says that there are also political reasons to extend the run. The world's second most powerful accelerator, the Tevatron at Fermilab in Batavia, Illinois, is nipping at the LHC's heels, and if it continues to run, might beat the larger accelerator to the Higgs. Moreover, European plans for high-energy physics, as well as a global plan for a next-generation linear collider, are facing big decisions in the coming years and will be greatly influenced by the LHC's results.

But keeping the machine running for an extra year will have consequences. The delicate alignment of the LHC's superconducting magnets could suffer, requiring extra maintenance, says Myers. And additional computing resources will have to be found to handle the flood of extra data produced by the detectors.

Managers recognize the difficulties, but Bertolucci says they have strong incentives to extend the run: "If we stop the machine with 3,000 people apiece in the experiments waiting for data, there is no way we could get home at night without having slashed tyres on our cars."

The decision will be discussed at a meeting in the French town of Chamonix in late January, and should be finalized shortly after. 

Comments

If you find something abusive or inappropriate or which does not otherwise comply with our Terms or Community Guidelines, please select the relevant 'Report this comment' link.

Comments on this thread are vetted after posting.

• #16683

  Extending its run through 2012 will enable the LHC to play a timely role the predicted end of history on Dec. 21, 2012, as specified in the Mayan calender. Hopefully, we'll all laugh about this in 2013. There remain, however, disturbing and unrefuted scientific reasons to believe that CERN's in-house safety report was a PR whitewash and that the LHC, by potentially generating destructive strangelets and black holes, may be capable of causing global harm.

  International critics groups recently released two extensive and well-documented reports that undermine CERN's safety claims (at LHC-Concern.info and HeavyIonAlert.org). Given the acknowledged uncertainties and planetary stakes, it is unethical for the LHC experiments to proceed – particularly when there is no outside oversight or regulation.

  • Report this comment
  • 2010-12-10 11:42:42 PM
  • Posted by: Robert Houston
• #16690

  Why cannot we grasp that mass is more fundamental than pure energy (i.e. its mass is equal to zero)? Pure energies, for example photons, are the excitations of the Einstein spacetime – this spacetime has the MASS DENSITY NOT EQUAL TO ZERO. In the Everlasting Theory, the ground state of the Einstein spacetime is a gas composed of the non-rotating binary systems of neutrinos. Photons are the rotational energies of the binary systems. Vortices of energy transform into mass in the Einstein spacetime because rotational energy decreases local pressure in the Einstein spacetime – from it follows that the binary systems flow into regions with lower pressure. Such inflows increase local mass density so also mass – such is origin of the famous Einstein formula m=E/c^2. This formula is not valid for pure energy in truly empty volume. Photons cannot move in truly empty volume. Energy is an attribute of mass.
  The energy equation applied in the Special Theory of Relativity shows that even energy of a mathematical point moving with infinite speed IS EQUAL TO ZERO. Such points cannot lead to photons so also to mass. Higgs bosons are not in existence.

  • Report this comment
  • 2010-12-11 06:08:41 AM
  • Posted by: Sylwester Kornowski
• #16730

  Yes. The Higgs does exist.

  "Despite being rather majestic, Boltzmann's deep integration of probabilities into science was adopted by quantum mechanics. It was attacked from the start. The most basic line of attack at the time of Boltzmann's formulation of a statistical interpretation of the thermodynamics was his use of the never-before-seen-measured microscopic "atoms of molecules". Remember Boltzmann advanced his ideas some fifty years before the recognition of atoms by scientist such as Sir J.J. Thomson and Lord Rutherford. Boltzmann's critics were formidable, the finest physicists at the time. Ernst Zermelo, Ernst Mach, and Friedrich Wilhelm Ostwald attacked Boltzman relentlessly. Not because his viewed time as one-way, but because he had the audacity to suggest matter was made of atoms. This group became known as the Vienna Circle of "Logical positivists" and insisted that Science could be conducted only when all the objects of study were seen and understood. Their main objection to Boltzmann was that there was no means of verifying the existence of atoms and molecules, whose behavior lay at the foundation of Botzmann's probability-based version."
  -Into the Cool (Energy, Flow, Thermodynamics and Life)

  • Report this comment
  • 2010-12-13 09:20:12 AM
  • Posted by: Scott Humphrey
• #16743

  is it a race to find higs
  or is it about who is finding it?

  I mean whoever finds it it will cost tax payers a lot searching at 2 places at the world for the same thing.

  I'm guessing the who part is more important, instead of its energy value; because that's how prestigious people are. I hope they can prove tax payers wrong on it, as it has cost a lot so far.

  • Report this comment
  • 2010-12-13 11:43:56 AM
  • Posted by: Peter Boos
• #16744

  @ Robert

  Robert, in order for anyone to take this kind of thing seriously, you'd have to demonstrate why there is a difference between collisions created in a particle accelerator versus the much higher energy collisions that are caused by cosmic rays in the atmosphere every day.

  The LHC cannot ever hope to reach the energies of these kinds of collisions, and they've been going on for billions of years, without any catastrophes.

  This is why I roll my eyes when I hear about these 'dangers' of the LHC and other colliders.

  • Report this comment
  • 2010-12-13 11:55:25 AM
  • Posted by: John Cunningham
• #16784

  @John Cunningham,
  John,
  No catastrophic incidents? What about "our" own universe and perhaps the infinitive number of other universes that might have been created due to collisions of cosmic particles? Who knows? As space-time is infinitive, "catastrophes" happen forever simply said. When our lights go out one day, who cares about the cause?

  • Report this comment
  • 2010-12-14 10:55:22 AM
  • Posted by: nick bos
• #16792

  The recent evidence of fourth generation of quark and neutrinos virtually excludes the finding of unique Higgs boson. It's just wasting money of tax payers and risking their lives for nothing.

  • Report this comment
  • 2010-12-14 12:02:52 PM
  • Posted by: Zephir Zephir
• #16815

  The safety argument equating the LHC beams with "cosmic rays in the atmosphere," reprised above by John Cunningham, was admitted to be invalid by CERN itself. In fact, CERN's 2008 public safety report states that "collisions at the LHC differ from cosmic-ray collisions with astronomical bodies like the Earth..." (Par. 7). A crucial difference is velocity, for the magnetically focused head-on collisions at the LHC could slow some of the products to below escape velocity to plague us. Thus, in regard to neutral microscopic black holes, CERN admits: "Those produced by cosmic rays would pass harmlessly through the Earth into space, whereas those produced by the LHC could remain on Earth" (CERN, Safety of the LHC, 2008, Par. 7).

  The higher energies of some cosmic rays would result in a faster exit of the products, which may contribute to the dark matter of the galaxy. The cosmic ray argument was relocated in 2008 to dense neutron stars and white dwarfs, but flaws were found in the new argument as well (see Sec. 4 of paper by German astrophysicist Rainer Plaga at http://arxiv.org/abs/0808.1415v3 ). Moreover, astrophysicists believe that neutron stars consist in part of strange matter, the outcome critics fear for Earth from strangelet production at the LHC.

  • Report this comment
  • 2010-12-15 01:06:14 AM
  • Posted by: Robert Houston
• #16837

  Amazing, To put so,so much emotional energy into an outcome that tires and children would be slashed by others in the experiment of no experiment should someone embodied in the process should mis-step or default to a natural position of stasis within the compound to save their career.
  The particle "Understands" your positioning and the test has been completed,actually and the resultant flow is only to stage the next scenario by the system operator.
  Have fun boys,deciding who to deplete,and who to save for the final disposition.

  • Report this comment
  • 2010-12-15 08:48:19 PM
  • Posted by: Dr.Thomas Hughes

Add your own comment

This is a public forum. Please keep to our Community Guidelines. You can be controversial, but please don't get personal or offensive and do keep it brief. Remember our threads are for feedback and discussion - not for publishing papers, press releases or advertisements.

You need to be registered with Nature to leave a comment. Please log in or register as a new user. You will be re-directed back to this page.

• Log in / register

via nature.com

A physics pathway to the Riemann hypothesis

via arxiv4.library.cornell.edu

IBM Launches Five-Year Effort To Develop Quantum Computing | Popular Science

By Rebecca Boyle Posted 11.10.2010 at 2:10 pm 5 Comments

Quantum Computer Courtesy D-Wave

Ramped-up research efforts at IBM and other labs in the U.S. and Europe could lead to more powerful and more prevalent quantum computers in the near future.

IBM is breathing new life into a quantum computing research division at its Thomas J. Watson Research Center, reports New York Times. The computer giant has hired alumni from promising quantum computing programs at Yale and the University of California-Santa Barbara, both of which made quantum leaps in the past year using standard superconducting material.

Groups at both universities have been using rhenium or niobium on a semiconductor surface and cooling the system to absolute zero so that it exhibits quantum behavior. As the Times reports, the method relies on standard microelectronics manufacturing tech, which could make quantum computers easier and cheaper to make.

Related Articles

	Thirty-Year-Old Encryption Formula Can Resist Quantum-Computing Attacks That Defeat All Common Codes
	Quantum Computer Successfully Calculates Exact Energy of Molecular Hydrogen
	It's a Trap! Atom Corral Is a Major Step Toward Quantum Computing

Tags

Technology, Rebecca Boyle, computers, future of computers, IBM, quantum computer, quantum computing, quantum mechanics, qubits

The Santa Barbara researchers told the Times they believe they can double the computational power of their quantum computers by next year.

Quantum computing uses spooky action at a distance to conduct superfast calculations. Rather than using transistors to crunch the ones and zeroes of binary code, quantum computers store data as qubits, which can represent one and zero simultaneously. This superposition enables the computers to solve multiple problems at once, providing quick answers to tough questions. But observing a qubit strips it of this duality — you can only see one state at a time — so physicists must figure out how to extract data from a qubit without directly observing it. That’s where quantum entanglement comes in handy; two qubits can be connected by an invisible wave so that they share each other’s properties. You could then watch one qubit to see what its twin is computing.

None of this is simple, however; there are several competing methods for making the qubits, including laser-entangled ions, LED-powered entangled photons, and more. Google is working with a Canadian firm called D-Wave that has claimed 50-qubit computers, although skeptics have questioned that number. In most systems, the number of entangled qubits remains small, but Yale researchers believe they will increase in the next few years, the Times says.

Even better: with all this practice, physicists are getting a lot better at controlling quantum interactions. Their precision has increased a thousand-fold, one researcher said. That’s good news for anyone studying quantum mechanics.

[New York Times]

via popsci.com

IBM and Oracle change the game: A surprising alliance on OpenJDK

IBM and Oracle surprised many with their joint announcement on October 11 that they would join forces to advance the OpenJDK project. Most commentators agree that the move, which redefines the Java ecosystem by bringing together two of its biggest players, is good news for the future of Java technology.

More than 60 percent of respondents to a Javalobby poll (600 at last count) said that they believe IBM's decision to co-sponsor the OpenJDK project is good for Java technology. By deciding to focus joint development efforts on OpenJDK, the companies have effectively ended speculation about an IBM-led Java fork, and what it would mean for the multibillion dollar Java industry. With these worries off the table, said Mike Milinkovich of the Eclipse Foundation, "we can get back to innovation."

At the heart of the Oracle-IBM announcement are hard choices made by an industry in flux, from multinational corporations with long-term technology investment to smaller companies and individuals deciding whether to continue developing software on the Java platform. This article presents an overview of the key factors and players involved in, or affected by, the Oracle and IBM decision. At the end of each section, you'll find pointers to web resources that address aspects of the alliance.

OpenJDK as an Oracle-IBM project

OpenJDK is the open source reference implementation for the Java platform; it encompasses Java SE, the Java language, the JDK, and the JRE. OpenJDK specification requests are subject to vote by the Java Community Process. An upcoming vote will determine whether the new proposed OpenJDK roadmap is accepted by the JCP executive committee.

Mark Reinhold, chief architect of the Java Platform Group at Oracle, has stated that IBM engineers working on OpenJDK will probably "contribute primarily to the class libraries, working with the rest of us toward a common source base for use atop multiple Java virtual machines." The two companies will likely continue to work independently on their respective JVMs, "where most of the enterprise-level feature differentiation" is found, he said.

OpenJDK governance?

The OpenJDK project has an interim governance board tasked with creating a constitution for the OpenJDK community. As Simon Phipps has pointed out, the board's status appears to be in limbo as of this writing.

Win some, lose some

The decision to reach out to IBM as an OpenJDK partner was clearly a strategic one for Oracle. Oracle's vice president of software, Adam Messinger, said that the move reflected the pressure on both companies to move quickly and address the challenges posed by evolving multicore hardware. "The agreement is a reflection of the strategic reality we both face," he said.

The OpenJDK alliance de-isolates Oracle, said RedMonk's Stephen O'Grady, effectively affirming and centralizing its role in the Java ecosystem:

If Oracle was going to pick one vendor to stand beside them in their Java efforts, IBM would be the easy choice. Besides the blind trust enterprises place in the firm — "you don't get fired for buying IBM," etc. — Big Blue has an enviable reputation with developers. With IBM now publicly on the same page as Oracle, the latter's task of preserving the ecosystem becomes far, far easier.

It was also a good move for IBM, even accounting for the obvious sacrifice of Harmony. In shifting its engineering resources from Project Harmony to OpenJDK, IBM has solidified its influence on the future of Java technology, albeit clearly under Oracle's stewardship. Both companies have said that they will work together to ensure that the JCP is fortified and enhanced as the primary standards body driving the growth of the Java platform.

Left unresolved are issues of what will happen now to Project Harmony, what the Oracle-IBM alliance means for Google (and by proxy Android), what the OpenJDK alliance (and Google's response) could mean for other vendors in the Java technology space, and how and to what extent the JCP will be reformed.

Further reading: OpenJDK and the Oracle-IBM decision

• The majority of OpenJDK committers already are employed by Oracle (formerly Sun) and IBM, followed by developers from Google and Red Hat. (Oracle Java/FOSS Ambassador Dalibor Topic has more about this.)
• IBM's Bob Sutor, vice president of Open Systems and Linux, lays out the reasons for IBM's decision. He addresses both the upside of IBM's improved leverage for ensuring the open source future of Java and the JCP and the upset about the decision's impact on Project Harmony.
• Stephen O'Grady gives an analyst's insight into the ripple effects of the Oracle-IBM decision across the entire Java ecosystem, including speculation as to why partnering with IBM on OpenJDK was a good move for Oracle.
• Mark Reinhold explains the thinking behind the new OpenJDK roadmap and its split JSRs.

Back to top

What about Project Harmony?

IBM has been a longstanding backer of Project Harmony, the open source Java runtime developed and licensed by the Apache Software Foundation. To some in the Java community, Harmony has seemed a viable alternative to the official Java platform implementation, should the need arise. Harmony also is seen as a test case for Oracle's position vis-a-vis independent Java implementations and licensing.

Bob Sutor, IBM's vice president of open source and Linux®, summed up IBM's decision to redirect its engineers from Project Harmony to OpenJDK, calling it pragmatic:

It became clear to us that first Sun and then Oracle were never planning to make the important test and certification tests for Java, the Java SE TCK, available to Apache. We disagreed with this choice, but it was not ours to make. So rather than continue to drive Harmony as an unofficial and uncertified Java effort, we decided to shift direction and put our efforts into OpenJDK.

While the move leaves Harmony's future uncertain, whether and how the project will evolve is in the hands of developers. IBM's decision "is not a good thing for Harmony" said Harmony creator and Apache board member Geir Magnusson. "But keep it in perspective: For the Apache Foundation, it's up to the community what will be done. We do what the community wants."

Initial reaction to the decision has ranged from variations on "game over (and not just for Harmony)" to the suggestion that parts of Project Harmony could make it into OpenJDK. Some have also speculated that the platform could continue to evolve under the backing of another corporate sponsor; namely, Google.

Further reading: Project Harmony, past and future

• Ryan Paul, reporting for Ars Technica, gives a concise overview of Harmony's licensing history; the implications of Sun's, and now Oracle's, field-of-use restrictions; and IBM's role in championing the platform until now.
• Stephen Colebourne, an ASF member, summarizes his views on both the Sun/Oracle licensing dispute and the upshot of IBM's decision.
• According to Harmony creator Geir Magnusson, Harmony's future remains in the hands of its developers.
• Many, including DZone's James Sugrue, are wondering what role Google might play in Harmony's future , given the subset of Harmony libraries used in Android.

Back to top

Google, Android, and the new cold war theory

While Google isn't the only Java technology vendor with a stake in the Oracle-IBM decision, it may be the vendor with the most to lose, or gain, as this story unfolds. Oracle's suit filed against Google in August (claiming multiple counts of patent and copyright infringement related to Android) was a blow to the open source ethos under which the Java ecosystem has thrived. Calls for a Java fork increased following the announcement, and some feared that developers formerly on the fence about Java technology would decamp.

That Project Harmony is without a strong corporate sponsor could be bad for Google (given that Android is built on a subset of Harmony); or it could be very good, if Google chooses to sponsor Project Harmony itself.

Whatever Google's decision, it will affect not just Android, but how vendors view and leverage Java technology in their own implementations. Moreover, as several have pointed out, we may be entering a new cold-war era — with Google, not Oracle, as the outlier.

Further reading: What's next for Google

• Charles Nutter hits all the bases in his summary of the Oracle-Google lawsuit and its ripple effects across the Java ecosystem.
• Greg Luck outlined a proposal for a Java fork in his October 4 blog post "Is it time to fork Java?"
• Googling Google blogger Christopher Dawson discusses Google's options to fight or join and concludes that Google will 'keep on being Google'.
• Google, along with IBM, Oracle, and Red Hat, is a leading contributor to the OpenJDK project.

Back to top

Reforming the JCP

Oracle and IBM have stated that they will work together to reform and enhance the JCP, ensuring that it continues to be the standards body defining the Java platform and language specifications. Oracle reps have affirmed that JCP approval is essential to Java SE development, starting with the upcoming vote on the revised OpenJDK roadmap announced at JavaOne.

Bob Sutor has said that IBM expects to see "long needed reforms in the JCP [...] to make it more democratic, transparent, and open." Some Oracle reps have also hinted not only that JCP reform is under discussion with the executive committee, but that they believe the community will be pleased with the resulting proposal.

Time will tell how the executive committee, and the community at large, respond to proposed JCP enhancements. According to Apache Software Foundation member Stephen Colebourne, the upcoming JCP vote will be an initial test case, however; not just for the revised OpenJDK/Java 7 roadmap, but for how vendors like Red Hat, VMWare, SAP, and Google react to the Oracle-IBM alliance. Colebourne has also proposed a JCP split that would leave Oracle the explicit sole voting power on the specification of the Java core (Java SE, ME, and the JVM, according to Colebourne), while declaring auxiliary libraries a separate province under the direction of a vendor-independent JCP.

Further reading: JCP reform and open source Java

• Oracle reps Adam Messinger and Henrik Stahl have both hinted that JCP negotiations could please the Java community.
• For an idea of how members of the JCP executive committee might view JCP reform, see the DZone panel comments from February 2010.
• Stephen Colebourne has proposed that the upcoming JCP vote could be a measure of where executive committee members stand on the Oracle-IBM decision. (Reporting by Jessica Thornsby for JAXmag online.)
• Colebourne has also proposed a JCP split.

Back to top

A healthier Java ecosystem?

The Oracle-IBM alliance is widely viewed as a win for Java technology: it both accelerates the OpenJDK project and enables collaboration and resource sharing among a much larger pool of engineers. The move consolidates the energies of two of the industry's most influential forces (by virtue of technology investment and revenue) on its fundamental project, OpenJDK. And it has effectively put an end to speculation about an IBM-led Java fork, which would have done more harm than good to the Java industry as a whole.

In his comments on the alliance, IBM's vice president of emerging technologies, Rod Smith, stressed its stabilizing effects on the Java ecosystem, for developers, for vendors, and for business. "This should remove some of the uncertainty about the future of Java," he said. Danny Coward (formerly of Sun) hailed the alliance as the beginning of a "new era of co-oper-tition," which Oracle's Adam Messinger said would accelerate innovation on the Java platform.

Stability is good, and so is innovation; both are essential to a healthy Java ecosystem. And while stability may rest on the shoulders of giants, innovation in the Java industry has historically been a disruptive force: an arena where small vendors and independent, loosely networked developers count sometimes more than multinational corporations. It's the interplay between those two powerful interests that keeps the Java industry both healthy and honest, and hopefully thriving.

As Fabrizio Giudici (and Gianugo Rabellino) have pointed out there is one final question, and that's the question of freedom; freedom as defined by the Free Software Foundation and codified by open source licenses. That question may yet determine whether the future of Java is founded on one core platform or two, or more.

Further reading: What makes a healthier Java ecosystem?

• Fabrizio Giudici evaluates shades of gray in his discussion of definitions of freedom — Rabellino's open source versus open standards — and whether an OpenJDK fork would be worth the price.
• Writing 10 days before the Oracle-IBM announcement, James Governor called disruptive innovation (and open source governance) the rule for the future of Java technology, and no longer the exception.

Resources

Learn

• OpenJDK : Learn more about the open source Java platform implementation.

• The JCP is the standards body that develops Java technology specifications.

• "IBM, Oracle, OpenJDK, and the implications" (Scott Langingham, developerWorks podcasts, October 2010): IBM's Rod Smith and Jason Gartner discuss the implications of the Oracle-IBM alliance on OpenJDK.

• IBM developer kits for the Java platform: Learn more about what IBM's runtimes and VMs

• Browse the technology bookstore for books on these and other technical topics.

• developerWorks Java technology zone: Find hundreds of articles about every aspect of Java programming.

Discuss

• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

About the author

Athen O'Shea is a high technology editor and writer, and former editor of JavaWorld.com. As a freelancer, he has plied his trade for developerWorks since 2001.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

via ibm.com