в листе есть два элемента

First one wins - допустимо

Элемент A считает что должен стоять перед элементом B, а элемент B считает что всё не так

Comparable - разве не сам объект решает где ему быть?

Цикличные зависимости отсутствуют, кстати

нет. Он решает где он должен быть относительно любого другого элемента

то есть тебе надо выстроить дерево

Для этого у нас есть TreeSet

Можно сделать своё красно-чёрное дерево с разрешёнными дубликатами

которое принимает, прости господи, компаратор

а компаратор получает предпочтения объектов относительно руг друга

Если предпочтений нет — то это 0

Может быть, раз в решётках имеет смысл понятие верхней и нижней границы, то вместо функции compareTo должны быть функции sup и inf, которые возвращают эти границы. Граница - это множество. Соответствено, "отсортированный" лист должен содержать не элементы, а множества элементов размерностью 2, то есть пары.

Как разлинеить в список? А хз, а может не надо разлинеивать вообще? Ну или брать элементы внутри одной пары в произвольном порядке

https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%88%D1%91%D1%82%D0%BA%D0%B0_(%D0%B0%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0)

что-то ты вот сложное собрал сейчас

А, компаратор не гарантирует сравнения всех со всеми, да?

@bsideup а у тебя там как, любой объект может понять где он должен стоять относительно дугого объекта?
Типа у нас есть мноество
A-B-C-D
B знает что должен стоять до C. Знает ли он что должен чтоять до D?

Я тут просто про PriorityQueue вспомнил

А, не, у неё не сортированный итератор

для обычных объектов мы говорим, что есть две сущности и их сравнение даёт расстояние в виде числа (int compareTo).

простое решение само напрашивается, если и аргументы такой функции подобны целым числам. То есть, если для любых a и b мы можем выбрать функцию, которая спроецирует их на целые числа. Например, User.getPenisLength():: (User) -> int.

и дальше мы говорим, что раз у нас теперь всё есть целые числа, а они - это линейно упорядоченное множество, то если a <= b, то sup(a,b) = b, а inf(a,b) = a. По сути, copmpareTo здесь и есть inf.

но представим, что у нас такой домен, когда существуют несравнимые элементы. Из твита: "does not depend on any other and cannot be compared by anything". Их уже не спроецировать на числа, потому что числа всегда можно сравнить друг с другом, это тот самый полный линейный порядок.  И вот тут  inf уже не compareTo:: Pair->Int, а её полная форма, когда она вместо инта должна отдавать compareTo:: Pair->Pair.

пока всё так? :)