Задать вопрос
  • Как определить тип выражения, написанного на java?

    @fantomasdnb
    Java разработчик, BPM
    Поставьте себя на место транслятора.
    Вы читая строку `for x: dataSource.getUsers(true)` должны знать, что такое dataSource - какого он типа, что возвращает getUser и вообще есть ли он.
    Откуда это можно узнать? - Из текста программы. Замечу, что значения в Wildcard <> в рантайме уже неизвестно.
    Для примера с dataSource это должно быть описано где-то в коде: определение поля класса или локальной переменной. Если этой информации нет, то значит, что вы сами этого не знаете и компилятор научить не сможете.
    Согласитесь, если я напишу for x: foo.getBar('1'). вы не будете понимать что это и спросите: "а где объявлена foo и что возвращает метод". Для этого нужны исходники (возможно вы и так это понимаете) .

    Для примера с "1,2" + ",3" тип понятен из контекста.

    Что делать дальше: вам нужен практически парсер/компилятор java. Я бы для этого посмотрел в сторону AST (Abstract Syntax Tree) из эклипса. Не самое удобное API и можно легко написать плохой код, но оно 100% решит задачу.)

    С помощью него можно распарсить текст до шаблона, узнать тип переменной и тип возвращаемого значения и получить тип в <>.
    Со строками будет аналогично, только тип можно получить сразу, без парсинга остального кода, так как известно что литерал типа String и все методы этого типа известны всем.

    Надеюсь хоть что-то понятно.

    К слову то, что вы пытаетесь сделать уже реализовано в похожем виде в приблуде под названием Xtend.
    https://eclipse.org/xtend/documentation/203_xtend_...
    Возможно вам это поможет, правда документация у них покоробилась...
    Ответ написан
    Комментировать
  • Как обеспечить взаимодействие потоков в андроиде?

    @fantomasdnb
    Java разработчик, BPM
    Думаю решений может быть несколько.

    1 - блоки synchronized с wait/notify[All]. Обработчик встал на wait, накопитель пашет, как закончил, встает делает notifyAll и встает на sleep. далее аналогично.
    Проблемы: трудно масштабировать, notifyAll будет будить все ждущие потоки и если добавится ещё, то просыпаться будут все и жрать буфер будут все.

    2 - Аналогичное решение c Lock-ами.

    3 - Очередь, Один поток пишет в очередь, другой читает из неё, наверняка можно завернуть в очередь буфферизированный поток или навернуть свой буффер вокруг этой очереди. Плюсы - легко реализовать, синхронизация из коробки. Минусы - масштабирование - не ясно как читать из очереди чанки из буффера множеством потоков, чтобы потом выдать результат в нужном порядке.

    4 - пул потоков обработчиков. Это решение нужно для более простого масштабирования, возможно вам не подойдет. Делаете пул потоков, который умеет обрабатывать определенный класс буффера. Накопитель по готовности скармливает буффер готовому потоку из пула просто запуская этот thread.
    Ответ написан