Tag Archives: module

opening multiple intellij modules in the same project and remembering them on reopen

Posted on by
3

This is the number one problem that has prevented me from using IntelliJ more and I finally know how to do it. (I’ve known how to open multiple modules for over a year. What I learned yesterday at the IntelliJ 20th anniversary conference was how to reopen that same set)

Note about terminology to Eclipse users

If your primary IDE is Eclipse, keep this difference in terminology in mind as you read this.

EclipseIntelliJ
WorkspaceProject
ProjectModule

Step 1: Create a dummy/grouping project

Create a new project. This project’s purpose is to contain the modules you want together and give it a distinct name. I’ve been keeping them in an IntelliJ folder in my home directory to avoid confusion. (Most of my stuff is under the git folder in my home directory). The idea of keeping them separate is so I know there’s not code in there.

Step 2: Add your modules

There are several ways of adding modules. Any of them are fine. I find the fastest for repeated adds is:

  • File > Project Structure > Modules
  • Click “+”
  • Choose “Import module”
  • Navigate to the build file (ex pom.xml) or .iml file for generic projects

Step 3: Rename the project (if needed)

On rare occasions, I noticed the project name got my first module name. I couldn’t reproduce this, but started double checking. This name is what will show up in your recents list.

  • File > Project Structure > Project
  • Enter a new name if needed

Testing

File > Open Recents and open another project. Then File > Open Recents and open this project. Admire how all your modules are back!

Seeing the modules on disk for the curious

In the dummy project, the .idea directory has a misc.xml file. I was told it contains all the modules. And it did when I tested on Windows

<list>
  <option value="$USER_HOME$/git/myProj/pom.xml" />
  <option value="$USER_HOME$/git/myProj2/pom.xml" />
</list>

When I tested on Mac, modules.xml had this info

<modules>
   <module fileurl="file://$USER_HOME$/git/myProj.xml" filepath="$USER_HOME$/git/myProj.xml" /> 
   <module fileurl="file://$USER_HOME$/git/myProj2.xml" filepath="$USER_HOME$/git/myProj2.xml" /> 

</modules>

And a note about “you are doing it wrong”

I am an Eclipse power user and an IntelliJ competent user. What holds me back is not using IntelliJ more at work because of not knowing how to do this. While I don’t want to replace my usage, I do want to be an IntelliJ power user and use Eclipse enough to not lose my skills! I think this is the thing that will do it!

When I’ve tried to find out how to add multiple modules and have them remembered multiple times in the past, I was told that I was “using IntelliJ wrong” and should have one project that I focus on. (I work on many sets of small related projects; that model doesn’t work for me.)

Yesterday, someone attempted to tell me that I should have one big project that I focus on at a time. (aka my problem doesn’t exist.) After explaining what I do, another user said he does that I do. The first user said something about religion. That seems like just it. There’s multiple religions. It’s fine to be passionate and a true believer in yours. But as part of society, accepting that other people believe differently is part of life.

[2019 oracle code one] modules

Posted on by
Reply

Java Modules: Why and How?

Speaker: Venkat  Subramaniam @venkat_s

For more blog posts, see The Oracle Code One table of contents


Why modules?

  • Modules designed to make the JDK itself modular
  • It’s like bringing these 70 suitcases with you on vacation in case you need something.
  • Better security. Can’t create another jar with same package and access package private.
  • Easier to make new things secure
  • In law mode – The build team drops a few jars until you call that functionality and get class not found. With modules, runs in mother mode. Pre-check what need. Fail fast
  • Reuse release equivalency principle – reuse the whole of what released. USPS gives partial packages. Don’t want that. You export packages but receive/require module. This is a handshake. Both have to extend hands. One must export and the other must require.

Module example

  • Showed compiling, jarring up and running the java command
  • -p modulePath
  • -m modName/my.package.MyClass
  • jar -f myJar.jar -d – tells you about jar file metadata. Will show derived info for old modules that lack formal metadata

Module types

  • Unnamed module – exactly one. Contains everything you dump in the classpath. Whether it is a module jar or not
  • Automatic module – legacy jars on module path
  • Explicitly named modules – jars with module descriptor on module path

Module info

  • exports – package that other code on module path should be able to access.
  • Public is no longer public. Public without exports is not available
  • requires – want to use module
  • requires transitive – never use for third party library. Only use when refactoring a ball of mud into pieces

Rules

  • Any jar running in the classpath is called an unnamed module
  • Any transitional jar running in the module path is called an automatic module
  • Any jar with a module descriptor running in t classpath is a n unnamed module
  • Any jar with a module descriptor running in the modulepath is an explicitly nmaed module
  • Modules can’t share packages
  • Unnamed modules can talk to other unnamed modules
  • Automatic modules can talk to other automatic modules
  • Automatic modules can talk to unnamed module
  • Unnamed modules cannot talk to automatic module (Get class not found across module path/classpath when can’t access because doesn’t even look there)
  • An explicit named module can talk to other explicit named modules
  • An explicit named module can talk to automatic modules
  • An explicit named modules cannot talk to unnamed module
  • An explicit named module has to require any modules it needs incudling automatic modules (so please give a decent name)
  • An explicit named module exports only what it specifically exports
  • An unnamed module automatically exports all its packages

Migration path

  • Run all in classpath in old Java
  • Run all in classpath in latest Java
  • Fix any errors
  • Run them all in module path
    Give names for automatic modules
  • COnvert from top to bottom to explict modules

My take

I like Venkat’s laptop stand so he can type and use the computer. I also enjoyed seeing his enthusiasm. I’ve been writing about modules lately so seeing it explained a different way is useful. The demos are good. The list of rules is a good reference (or review) as well