Tag Archives: java

Java software quality: frameworks good, Struts or C++ bad says report

CAST has released an intriguing report on Java applications and software quality.

The company analysed 497 applications, comprising 152 million lines of code across 88 organisations and six global industries. It then looked at how software quality correlated with frameworks used.

◾Hibernate has the highest quality scores.
◾Applications built with Struts have the lowest quality scores.
◾Applications that did not use any framework had a huge variance in quality, which indicates that frameworks do in fact help develop applications of predictable quality.

A further investigation looked at what happens to software quality in mixed language applications:

◾Applications built in pure JEE, with no frameworks or multi-lingual mingling, had the highest quality scores.
◾Mixing Java with C or C++ lowers quality scores.
◾Mixing Java with COBOL, Java-DB, and Microsoft .NET delivered higher quality scores.

Frameworks are good but pure J2EE is better? Mixing with C/C++ lowers software quality, but mixing with .NET or COBOL raises software quality? These are odd results, and I wonder if this research is correlating the right factors. Here is a clue:

One common challenge for developers with framework usage is configuring them correctly. CAST data shows that a large majority of applications analyzed had some level of misconfiguration, indicating the need for better training or to simplify the use of frameworks.

I have a hunch that what this research really tells us is that the most competent developers deliver the highest quality code. Maybe the smartest developers do not use Struts.

ThoughtWorks bemoans excessive software complexity, advocates small, focused services

ThoughtWorks has released its latest Technology Radar, an opinionated analysis of software development trends.

Things the folk at ThoughtWorks like include automated build and deployment, essential for Continuous delivery; NOSQL database managers especially Neo4j; mobile-first development; the AppCode IDE for Apple’s Objective-C; the Graphite realtime graphing tool for creating dashboards; Clojure and Scala for programming.

I meet some of the ThoughtWorks team at developer conferences from time to time, and generally find them smart and though-provoking to talk to. They must be the despair of the big enterprise software vendors, with a liking for open source and an aversion to heavyweight high-maintenance systems.

This remark particularly caught my eye:

Simple architectures—Simple continues to gain traction, including both techniques for building and composing applications, as well as infrastructure-based techniques to enable simple deployment, failover and recovery. This theme is a recurring one for us, but we have not yet seen the usage shifts we believe are necessary.

I asked consultant James Lewis and practice lead Sam Newman to expand on that. Why do we continue to choose complexity over simplicity?

“A lot of people like to stay inside their big box, and don’t understand the complexities that then creates,” said Newman. “There’s a lack of critical thought given to how services talk to each other. A lot of them are driven by whatever the vendor says you do. Java makes RMI very easy. [Microsoft] .NET makes binding to WSDL [SOAP] schemas very easy. All these tools make bad things very easy to do.

“When you start talking to organisations about smaller services that are focused on doing one thing well, they have the horror associated with now having more than one box to manage and operate. So it’s hard to talk about moving from one big monolithic complicated box that is hard to change, to lots of little boxes, without also having conversations with those clients about how they get better at managing multiple services.

“Netflix has 300 services. Each service runs on at least six machines. They are very good at deploying those services. Yet they are not an overly complicated domain compared to some of our clients.”

“Amazon were talking about this in 2004,” adds Lewis, “the idea that you join up development of these small, simple applications with the operational control, so the same people who build them are also the people who run them. Now that we’re seeing both private and public clouds, and the ability to spin up machines becoming more and more prevalent, its starting to become more attractive.”

This is a consistent theme from ThoughtWorks. Break up complex solutions into many small services, think about how they talk to each other (with REST and HTTP favoured), and think about the infrastructure and how to automate it as well as the software itself.

“In many organisations these conversations are happening,” Newman told me. “I go to clients now, and they talk about the Enterprise Service Bus as being something they’d love to get rid of if they only knew how. Five to ten years ago, to even mention the Enterprise Service Bus as being a problem, they’d look at you with daggers in their eyes.”

“It’s almost like we’re now able to fulfil the promise of service orientation,” says Lewis. “It needed these additional practices, around things like automated deployment, automated rollback, and an understanding that people and process are tied intrinsically with it.”

