Graham Lee discusses some of the vulnerabilities that may affect Objective-C programming, offering solutions to avoid them. By Graham Lee

Let's take a quick look at what happened in AWS-land last week: Monday, August 27 New AWS Report interview, Chris Wheeler discusses the Amazon Simple Email Service (SES). Friday, August 31 Amazon S3 now supports Cross Origin Resource Sharing (CORS)....

The Enterprise Java 2.0 TechTalk at gameduell.com HQ in Berlin was recorded and is available online: It was a nice evening. Thanks for the questions and especially late night conversations! Real World Java EE Bootstrap and Effective Java EE Bootstrap Workshops [Airport Munich]

Hackers are distributing rogue email notifications about changes in Microsoft's Services Agreement to trick people into visiting malicious pages that use a recently circulated Java exploit to infect their computers with malware.

Breaking promises is something that Oracle seems to be doing a lot of at that moment. Just after the dust has settled from the Project Jigsaw debacle, there’s been yet another setback in Oracle’s Java roadmap, after it emerged that key cloud features look set to miss out on Java EE 7. In a blogpost  late last week, spec lead for the next enterprise version of Java (JSR 232) Linda DeMichiel revealed a variety reasons for their latest proposal to postpone: Despite our best intentions, our progress has been slow on the cloud side of our agenda. Partially this has been due to a lack of maturity in the space for provisioning, multi-tenancy, elasticity, and the deployment of applications in the cloud. And partially it is due to our conservative approach in trying to get things "right" in view of limited industry experience in the cloud area when we started this work. It sounds to us that Oracle bit off more than it could chew when it spent much of 2011 proclaiming that Java EE 7 would finally bring enterprise-grade cloud support. In fact, the introduction of multi-tenancy was to be the big draw for the release, as was the inclusion of a APIs made for seamless cloud environments. De Michiel went on further to explain that for Oracle to provide solid standardisation, it would delay the release of Java EE 7 until Spring 2014 at the earliest, and two years behind schedule. Unlike the Project Jigsaw announcement, which split the community down the middle, this decision has been commended appears to be the correct one, with names coming out in support of this proposal, notably those who sit on the Java EE 7 Expert Group. Red Hat’s Pete Muir wrote: Speaking as a Java EE implementor, we (Red Hat) are very much in support of this. We've long advocated that we, the Java EE community are not ready to standardise cloud yet, and feel this is proven by OpenShift, our Java EE cloud offering, which is working well with Java EE 6. Speaking as a spec lead, we're also in support of this, modulo understanding and agreement on what this means for the schedule of the specs we lead (CDI and Bean Validation). TomEE creator David Blevins wrote on the Java EE platform mailing list that he found it “to be quite a relief”, adding that whilst “Java EE is already 90% cloud-ready due to its focus on clear packaging, deployment and portability” the unmet 10% of cloud needs are in a “time of experimentation, not standardization”. We couldn’t agree more with him here. To even think about standardizing what is a market in flux was a bad move to begin with, and at least Oracle have heeded the warning before it was too late. As has been shown by Red Hat’s OpenShift and VMware’s Cloud Foundry, platform-as-a-service is still very much a blank canvas for testing new ideas. As alluded to in DeMichiel’s blogpost, Oracle understand that several vendors - such as Red Hat and CloudBees - are already partially providing some of Java EE specification in their cloud solutions. For them to wade in and start afresh just didn’t make sense. It’s quite clear that Oracle seem more interested in pursuing options alongside other vendors with the big reveal last week of CAMP - an early draft for interoperability across the board to ease private and public cloud management. That’s something which is definitely not mature enough to chuck into a Java EE 7 specification, so it’s well worth Oracle’s while to flesh it out, alongside those already well invested in cloud technologies. Undoubtedly, competitor input is invaluable to the future cloud-focused moves for Java EE 7. So what does this mean for the enterprise roadmap? In terms of what stays in Java EE 7, we can expect HTML5 advances with the addition of Web Sockets and JSON-P and the JAX-RS 2.0 client API. To us, this is a bit wafer-thin compared to the proclamation of 12 months ago, but is admittedly the right decision for Java EE 7. Should the Expert Group ratify the decision, the multi-tenancy aspects will be bumped until at least the spring of 2015. With Oracle’s recent tardiness (they’ve already pushed Java EE 7 back once), don’t take that as gospel. From the outset, this looks like another dark day for Oracle when it was the only call to make. Java EE is certainly not ready for standardised cloud features just yet, and anyone wanting a more advanced feel should look to a third party vendor. If Oracle are guilty of anything here, it was that they rushed in too soon with claims they had no chance of fulfilling to a releasable standard. The real concern here is that both Java SE 8 and Java EE 7 look a bit barren of innovation. With nothing gamechanging about the new releases, you'd expect many will stick to what they’ve got and that doesn’t bode well down the road for Java. Crucially, will enterprises care when they get their second bite at the cloud cherry?

