Lately I encountered a problem with IntelliJ on macOS I wasn’t aware of so far. For a new project I joined it was necessary to let Java execute a shell script which resides in /usr/local/bin and calls another script. Putting all the questions for the reason behind this aside I was pretty puzzled when I couldn’t get this to work while on all my colleagues Linux machines it worked like a charm.
After fiddling around with it for a while it became very much clear that the JVM which I started from IntelliJ didn’t had /usr/local/bin in its PATH environment variable and because of that couldn’t execute the script. The question was why this was the case. When I started the application via gradle on the shell everything worked correct which seemed to point to an IntelliJ problem. After some research it became clear that the root cause of the problem is a concept in macOS which separates the shell environment variables from the environment variables for GUI processes, or better said the environment variables for processes which are started from Spotlight, Finder or the desktop.
The standard environment variables set for GUI applications on macOS are controlled via launchctl and are per default set to /usr/bin:/bin:/usr/sbin:/sbin.
The quick solution to get around this and use the environment variables set in the Shell via .bashrc or .zshrc etc. is to start IntelliJ (or any other UI application) via the command line. This can be done on with the command
open /Applications/IntelliJ\ IDEA.app
After that IntelliJ runs in the shell context and has access to all the variables set there. If this doesn’t suit you and you want a more permanent solution which makes it possible to start IntelliJ without the shell and still have access to the environment variables there is a solution for that, too.
You have to create the file ~/Library/LaunchAgents/environment.plist. A plist file in macOS is a property list file which is a widely used concept in macOS (read more about it here). In this file there can be some startup configurations stored. A minimal configuration to just control the environment variables could look like this:
Read More Read More
You might all have experienced the situation when you want to start a server either from within your IDE or via the terminal to only get the error that the “port is already in use” and the startup is aborted. This is mostly caused by aborting the server or a crash of the IDE which started it and not terminating it properly. When using macOS (or any other BSD or a Linux) there is a simple solution for this.
For such purposes macOS comes with the “lsof” command which stands for “list open files”. Its purpose is to show who is using a specific file or in our case who is using a specific port. After identifying the process it is easy to terminate it using the “kill” command. …
Read More Read More
This blog should not transform to yet another Apple blog but as a Java Developer the Mac is my preferred platform which I use daily. This is the reason why I tend to take a closer look when Apple shows the next generation of macOS or Mac hardware even if I’m not buying a new one immediately. I want to get a feeling were the platform is going to. Last week Apple showed its last iteration of the MacBook Pro to the public and I want to share my thoughts as a developer about it.
At first I like the new look, the lower weight is really great for me as I often travel around with the MacBook being in my backpack and every grams you could save there is a win. The first thing that got me thinking was if it really is a good idea to start the 13″ model with just 8GB of RAM. From a developer standpoint I think that this is the absolute minimum and you should get an upgrade here if possible. When you are a Java developer and start your app server (sometimes multiple servers at once), a database in a VM, your IDE, Browser, Mail etc this will lead very fast to eating up all the RAM and swapping out to the SSD. SSDs are very fast these days but they are no match to the RAM and it will slow down your system. 16GB will be a better solution here and that Apple doesn’t offer 32GB for the 13″ model is a shame. That they commented afterwards that this decision was made because 32GB would have used to much of the battery is a reason but not one that I like. I would much more like to work a shorter time with a faster system then work longer with a slow system that has used up all its memory because this often makes effective working impossible and I guess in the future we will need more RAM than today instead of less. …
Read More Read More
Jetbrains has come up with a solution for the scrolling problem with IntelliJ IDEA based IDEs under macOS Sierra. They released a modified JDK8 which hast to be set as boot JDK for IntelliJ. You can download the JDK here.
For setting it as the boot JDK you need to got to action menu. This is reached under macOS by pressing ⌘ + ⇧ + a (in other words cmd + shift + a) buttons and entering in the search box the term “switch IDE boot JDK”.
The new JDK will be part of the next stable release of IntelliJ and is actually available as part of the 2016.3 EAP.
As this seems to fix the scrolling issue there are still reports of problems with the context click behavior.
If you rely on IntelliJ (or any other IDE based on the IntelliJ platform like WebStorm i.e.) for your daily work and use a touchpad (no matter if the Macbook internal or the magic trackpad) you should not upgrade to Sierra at the moment. The issue is that the scrolling behavior in IntelliJ is extremely sensitive which makes a controlled scrolling nearly impossible. IntelliJ seems to doesn’t know of a way to fix this at the moment and filed itself a radar at Apples bug tracker. As you can find complains from users of other Apps with the same problem as well (VLC and Minecraft i.e.) it seems plausible that the ball on this is in Apples field.
As Jetbrains obviously have done nothing wrong with its implementation to trigger this issue it would have been a good move from them to address the issue to their customers early (previous to the sierra release) so that they could have waited with the macOS upgrade until the problem is solved. If you are interested you can find a discussion about the problem at their bug tracker.
Not knowing how long it will take Apple or Jetbrains to solve the issue the easy workaround for the users is using a mouse as it affects the trackpad only. I use the magic mouse but every other mouse should work fine, too.
Jetbrains has come up with a solution for the problem which you can find here