Here's the best news you'll hear all day: Bloomberg has opened up its market data APIs to the public. That means you can use their APIs to build access to their market data services into your applications. Previously, as you stock market folk already know, Bloomberg's data services came into organisations through Bloomberg terminals.

Mind you, the actual market data is not free here, but if you've already got Bloomberg data services pouring into your organisation, this will open the doors to a lot more options for your application development teams.

In theory, this should give rise to something resembling a standard in the market data API world. Unfortunately, it sounds like that space is a complete mess, thanks to highly expensive data.

That is, getting live, real time market data is expensive, and it takes up a lot of bandwidth. While reading up on this release, I encountered some very well informed comments on Hacker News. One of them pointed to Nanex as a good, cheapish source of data. Unfortunately, their data can only be accessed via a Windows DLL. No Linux for you.

That same comment pointed out that there's a real need for a high quality, Web 2.0'ish real time data feed for investment firms. Maybe Bloomberg's effort here, to lay out a publicly accessible method for accessing such data, will spur the creation of such a company.

Intellectual property law was created to protect the rights of creators over products of the mind. Speaking loosely: Patents protect inventions. Trademark protection covers names, images, and designs used in commerce. Copyright covers literary and artistic works, including both tangible artifacts and intangibles such as performances. Trade-secret protection is for information that owners keep secret to maintain competitive advantage.

The intersection of intellectual property law and software development is a fascinating and potentially lucrative field. The application of traditional intellectual property law to software is not always straightforward. It is generally acknowledged, for instance, that computer source code is subject to copyright protection – it is, after all, a written work, same as a novel or screenplay. (Well, sort of the same.) Of course, the same source-code file might be protected by patent law or trade-secret protection. You are surely aware that software patents have become very big business in recent years. If your job is in jeopardy of being outsourced or offshored, consider leveraging your technical expertise into a new career as a patent agent. You don't even have to go to law school – just pass the patent bar exam (you can find review materials and courses online) and you're in business. According to one site, patent agents earn about 25 percent more than software engineers.

But I digress.

The relationship between software and patent law is straightforward compared to the intersection of software and copyright protection. Specifically, it is unclear whether or not computer programming languages should be eligible for copyright protection. Uncertainties and apprehensions have attended this question for a long time.

A couple decades ago, Borland International – a publisher of C and Pascal compilers, spreadsheets, and database systems – was at the center of the copyrighting-a-language controversy. On the one hand, Borland was sued by Lotus, which claimed that because Borland's Quattro Pro duplicated a portion of Lotus 1-2-3's “command structure” – the keystrokes controlling operation of the spreadsheet – Borland was guilty of violating Lotus's copyrighted language. (Borland prevailed in court, setting a precedent against the copyrightability of programming languages.) At about the same time, Borland acquired dBase publisher Ashton-Tate, which was at the time litigating against Fox Software, whose database system implemented the dBase programming language. In this case, Borland's interests were on the opposite side of the copyrighting-a-language issue. No one knows how the judges might have ruled: Borland agreed to drop the case, and all future cases based on infringement of the dBase programming language, in return for regulatory approval of its acquisition of Ashton-Tate. It is important to note, however, that the U.S. Justice Department's Antitrust Division did not reject the copyrightability of the dBase language in its 1991 Competitive Impact Statement. It merely enjoined Borland from pursuing infringement lawsuits. (Read more here.)

Fast-forward to August 2010, when Oracle sued Google for alleged intellectual-property violations in the Android operating system. Alongside 50 alleged patent violations was this claim: “Oracle America owns copyrights in the code, documentation, specifications, libraries, and other materials that comprise the Java platform.” In particular, Oracle alleges that Google violated its copyright by implementing copyrighted Java APIs and copying a dozen small library source files. The source-file issue isn't interesting – source-code files are obviously copyrightable. But if you can copyright a language's APIs, are you copyrighting the language? It's hard to say. We'll have to wait for the judge's ruling – this case is still pending. (Read more here.)

Outside the U.S., the applicability of copyright law to programming languages is being tested in the United Kingdom, where SAS Institute, a publisher of statistical-analysis software, has brought suit against competitor World Programming Ltd., alleging that World has duplicated the SAS programming language in its software. Again, we are waiting for a judge's ruling (the case is being adjudicated by the UK High Court). There is an interesting twist, however. In July 2010, the British court asked for guidance from the Court of Justice of the European Union. Specifically, the court asked the CJEU if programming languages could be copyrighted. The court has not ruled on the issue, but it has released a statement from the office of Advocate General Yves Bot, whose advisory statements are almost always followed by the court. Bot dismissed the idea the languages could be copyrighted: “The functionalities of a computer program and the programming language cannot be protected by copyright.” Should the court adopt this position, the matter would essential be closed throughout the European Union. (Read more here.)

