As usual, the newest version of IntelliJ IDEA contains updates to help you debug applications. Given that we are working more and more with large data sets, IntelliJ IDEA 2017.2 has added the ability to filter arrays and collections in our variables or watches.
In this example, I have a variable allWords that’s a list of Strings. This is a large list, so when I’m debugging my application I may want to look for specific values, or types of values, in this list. I can do this by right-clicking on the list and selecting “filter”.
Then I can enter the criteria to filter. As you’d expect, IntelliJ IDEA offers code completion and suggestions here.
The debug window will now show me the subset of values in the list that match this criteria.
If I right click on the filter, I can edit the filter to change the original criteria or add further filters
And I can easily remove the filter using the clear button.
This feature also works on other Collection types, and arrays. Here, we’ve added a watch expression that creates an array of random ints
We can filter these values too
This ability to filter the values in large collections like lists and arrays make it easier for us, as we’re debugging an application, to see which values are available, and particularly if one or more of them match some criteria we’re looking for.
Last Thursday we had a pleasure to host a live webinar with Jeff Scott Brown, the founder of the Grails framework. Jeff gave a comprehensive overview of the Grails 3 support in IntelliJ IDEA (both Community and Ultimate.)
In case you missed it, here’s a recording along with transcript of the Q&A session. Enjoy!
Does IntelliJ IDEA offer coding assistance for the GORM methods, such as .list(), .where(), .save(), etc?
GORM, among other Grails concepts, is fully supported by IntelliJ IDEA Ultimate. Community Edition doesn’t include this. If you want this support in Community Edition, make sure your classes implement the corresponding traits explicitly.
How to enable auto-reload in IntelliJ IDEA?
IntelliJ IDEA Ultimate supports auto-reload out of the box. In Community Edition, you have to manually add “-noverify“ to the VM options (to disable the bytecode verifier) in your Run Configuration.
What is the difference between GGTS and IntelliJ IDEA?
Currently the biggest difference is the dedicated support for Grails 3. AFAIK, Eclipse (GGTS) doesn’t support Grails 3.
How do I deploy a Grails 3 application to GlassFish?
Use the Grails command “grails war”, and then deploy it to GlassFish as a regular WAR file.
How to use Grails 3 along with GWT?
If we’re talking about simultaneously working with two separate applications in one IDE, then the best way to do that would be to use a multiple project Gradle build. If it’s about using GWT on top of Grails, check our the GWT Grails plugin.
Recommend a quick tutorial on GORM for a personal with SQL background
2017.2, a new massive update for IntelliJ IDEA, is out and it’s packed full of new features and important bugfixes. Get a copy of this new release, and see for yourself, but before you do, it is worth spending a couple of minutes reading this summary for ideas on where to look.
Smarter code completion and control flow analysis
Smart Completion becomes aware of builder classes and suggests chains of method calls on its first call, and the chain suggestions are sorted according to how frequently symbols are used in the current project.
Control flow analysis has become much smarter and detects a wider array of problems, especially when booleans, strings, arrays, lists, and maps are involved; it also checks nullability issues when corresponding annotations are used on type parameters for collections and maps.
New inspections and refactorings
Inspections and quick-fixes: Replace with Set.of and Add Thread#onSpinWait() (both require Java 9), and Extract set from comparison chain.
Refactorings: Extract as Map Operation (for streams), Extract Functional Variable, and Extract Lambda to Method Reference
As Java 9 continues to evolve, so does IntelliJ IDEA’s support for it. This screencast shows the new features to support Java 9 development in the upcoming IntelliJ IDEA 2017.2 release.
In the rest of this blog post we’ll break down what’s in the video and talk about each feature.
As you’d expect, a lot of the improvements are to support the Java Platform Module System. One of the new features to help developers getting up to speed with Jigsaw and Java modularity is the new Java Module Diagram. This diagram shows the modules you’ve defined in your project in green; any automatic modules, (those modules that are dependencies on traditional jar files) in blue; and any JDK modules in yellow.
You’ll notice there are two different types of lines in the diagram, the thick blue lines show “requires transitive“, the thinner black lines are standard “requires” dependencies.
These diagrams give a clear picture of which modules have been defined and which modules they depend upon, and can help you either to create a clean separation when creating a modular system, or simply visualise what’s going on with the new Java Platform Module System.
If you are working with Java 9 modules, you’ll see code completion and generation has been improved for the module-info.java file. For a start, the generated module name more closely matches the IntelliJ IDEA module name.
Errors and warnings and their suggested fixes have also been improved. For example, if you try to use opens in a module that is already open , the error is clear and you can opt to either remove the opens statement or change the module so it’s no longer open.
Duplicate opens or provides statements are detected and can be deleted or merged.
You can also use find usages on a module name to locate other places that use this module, including JDK modules that use it.
And, of course, you can refactor module-info files, for example using rename.
Project Jigsaw has a wider impact than just allowing you to create your own modules. Modularity impacts the visibility of packages, so classes that were previously accessible may not be any more. This even includes reflection. IntelliJ IDEA’s inspections can help locate reflection code that tries to access modules that are not on the module path, and offers suggestions to fix the problem.
There are a few new inspections to help migrate code to Java 9. There’s a section under the Java language level migration aids inspections for Java 9.
The first inspection highlights module-info files that require automatic modules – automatic modules are useful during migration to Java 9, but over time code should be migrated to use true modules. By default, this only highlights transitive dependencies, as this means your code is exposing automatic modules to other modules.
The second inspection points out places where we can use the new Collections Factory Methods. For example, if we’re creating an unmodifiableSet, this verbose code can be enormously simplified in Java 9. We can also convert unmodifiableList to the new syntax too.
There’s one final inspection to help us make use of new Java 9 features. If your code has while loops that wait for a particular value to change, they can be updated to add the new onSpinWait hint, which allows the runtime to potentially optimise this operation.
Finally, IntelliJ IDEA is also ready for the updates to Javadoc in Java 9. Generated Javadoc is now searchable, letting developers search for classes, methods or keywords in the documentation. To make the most use of this, you may want to add an index tag to your documentation to provide keywords to the search.
Ever since Gary and I started the Git Questions video series, we’ve been asked to talk about merging. We’re also frequently asked about rebasing – what is it, and when should I do it?
In this week’s video, we take a look at how to use IntelliJ IDEA to merge a branch back into the “main” development branch. We also talk about rebasing – not only showing how to do it in the IDE, but what it means and when you should do it.
We don’t show how to deal with merge conflicts in this video, but they are discussed, and a more complete conflict-resolution video is definitely high on the TODO list.
The start of June brought the disappointing news that we’d have to wait longer for Java 9, so July and August news won’t be all about the big release. However, there’s still plenty of Java 9 news, the usual handful of interesting Design and Architecture links, and this month a massive amount of Android and Kotlin news as we try to catch up with everything from Google I/O.
The last couple of months have been a lot of fun as we’ve been working on IntelliJ IDEA 2017.2 which is due out this summer. We appreciate the contributions from all EAP participants and the feedback they’ve shared on the new features. We reached a feature-freeze two weeks ago, and today, with roughly a month before the release, we’re happy to give you a detailed glimpse of what’s noteworthy in the upcoming IntelliJ IDEA 2017.2.
If you can’t wait, download the public preview build right away and try it on your own. Otherwise read on and learn about the major changes. Continue reading →
Another week of work for us—something new for you to try: have a look at the fresh IntelliJ IDEA 2017.2 EAP build. In addition to bugfixes, it introduces a new, experimental feature called Unloaded Modules.
This feature is supposed to help you to deal with large codebases by giving you the ability to select what modules you are going to work on in your project. Modules that you are not working with at the moment are marked as Unloaded and IntelliJ IDEA will not index or otherwise touch any files in these modules, which can help to conserve CPU and memory resources.
To access the feature, invoke the Project tree context menu and select Load/Unload Modules:
And now you just select the modules you’d like to work with at the moment.:
If a module you marked as loaded depends on other modules, IntelliJ IDEA will prompt you to load them as well:
When you’re about to refactor something, or are looking for usages of a symbol, you will be warned about the fact that there are unloaded modules that depend on the modules with which you are working, and therefore might contain code that should have been affected by the action, but won’t be:
It’s important to understand that when you exclude a module, consistency of changes in code that belongs to it will not be guaranteed, so be cautious when using this feature.
Even though this feature is openly available, it’s still under development, so please share your feedback, including bug reports in our issue tracker.
Last month we introduced Java Stream Debugger, a plugin that adds visualizatoion of Java Stream operations to IntelliJ IDEA debugger. Today, we’re taking debugger improvements one step further with this feature: filtering arrays and collections.
This latest EAP build also brings you module diagrams for Java 9, that are available for selected modules or projects via Diagrams | Show Diagram (Ctrl+Alt+Shift+U or Cmd+Alt+Shift+U for macOS), Java Modules Diagram:
Diagram displays selected module dependencies. To quickly locate a module, press Ctrl+F (Cmd+F for macOS):
To see selected module usages, use the good old Show Usages via Alt+Ctrl+F7 (Alt+Ctrl+F7 for macOS):
JRE modules dependencies are displayed, too:
Last but not least, Smart Completion got even smarter and now suggests constructing an instance of the expected type with a builder class available in the project:
We hope you’ll find these small improvements useful. As always, we appreciate your feedback, so don’t forget our issue tracker.
There are a lot of different Version Control Systems out there. Over the years, some of them have become more popular than others.
While the IntelliJ platform provides Integration with various VCSs out of the box, the usage for some of these have steadily declined, to the point that a few of them have very little support demand whatsoever. As such, we’ve decided to reduce the number of VCSs supported out-of-the-box and focus on improving the most popular ones.
What does this mean?
Visual SourceSafe has reached its end-of-life, and ClearCase is approaching it next year. Given this, along with the low demand and popularity for these integrations, we no longer plan to continue development on these plugins, and will be closing their support as of 2017.3 release.
A separate announcement will follow when it happens.
Note that plugins will stay available in the repository, and we will maintain compatibility with successive versions of the IntelliJ platform, making sure no critical regressions are introduced.