Another issue, claims Lewis, is that software architects simply get out of touch with best practice.

“Most architects who build big systems are quite a long way from their codebases. They sit in rooms talking to other architects. They might have last written a line of code five or ten years ago. What they do is to design systems as they would have done ten years ago. People do get divorced from the latest trends and perpetuate less effective ways of doing things.”

Finally, here’s something for the Microsoft platform people who read this site. ThoughtWorks is not altogether averse to Microsoft and mentions the Azure cloud platform as something which is becoming interesting. But Windows Phone:

Despite a promising start to Windows Phone, a well thought-out user interface, and probably the best development experience of any mobile platform, we have seen several stumbles in the execution of the platform strategy by Microsoft and its partners. This makes us less optimistic about the future of the platform than we were in the last radar.

Translation: nice mobile platform, but nobody’s buying it. Then again, on Monday next week Windows Phone 8 will be properly unveiled. Still hope?

Top languages on Github: JavaScript reigns, Ruby and Python next

I cloned a github repository today, and while browsing the site noticed the language stats:

image

Git was originally developed for the Linux kernel and is mainly for the open source community. I was interested to see JavaScript, the language of HTML 5, riding so high. PHP, C and C++ are lower than I would have guessed, Ruby and Python higher.

Here are some figures for the venerable Sourceforge:

Java (7,163) 19%
C++ (6,449) 17%
C (4,752) 13%
PHP (3,521) 10%
Python (2,694) 7%
C# (2,481) 7%
JavaScript (2,011) 5%
Perl (1,138) 3%
Shell (757) 2%
Visual Basic NET (688) 2%
Delphi/Kylix (581) 2%

This comes with a health warning. I have taken the figures from the what you get if you browse the directory and drop down Programming Languages; but the total is only about 37,000, whereas Sourceforge hosts around 324,000 projects. I am not sure what accounts for the discrepancy; it could be that language is not specified for the other projects, or they are dormant, or some other reason. But I hope the proportions indicate something of value.

Github is madly trendy, and Sourceforge ancient, so this tells us something about how open source activity has shifted towards JavaScript, Ruby and Python, and away from Java, C/C++ and C#.

Of course the overall picture of programming language usage is quite different. For example, you can get some kind of clue about commercial activity from a job board like indeed.com, which currently has 77,457 US vacancies for Java, 22,413 for JavaScript, and only 5030 for Ruby.

Nevertheless, interesting to see what languages developers on Github are choosing to work with, and perhaps an indicator of what may be most in demand on the job boards a few years from now.

Finally, looking at these figures I cannot help thinking how short-sighted Microsoft was in abandoning IronPython and IronRuby back in 2010.

Android: good or bad for Java? Oracle claims harm but I am sceptical

Patent blogger Florian Mueller quotes a statement filed by Oracle in its legal dispute with Google over its use of the Java language in Android:

Android’s growth in the mobile device market has been exponential, steadily diminishing Java’s share. For instance, Amazon’s newly-released Kindle Fire tablet is based on Android, while prior versions of the Kindle were Java-based. Android has been gaining in other areas as well, with Android-based set-top boxes and even televisions appearing this year. These are markets where Java has traditionally been strong but is now losing ground to Android. The longer Android is allowed to continue fragmenting the Java ecosystem, the more serious the harm to Java becomes, and the more difficult it is to try to unwind. Oracle suffers harm in the form of lost licensing opportunities for its existing Java platform products, and the enterprise-wide harm from fragmentation of Java, which reduces the ‘write once, run anywhere’ capability that has historically provided Java such great value.

The Kindle is an interesting example. I had not realised that the pre-Fire Kindle runs Java, but Oracle shows it as a case study and indeed, here are the javadocs.

Android infuriates Oracle because it uses the Java language, but has its own virtual machine called Dalvik. Dalvik bytecode is different from Java bytecode.

I have no expertise on the legal position, but while I can see Oracle’s point it is also true that Android has greatly boosted interest in Java development. Although Google has fragmented Java, the fact that the language is the same benefits Oracle insofar as it increases the pool of Java developers who may also be inclined to create Java applications on the server or in other contexts.