Should languages be subject to copyright? I keep scratching my head. I can definitely see both sides of this fascinating issue.

Web recommendation: I read an interesting report on language choice and software quality today. The report was produced by an international consulting firm called CAST, which says it has analyzed 365 million lines of code in 745 IT applications. A language-by-language comparison shows the highest density of bad code in Java EE applications, while COBOL applications show the fewest problems. CAST, which advocates metrics in software development and management, makes a summary of the report available on its Web site for free, though you must fill out a registration form to get at the data. I'm not wholly convinced, but the report is food for thought. You can read it here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He plays a mean game of gin rummy.

Just sent to the Lambda-dev list by Brian Goetz:

This just in: the EG has (mostly) made a decision on syntax.

After considering a number of alternatives, we decided to essentially adopt the C# syntax.  We may still deliberate further on the fine points (e.g., thin arrow vs fat arrow, special nilary form, etc), and have not yet come to a decision on method reference syntax.

The C# syntax is:

   lambda = ArgList Arrow Body
   ArgList = Identifier
             | "(" Identifier [ "," Identifier ]* ")"
             | "(" Type Identifier [ "," Type Identifier ]* ")"
   Body = Expression
             | "{" [ Statement ";" ]+ "}"

Here are some examples of lambda expressions using this syntax:

   x => x + 1
   (x) => x + 1
   (int x) => x + 1
   (int x, int y) => x + y
   (x, y) => x + y
   (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }
   () => { System.out.println("I am a Runnable"); }

The decision to choose this syntax was twofold:
  - The syntax scores "pretty well" on most subjective measures (though has cases where it looks bad, just like all the others do).  In particular, it does well with "small" lambdas that are used as method arguments (a common case), and also does well with large (multi-statement) lambdas.

  - Despite extensive searching, there was no clear winner among the alternatives (each form had some good aspects and some really not very good aspects, and there was no form that was clearly better than the others).  So, we felt that it was better to choose something that has already been shown to work well in the two languages that are most like Java -- C# and Scala -- rather than to invent something new.

A compiler implementation should be available soon.

A lot has been made of the "show stopper bug" in Java SE 7. For the record, here is the original posting from the Apache mailing list, where Uwe Schindler laid it out in full:

Hello Apache Lucene & Apache Solr users,

Hello users of other Java-based Apache projects,

Oracle released Java 7 today. Unfortunately it contains hotspot compiler optimizations, which miscompile some loops. This can affect code of several Apache projects. Sometimes JVMs only crash, but in several cases, results calculated can be incorrect, leading to bugs in applications (see Hotspot bugs 7070134 [1], 7044738 [2], 7068051 [3]).

Apache Lucene Core and Apache Solr are two Apache projects, which are affected by these bugs, namely all versions released until today. Solr users with the default configuration will have Java crashing with SIGSEGV as soon as they start to index documents, as one affected part is the well-known Porter stemmer (see LUCENE-3335 [4]). Other loops in Lucene may be miscompiled, too, leading to index corruption (especially on Lucene trunk with pulsing codec; other loops may be affected, too - LUCENE-3346 [5]).

These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see [6]). This means you cannot use Apache Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM option to not risk index corruptions.

Please note: Also Java 6 users are affected, if they use one of those JVM options, which are not enabled by default: -XX:+OptimizeStringConcat or -XX:+AggressiveOpts

It is strongly recommended not to use any hotspot optimization switches in any Java version without extensive testing!

In case you upgrade to Java 7, remember that you may have to reindex, as the unicode version shipped with Java 7 changed and tokenization behaves differently (e.g. lowercasing). For more information, read JRE_VERSION_MIGRATION.txt in your distribution package!

On behalf of the Lucene project, Uwe

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134

