In the last post we talked about Spring Data improvements, but it doesn’t stop there. IntelliJ IDEA 2017.1, released last week, has enhanced support for testing using the Spring framework.
Gutter Icons and Navigation
You’ll see that where you use the standard test annotations, you have gutter icons to help you to navigate around the code, the same as you’d usually expect from Spring annotations. For example, you can see and navigate to the relevant application contexts, and navigate to the declarations of autowired beans.
IntelliJ IDEA 2017.1 is available for download! In addition to many important bug fixes, this massive update brings lots of improvements to supported languages, frameworks, and built-in tools.
Java 9: The latest builds of JDK 9are fully supported, with assisted project import and coding assistance for editing module declarations. Built-in inspections validate module declarations and provide quick-fixes for adjusting project dependencies. Learn more…
Java 8: Quick-fixes that help migrate for loops to Stream API calls have been improved and now support more sophisticated scenarios. We’ve also added a quick-fix that turns Stream API calls back into for loops, which is handy for debugging or exploring code.
Async-aware debugger: Async stacktraces is a new feature that substitutes parts of a stack trace related to asynchronous code execution with data captured from where that code is invoked. This helps you focus on what you’re debugging. An improved Smart Step Into also supports asynchronous code and lambda expressions running on other threads.
Better VCS: The Log panel for Git and Mercurial has new display options, the Diff dialog gets an option to Ignore imports and formatting, and File History for Git is now faster. We’ve also added Favorite Branches and Speed Search to the Branches popup for Git.
Search: The Find in Path dialog, which previously had added a Preview tab, has been reworked from the ground up and now shows instant results in the first place. What is more important, now you can open any selected result in the Editor simply by pressing Enter.
Spring: Spring Testing has been updated to support Spring Boot 1.4.3, and the upcoming Spring 5.0. Spring Data tools are updated to version 2.0 (including MongoDB, Redis, Solr,KeyValue, Gemfire, Apache Cassandra, REST, Neo4j, Couchbase, and Elasticsearch). There’s also a new Data tab in the Spring tool window which brings better repository navigation.
Gradle: Support for Composite Builds is much improved with the detection of includeBuild in Gradle settings and automatic project configuration.
Scala: Scala plugin improvements include a simpler Project Wizard, better SBT support, additional Akka-specific coding assistance, and the new Worksheet REPL mode.
Database tools: IntelliJ IDEA now allows you to transfer table schemas and data between any two databases (yes, even from MySQL to Microsoft SQL Server and back).
Emoji: The editor now supports Unicode emoji characters (handy for writing comments).
Android Studio 2.2.2: This update includes all changes from Android Studio 2.2.2.
Docker: The Docker plugin now supports Docker for Mac and works via “unix://”.
Windows: The 64-bit installer for Windows lets you give IntelliJ IDEA more RAM.
For more details about IntelliJ IDEA 2017.1, check out the What’s New page.
Your feedback is very much appreciated here in the comments, as always. For bug reports, please use our issue tracker.
P.S. Don’t forget to install Toolbox App – it’s really great at managing your IDE installations and projects. It helps you always be up-to-date with the latest releases, and safely roll back to stable versions if anything goes awry.
The upcoming IntelliJ IDEA 2017.1 includes numerous features to help Spring developers. In this post, we’re going to look specifically at the feature for Spring Data. Support for Spring Data has been updated to include support for features in release train Kay.
One of the new features in IntelliJ IDEA 2017.1 is full support for Gradle Composite Builds. We were fortunate to have Stefan Oehme from Gradle presenting a webinar, showing what composite builds are, how they work and why you might want to use them. In the second part of the webinar, I (Trisha Gee) cover the support for Gradle composite builds in IntelliJ IDEA 2017.1. Take a look at the end of this post for the full video and list of points covered with links to each section.
Imagine you have a project set up to be dependent upon some libraries
You may have access to the source code for this library, and even be able to make changes and commit them, but this traditionally required you to use a different IntelliJ IDEA project to make the changes, then build it and somehow deploy the updated library. But now with Gradle’s Composite Builds, you can easily update and test the library code. All you need to do is to change settings.gradle to include the location of the build for the library code.
Now Gradle is using composite builds, i.e. it can build multiple independent projects together. IntelliJ IDEA recognises this, and as you can see from the screenshot above, it not only updates the Gradle window to reflect the multiple builds, but imports the code for the included build as an additional IntelliJ IDEA module.
Stefan talked about the use cases that really benefit from using Gradle’s composite builds. Composite build support in IntelliJ IDEA means you can work very naturally with code from other libraries, modules or plugins you may be dependent upon. You can make changes to the library code, and even commit these changes to the library’s own repository.
If your projects are already using composite builds, IntelliJ IDEA has full support for importing, building and running these projects. The behaviour inside the IDE is what you would expect, you get the included Gradle builds imported as IntelliJ IDEA modules.
Another use case for composite builds is to bundle together projects, possibly from different repositories, that are effectively separate modules that work together. This use case may be particularly useful if your team is moving from a single repo “monolith” type of application to something that’s made up of independent modules or services. Gradle lets you include the builds for all the different modules (see the settings.gradle in this sample code for an example) into a composite build, and IntelliJ IDEA will find all those Gradle projects and treat them as IntelliJ IDEA modules.
The final example shown in the webinar is how valuable composite builds can be for Gradle plugin developers. Whether you’re developing a plugin and have an example project that uses the plugin to test it, or whether you’re working on an application that uses a plugin that you may want to experiment with, you can create a project from the “consumer” of the plugin (like in this sample code) and see the plugin code also imported as an IntelliJ IDEA module.
In summary, you’ll see that if you’re using composite builds with Gradle, IntelliJ IDEA will figure out the right project and module structure for you to be able to work naturally with the builds you’ve included, with the ability to see the code for the included projects, navigate to it, use refactoring and everything else works as if you were working with an ordinary IntelliJ IDEA module.
We’ve taken on board suggestions from last month’s experiment and this month we’re trying to please everyone – what could possibly go wrong? February is a short month so you might expect a shortage of news, but far from it! It’s a big year for releases, with Java 9 and Java EE 8 on their way, and it’s never too early to get up to speed on what’s coming.
It’s been three months since we released v2016.3. Roughly half of this time we spent working on bug-fixes; some fixes made it to minor updates, others will go into v2017.1, and others are planned for further releases. The other half was used to enhance the existing functionality and extend it with new features. Today we’d like to give you a glimpse of the most notable changes coming in v2017.1 planned to release this spring. Please welcome IntelliJ IDEA 2017.1 Public Preview – an EAP build where you can try most of the upcoming enhancements.
Last week we published EAP of the upcoming IntelliJ IDEA 2017.1 that included initial support for async stacktraces. Today, along with a fresh EAP build, we’re happy to introduce another improvement aimed at making debugging asynchronous code easier: step into that supports lambda expressions executed on other threads:
Earlier this was only possible when you manually added a breakpoint directly at a lambda expression, but now you can just Smart Step Into to debug asynchronous code.
Another improvement available in this update is the reworked Git File History. It’s faster, can display the revisions graph, and even has a button to include changes from branches other than the current.
Last but not least: we’ve added a new option that allows you to drag and drop breakpoints to remove them. If you enable it, simply clicking a breakpoint, instead of removing it, will enable/disable it. This is very convenient because it saves you from accidentally removing a breakpoint and losing its parameters such as a condition.
This option is selected via Settings | Build, Execution, Deployment | Debugger | Drag a breakpoint to the editor area to remove it.
As always, your feedback is welcome here in the comments and in our issue tracker.
Following the reactive programming trend, our code is getting more asynchronous. Earlier Java 8 introduced CompletableFuture (adopted from Guava’s ListenableFuture). Akka, Ratpack, Reactor, RxJava, Vert.x and other libraries implement Reactive Streams, Scala offers Future, Kotlin is adding Coroutines, and finally, Java 9 is about to bring us the Flow. Well, reactive programming helps us build efficient applications, but boy are they difficult to write and debug.
New year, new style? This month we’re experimenting with a simpler format for JAM, so you can see at a glance the real titles of the articles being linked to. The upside is more links! More news! And you can see all the topics at a glance. The downside? Less witty banter from yours truly. Let us know in the comments whether you prefer the “usual” format or the new. As always, we will cover what’s new in the Java world and throw in other bits and pieces that seem interesting for developers.