If you follow the Java world, you'd have a hard time missing the announcements about Terracotta's BigMemory over the past few days. The module, a part of the open source Ehcache caching library, bypasses the traditional Java garbage collection mechanism and creates its own memory, which can be much bigger (thus the name!) than Java's GC heap. ]]>
If you follow the Java world, you'd have a hard time missing the announcements about Terracotta's BigMemory over the past few days. The module, a part of the open source Ehcache caching library, bypasses the traditional Java garbage collection mechanism and creates its own memory, which can be much bigger (thus the name!) than Java's GC heap. Access to data in this store isn't as quick as accessing the standard Java heap, but the elimination of traditional garbage collection will supposedly make up the difference.
Terracotta is of course touting this as a breakthrough. And to be sure, garbage collection's impact on performance has been a somewhat vexing issue since the earliest days of the platform, with elaborate support documents explaining how to tune your garbage collection just so. Terracotta's solution seems to cut this Gordian Knot.
On the other hand, most Java shops have already learned how to tune their apps for Java's GC. Thus, adopting BigMemory might well mean losing a lot of the work that went into building an application in the first place. In the end, BigMemory seems to fall into that category of tool that sacrifices finesse for ease of use. It will be interesting to see if new projects are more likely to start with it than old ones adopt it.
I'm off on vacation next week -- I'll be back on the 27th, perhaps with exciting news from JavaOne!
]]>Admittedly it's an elaborate exercise in rejiggered expectations, but Java on iOS (the operating system that runs the iPhone, the iPod, and the iPad) sort of became possible last week, or at least a bit more possible than it was before, and at least in theory. Of course, there isn't going to be any Java runtime or VM allowed on Apple's precious iOS -- oh, no, those hopes, which once seemed quite fond, were shot down years ago. But at least Java transcoding to iOS is possible, and that's something, right? ]]>
Admittedly it's an elaborate exercise in rejiggered expectations, but Java on iOS (the operating system that runs the iPhone, the iPod, and the iPad) sort of became possible last week, or at least a bit more possible than it was before, and at least in theory. Of course, there isn't going to be any Java runtime or VM allowed on Apple's precious iOS -- oh, no, those hopes, which once seemed quite fond, were shot down years ago. But at least Java transcoding to iOS is possible, and that's something, right? Right?
Basically, a few months ago Apple, which had never even considered allowing VM-based execution environments like Flash or Java on iOS, turned the screws even tighter, and forbade even those apps originally written in those languages and later ported to an iOS-compatible binary. This brought Apple-developer relations to something of a low point, and the decision was more or less quietly reversed last week.
The funny thing is that it's been the status of Flash that has driven all the press storylines on this subject. This is funny because, even with the revival of Adobe's Flash-to-iOS tool, there's no chance that Flash will do for the iOS what it does for the huge majority of its users: work in the browser. It'll just be another transcoded language, one of a list of many that could theoretically include Java. ZDNet was nice enough to name-check Java in its headline on the subject; and Jeff Martin an insanely hopeful talker on DZone implying that there might be some kind of big Apple-Oracle joint announcement about Java on iOS at JavaOne, which seems to miss the point the relaxation of developer rules are as big an announcement as anyone is going to get out of Apple.
It wouldn't be out of the question to see some announcements of third-party tools that would ease the conversion process, though. What projects are in the works now? xmlvm is active and tweeting happily about the changes to Apple's licensing, but it's not clear to me how mature their tech is.
]]>Mark Reinhold, the Chief Architect of the Java Platform Group, has announced the a delay in the anticipated release of the JDK, by at least a year. In fact, the Java community seems to be faced with two different choices: a two year pushback, to mid-2012, for an all-features-as-promised version of the JDK; or a release in the middle of next year that would exclude Projects Lambda (closures), Jigsaw (modularity), and Coin ("small language changes"), which would instead by rolled into a JDK release for late 2012. ]]>
Mark Reinhold, the Chief Architect of the Java Platform Group, has announced the a delay in the anticipated release of the JDK, by at least a year. In fact, the Java community seems to be faced with two different choices: a two year pushback, to mid-2012, for an all-features-as-promised version of the JDK; or a release in the middle of next year that would exclude Projects Lambda (closures), Jigsaw (modularity), and Coin ("small language changes"), which would instead by rolled into a JDK release for late 2012. This is by rights the cause of quite a bit of community hand-wringing, as closures (and to a lesser extent) the module system of Project Jigsaw have been among the most hotly anticipated features of the new JDK. Reinhold says the team is leaning towards the second course, and late 2012 seems like a long, long time away.
On a totally different point, though, Reinhold slips in this rather important parenthetical:
(As always, our intent is that JDK 7 will ship concurrently with a Java SE 7 JSR, and likewise for JDK 8 and Java SE 8, and also that there will be JSRs for Lambda and Coin.)
This may seem fairly straightforward, but it's worth noting that there has been some pessimism as to whether Java 7 (as opposed to JDK 7) would actually come to pass as a Java spec, due to Sun/Oracle's longstanding dispute with Apache and others over the licensing terms of the TCK. Stephen Colebourne lays out the reasoning here; Reinhold implies that Oracle, or at least his group within Oracle, wants a real live JCP-standardized spec.
]]>James Governor over at RedMonk has a nice wrap-up of new and interesting and important projects being backed by Java these days, so as to refute the "Java is dying" meme. I consider this meme to be something of a joke and tend to only deploy it ironically myself, but it is an important part of the Java discourse. The question that ought to arise is: what would a dying platform look like?
]]>James Governor over at RedMonk has a nice wrap-up of new and interesting and important projects being backed by Java these days, so as to refute the "Java is dying" meme. I consider this meme to be something of a joke and tend to only deploy it ironically myself, but it is an important part of the Java discourse. The question that ought to arise is: what would a dying platform look like?
To say that "a platform is dying when the cool kids stop using it" is silly, because the cool kids don't necessarily determine who uses a platform day to day (or, as Governor says, "if its in production, it's 'dead'"). Nevertheless, there are aspects of Java that aren't doing so well, and it's interesting to look at Governor's list and see what's been left out. None of the projects he mentions involve JavaFX, for instance, or Java ME. If I had to pick two realms of Java that are moribund (or, in the case of JavaFX, stillborn), those would be the two. But perhaps I am mistaken? Can you compile a list of interesting new projects based on those technologies? Feel free to pitch in in the comments.
]]>First VMware made SpringSource's flavor of enterprise Java the programming environment for its teamup with Salesforce.com; then Rod Johnson proclaimed that you could build apps in that environment that had little to do with Salesforce.com's core CRM functionality. ]]>
First VMware made SpringSource's flavor of enterprise Java the programming environment for its teamup with Salesforce.com; then Rod Johnson proclaimed that you could build apps in that environment that had little to do with Salesforce.com's core CRM functionality. Now it seems like this was just a trial run for the big announcement at VMware's VMworld conference, about the VMware Cloud Application Platform, which has SpringSource's tc server at its core. Developers can write Java apps for the Spring Framework and have them run in a variety of cloud environments that VMware supports, all without having to worry about writing the plumbing code to run in a distributed environment.
Java developers who want to build cloud-savvy apps (or VMware-based-cloud-savvy apps, anyway) are pretty lucky, as they've been given pride of place in the virtualization giants app dev plans. I'm not sure if VMware gobbled up SpringSource because they thought Java was good fit technically for their platforms, or just because they wanted quick access to a very large base of developers. But VMware Cloud Application Platform isn't going to be only about Java forever: Johnson says that the platform will soon support PHP, Ruby, and even .Net languages. That shouldn't be a big surprise (though it is interesting that Johnson, a Java guy, is heading up the effort). Still, Java's prominent role in this is a nice reminder that the old platform's still got it.
On an unrelated note, I once idly speculated that SpringSource could be next for an Oracle lawsuit, since one might see the Spring Framework as having the same relationship with Java EE and Android has with Java ME. But Johnson seems very much not worried about this; indeed, he's pretty upbeat on the future of the platform even taking the lawsuit into consideration.
]]>I respect James Gosling in several ways: both as a technical whiz and as a guy who managed to rise pretty far up in a big corporation without losing his soul or sense of idealism. Google may be using its newfound position as bullying victim for PR advantage, but Gosling has as near as I can tell no financial axe to grin in the conflict, and is motivated mostly by his vision for the platform he created. (In fact, if he has Oracle stock left over from his Sun compensation, he may be acting against his own financial self interest.)
]]>I respect James Gosling in several ways: both as a technical whiz and as a guy who managed to rise pretty far up in a big corporation without losing his soul or sense of idealism. Google may be using its newfound position as bullying victim for PR advantage, but Gosling has as near as I can tell no financial axe to grin in the conflict, and is motivated mostly by his vision for the platform he created. (In fact, if he has Oracle stock left over from his Sun compensation, he may be acting against his own financial self interest.)
But Gosling's latest move -- selling t-shirts asking Oracle to live up to its 2007 pledge to "release Java" -- is about as quixotic as you can get without actually tilting at windmills. Gosling wants JavaOne attendees to wear them to send a message at JavaOne, and if people as suggested wear them to "spend...quality time with an Oracle salesperson," they might succeed in making said salesperson feel uncomfortable. But the idea that they'll somehow change Oracle's trajectory strikes me as ludicrous.
The specific "pledge" that the t-shirts refer to pretty well exemplifies how little room for sentiment there is in modern corporate life. At a 2007 JCP meeting, Oracle proposed that the JCP be spun off from Sun as an "open independent vendor-neutral Standards Organization where all members participate on a level playing field." This was a useful suggestion at the time for Oracle, because it would have reduced Sun's power over Java and increased the say other companies (including Oracle) had over the platform. Oracle wanted Sun to have less power not due some ideological stance about what control in the abstract it felt the owner of Java should have, but because it would make things easier (and more profitable) for Oracle. Now that Oracle is the one who owns Java, it has no more interest in the proposed arrangement, because it would no longer be beneficial to Oracle's interests. That's the kind of hard-headed thinking that you don't influence with t-shirts.
Still, it can't hurt to wear them, can it? Check out Gosling's CafePress store if you're so inclined.
]]>The question of whether you'll be heading to JavaOne is more relevant than ever, now that Oracle's decision to sue Google over Java has so many Java developers roiled up. The spectacle of Larry Ellison giving the keynote speech will certainly be worth the price of admission, not least to see how hostile the audience gets. ]]>
The question of whether you'll be heading to JavaOne is more relevant than ever, now that Oracle's decision to sue Google over Java has so many Java developers roiled up. The spectacle of Larry Ellison giving the keynote speech will certainly be worth the price of admission, not least to see how hostile the audience gets. There's also been some cancellations of rather exciting tech sessions, like one on Scala and Clojure and another on JavaFX animation.
If that all bums you out, Software and Support Media is planning an American version of its Java Apache XML conference, with an inside source saying that the company is quite happy to poach developers disillusioned with Oracle. In fact, skipping JavaOne may be one of the easiest ways to hit Oracle in the pocketbook, as the conference was quite the moneymaker for Sun in its day, and still costs pretty penny to attend.
I imagine that most of the people who usually attend JavaOne will still show up, though. Computer programming as a discipline is particularly prone to people working alone in dark rooms, and a lot of people really enjoy the sense of community they get there. I think before people give all that up, they'll want to see for themselves how the vibe changes under new management. Keep a close eye on the commentary emerging from next week's conference, though, to see how 2011 might go.
]]>Interesting news from Bloomberg about BlackBerry's rumored BlackPad tablet. According to anonymous sources "familiar with the plans," the new tablet will run not a version of the BlackBerry OS, but a QNX variant. These sources "didn't know the specific reasons for the decision, though one person said it may have been simpler and faster to use QNX because the BlackBerry 6 includes legacy software code from older BlackBerry phones."
]]>Interesting news from Bloomberg about BlackBerry's rumored BlackPad tablet. According to anonymous sources "familiar with the plans," the new tablet will run not a version of the BlackBerry OS, but a QNX variant. These sources "didn't know the specific reasons for the decision, though one person said it may have been simpler and faster to use QNX because the BlackBerry 6 includes legacy software code from older BlackBerry phones."
BlackBerry OS is the grandaddy of smartphone operating systems, but like all such incrementally advancing systems, it no doubt contains a lot of cruft; one can see the appeal to RIM of going with a whole new system. (RIM bought QNX back in the spring; at the time, speculation was that the move was about car integration.) It's not out of the question that RIM might hope to move its new QNX-based OS to next-generation BlackBerry handhelds if the BlackPad system goes well.
But one potential big loser in such a move would be the Java ME platform. Right now BlackBerry OS is the only major high-end smartphone platform with a development environment primarily based on Java ME. It seems likely that there would be some kind of bridging environment that would allow existing BlackBerry apps to run under the new system. But QNX is a Unix-like system with POSIX APIs, and could support a wider range of programming languages; RIM may not want to pay Oracle for those Java ME licenses any longer than necessary. It could be another nail in the coffin for the mobile Java platform.
]]>So Oracle has two distinct claims in its lawsuit against Google over Android: copyright violation and patent violation. The copyright claims are extremely vague and its hard to see how they could apply, given that what Java code Android does contain comes from the open source Apache Harmony project. I suppose it's possible that Oracle will make a SCO-like claim that some source code that they owned was open-sourced without their consent, though this seems improbable. More likely this is a "let's throw this in and see if anything sticks" clause.
]]>So Oracle has two distinct claims in its lawsuit against Google over Android: copyright violation and patent violation. The copyright claims are extremely vague and its hard to see how they could apply, given that what Java code Android does contain comes from the open source Apache Harmony project. I suppose it's possible that Oracle will make a SCO-like claim that some source code that they owned was open-sourced without their consent, though this seems improbable. More likely this is a "let's throw this in and see if anything sticks" clause.
The patent claims are the main event. If, as I'm guessing many Java enthusiasts do, you'd like to see them dismantled, read this longish post from longtime Java developer Charles Nutter, who regards most of them as overly broad, obvious, or invalidated by prior art. This is a fairly typical response of a well-informed technical non-lawyer to software patents; unfortunately, it hasn't always been borne out in court, and patent cases are decided in court, not on blogs.
James Gosling also put up an amusing blog post in which he reveals that Sun didn't get serious about software patents until it lost a patent fight with IBM, at which point Sun's legal department demanded patents on everything. Sun's engineers apparently treated this as a lark, trying to see who could get the goofiest patent accepted by the PTO. He seems fairly careful to not come out and say that any of the patents used as a basis for the lawsuit are a result of this competition, but it sure would be intriguing to call an ex-Sun engineer to the stand to say that the patent had been filed in bad faith. We will have to wait and see how it turns out -- and at the rate that the legal system moves, we'll have a long time to wait.
]]>Oracle's move to sue Google over Android is, if a surprise, then not a shock. Oracle has a reputation of playing hardball; Android was a direct threat to Oracle's Java ME business. The question is: is this just the first of many lawsuits over technology that Oracle thinks it has a right to? And if so, who's next?
]]>Oracle's move to sue Google over Android is, if a surprise, then not a shock. Oracle has a reputation of playing hardball; Android was a direct threat to Oracle's Java ME business. The question is: is this just the first of many lawsuits over technology that Oracle thinks it has a right to? And if so, who's next?
One candidate that popped into my mind the moment I got my head around the nature of the lawsuit was SpringSource. In some ways, the Spring Framework and Spring's tc Server is the enterprise mirror of Android. Android offered an alternative to the restricted and fragmented Java ME platform, based on the Java SE platform that was more familiar to developers; the Spring Framework is an open source alternative to Java EE, without a lot of the enterprise-y cruft in the Java EE spec that many developers don't need. Android avoids the need to pay for Java ME licensing; I'm not sure if vendors need to pay Oracle to get their app servers Java EE certified, though it seems likely to me (I'd love to hear from someone who knows for certain). Android and the Spring tc Server are even both built atop Apache projects (Harmony and Tomcat, respectively).
I'm not the only one worried, but it's important to note that there are differences, too. Perhaps more important is the fact that Android represents an existential threat to Java ME as a platform. As processors become more and more powerful, there's no reason why the Java ME platform, optimized for resource-restricted environments, will be necessary at all, and platforms like Android, built from the ground up for modern mobile processors, will have a big advantage. And Java ME wasn't necessarily taking the market by storm even before Android came onto the scene. By contrast, the Java EE server market is pretty healthy -- and as server chips too become more powerful, the need to for a slimmed-down enterprise Java alternative like Spring might fade somewhat.
Still, anyone building on the Java platform that doesn't have Oracle's seal of approval is officially on notice. It's possible that lawsuit against Google is really about Google and Android in particular, that Oracle sees Android as a looming threat that has to be dealt with now. But it's also possible that it's the equivalent of picking a fight with the biggest guy in the yard on your first day in prison -- it's not just about that fight, but about sending a message to others as well. EMC, SpringSource's ultimate corporate parent, may not be Google, but it's pretty big too -- and Oracle may feel like taking it down a notch.
]]>Usually I update this blog on Mondays and Wednesdays, but obviously there's been a big news story that can't really wait. To read my immediate take, check out the post I wrote on InfoWorld's Tech Watch blog, "Oracle launches scorched-earth fight to profit from Java." More in depth discussion coming next week!
]]>Usually I update this blog on Mondays and Wednesdays, but obviously there's been a big news story that can't really wait. To read my immediate take, check out the post I wrote on InfoWorld's Tech Watch blog, "Oracle launches scorched-earth fight to profit from Java." More in depth discussion coming next week!
]]>Continuing with our Java tooling theme, we come to a couple of developments from Oracle on IDEs. The higher-profile one is the release of the Oracle Enterprise Pack, a free set of plug-ins for Eclipse. There isn't anything terribly new here, and the motivation is fairly transparent; as the Inquirer dryly puts it, "Oracle is hoping that by giving developers who use Eclipse an easier ride, more will incorporate its Fusion Middleware software into their applications."
]]>Continuing with our Java tooling theme, we come to a couple of developments from Oracle on IDEs. The higher-profile one is the release of the Oracle Enterprise Pack, a free set of plug-ins for Eclipse. There isn't anything terribly new here, and the motivation is fairly transparent; as the Inquirer dryly puts it, "Oracle is hoping that by giving developers who use Eclipse an easier ride, more will incorporate its Fusion Middleware software into their applications."
The other IDE announcement is lower profile, and it involves the NetBeans platform Oracle inherited from Sun. Plans for the next point release of NetBeans, 6.10, have been announced; according to The H, NetBeans' "developers aim to unify the user experience when using different Java EE servers, especially WebLogic and Glassfish 3.1." That's a particularly interesting ambition, considering that NetBeans is much more closely associated with the free and open source Glassfish app server than it is with Oracle's enterprise offerings. It looks like Oracle is going to at least try the oft-suggested technique of using open source offerings as a gateway to paid products: perhaps if developers favorite IDE can help them make that transition, corporate dollars will follow?
]]>A few weeks ago I discussed Oracle's crowded IDE picture, then noted that Google's new IDE, aimed at non-programmers, made quite a splash. Google seems to be trying to get itself into the "real" tooling market with its acquisition of Instantiations, which, amongst other things, makes a highly regarded GUI designer for the Java-backed Google Web Toolkit.
]]>A few weeks ago I discussed Oracle's crowded IDE picture, then noted that Google's new IDE, aimed at non-programmers, made quite a splash. Google seems to be trying to get itself into the "real" tooling market with its acquisition of Instantiations, which, amongst other things, makes a highly regarded GUI designer for the Java-backed Google Web Toolkit.
Most observers seem to think that this was in fact the driver behind Google's buy. The question that arises is, what exactly does Google plan to do with this new tool? Instantiations makes other Java tooling products, and Google got all of them (the company's Smalltalk business will be spun off under the original ownership), though they don't seem directly relevant to Google. It would be interesting Google plans to support its own series of tools to support its own stable of technologies -- TechCrunch's MG Siegler speculates that Instantiations' Java tools could be adopted specifically for Android. Google might be seeking, if not the level of lock-in Microsoft has with Visual Studio, then at least an ecosystem that it can control that is closely aligned with developers' work on apps for Google platforms. Seeing which products from this company Google promotes and continues work on might be a good bellwether for the company's Java ambitions.
]]>The evolution of tech companies over the years and decades is something of interest to me, and Salesforce.com is in the midst of a change that I find particularly intriguing. Born as a CRM service company that happened to offer its functionality over the Internet, it has come to realize that perhaps its greatest asset is the virtualized infrastructure it built to provide those services to customers. The upcoming VMforce team-up with SpringSource is a big jump in that direction. ]]>
The evolution of tech companies over the years and decades is something of interest to me, and Salesforce.com is in the midst of a change that I find particularly intriguing. Born as a CRM service company that happened to offer its functionality over the Internet, it has come to realize that perhaps its greatest asset is the virtualized infrastructure it built to provide those services to customers. The upcoming VMforce team-up with SpringSource is a big jump in that direction. The thrust of the announcement of that product involved integrating SpringSource-based Java apps with existing Salesforce.com setups; but VMware head Rod Johnson told Network World that you need not have any interest in Salesforce.com's CRM offerings:
"The absolutely killer app for it is where you have Salesforce data," and need to build enterprise-class applications that boost the capabilities of Salesforce while interacting with that data, Johnson says. "It will enable people to build applications and technology from anywhere and get excellent performance because it runs in the same data center. "But [VMforce] is certainly not limited to that," he adds. "It will also be capable of running general enterprise Java applications. You can go build any application you'd like and benefit from Salesforce's operational experience."
While obviously having more customers is good, I do wonder if this is something of a devil's bargain for Salesforce.com. They're essentially giving up virtually any kind of customer-facing role in this proposed ecosystem and simply providing the plumbing that the apps run on. And in fact Johnson says that this really should be the whole point of how apps are written for the cloud:
"As a developer, you shouldn't be writing any code that knows about a particular hypervisor ... You shouldn't really be writing code that knows about the infrastructure-as-a-service layer, period. If you're going to write a platform-as-a-service application, you absolutely don't want to have any knowledge in your application of hypervisors, or provisioning, because if you do that, firstly your application will end up more complicated than it was in the traditional enterprise, and secondly you do couple yourself to a particular technology stack."
Presumably, under this model if an offer better than that from Salesforce.com came along, you could just move your application over to it. But -- and here's where SpringSource wins -- you would have already written it with the Spring Framework, which is open source an will no doubt be adapted to many a cloud platform. People who already use Salesforce are probably locked in, but if you're just trying out VMforce because you're interested in Java cloud computing in general, you'd be much more likely to roam.
]]>The beta version of Tomcat 7 came out last week. This is a Big Deal! Tomcat has been at various times the reference implementation of Java Servlets, and Tomcat 7 now includes support for the latest version of the Servlet spec. Then there's GlassFish -- once Sun's, now Oracle's. ]]>
The beta version of Tomcat 7 came out last week. This is a Big Deal! Tomcat has been at various times the reference implementation of Java Servlets, and Tomcat 7 now includes support for the latest version of the Servlet spec. Then there's GlassFish -- once Sun's, now Oracle's. While still crucial to the whole Java project as the reference implementation of Java EE, many people have questioned Oracle's commitment to it, as it competes with Oracle's other (paid, closed source) app server offerings. The official GlassFish roadmap still exudes optimism, but Douglas Dooley is glummer, suggesting that the GlassFish team is starved of resources.
The two servers are important rivals, in a sense: Tomcat is the foundation for SpringSource's server offerings, and SpringSource is of course conceived of as an alternative to the Java EE for which GlassFish is a reference implementation. Thus it's important for SpringSource that Tomcat is moving forward as it is. The flipside is that GlassFish is important for Java EE, which makes its own progress important for Java as a whole. Dooley suggests that it just be handed over to Google, which may make something interesting of it; the chances of this happening strike me as essentially nil, but lacking obvious investment from Oracle it's hard to say what the benefit to anyone keeping it where it is might be. Just keeping it so that nobody else can have it isn't a helpful reason to control something; but it may be that it's the whole rationale behind Oracle's takeover of Java in the first place.
]]>