The Big Announcement: Closures in JDK 7!
]]>The Big Announcement: Closures in JDK 7!
The biggest current news in the Java world is the apparent reconsideration by Sun regarding the addition of closures to JDK 7. Mark Reinhold's Devoxx announcement has led to many posts on the subject including Stephen Colebourne's Closures in JDK 7, Alex Miller's Closures After All?, Ted Neward's Closures Are Back Again, Cay Horstmann's Closures? In Java 7???, Mitch Pronschinske's Closures Coming to Java 7, Geertjan Wielenga's Devoxx Day 3: Conference Day 1, and a summary of some of these posts in the Java.net editorial DEVOXX Surprise: Out of Nowhere: Closures in JDK 7!
The collective excitement, concern, confusion, and questioning attitudes represented by these posts is likely indicative of the general Java community's feelings regarding this announcement. I have blogged before regarding closures being (at that time we thought based on last year's Devoxx announcement) one of the most-missed features to not be included in Java 7. Dionysios G. Synodinos summarized, in Java 7 Roadmap Updated: Reactions, several online reactions (including mine) to the 2008 Devoxx announcement that closures were being omitted from JDK 7. The Java.net poll on most-missed Java 7 features showed closures being the most voted for "missed feature" with nearly half the votes. Even James Gosling has weighed in with his favoring of closures in Java. The JSR Proposal for Closures in Java also lists individuals and organizations particularly interested in Java closures. Closures are clearly popular with Java developers who read and write regularly in the blogosphere.
What Are Closures?
For those who are not familiar with closures, Martin Fowler's post Closure is perhaps the definitive explanation of what constitutes a closure. Fowler states about closures: "Essentially a closure is a block of code that can be passed as an argument to a function call." Fowler compares and contrasts closures with anonymous classes and highlights closures as syntactically simpler than anonymous classes and able to see variables available at time of closure definition.
Besides Fowler's Closure post, other useful introductions to closures can be found in the Groovy User Guide section on Closures (defines closures as "A Groovy Closure is like a 'code block' or a method pointer.") and in the Wikipedia entry on closures.
What Are the Java Closure Proposals?
The JavaWorld article Understanding the Closures Debate lays out the three most popular proposed alternatives for closures in Java. The three primary proposals for Java closures are BGGA, CICE, and FCM.
The BGGA proposal is named after the first letter in the last names of each of its original authors: Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahe. It is often referred to as the "full closures" proposal and was by far the most popular of the three options voted on in this Java.net poll.
The FCM (First Class Methods) closure proposal is the one closest to the example syntax Mark Reinhold reportedly wrote on the airplane ride to Devoxx and it sounds like FCM 0.5 is considered the starting point for Java 7 treatment of closures. It currently sounds like the Java 7 implementation would exclude inclusion of the Java Control Abstraction (JCA) features.
A third Java closures proposal is the Concise Instance Creation Expressions (CICE) proposal by Josh Bloch, Doug Lea, and Bob Lee proposes "a more concise syntax to instantiate anonymous classes." Bob Lee's introduction of CICE closure proposal compares it to the BGGA proposal. Elliotte Rusty Harold has posted his complaints about the CICE proposal.
The blog post Comparing Inner Class/Closure Proposals compares the three above proposals and throws the Clear, Consistent, and Concise (C3S) for Java proposal into the comparison.
Additional Resources
Another good resource regarding Java and closures is Brian Goetz's The Closures Debate. The Closures Syntax in Java 7 Twiki page and Alex Miller's Java 7 page have numerous links to additional information on closures in Java.
]]>If you're worked up over the post-merger future of the Java platform, you owe it to yourself to read Peter Wayner's longish piece on this very Web site! It is quite soothing, and you can imagine it being read aloud in the calm, ration voice of a public radio announcer. ]]>
If you're worked up over the post-merger future of the Java platform, you owe it to yourself to read Peter Wayner's longish piece on this very Web site! It is quite soothing, and you can imagine it being read aloud in the calm, ration voice of a public radio announcer. The thesis goes something like this: Java could be wrecked by Oracle heavy-handedness driving wedges between it and other big companies with big Java stakes, and it could be supplanted by other, hotter and noisier, languages. But it probably won't, because of inertia! Well, OK, "inertia" sounds bad; let's say because of a huge pool of happy Java developers, and a huge number of installed JVMs, which are really doing just fine for most things people use them for. I quibble with some of his details -- I particularly doubt that even the biggest, most lumbering company would pay "$100, $200, or even $1 million per CPU to avoid recoding their Java EE applications" -- but in general I think he's right: Java is here to stay because you can't just turn it off, and if it gets screwed up everyone would suffer.
This is not exactly the stuff of enthusiasm building! I got my very first real job in 1999 as a copy editor for the group that was putting JavaWorld out in those days, and the technology had buzz then -- certainly more than some of our other publications, like SunWorld (which focused on Solaris) and Windows TechEdge (which was for NT admins, whee!). Java was innovative, weird, and was going to take over the world, maybe. Now it's everywhere, like everyone dreamed. If there are no more worlds left to conquer, well, it's big enough that it won't go away any time soon, either.
And who says you can't teach an old dog new tricks? The much-desired advent of closures in Java 7 may be on the horizon! So, despite the grumpiness that often comes to the fore in this blog, I do believe that Java has a steady future, that may even feature some excitement now and then.
]]>Without a doubt, the burst of innovation occurring in the open source world over the last few years has led to an increase in developer productivity, baby. Freely available tools, frameworks, and solutions address once-common time sinks. Apache’s CouchDB is no exception. It’s amazingly easy to get going with CouchDB once you have it up and running.
]]>Without a doubt, the burst of innovation occurring in the open source world over the last few years has led to an increase in developer productivity, baby. Freely available tools, frameworks, and solutions address once-common time sinks. Apache’s CouchDB is no exception. It’s amazingly easy to get going with CouchDB once you have it up and running. And all you need to work with it is an HTTP connection; no JDBC driver is required, nor do you need a third-party administrative-management platform.
In this article published by IBM DeveloperWorks entitled “REST up with CouchDB and Groovy’s RESTClient“, you’ll meet CouchDB and see how you can rapidly get up to speed with using it. For ease of installation, you’ll take advantage of Amazon’s EC2 platform and you’ll RESTfully communicate with CouchDB via a handy Groovy module dubbed HttpBuilder. If you ask me, it can’t get any cooler, man!
If you enjoy these kind of technologies, then have a look at some other related articles like:
So what are you waiting for? Read on!
Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.
]]>
Those of you who've seen me speak on Java 7 at various conferences have heard me lament
(in a small way) the fact that Sun decided last year (Dec 2008) to forgo the idea
of including closures in the Java language. Imagine my surprise, then, to check my
Twitter feed and discover that, to everyone's surprise, closures are
back in as a consideration for the Java7 release.
Several thoughts come to mind:
]]>
Those of you who've seen me speak on Java 7 at various conferences have heard me lament
(in a small way) the fact that Sun decided last year (Dec 2008) to forgo the idea
of including closures in the Java language. Imagine my surprise, then, to check my
Twitter feed and discover that, to everyone's surprise, closures are
back in as a consideration for the Java7 release.
Several thoughts come to mind:
In the meantime, if you want to keep on top of the Java space, maybe it's time to consider
a trip to Antwerp this time next year, since, if the new ship date rumors are
to be believed, it looks like Sun (once again) is planning to use Devoxx as
the platform from which to make a large announcement, this time the release Java7
itself.
Update: Ola Bini noted
that...
Two things:
which prompted me to respond thusly:
First off, I actually never used the term "anonymous function"; instead,
I said "anonymous method", which, as I understand it, is how the underlying
implementation of these proposals will work: the syntax "#() return 42"
will create an anonymous inner class instance of an interface defined by the library
(in its "SimpleClosure" example, the BGGA compiler uses the interface "javax.lang.function.I",
which has one method on it, "invoke()"), which, thus, makes this an anonymous
method. We can't call them "anonymous functions" because Java has no function
type, and probably never will. (And yes, it may seem like we're splitting hairs somewhat
to differentiate between functions and methods,but once you've explored ML, Haskell,
Scala, or F#, you really begin to see a huge difference in those terms, so it's important
to be precise with our terminology, or else the conversation becomes almost entirely
meaningless.)
Neal Gafter uses the definition "A closure is a function that captures the bindings
of free variables in its lexical context." (http://gafter.blogspot.com/2007/01/definition-of-closures.html) Given
that said same post also claims that Java has no function type (and therefore, by
his definition, can't really have a closure), I suppose we could split the hairs even
further and suggest that Java will never have closures until it has true function
types. Personally, I'm happy to say that we can swap in "methods" for "functions"
in this particular discussion, but my understanding is that capturing free variables
also implies capturing variables referenced in the enclosing lexical context, which
the current "closures" proposal (as reported by Alex Miller's closures page)
will not do. (Non-final enclosing parameters will not be accessible, only those passed
in formally as parameters. Stephen
Colebourne reports as much: "[Mark Reinhold] also indicated that access to
non-final variables was unlikely.")
Given that the current proposal suggests the new #() syntax will essentially generate
an anonymous inner class with a method of the appropriate signature (though I do believe
that method handles are targeted for use at some point, based on what I've been hearing
through the rumor mill), to me it feels like the "closures" implementation
is generating an anonymous method of an anonymous class with a few other restrictions
included--hence my commentary above.
(Having said all that, the FCM
proposal does provide complete capture of all referenced variables in enclosing
scope, but Mark's keynote hasn't officially endorsed either the BGGA proposal or the
FCM proposal, and if Sun keeps to their habits, they won't. They'll build something
that's an amalgamation of all of them. Right now the current consensus seems to be
to adopt the BGGA implementation behind the FCM syntax, which jives with Neal's 0.6a
specification proposal.)
On top of that, the comment "all of these will be closures, since they will be
closing over the this at least" is not, I don't think, entirely true. The details
of the closures proposal aren't clear, but the "outer this" (which I believe
is the "this" Ola refers to above) hasn't been explicitly mentioned in any
of the closures proposals I've seen, nor have I seen any text suggesting that they
will honor it, so I don't know that this is true. Of course, in absence of a specification
or real working bits, all we can do is just speculate. However, having said that,
playing around a bit with the BGGA prototype compiler (which, admittedly, is still
one minor rev back from Neal's revised proposal), I saw no generated "outer this"
in the generated code for the generated inner class implementation of the closure.
If the comment above is meant to refer to the "this" of the inner class
instance, then that would make all methods of an object-oriented language that provided
an implicit "this" a closure, and somehow I doubt that's what Ola means,
though I could, as always, be wrong.
As for the runtime implementation, as I said earlier I believe the plan is to use
method handles (already on the table for JDK 7), which do have some runtime implications
(generally good ones, from what I can tell so far), but not beyond what was already
on the table for 7.
Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.
Is Android a Java platform? It's certainly Java-esque, in the sense that for the most part you write apps for it in Java code. But it's not blessed by Sun or tested for compatibility -- in fact, it's incompatible with standard Java in several specified ways; its VM isn't an official JVM; and, to make things wackier, the Java it's based on is Java SE, not Java ME. This drives folks like Hinkmond Wong, Sun's Java ME blogger, crazy. ]]>
Is Android a Java platform? It's certainly Java-esque, in the sense that for the most part you write apps for it in Java code. But it's not blessed by Sun or tested for compatibility -- in fact, it's incompatible with standard Java in several specified ways; its VM isn't an official JVM; and, to make things wackier, the Java it's based on is Java SE, not Java ME. This drives folks like Hinkmond Wong, Sun's Java ME blogger, crazy. But you can make a decent argument that the sorry, fragmented state of Java ME brought made Android inevitable. With its crazy quilt of different implementations on various handsets and OSes, Java ME was never going to be the platform for the next generation of desktop-quality apps; a new platform was necessary to help Java code take over the mobile world.
Except! It turns out that Android is hitting all the same fragmentation problems as Java ME, and in record time! Not only are there three different versions of the Android OS out in the wild at the moment, but different handset manufacturers customize the platform and add their own specialized ROMs, with the result that code that runs on one phone completely borks out on another.
You can say a lot of negative stuff about how Apple handles the iPhone -- their arbitrary rejection of apps based on content is particularly egregious. But I think that their basic model, in which they tightly control the both the OS and the hardware, is boon for developers. It may be that the only way to have a platform that is truly standardized is to have one company in charge of it. Microsoft was essentially able to impose a more-or-less standard x86 platform spec on PC manufacturers by the sheer power of its monopoly, but nobody has ever managed to do the same for cell phones. Android was supposed to be developers' great hope, but it may be another sign that a truly interoperable platform can't be built by multiple companies with competing agendas. And that's something that ought to interest Java developers, whether they care about cell phones or not.
]]>I wrote about Groovy Shell in my last blog post. As I wrote in that post, Groovy Shell is a highly useful command line based method for experimenting with Groovy code. For those who prefer a graphical interface over the command line interface, Groovy Console provides a nice alternative and that is the subject of this blog post.
]]>I wrote about Groovy Shell in my last blog post. As I wrote in that post, Groovy Shell is a highly useful command line based method for experimenting with Groovy code. For those who prefer a graphical interface over the command line interface, Groovy Console provides a nice alternative and that is the subject of this blog post.
Assuming Groovy is appropriately installed on one's system with GROOVY_HOME defined correctly, it is easy to run the Groovy Console by simply typing groovyConsole at the command line. The next screen snapshot shows the running of Groovy Console along with the output from selecting Help->About.
It is easy to enter Groovy code and execute it (by clicking on the icon on the far right with the green arrow pointing right). The next two screen snapshots show entering Groovy code in the top pane and then the results of clicking on that "Execute Groovy Script" button in the bottom pane. Color coding helps make the scripts and the output more readable.
The Groovy Console supports larger fonts. The next screen image shows the results of selecting View -> Larger Font multiple times.
This image also shows a simple script for getting the date/time from Calendar using Groovy's property access syntax. Instead of needing to call getInstance() on Calendar and getTime() on the returned Calendar instance, I was able to access those directly with .instance.time.
Groovy Console allows one to select whether shortened or full stack traces should be displayed. The following two screen snapshots demonstrate the difference between the normal (shortened) stack traces and full stack traces. To turn on full stack traces, one selects View -> Show Full Stack Traces.
In this case, it is easy to deal with the stack trace. All that needs to be done is to import the Color class as shown in the next screen snapshot (classes in java.awt package are not automatically imported in Groovy).
Groovy Console supports numerous other useful features. Scripts can be saved to disk once they do what the developer wants. JAR files and directories can be added to the Groovy Console classpath for custom Java classes used by Groovy scripts. The Groovy Console page lists many more useful features of Groovy Console such as the ability to host Groovy Console as an applet and the ability to embed Groovy Console in Swing-based applications.
Another useful graphical approach to playing with Groovy code is the Groovy web console deployed on Google App Engine.
]]>Because it’s my bag, I’ve recently taken to learning Scala.
]]>Because it’s my bag, I’ve recently taken to learning Scala. In particular, I’ve run across some situations where I’ve known instinctively that a more functional language (i.e. one that avoids state and mutability) would have perhaps made the task at hand a bit easier or at least safer to code (think situations involving threads (i.e. concurrency), for instance). And while I’ve thus far handled those situations with various libraries and frameworks on the JVM (either straight Java or via Groovy), Scala has always held my interest in that the language is functional by nature — that is, functional aspects are intrinsically present as opposed to added in or forced via additional libraries, etc.
One of my favorite techniques for learning a new language is to leverage it via a testing framework — that way, you get to learn the syntax while also learning about how the language behaves. For instance, because BDD is my bag, I thought I’d start things off by writing a few behaviors with ScalaTest. Briefly, ScalaTest is
an open source test framework [written in Scala] for the Java platform designed to increase your productivity by letting you write fewer lines of test code that more clearly reveal your intent.
Interestingly, they team behind ScalaTest has even trademarked the slogan
Less code, more clarity
Of course, I’m all about less code and more clarity — I’m all about easy, baby! So I thought it would be fun while learning about Scala to also compare and contrast Scala and ScalaTest to Groovy and easyb. Before I go any further, please allow me to state, for the record, that I’m much for familiar with Groovy than Scala and that I’m almost certainly biased towards easyb no matter how hard I might try to admit otherwise. Nevertheless, I do believe I can be objective in this situation as I am intent on leveraging Scala where appropriate.
The ScalaTest team has done a wonderful job of documenting the various options available for testing; in fact, they’ve got an entire section dedicated to BDD-style testing; in particular, they have an RSpec inspired syntax that is obviously similar to easyb’s specification syntax (which was also inspired by RSpec). Thus, with ScalaTest’s Spec trait, you can leverage an it-style syntax for behavior verification; plus, via Scala’s mix-ins feature, you can also leverage a more natural should-style of verification, which definitely leads to a more readable specification.
Using the ScalaTest documentation, you can create a specification that describes a stack like so:
import org.scalatest.Spec
class ExampleSpec extends Spec {
describe("A Stack") {
it("should pop values in last-in-first-out order") (pending)
it("should throw NoSuchElementException if an empty stack is popped") (pending)
}
}
This is, of course, runnable and yields a report that states that there are two pending tests (or behaviors). Note, with ScalaTest, you must indicate a specification is pending by appending a (pending) clause.
Conversely, with easyb, the same specification can be written like so:
description "this specification describes a stack"
it "should pop values in last-in-first-out order"
it "should throw NoSuchElementException if an empty stack is popped"
What’s noticeably lacking from easyb’s syntax is the describe clause (which, in many ways, is just like a scenario); however, easyb doesn’t force you do declare that a particular behavior is pending — it’ll figure that out by itself. What’s more, you aren’t forced to create a class structure to contain your specification. You don’t have to import anything either.
Next, when you decide to code your behavior, in ScalaTest, you implement the it’s method body like so:
import org.scalatest.Spec
import org.scalatest.matchers.ShouldMatchers
import scala.collection.mutable.Stack
class ExampleSpec extends Spec with ShouldMatchers {
describe("A Stack") {
it("should pop values in last-in-first-out order") {
val stack = new Stack[Int]
stack.push(1)
stack.push(2)
stack.pop() should be === 2
stack.pop() should be === 1
}
it("should throw NoSuchElementException if an empty stack is popped") {
val emptyStack = new Stack[String]
evaluating { emptyStack.pop() } should produce [NoSuchElementException]
}
}
}
As you can see from the code above, this behavior is validating a simple Stack object– in this case, its Scala’s own stack implementation; suffice to say, it behaves, for the most part, just like a normal stack. First and foremost, ScalaTest’s ShouldMatchers mixin is slick! Note how you can literally write should be and then pass in a condition. I think this syntax reads nicely (except for the fact that ScalaTest is using 3 =’s). Moreover, exception verification is quite nice too — the evaluating line is quite elegant and the keyword produce is hip! I take it the produce clause takes a collection of exceptions, so it would be nice if, in the case of only one exception, you could drop the [] syntax though.
ScalaTest also has another mixin type dubbed MustMatchers, which replaces should with must should you want to use that word instead.
The same verification process in easyb looks like so (note, in the code below, I’m going to use Java’s Stack):
description "this specification describes a stack"
it "should pop values in last-in-first-out order", {
stack = new Stack<Integer>()
stack.push 1
stack.push 2
stack.pop().shouldBe 2
stack.pop().shouldBe 1
}
it "should throw EmptyStackException if an empty stack is popped", {
emptyStack = new Stack<String>()
ensureThrows(EmptyStackException){
emptyStack.pop()
}
}
In easyb’s case, the actual assertion-like clause is shouldBe (or its cousins like shouldEqual, etc); what’s more, you must “attach” the clause to the desired object (as opposed to ScalaTest’s more removed syntax, which allows you to drop .’s). Nevertheless, the shouldBe call doesn’t insert an additional operator either (i.e. there isn’t the ===). easyb’s exception verification is certainly not as nice as ScalaTest’s though — I suppose I could write the ensureThrows clause as one line but it doesn’t read as nicely as evaluating { blah } should produce [Exception] — I really like that syntax in ScalaTest.
As you can see from these two simple examples, the spirit of BDD is there — each framework takes a slightly different approach in terms of syntax, but that’s probably due to the underlying nature of the languages themselves. Scala is certainly less verbose than normal Java, but it seems to me that Groovy is less verbose than Scala (but I concede that this might just be a result of each framework’s syntax) . I find that easyb yields more clarity but I do find that ScalaTest’s matchers syntax to read quite nicely.
Scala is definitely an interesting language that exposes some interesting features. Like every other major player on the JVM, it has its spot — for me, the strict nature of its typing and functional-ness makes it applicable in concurrency situations; however, its syntax, while less verbose than that of Java, isn’t necessarily as flexible as Groovy, for instance (although dropping the dot (”.”) on method calls makes successive method calls read copasetically (i.e. should be)).
ScalaTest is well documented and offers quite a few neat options (via Scala traits & mixins) that make testing a lot more interesting and certainly clearer than plain Jane JUnits; however, for me, I still find easyb’s syntax to be much more clarifying (and of course, much less code). Nevertheless, for Scala code that I do write, I’ll be leveraging ScalaTest — it’s already taught me a few things! Can you dig it, man?
Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.
]]>Groovy Shell brings to Groovy what irb (Interactive Ruby) and jirb (Interactive JRuby) bring to Ruby and
]]>Groovy Shell brings to Groovy what irb (Interactive Ruby) and jirb (Interactive JRuby) bring to Ruby and JRuby respectively. I have written about both IRB and JIRB and in this blog post I look more closely at Groovy Shell.
As IRB and JIRB do for Ruby and JRuby, Groovy Shell provides an easy, command line based interactive tool for experimenting with Groovy syntax. This can be easier to use for experimenting with Groovy than writing files to be run in a separate step or trying to pass multiple commands to the Groovy interpreter with the -e option.
Assuming that Groovy has been appropriately installed, it is easy to run Groovy Shell with the groovysh command. Doing so leads to the output shown in the next screen snapshot.
Entering "help" at the Groovy Shell prompt brings up usage information as demonstrated in the next screen snapshot.
At this point, I'll demonstrate via Groovy Shell capabilities that Groovy applies similar to capabilities I demonstrated previously for Ruby and JRuby using IRB and JIRB. The next screen snapshot demonstrates some Groovy math operations in Groovy Shell.
Groovy provides many String operations one might not expect in a language as tied to Java as Groovy is. However, the next screen snapshot proves some of Groovy's string operations that behave similarly to those demonstrated for Ruby and JRuby in my previous writings on IRB and JIRB.
The 2004 JavaOne conference presentation The Groovy Programming Language: Let's Get Groovy includes a nice tip related to use of Groovy Shell. In one of that presentation's slides, Rod Cope and James Strachan demonstrated using Groovy Shell to easily determine the methods available on a particular class. They specifically looked at the File class, but it could be used on any class as shown in the next screen snapshot with File and String.
There is much more that can be done with the Groovy Shell and more information is available in the online Groovy User Guide section Groovy Shell. Some problems previously encountered with Groovy Shell are covered in the Troubleshooting section.
For those who prefer a graphical tool similar to Groovy Shell, the Swing-based Groovy Console or Google App Engine powered browser-based Groovy Web Console is likely to be of great interest.
]]>From the job-hunter's viewpoint, this is simply a matter of avoiding exhaustion. Even the thought of talking to five people in a single day of interviews makes me shudder. Plus, it might seem as though your chances of getting the job decrease with every additional person with whom you interview, because everyone will have his own expectations. Who can possibly meet everyone's idea of "the person who'd be perfect for this job"?
I've seen and experienced just about every variation on this theme, from the Hire decision coming after a ten-minute phone interview with the manager to a grueling day in which everyone in the company had to ask a really tough question. Or, too often, a really stupid one.
Over the years, I've come to lean towards the "more interviews are better" side of the issue. From the job-hunter's point of view, every discussion you have with someone who works at the company gives you another opportunity to judge the corporate culture, particularly if you speak with folks at different levels. Your prospective boss might tell you how important it is for developers to grow their skills, for instance, but if you ask three people you'd be working with when they last got developer training you'll find out if the company puts its money where its mouth is. The more people you talk with, and the more questions you ask (rather than answer) the better you can triangulate on the department's goals; is everybody heading in the same direction or do departments have differing priorities?
But I'm a little more interested in the question from the company's point of view... or rather, the point of view of the team who's going to bring on the new developer. As I wrote about several months ago, in Interviewing Your Next Boss: Putting the Programming Lead on the Hot Seat, dire and terrible things can happen when the people above the manager have a different idea of what's needed than the people who will report to him. (Read the comments, if you don't believe me.)
But the same rule applies to the people you'll work with. I don't know why "team fit" is so often considered by Management and by HR departments (the same HR departments who dump your résumé because you lack a current tech buzzword or because they didn't accept your expertise gained in an open source project) but they think that team members don't recognize the need for "fit," too. Who do they think will be spending all the time with the new developer?!
A long time ago, I worked for a very small company — it employed 12 people — at which every new hire spoke with everyone on staff, from Carolyn the bookkeeper to the guy who owned the firm. (You didn't formally interview with Sam, the owner's dog, but I can't imagine that anyone who Sam objected to would be offered a position.) Anyone could veto a new hire. Anyone. An explanation wasn't required, though the company culture was such that it'd be expected. The result was that we had an incredibly strong, diverse team of people who truly loved one another, learned from each other, and were immensely productive. (I'm still in touch with half my coworkers, and I live on the other side of the country, now.)
However, one reason I'm even more in favor of "have more interviews, not fewer" is on Agile grounds. If the developer is going to work with people in other departments (whether IT or line-of-business), those users have to be comfortable with her, too. A candidate may be able to speak brilliantly to other programmers, but have terrible listening skills when it comes to learning what the users need. In the real-world scenario that inspired this blog post (a hiring anecdote imparted by a friend), the developer got along fine with the tech staff. But when he interviewed with the project manager, she gave him a thumbs-down; according to the non-technical project manager, the guy didn't understand the business processes required.
What's your experience been? I created a poll so we could judge what "normal" is (I'm sure you're as curious as I am). But I'm sure there's arguments for-and-against the "many interviews" options. Tell me what's worked for you.
You probably should follow me on Twitter. Because, y'know, you just should.
]]>Ugg shoes, tiffani wathes, gucci glasses... JavaWorld became a good source of information about all those useful and luxury commodities lately. Spam messages flooded this site.
Last week I took some time and liberty to filter out hundreds of spam messages, block dozens of users, and change some policies.
]]>Ugg shoes, tiffani wathes, gucci glasses... JavaWorld became a good source of information about all those useful and luxury commodities lately. Spam messages flooded this site.
Last week I took some time and liberty to filter out hundreds of spam messages, block dozens of users, and change some policies.
Until things stabilize (or until I get bored with this voluntary duty) messages like this will be deleted, messages like this will get spam links stripped.
Message signatures are disabled as most of times they contain spam links. Reply preview is mandatory.
If that's too strict or you have any other suggestions - don't hesitate to reply right here ;-)
The only open question (imo) is whether a message which content makes sense signed smth like super.com dev should be considered spam, should we filter out the link etc.
]]>Oh, I'm sorry, have you been bored by the Sun-Oracle merger drama because it's been all about MySQL and Java has been reduced to a baffled bystander? Well, get ready for some ancillary Java-related corporate drama that has the added benefit of being pretty hysterical!
]]>Oh, I'm sorry, have you been bored by the Sun-Oracle merger drama because it's been all about MySQL and Java has been reduced to a baffled bystander? Well, get ready for some ancillary Java-related corporate drama that has the added benefit of being pretty hysterical!
It seems that the Wall Street Journal in a recent editorial noted that SAP had sent a letter to Oracle proposing some sort of meet-up between the companies' leaders; the WSJ speculated that this was in essence an offer on the part of SAP (which is based in Germany) to intervene with EU regulators on behalf of the troubled Sun-Oracle merger. Well, that certainly came as surprise to SAP! According to the company, the letter was actually a request that Oracle keep Java open, or perhaps even open it further; Oracle never actually replied to the missive, but did leak an out-of-context paragraph from it to the Journal to make it look like SAP was trying to help the merger along.
No doubt partly in response to all this, SAP CTO Vishal Sikka put up a blog post covering what I assume is the same ground covered in SAP's letter to Oracle. The opening paragraphs hit points that I think many people, particularly those not affiliated with Sun or Oracle, would agree with: Java ought to be more open, the JVM ought to be open source, and the Java Community Process ought to be under the control of an outside foundation, like Eclipse is. For extra burn, he even finds a 2007 quote from Oracle's representative on the JCP to this effect.
But then his next quote is from Mikhail Gorbachev. Because he finishes up the blog post memorializing the fall of the Berlin Wall 20 years ago, and claims that in making his triumphant call for Java liberty, he is the moral equivalent of Ronald Reagan demanding that Gorbachev tear down the Wall. This is, to put it mildly, overstating things. Still, it's nice to know that Java can elicit such passion, you know?
]]>As predicted by everybody, the EU has issued a formal objection to the Oracle-Sun merger. In particular, the European Commission worries that Oracle will hold back on MySQL development, presumably to prevent the open source database from becoming a rival to Oracle's much pricier high-end offerings. ]]>
As predicted by everybody, the EU has issued a formal objection to the Oracle-Sun merger. In particular, the European Commission worries that Oracle will hold back on MySQL development, presumably to prevent the open source database from becoming a rival to Oracle's much pricier high-end offerings. While you may have a knee-jerk reaction to this to the effect that "Oh, MySQL is open source, if Oracle doesn't advance it someone else will," note that almost all MySQL development comes in-house, not from outside developers.
Of relevance is that the same can and has been said for Java; thus, it's relevant that, according to the New York Times article I linked to above, the EU's antitrust attention was originally focused on how Oracle's acquisition would affect Java. And to be sure one might speculate on ways Oracle could direct Java to aid its own projects and irritate its competitors; still, the potential clash in the database market is obviously easier to get one's mind around.
EU regulators apparently have a much keener interest in open source than their American counterparts, so it's not too crazy that they're sniffing around these specific areas. (Also relevant, of course, is that MySQL is in origin a European project.) The upshot of the EU's focus on MySQL is that, if the merger passes (and the smart money still thinks it will), then Oracle's intentions for Java will not have gotten strong regulatory scrutiny, and won't necessarily be the subject of any promises from Oracle.
]]>CouchDB is an open source document oriented database written in Erlang that allows you to model domains in a flexible manner as a self-contained document that contains no schema but, instead, a roughly similar blueprint to other documents.
]]>CouchDB is an open source document oriented database written in Erlang that allows you to model domains in a flexible manner as a self-contained document that contains no schema but, instead, a roughly similar blueprint to other documents.
Provisioning a CouchDB instance in the cloud is easier than you think, baby! In fact, you can watch it done in 3 and a half minutes. In this video, an instance of CouchDB is provisioned (via aptitude) on an ubuntu 9.04 instance running on Amazon’s EC2.
As you can see, in many ways, this video and, of course, CouchDB embodies the core aspects of Development 2.0:
Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.
]]>J2EE Web security is based on the separation of content into two web contexts - protected and public. But there are lots of cases (in my experience majority of cases) when you provide the same content (e.g. a web page) but with different information displayed for different types of users. For non-authenticated (non logged-in) users you hide some sensitive info from your content, and for authenticated (logged-in) users you may choose to hide of display some data depending on their authorization (the user role).
]]>J2EE Web security is based on the separation of content into two web contexts - protected and public. But there are lots of cases (in my experience majority of cases) when you provide the same content (e.g. a web page) but with different information displayed for different types of users. For non-authenticated (non logged-in) users you hide some sensitive info from your content, and for authenticated (logged-in) users you may choose to hide of display some data depending on their authorization (the user role).
The form-based J2EE security automatically protects the 'secure' part of the web application. Which in reality means that J2EE container automatically asks for user credentials when the user tries to access the protected context. Context here means a folder on the server (something like 'secure'), which is accessible by a URL path (something like 'http://server.com/secure').
But what if you just have a page or two (or a dozen) that render themselves differently depending on the user type? In this case you don't have anything that could be considered a secure context, as you can't physically separate you content into two, unless you want to copy all your pages to a 'secure' folder.
The bitter truth is that the only way J2EE container authenticates (logs-in) a user is by intercepting user's access to the protected context. You just can't manually ask J2EE container to log your users in, and to present a form to enter their credentials. This situation is a long-lived problem for all J2EE devlopers.
Under the hood the J2EE form-based security has three entities: the log-in page (where the user enters his login/password) which pops-up when user tries to access the protected content, the error page (the one that shows up if login/password entered was incorrect), and the /j_security_check URL which is built-into any J2EE container. The latter is capable of receiving login/password info from the login page, validating them, and upon successfull validation redirecting to the page that was originally requested, or, in case of validation failure, redirect the user to the error page (to give him another try).
The tricky part is that /j_security_check URL cannont be used manually. You can't just send user/password to it, J2EE container requires that this URL be called automatically. Wouldn't it be wonderful if it was possible to make an AJAX call and pass login/password to /j_security_check?
The solution that I've come to for situations with no physical separation between protected and public content is based on an <iframe>.
So, lets suppose that we have configured a form-based secured web-application, in web.xml it looks something like:
<security-constraint>
<web-resource-collection>
<web-resource-name>secured</web-resource-name>
<url-pattern>/secure/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>admin</role-name>
</security-role>We will need two pages - login.jsp and parentReload.jsp. The first one goes to J2EE login-config config in web.xml, so that it would show up if a request is made to a secure context:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login.jsp?invalid=true</form-error-page>
</form-login-config>
</login-config>The login.jsp itself should look something like this:
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<body>
<%
if (request.getParameter("invalid")!=null) {
%>
Incorrect login/password, try again:
<%
}
%>
<form action="j_security_check" method="post">
user name: <input type="text" name="j_username"/><br/>
password: <input type="password" name="j_password"/><br>
<input type="submit">
</form>
</body>
</html>The parentReload.jsp goes to the /secure folder, probably becoming its the only inhibitant. The JSP content is pretty simple, can you guess what it does?
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
<script type="text/javascript">
parent.location.reload();
</script>
</head>Now, on each page that is supposed to be rendered differently for different types of users you can put this nice code on the top of page:
<%
final java.security.Principal userPrincipal = request.getUserPrincipal();
if(userPrincipal==null) {
%>
<iframe src="secure/parentReload.jsp" frameborder="0"></iframe>
<%
}
%>This is how it works, if you haven't guessed it by now: if the current user is not authenticated yet an iframe is rendered on the page. This iframe's src 'secure/parentReload.jsp' is located in the protected area, so, instead of displaying the original parentReload.jsp J2EE container intercepts this request and renders the login.jsp page inside the frame, which results in a little user/password widget on the top of each page, which is pretty neat. Once the user decides to login the iframe form is submitted without reloading the main page. If user credentials were valid J2EE container renders the parentReload.jsp in the iframe. Once rendered inside the iframe it will cause the parent window (the main page) to reload. Upon reload it will no longer try to render the iframe anymore, and you are free to render the protected content.
This has been tested and workd great on Tomcat, and supposed to work with any J2EE container. Enjoy.
]]>I've just run into the issue with misleading, or at least incomplete documentation related to HTTP Cookie representation in J2EE. Cookie class JavaDoc states that Cookie.setMaxAge(int) method "Sets the maximum age of the cookie in seconds."
That's not true, unfortunately. Cookies, as we know, don't hold info about their max age. They hold the date/time value of their expected expiration.
I've just run into the issue with misleading, or at least incomplete documentation related to HTTP Cookie representation in J2EE. Cookie class JavaDoc states that Cookie.setMaxAge(int) method "Sets the maximum age of the cookie in seconds."
That's not true, unfortunately. Cookies, as we know, don't hold info about their max age. They hold the date/time value of their expected expiration.
So, instead of setting the max age for a cookie, this setMaxAge method adds the int parameter seconds to the current SERVER date/time and puts this new date/time value to a cookie as its expiration time. Later, when this cookie is sent to the browser, this expiration date is compared to the CLIENT date/time, and cookie gets expired if its expiration date is in past.
All this means that setMaxAge method description is valid in just one case: all clients are run on the same machine with the server, or at least have their system time synchronized with the server. Rather idealistic, isn't it. There are lots of computers with system time that is in the past.
If you'd really like to rely on a cookie expiring after a defied period then a different approach should be taken, the brand new System and Method for Defining a Cookie Max Age :-)
So, if you'd like your cookie to expire in definite time you will need another cookies to hold the cookie 'meta-information'. To make sure that cookie 'cookie1' having value 'someValue' will expire in, say, 20 seconds, in your servlet or servlet filter you could do:
response.addCookie(new Cookie("cookie1Name","cookie1"));
response.addCookie(new Cookie("cookie1Value","someValue"));
response.addCookie(new Cookie("cookie1Timeout","20"));Then, add the next JavaScript on the page that the servlet produces:
<script type="text/javascript">
// Original JavaScript code by Chirp Internet: www.chirp.com.au
// Please acknowledge use of this code by including this header.
function getCookie(name) {
var re = new RegExp(name + "=([^;]+)");
var value = re.exec(document.cookie);
return (value != null) ? unescape(value[1]) : null;
}
function setCookie(name, value, expiry) {
document.cookie = name + "=" + escape(value) + "; expires=" + expiry.toGMTString() + "; path=/";
}
var cookie1Name = getCookie('cookie1Name');
var cookie1Value = getCookie('cookie1Value');
var cookie1Timeout = Math.abs(getCookie('cookie1Timeout')) * 1000; // converting to milliseconds
setCookie(cookie1Name, cookie1Value, new Date((new Date()).getTime()+cookie1Timeout));
</script>This will result in a cookie1 to expire in 20 seconds.
Awkward, but it works.
Unfortunately this approach will not work for Cookies that are set during AJAX calls, as there will be no possibility to run a custom JavaScript in this case.
]]>