[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738

[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051

[4] https://issues.apache.org/jira/browse/LUCENE-3335

[5] https://issues.apache.org/jira/browse/LUCENE-3346

[6] http://s.apache.org/StQ

So what's really going on here? Java SE 7's included HotSpot JVM is compiling some loops incorrectly because a flag that enables optimizations during compilation has been turned on by default. That's a nasty bug, for sure, because it means Lucene and Solr users are completely unable to just unpack Java SE 7 and run it. They have to turn off the compiler optimizations before they can use SE 7 at all. But is that really a show stopper? Just about every major version upgrade in history turns something that was off by default in the previous versions on by default in this version. It's a pain, but it's not a show stopper, at least, not now that everyone knows about it. The first people to fire up Lucene on SE 7 sure got a nasty surprise, and corrupted some indexes, though. But now we know, and knowing is half the battle.

Look for a fix in the next update of Java SE 7. It'd be great to compile (pun intended) a list of other affected software packages. I'm sure this can't just screw with Lucene and Solr. But so far, they're the only two I can find complaining on the Internet. Thus, the whole affair makes me think that Apache is being a tad dramatic. But that's to be expected. As are some bugs in an initial release. Java SE 7 is nothing if not brand-spanking new.

At the end of the day, what really happened here is we've seen a symptom of Apache's walking away from the JCP and it's distancing itself from the OpenJDK project. The two should have a group hug and get more work done, but that's not likely to happen, especially with Oracle suing Google over its use of Apache Harmony libraries in Android, and Apache's ire over the slow pace of changes to the JCP itself.

Red Hat's JBoss Middleware division released the JBoss Application Server 7 earlier this week. We caught up with Craig Muzilla, vice president and general manager of the Middleware business unit at Red Hat, and asked him what this update means for the platform as a whole.

EE 6 is all about laying the foundation for modularity for the platform, through the new Profiles. How is JBoss taking advantage of this?

What we're announcing next. JBoss Application Server 7. At the core of this is a micro-services container. We came out years ago with the concept of a micro-kernel. JBoss EAP 5.0 came out with the idea of a micro-container on top of the Java Virtual Machine. Now we have this concept of more modularity. If you have transactionality in JTA [Java Transaction API], or caching, or messaging, or clustering, or security, all of these services can be added or subtracted easily from the micro-services container.

The other thing this does is allowed us to add a lot more manageability capabilities. We're extending the API so that the platform container can be more easily managed without having to bring in something hard-coded. You can manage and configure and deploy this environment much more easily. We're doing a lot for flexibility for the developer, but also for the operational excellence and managing it after the fact.

We have a profile which is essentially Tomcat, slimmed down. It's just the servlet engine, but then you begin to build on top of that by adding services with micro-services containers. The problem with Tomcat is that it's really simple and easy to deploy, but the problem is if you need to scale it up and add services, thats not so easy. If you need transactionality, if you need highly distributed caching capability, you can't do it easily with Tomcat.

I'd say Tomcat is still healthy. It seems like from the market research data we have, show that its usage hasn't declined, but it hasn't increased either. What these other vendors (Mulesoft, SpringSource) are doing is, they all need a container. With Mule, their ESB needs a container, but if you need it to be more than the runtime environment for the ESB, you will not have services to do that. I think that's the dilemma. Some of these companies are offering their own Tomcat versions, but can that be a rich environment or not?

How goes the work on Java 7, both SE and EE?

We participate in the JCP Executive Committee and in the expert working groups for Java EE 7, and for SE. We participated in the recent EE 7 announcement. In terms of SE 7, we are on the expert group for that. We're feeding in our comments and making sure we're part of the process. We are also the number one contributor, outside of Oracle, to OpenJDK. We have quite a few people working just on OpenJDK. We have had a Test Compatibility Kit (TCK) compliant Java for around 4 or 5 years now, and we ship it with Red Hat Enterprise Linux. We plan on continuing that tradition, and we're fully behind OpenJDK. I think what is uncertain is what happens beyond the OpenJDK, in terms of what Oracle does.

They may package up another distro based on OpenJDK, with Hotspot and Jrockit. What types of add-ons will they put in that environment? From the market standpoint, they said they want to add value on top of Java, but I think it's unclear where they're going to go. We want to make sure the specification itself and the reference implementation is nice, and strong, and healthy, and has all the capabilities at a base level that everyone at the marketplace will need.

Tell us about Cloud Forms and Open Shift.

We recently announced Cloud Forms, and OpenShift, which is our platform as a service offering.

The JBoss product line is bringing together all these pieces we have and offering them as services in OpenShift. People can use us as the engine in their cloud. It doesn't end at the container. Think of an integration service from Salesforce.com to an internal ERP. On top of that, you get busineess process management as a service, and user experience and collaboration as a service.

JBoss Application Server 7 is the engine in our middleware offering in the cloud. This goes live within the next several weeks, and JBoss Application Sever 7 is the engine driving that in OpenShift.

What are your goals for your platform as a service?

I think the primary requirement is making it very accessible and easy and to attract developers from corporations that need to do development in the cloud and bring it back on premises. Also, people who have ancillary applications that are mainstream, so it doesn't make sense to do it on-site, so you do it in the cloud. Why start on premises? Do it in the cloud? For smaller organizations that need Web-based applications, do it right in the platform as a service. I think one of the key requirements is to make it easy for all these audiences to use OpenShift. Second is to make it portable so they can move from cloud to cloud, or cloud to on premises.

We're trying to embrace applications, whether its Spring or EE or Ruby on Rails, or PHP. We embrace all of these, and let the developers use the workload that best suits their needs.

Stepping back a second, I think Red Hat is always looked upon as only a Linux company. But I think, as people get to know us more, they realize we have really a full portfolio of infrastructure as well as development and middleware offerings, and we bring it all to the table. I think it's good for all developers that they understand Red Hat is more than a Linux company. It's a middleware company. It's a management company. It's a cloud company.

I've been trying to reel in a rumor I heard about Google's Android team creating a new build system. It's supposedly called "Presto," and it's going to be an open source project as soon as it gets prettier. Unfortunately, that's all I was able to find out so far, and Googlers can be quite tight-lipped, even when plied with food and beverage.

So, rather than burn any contacts, I felt we should take a gander at what a new build system from Google would do to the Java market. Right now, the world of build and deploy tools in Java is at about the same point Java SCM stuff was in 2004. Remember the move from CVS to Subversion? That seems to be happening with Ant, but slowly. Maven and Hudson/Jenkins are still quite popular, but according to the Eclipse Community Survey, Ant is still the king, and both Hudson/Jenkins and Maven are fighting over 30% of the build market, each.

Ant, as the survey shows, is still the king. Which is kind of shocking. It's not that Ant is bad, but it does get out of hand very quickly unless you keep an eye on those XML files. Usually that means someone has to be the Ant guy. On the other hand, Maven solves most of Ant's problems, but requires a bit of restructuring for your repositories and other such assets. Hudson and Jenkins are terrific for continuous integrations, but the split that's happened there ensures a divided community. As a kind commenter has pointed out, all three of these systems can be used together, or independently, so they're not really competing for market share. Still, Ant is still the most popular build component in the Java world, undeniably.

Into this, throw a brand new build system from developer-favorite Google. I'd expect that, though it'll be from the Android team, Presto might just work out for any Java team after a bit of modification from the community. And considering that the Android team is the fastest one at Google, right now, you can bet Presto will support continuous integration. I'm envisioning some sort of Web-administered build server that connects to everything. Expect support for testing on Selenium and building with Harmony, right off the bat.

But, again, I'm speculating. At this point, all I know is that Presto will eventually be an open source build system from Google, coming out of the Android team. We'll just all have to wait and see what form it takes, because I've had little success prying free more information on the subject.

I had the delightful opportunity to speak with Mike Milinkovich, director of the Eclipse Foundation, earlier this week. He's in town for EclipseCon, which is where we chatted. Eclipse is rolling along nicely, and he said that this summer's Indigo release is going to be the biggest gift Java developers have received from the Foundation in about 5 years. The inclusion of WindowBuilder, recently made free by Google's acquisition of Instantiations, should make Eclipse a complete end-to-end IDE for the first time. While many other GUI building tools have been brought to Eclipse already, WindowBuilder is a remarkably mature offering with full round-tripping capabilities. Milinkovich also took credit for bothering Google until they opened the software to the public. As we speak, Google and others are working on preparing WindowBuilder for the Indigo release train.

Here's a transcript of some of our interview:

You seem to like WindowBuilder a lot

WindowBuilder has been around for a really long time. I remember using it when I was a Smalltalk programmer. That technology has been around for a long time. They had several hundred-thousand paying customers when they were Instantiations. This is not something that's starting out, it's stable, it's mature, it's well known amongst Java developers.

As an Eclipse project, however, it's just starting. [March 21 was] the first day they had a build you could download from Eclipse. I'm very confident that when it shows up in the indigo packages, people will love it. The team is working extremely hard to make that happen. Getting it into Indigo will set a new land-speed record for a project going from proposal to acceptance.

As always, this is the most technical show I attend all year.

The keynotes are great. Did you see the Watson keynote? This is a very technical crowd, and it was a fairly deep dive into IBM's Watson. All the feedback I saw on Twitter was positive and there were lots of really good questions at the end. [On March 22] Mark Reinhold is talking about OpenJDK. I think that's going to be of great interest to everybody in the room. Then there's a panel afterwards. I'm sure we'll get some good questions. [They did!]

What's up with the OpenJDK? You're on the governance committee... what do you want out of this project?

We could be more transparent, faster. We made a lot of progress. We've gotten a lot of good feedback from the early drafts, and I expect there will be more drafts. The OpenJDK governance body is focused on redoing the by-laws. It's moving. People from the outside don't see any progress. But the message is "progress is happening, stay tuned." There will be more content shortly.

You're also representing Eclipse in the JCP. How would you assess Oracle's overall approach to Java?

As I understand it, Java 7 is scheduled for release late this summer, and as far as I know they're on track.Under Sun, the code wasn't moving forward. One of the things about Oracle's stewardship of Java is that it takes time to get going, but they are actively investing in moving Java forward. Sun was using the deadlock at the JCP as a convenient excuse to save money on a lot of engineering resources. The pace of innovation in the Java platform is going to get a lot better. In terms of Java as a language, some innovation is going to happen there, and around modularity. But there are a lot of things Java needs to do to innovate and to be more relevant to today's world. It needs to be much better and more relevant to Web developers

So, modularity is scheduled for Java 8. Will that modularity look like OSGi?

There is not yet an answer to that question. I made it really clear in Eclipse's vote on the Java 8 JSR, that if there wasn't room for OSGi to play within the modularity story for Java 8, that we would be voting against it. There is work going on around bridging that gap with conversations amongst the technology guys. In my view, it's a no-brainer. There is a lot of stuff being built on top of OSGi right now, and it's in nobody's interest to break that in Java 8.

The cloud is all about interoperability, right? Microsoft has taken a step in that direction with the recent release of Windows Azure Starter Kit for Java, an Eclipse-based plug-in that enables Java developers to deploy their applications to the .NET-based Microsoft cloud. The community technology preview is available for Java developers to use with the Eclipse IDE; Microsoft is waiting for your feedback. The idea is to give developers writing in Ruby, PHP or Java an Eclipse-based solution for deploying onto the Azure platform. The starter kit includes an Apache Ant build extension that understands Azure configuration options to simplify deployment. Microsoft's goal, of course, is to have more applications running in the Azure cloud, which Microsoft hosts, as part of its all-in bet on cloud computing.

It's official: Hudson has been forked. The "real" Hudson is now called Jenkins. Of course, Oracle will say they've got the "real" Hudson because they've inherited the name. Or, rather, they've sat down upon the name and made it impossible for anyone to pull the project out from under them.

The official word from Oracle, as it were, is really in this email to the Hudson-dev list. Kohsuke Kawaguchi and his posse have moved on to Jenkins, which will not likely push forward with the same frenzied pace that Hudson had.

And this was the real issue for Oracle, I believe: Hudson just moved too fast for enterprises to handle. Oracle is all about updating software, but it tends to do so quarterly, or even less frequently than that. Enterprises are just not able to update their stacks every week as a project moves forward.

This is an understandable desire, but in the end, there was probably a better way to address this problem than an out-right fork. Still, Kohsuke has already accomplished his primary goal: fixing Java builds. Sonatype recently completed a survey of 1000 Java developers, and the results showed Hudson was used by over 80% of them. I can't think of very many open source Java tools projects that have that kind of uptake. Not even Subversion or Eclipse has that level of acceptance.

So while this may look bad, the end result is that the Java build problem has already been fixed. And now, Java developers will be able to choose between two options for handling those builds correctly.

The JCP has finally gotten around to addressing the future of Java. Today, four new JSRs were issued by the JCP: one each for Java SE 7 and 8, and two additional JSRs for Project Coin and Lambda Expressions.

JSR 334A successor to JSR 201 to enhance the Java programming language with an assortment of small changes to improve productivity. Changes must be simultaneously small in specification, implementation, and testing.

JSR 335 Extend the Java language to support compact lambda expressions (closures), as well as related language and library features to enable the Java SE APIs to use lambda expressions effectively. Project Lambda.

JSR 336 The Umbrella JSR for the seventh edition of the Java SE Platform.

JSR 337 The Umbrella JSR for the eighth edition of the Java SE Platform.