At the back end of last week, Oracle finally caved to days of increasingly negative press over the security holes in Java SE, releasing an emergency patch intended to fix all outstanding issues. While hardly making up for months of ignoring security researchers’ warnings, it at least silenced critics (like us) worrying that it would be neglected until the next security update, scheduled for October. Unfortunately, it appears that even this hasn’t been enough. Adam Gowdiak of Security Explorations, who last week revealed that Oracle had failed to act on known exploits since April, delivered another blow to the company by revealing on the Bugtraq mailing list that “not all security issues that were reported in Apr 2012 got addressed by the recent Java update”. Today we sent a security vulnerability report along with a Proof of Concept code to Oracle. The code successfully demonstrates a complete JVM sandbox bypass in the environment of a latest Java SE software (version 7 Update 7 released on Aug 30, 2012). The reason for it is a new security issue discovered, that made exploitation of some of our not yet addressed bugs possible to exploit again. So, if Gowdiak’s accusations are legitimate, it appears Java is still insecure. Which is bad enough by itself - but made yet worse by Oracle’s failure to acknowledge it. Over on Ars Technica, Dan Goodin reports that the company responded to a request for comment by directing him to Thursday’s security advisory, which was published before this latest news broke (update: we recieved the same response). Meanwhile, in the post’s comments thread, readers argued over whether uninstalling Java was a necessary protective measure. So a week on, what has been achieved? Very little, it seems: Oracle are still failing to engage with (understandably) worried users, and browsing with Java installed is still potentially insecure. But this time the situation is even worse, since convincing your average user to download two updates within such a short space of time will be a considerable challenge. From our point of view, there are two measures Oracle needs to take: bake an auto-updating security mechanism into Java, with updates at least once a week; and just as importantly, be honest and transparent about these issues - before the negative press spills outside of the tech community bubble.

JAX-WS stands for Java API for XML Web Services. It is a Java programming language API for creating web services and clients that communicate using XML. This post is a quick start for JAX-WS. Prerequisites GlassFish integrated with Eclipse. Preview Text: JAX-WS stands for Java API for XML Web Services. It is a Java programming language API for...

In this presentation, SpringSource's Josh Long and Spring Roo in Action authors Ken Rimple and Srini Penchikala introduce Spring Roo, 1.2, and then go further, exposing Roo's powerful addon-based underbelly. Preview Text: In this presentation, SpringSource's Josh Long and Spring Roo in Action authors Ken Rimple and Srini Penchikala introduce...

Today's post will focus on why and how we use the concepts known as LAZY and EAGER loading in an application and how to use Spring's hibernate template to load our LAZY entities in an EAGER fashion. And of course as the title itself suggests, we will show this by an example. The scenario is as such; Preview Text: Today's post will focus on...

While Java 8 is coming, are you sure you know well the enums that were introduced in Java 5? Java enums are still underestimated, and it's a pity since they are more useful than you might think, they're not just for your usual enumerated constants! Java enum is polymorphic Java enums are real classes that can have behavior and even data. Let's represent the Rock-Paper-Scissors game...

Recently, I tried to help a teammate design a WSDL file. I gently drove him toward separating the interface itself in the WSDL file and domain objects in a XML Schema file. One thing leading to another, I also made him split this XSD into two separate files, one including another for design purposes. Alas, tests were already present, and they failed miserably after my refactoring,...