The interesting question to ask is where Java would be without Android. On mobile, it would likely be close to death. Apple’s iOS platform is equally as resistant to Java as to Adobe Flash. RIM Blackberry used to be a Java platform, but is moving away:

While we will continue to support our BlackBerry Java developer community as they build for BlackBerry smartphones, after further investigation we decided against supporting BlackBerry Java on BlackBerry BBX. We concluded that the BlackBerry Java experience on the BlackBerry PlayBook platform would ultimately not satisfy us, our development community, or our customers as the platform continues to evolve.

Microsoft has no interest in Java on the Windows Phone OS or in the Windows 8 OS that will likely replace it on devices.

Oracle’s claim is in the context of a legal dispute, and as Mueller observes, the company is happy to show off growing interest in Java in its press releases – though without mentioning the A word.

Of course you can understand why Oracle might want to enjoy the benefit of Java’s Android boost as well as the reward of a legal victory over Google.

PS: interesting that Oracle’s Java press release seems to be served by Microsoft .NET:

image

Oxygene for Java released: develop for Android and Java runtime with Delphi language in Visual Studio

RemObjects has released Oxygene for Java, a new version of its Object Pascal compiler. Object Pascal is pretty much the Delphi language though with some additional features of its own. Previous versions target the .NET runtime, and a version of this is marketed by Embarcadero as Prism. The IDE for Oxygene is Microsoft’s Visual Studio. This new version targets both the Java Runtime and the Android Dalvik VM. The obvious target market is Delphi developers who now want to create apps for Android, or cross-platform Java applications.

I downloaded the trial and ran the supplied Hello World in the Android emulator … it works.

image

A few further notes from the RemObjects announcement. While only Visual Studio is supported initially, an Eclipse version is also in preparation. Oxygene directly consumes .JAR libraries so you can use both first and third-party libraries. There is also a tool called Oxidizer that lets you import Java language code, which will be converted to Oxygene Object Pascal.

A point to note is that Embarcadero has already announced that its cross-platform FireMonkey framework will support Android as well as Apple iOS. This means that developers who want to code for Android in the Delphi language will have two choices. It looks to me as if Oxygene will be more suitable if you want to stay close to the Android SDK, whereas FireMonkey has its own custom-drawn user interface widgets and effects and should come into its own if you want the same code to run on both iOS and Android.

Given that a skilled Delphi developer would probably learn Java fairly quickly, how much value is there in Oxygene for Java? I guess factors include how much more productive you can be in Oxygene and the value of sharing code across projects targeting different platforms, presuming that you do not want to run Java everywhere.

What is the best programming language for a child progressing from Scratch?

Someone asked me what is the best programming language for a child to learn after starting (and having success) with Scratch.

Scratch is a visual programming language which actually runs on Smalltalk, though its users do not need to know this. Scratch 2.0 seems to be written in Adobe Flash so you can create and program projects in a web browser. As far as I can tell though, there is no obvious and natural progression from Scratch to a code-centric programming language.

I guess the first answer is not to move away from Scratch until you need to. You can do a lot with Scratch, as the many shared projects demonstrate.

Still, I agree that it makes sense to learn text-based programming before too long. What is the best one for a child to learn, not necessarily with computer science or a professional career in mind, but just to take the next step and create some cool games and applications?

I find myself leaning towards Microsoft’s C#. The reason is that there is a capable free version and  you can add XNA Game Studio for game development. C# is an excellent language and has some family resemblance to other languages including C, C++, Java and JavaScript, and Visual Studio is a strong IDE that is perhaps more approachable than say Eclipse or Netbeans.

Snags with C# are that Visual Studio only runs on Windows, the language is proprietary to Microsoft (though Mono is free and open source) and it is not ideal if you want to run on the Mac, or Google Android or Apple iPad.

That said, I could also make a case for Java, or JavaScript, or Python.

I would value suggestions though: what would you recommend to a teenager?

Eclipse and Xtend: some confusion in getting started

Last weekend there was some publicity around Xtend, an Eclipse project which extends Java with new language features. Xtend now has a new landing page, as announced by the lead architect Sven Efftinge.

