apenas (surpreendentemente ;-) notei o motivo pelo qual os aplicativos parecem tão apertados em minhas máquinas win6 + (mesmo para o Vista e o Win7, ambos com configuração de 120dpi, jdk6 e jdk7): a fonte de controle pesquisada na propriedade desktop tem a fonte errada família e o tamanho errado:

public static void main(String[] args) {
    Font guiFont = (Font) Toolkit.getDefaultToolkit().getDesktopProperty("win.defaultGUI.font");
    int guiSize = guiFont.getSize();
    Font iconFont = (Font) Toolkit.getDefaultToolkit().getDesktopProperty("win.icon.font");
    System.out.println("gui default: " + guiFont + "\nicon default: " + iconFont);
}

saída:

gui default: java.awt.Font[family=Tahoma,name=Tahoma,style=plain,size=13]
icon default: java.awt.Font[family=Segoe UI,name=Segoe UI,style=plain,size=15] 

Este último é usado em aplicativos nativos para quase todo o texto, enquanto Swing usa o antigo ...

Questões:

Poderia haver alguma razão para isso, ou apenas um bug?Quem é responsável: a pesquisa Swing (ao ler-no desktopProperty de recursos do sistema relevantes) ou o sistema operacional em não relatá-lo corretamente?Como forçar o uso deste último?

Opções para resolver o último:

Com total controle sobre o LAF, pode-se considerar a definição de todas as fontes de texto relevantes (isso é o que o JGoodies faz, fatorado em uma FontPolicy / Set).Um hack sujo é definir o valor da propriedade da área de trabalho padrão GUI para o valor correto - envolve o acesso reflexivo ao kit de ferramentas, que naturalmente explodirá em contextos restritos de segurança.??

Editar

Apenas no caso de alguém estar interessado, aqui está o hack sujo:

/**
 * Replaces the default gui desktop font property with the icon font
 * if the former is smaller.
 * 
 */
public static void ensureDefaultGUIFontSize() {
    Toolkit toolkit = Toolkit.getDefaultToolkit();
    Font guiFont = (Font) toolkit.getDesktopProperty("win.defaultGUI.font");
    Font iconFont = (Font) toolkit.getDesktopProperty("win.icon.font");
    if (guiFont.getSize() < iconFont.getSize()) {
        invokeDeclaredMethod("setDesktopProperty", Toolkit.class, 
            toolkit, "win.defaultGUI.font", iconFont);
    }
}

private static void invokeDeclaredMethod(String methodName,
        Class<?> clazz, Object instance, String propertyName,
        Object propertyValue) {
    try {
        Method method = clazz.getDeclaredMethod(methodName, String.class, Object.class);
        method.setAccessible(true);
        method.invoke(instance, propertyName, propertyValue);
    } catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
        LOG.finer("forcing desktop property failed " + e.getStackTrace());
    }

}

Editar 2

Só para esclarecer: o hack é totalmente eficaz apenas para o WindowsLAF. Nimbus ignora completamente as configurações do sistema, Metal parcialmente: a fonte deste último é sempre Dialog, somente o tamanho é obtido de desktopProperties. Soa a meio caminho bom, mas não é: o mapeamento é bastante estranho para as fontes principais, f.i. o tamanho de controlFont muito usado é definido como "win.ansiVar.font.height" (que sobras de fósseis é isso?) que é 13 na minha máquina ...

Editar 3

Mesmo no windows ui, o hack é ... um hack com limitações, f.i. aqueles mencionados no comentário de @ Walter:

Esse bug é especialmente perceptível quando você dimensiona a interface do usuário do Windows. FYI, abrindo um JFileChooser reverte o hack. Além disso, a altura da linha JTree / JTable não será atualizada automaticamente para o novo tamanho da fonte e você precisará dimensionar seus ícones também