Java 8 is not Java. Java 8 is a good tool. Java's shift towards being a functional language is unstoppable. Java, however, as a principled, strongly typed, object-oriented, imperative programing language is no more. I have heard the argument that as a developer I can stick with Java 7 syntax using -source 7, but this is not practical. Libraries will evolve to use use functional practices. Old bugs will only be fixed in these evolved libraries. As functional practices becomes ever more rooted in the libraries their use from Java 7's syntax will become ever more cumbersome and perhaps impossible. If you want to continue developing in Java then you and your team will have to evolve with it.
So these days I am thinking ever more about what language to move to. I think the perspective of my employer would be to remain with a language targeting the JVM. I haven't asked, but I know well enough its conservative approach to solutions. The software architect in me would like to pick a language that is more aligned with a fail fast approach to service runtime and its corollary of needing to start fast.
Lots of folks at this week's O'Reilly Software Architecture conference in NYC are favoring Go (commonly called "golang" to make the conversation clearer and searchable). That it compiles to a binary (and even a statically linked binary) for direct execution on the host is a significant boost to start fast. Starting slow would be your architect's fault: Too much in-process preparation and not enough just in time initialization or not enough externalization of functionality into a service. I will look at Go and its libraries. I do worry that is the new black, like Ruby was several years ago.