I did intend to post about this yesterday, but I wanted to see it in action first, so I tried to download it and have a look. I believe this is a case where those who wrote the new landing page are too close to the project and made some assumptions, because I did not find it obvious how to proceed.

If you follow the Download link you are invited to paste one of the three URLs into the Eclipse update manager.

image

As a newcomer to the project, I did not want three URLs to choose from, I wanted just one. I picked Release as in general this one is likely to work.

Now, the instructions say:

To install the Xtend plugins open the update manager and paste one of the URLs on the right into the field ‘Work with’ and select the Xtend SDK.

The update manager actually presents you with a long list of updates, none of which say Xtend. I took a stab at what I thought was the right thing.

image

The All-In-One includes the Xtend SDK, which is what I want, right?

Wrong. After installation I could not find the tutorial which the docs said would be available.

I did some messing around with Eclipse and got the occasional error like this one:

image

Then I realised that I should have looked under the TMF Xtext-2.1.0 tree, which is where the correct Xtend SDK resides:

image

Except that if you find this helpful post by  Max Rohde you will know:

The other packages need to be selected since otherwise the Xtend editors will not work.

So you should select all of TMF Xtext-2.1.0 (or the latest release). Easy when you know, but not obvious since the word Xtend does not appear in the top node of the tree.

I was then able to create the tutorial project. I opened HelloWorld.xtend and got this:

image

Ah, but you have read Rohde’s post so you know this is expected and that you should run this as a JUnit Test. However it does not have any output. To see some output, you have to run one of the other examples, like Xtend08_RichStrings, or perhaps add:

sayHelloToSystemOut2(‘Tim’)

to the testHelloWorld() method in HelloWorld.xtend.

image

OK, it works.

So what is Xtend? It is essentially a code generator which lets you write in Xtend and generate Java. You can see the generated code in the tutorial project under xtend-gen.

image

Xtend adds some nice features: type inference, property syntax, closures, switch expressions with no fall-through, template expressions, extension methods, and multiple dispatch.

I can imagine C# creator Anders Hejlsberg smiling here, as most of this is already in C# in some form or other.

But is Xtend the right way to bring these features to Java? I am not convinced so far. It is an interesting Eclipse project, but it may be more significant in speeding the implementation of features like these into Java itself, than as a mainstream approach to writing applications. Xtend is a kind of hybrid approach, where you will be switching between Java and Xtend while you code and debug your application, and I suspect it would get frustrating.

There is also the question of widespread community support – beyond Eclipse.

Finally, it would be good if the new landing page could be made more helpful for those getting started.

Review: Continuous Delivery by Jez Humble and David Farley

I like this book. I know I like it because I find myself wanting to quote from it frequently. It is a book that almost every software developer should read, even if you disagree with parts of it – which is likely, because it is opinionated. The authors always give reasons for their opinions though, which means that if you disagree, you need to articulate why that is; or they may even change your mind. In consequence you find yourself learning as you read.

The authors are software theoreticians, but they are also practitioners; in fact they are practitioners first and theoreticians afterwards. This means they are pragmatic rather than dogmatic. Here is an example. Chapter 13 discusses software dependencies, and page 372 covers circular dependencies, “probably the nastiest dependency problem.” A circular dependency is when component A depends on component B, and component B also depends on component A.

A bad idea; but the authors write:

Surprisingly, we have seen successful projects with circular dependencies in their build systems. You may argue with our definition of “successful” in this case, but there was working code in production, which is enough for us.

As an aside, this kind of dry humour is characteristic, as also evident in remarks like this:

We are certain that, occasionally, manually intensive releases work smoothly. We may well have been unlucky in having mostly seen the bad ones.

The subject of the book is Continuous Delivery. So what is that? Well, if Continuous Integration is about ensuring that your software always builds, then Continuous Delivery is about ensuring that your software always deploys. The final form, as it were, of Continuous Delivery is Continuous Deployment, where you are so confident of your automated build and deploy process that any checked-in code that passes its tests can be deployed immediately. I was confused about the difference between Continuous Delivery and Continuous Deployment so I wrote a post about it; it turns out that there is not much difference.

