Sick with dozens of different layout managers, I decided to replace it with MiGLayout in my own project. The reason is using one layout manager all over the project: the rules of laying out are the same for all components, the flexibility of manager is huge, so this idea seemed attractive and I was happy to throw away all over-complicated built-in Java layout managers.
As it is written in docs, MiGLayout takes strings as args while laying out GUI. Furthermore, one string (one arg) can contain more than one instruction for layout manager. Of course, one can use chaining methods, but, as I understand, this way is not 'default' for MiGLayout, thus it is not recommended by MiGLayout docs. While using MigLayout, I mistakenly put incorrect instructions in one string sometimes, and this causes no error in compile-time (method needs string, and string is passed to it - compiler thinks, it is ok). Errors appear in runtime - my program fail with java.lang.IllegalArgumentException (reason is 'Illegal Constraint' in MiGLayout classes), and I have no good ideas, how I can gracefully handle it, moreover I am not sure, that this level of exceptions is my headache). Anyway, even if I will find an elegant way to add in my code layout manager's exceptions handling, the concept of using 'multiarg' strings as args seems to be bad practice, because it provokes mistakes in code (and this mistakes, being runtime-errors in future, would not be highlited by IDE). In general, carrying potential errors from compile time to runtime is not a good practice. However, MiGLayout is a widely used layout manager, referred to in official Oracle Using Layout Managers tutorial, and I think, it would not be so popular, if it forced bad practice while GUI development. Therefore, I feel myself misunderstanding MiGLayout using concepts, and I will be grateful for some explanations from experienced MiGLayout users.
If it allows you to apply settings in other ways, it's not really forcing you into bad practices. It's giving you a typesafe way and a non-typesafe way .
The non-typesafe way is essential in cases where the layout settings are stored externally, for example in programs that allow you to alter the layout in-program and save the settings for next time.
Whether you should use one or the other in a program that doesn't need to store the layout is opinion based, although Java is a typesafe language.