Алексейтекст ещё не в индексе
Тогда ты просто берёшь и пишешь на шарпе или на другом языке который ориентирован для десктопа.
Или пишешь веб приложение из фронта и бека.
И не заморачиваешься.
24 июля 2026
АлексейЕще раз подчеркиваю - есть продукты от JB. Они очень мертвые)
Они, вроде как, используют не штатный Swing, а существенно ими перепиленный. Изучить что они сделали и как это применить - отдельная большая работа, особенно для новичка. А дальше встаёт вопрос как эти знания использовать в дальнейшем.
WandererОни, вроде как, используют не штатный Swing, а существенно ими перепиленный. Изучить что они сделали и как это применить - отдельная большая работа, особенно для новичка. А дальше встаёт вопрос как эти знания использовать в дальнейшем.
Речь не об этом. А о том, что бросаться терминами типа "мертвая технология" - глупо. Было бы желание применить.
АлексейРечь не об этом. А о том, что бросаться терминами типа "мертвая технология" - глупо. Было бы желание применить.
Что считать мёртвой технологией. Если есть много задач на ней, то хорошо, используй. Если они ещё и деньги приносят - вообще хорошо.
Но, скажем, найти вакансию на жава-десктоп крайне сложно.
Да и пиля свои проекты, ты оказываешься один: нет никого кто тебе поможет и подскажет.
Можно сказать не "мёртвая", а "не востребованная" 🤷♂
WandererЧто считать мёртвой технологией. Если есть много задач на ней, то хорошо, используй. Если они ещё и деньги приносят - вообще хорошо.
Но, скажем, найти вакансию на жава-десктоп крайне сложно.
Да и пиля свои проекты, ты оказываешься один: нет никого кто тебе поможет и подскажет.
М
Скорее узконаправленная. Но не мертвая.
АлексейСкорее узконаправленная. Но не мертвая.
ну если для тебя принципиально говорить точными терминами, то пусть будет так
АлексейСкорее узконаправленная. Но не мертвая.
ну это теплое и мягкое, фреймы для десктопа на java как раз мертвые, потому что их развитие остановилось где то в середине нулевых, JB вроде как поддерживают форк для своих нужд, вот он может "узконаправленный, но не мертвый"
28 июля 2026
Всем привет! вопрос по проектированию REST API и Spring MVC. У нас есть 2 сущности комната (Room) и задача (Task). В комнате мы можем создавать задачи и ими управлять. Как мне спроектировать это на уровне сервиса и контроллера? Я думаю так: у нас будет 2 репозитория под каждую сущность (соответсвенно RoomRepository и TaskRepository). Они будут полями класса RoomService. Тогда методы этого класса будут помечены @Transactional для реализации транзакций. И в RoomController будут uri по типу /rooms, rooms/{id}/tasks, rooms/{id}/tasks/{id}... Корректная ли это реализация?
BalabolВсем привет! вопрос по проектированию REST API и Spring MVC. У нас есть 2 сущности комната (Room) и задача (Task). В комнате мы можем создавать задачи и ими управлять. Как мне спроектировать это на уровне сервиса и контроллера? Я думаю так: у нас будет 2 репозитория под каждую су
может ли задача существовать без комнаты? а если комнату удалят, выполненная задача должна быть доступна?
Tetraможет ли задача существовать без комнаты? а если комнату удалят, выполненная задача должна быть доступна?
Задача зависит от комнаты. При удалении комнаты все задачи в ней будут тоже удалены
@dmsol а чего превью отключены в чате чтоли?