The principle behind Continuous Delivery is that software is not done until it is released. If the release process is long, arduous and infrequent, then you are not really doing Agile development. A section of chapter 1 is devoted to release anti-patterns, and these form an excellent rationale for taking an interest in Continuous Delivery.

My guess is that anyone who has been involved in professional software development will wince a little while reading through these anti-patterns, thinking “that is what we used to do” or even “that is what we do”.

That said, Humble and Farley do not fall into the trap of merely writing about how not to do it. Rather, they address in some detail the kinds of problems you will face if you decide to embrace the Continuous Delivery methodology. The key ingredient in Continuous Delivery is that pretty much everything must be automated, otherwise it is too difficult to do. But how do you automate something like Acceptance Testing? That is the subject of chapter 8. How do you automate a deployment at all? That is the subject of chapter 6. The authors are not on a higher plane than the rest of us, and much of the advice is straightforward, even at the level of “Always use relative paths,” which is a tip in chapter 6.

The authors talk a lot about testing, as you would expect, but there is also extensive discussion of software configuration management, describing different approaches such as centralised and distributed version control and even specific tools. The chapter on Advanced Version Control is a particularly good read. Humble and Farley articulate the point that branching and merging is antithetical to Continuous Integration and therefore Continuous Delivery:

If different members of the team are working on separate branches or streams then by definition they’re not continuously integrating (p 390)

Does this mean branches are a bad idea? Not always, say the authors, but they also state:

Our strong recommendation is to crate long-lived branches only on release … new work is always committed to the trunk (p 392)

The reason is not only to enable Continuous Integration, but also because merging is complex and error-prone.

Software configuration management is not easy, but it is a relatively mature aspect of software development. This is less true of what you might call infrastructure configuration management; yet infrastructure dependencies such as versions and configurations of the operating system or web server are a common reason for deployment failures. Several chapters discuss this problem in detail. In principle, the authors say:

The desired state of your infrastructure should be specified through version-controlled configuration.

This leads to some thoughtful discussion of how to achieve this.

Another theme, as you would expect, is that development and operations people need to be working together and not in isolation. To some extent this is a DevOps book.

A great book then; but there are flaws. One is that there is some repetition because of the way the book is organised. This is good if you are inclined to read chapters in isolation, but not so good if you are reading straight through. In practice I did not find it too annoying, but it is there.

Another issue is that while the authors do cover Microsoft .NET to some extent, this is usually in the form of a brief mention and there is more focus on Java. This may be in part because of their preference for open source. It is still a good read for .NET developers, because the principles are platform-agnostic, but Microsoft platform developers may find it irritating at times. Team Foundation Server, say the authors, is “essentially an inferior knock-off of Perforce” (p 386).

The discussion of specific tools is a strength but also a weakness, in that the tools will change over time and the book will become dated.

This is not the last word on Continuous Delivery, but it is an enjoyable and thought-provoking read. Recommended.

 

Heroku gets Java, Salesforce.com embraces HTML5 for mobile

Salesforce.com has made a host of announcements at its Dreamforce conference currently under way in San Francisco. In brief:

  • Chatter, the Salesforce.com social networking platform for enterprises, is being extended with presence status, screen sharing, approval actions, and the ability to create groups with customers as well as with internal users. Salesforce.com calls this the Social Enterprise.
  • Heroku, a service for hosting Ruby applications which Salesforce.com acquired in 2010, will now also support Java.
  • Salesforce.com is baking mobile support into its applications via HTML 5. The new mobile, touch-friendly user interface is called Touch.salesforce.com.

image

Other announcements include the general availability of database.com, a cloud database service announced at last year’s Dreamforce, and a new service called Data.com which provides company information though a combination of Dun and Bradstreet’s data along with information from Jigsaw.

I spoke to EMEA VP Tim Barker about the announcements. Does Java on Heroku replace the VMForce platform, which lets you run Java applications on VMWare using the Spring framework plus access to Salesforce.com APIs? Barker is diplomatic and says it is a developer choice, but adds that VMForce “was an inspiration for us, to see that we needed Java language on Heroku as well.”

My observation is that since the introduction of VMForce, VMWare has come up with other cloud-based initiatives, and the Salesforce.com no longer seems to be a key platform. These two companies have grown apart.

For more information on Java on Heroku, see the official announcement. Heroku was formed in part to promote hosted Ruby as an alternative to Java, so this is a bittersweet moment for the platform, and the announcement has an entertaining analysis of Java’s strengths and weaknesses, including the topic “How J2EE detailed Java”:

J2EE was built for a world of application distribution — that is, software packaged to be run by others, such as licensed software. But it was put to use in a world of application development and deployment — that is, software-as-a-service. This created a perpetual impedance mismatch between technology and use case. Java applications in the modern era suffer greatly under the burden of this mismatch.

Naturally the announcement goes on to explain how Heroku has solved this mismatch. Note that Heroku also supports Clojure and Node.js.

What about Database.com, why is it more expensive than other cloud database services? “It is a trusted platform that we operate, and not a race to the bottom in terms of the cheapest possible way to build an application,” says Barker.

That said, note that you can get a free account, which includes 100,000 records, 50,000 transactions per month and support for three enterprise users.

What are the implications of the HTML5-based Touch.salesforce.com for existing Salesforce.com mobile apps, or the Flex SDK and Adobe AIR support in the platform? “We do have an existing set of apps,” says Barker. “We have Salesforce mobile which supports Blackberry, iOS and Android. We also have an application for Chatter. Native apps are an important part of our strategy. But what we’ve found is that for customer apps and for broad applications, to be able to deliver all the functionality, we’re finding the best approach is using HTML 5.”

The advantage of the HTML5 approach for customers is that it comes for free with the platform.

As for Adobe AIR, it is still being used and is a good choice if you need a desktop application. That said, I got the impression that Salesforce.com sees HTML5 as the best solution to the problem of supporting a range of mobile operating systems.

I have been following Salesforce.com closely for several years, during which time the platform has grown steadily and shown impressive consistency. “We grew 38% year on year in Q2,” says Barker. This year’s Dreamforce apparently has nearly 45,000 registered attendees, which is 50% up on last year, though I suspect this may include free registrations for the keynotes and exhibition. Nevertheless, the company claims “the world’s largest enterprise software conference”. Oracle OpenWorld 2010 reported around 41,000 attendees.

Java Standard Edition 7 is done, but feels like an interim release

Oracle has released Java SE 7:

Oracle today announced the availability of Java Platform, Standard Edition 7 (Java SE 7), the first release of the Java platform under Oracle stewardship.

image

What’s in Java SE 7? Despite the full version number increment, I am tempted to call this an interim release. In December 2010 the JCP approved the specification of both Java SE 7 and Java SE 8, with two of the more interesting features, Project Lambda and the Module system (Project Jigsaw), held back for Java SE 8. Java SE 7 does include the InvokeDynamic keyword which improves the performance of dynamic languages such as Ruby and Python running on the JVM, as well as most of the minor language enhancements known as “Project Coin”. There is also a Fork/Join framework to better support concurrent programming.

The good news is that Java SE 8 is set to follow in late 2012, not so long considering Java SE 6 was released in 2006 . You can see the roadmap summarised here. This post is from October 2010, but as far as I am aware it has not changed much since. 2012 is also when we can expect Java Enterprise Edition 7.

It is also worth mentioning JavaFX 2.0, set for release later this year. A handy summary of JavaFX 2.0 is here. Whereas JavaFX 1.0 was rushed out and features a new scripting language that in the end few wanted, JavaFX 2.0 is more promising. Dimitry Jemerov, developer of IntelliJ IDEA at JetBrains, told me earlier this year:

JavaFX is going to turn, when the version 2.0 is released, from a dead end resource sucker project into a set of distinct technologies of great immediate usefulness to many Java developers.

Is there still hope for Java on the client? Java is barred from Apple iOS which is a problem, and is no longer supplied as standard on Mac OS X, but it will still make sense for many business applications. Of course Java is also wildly successful in the context of Google Android, but that uses the Dalvik VM rather than the Java VM so is rather a different thing.

Update: As ever, upgrade critical machines with caution. In particular, Apache Lucene and Apache Solr do not work on Java 7 because of HotSpot optimization bugs.