nirvimel

Selenium WebDriver

Создание временного объекта допустимо (по соображениям производительности), если класс этого объекта удовлетворяет нескольким условиям.
Временный класс должен иметь только final поля (то есть никаких других полей кроме final он иметь не должен). И сам экземпляр этого класса (если не передается напрямую) должен храниться в final локальной переменной. Если это условие соблюдено (есть еще незначительные условия), то включается крутейшая оптимизация (кажется, начиная с Java 7, но точно не помню), которая на выходе дает код, практически эквивалентный тому, как если бы все поля этого класса передавались бы в функцию через параметры (никакой объект класса при этом не создается).
Дополнительное условие, требуемое для включения этой оптимизации - код во всех его методах (включая конструктор) не должен вызывать сторонних эффектов (не обращаться к внешним классам, не вызывать new, и др.). Без опыта написания чистых функций проще всего соблюсти это ограничение, если вообще не создавать никаких методов, кроме конструктора, который только инициализирует поля значениями своих параметров.
Еще одно условие - этот класс должен быть унаследован только от Object и должен запрещать наследование от себя (то есть сам должен быть final).

Кстати, в последних версиях версиях Java (7/8) вообще много разных оптимизаций для тех, кто пишет final по умолчанию везде, и убирает только когда это совершенно необходимо.

В режиме телепатии догадываюсь, что вы хотите реализовать. Видимо, речь идет о совершенно стандартном механизме порождения объекта соединения из объекта БД.
Чтобы понять как строятся подобные велосипеды загляните в код любой ORM или вообще любой ООП-обертки над драйвером БД. Вы увидите в большинстве случаев следующую картину:
1. Конфигурация БД представляет собой фабрику (да, да, те самые паттерны, которые неофитам НИНУЖНЫ).
2. Метод connect возвращает объект соединение.
3. Объект соединение (кроме методов по выполнению запросов) имеет метод close, который закрывает соединение (попытка выполнения запроса на закрытом соединении будет выдавать ошибку).
4. Соединение (как объект) живет один раз и не может быть переоткрыто после закрытия. Но из фабрики БД всегда можно открыть новое соединение.

Почему так:
Главный принцип ООП: отдельному понятию - отдельный класс. БД (на стороне клиента) представляет собой только конфигурацию: адрес сервера, имя юзера, пароль, имя БД и прочие параметры. Соединение к БД - это отдельная сущность, через которую создаются транзакции и курсоры (отдельные сущности), через которые выполняются запросы. Результат выполнения запроса - отдельная сущность. Отдельная строка в выборке - отдельная сущность (если только не кортеж). И только отдельные поля в строке имеют примитивные типы данных.

Можно подцепить libpython через JNI. Но придется писать JNI модуль на Си.
Если одним языком вам сложно обойтись, то тут не обойдетесь и двумя.

Можно ли организовать организовать сетевой обмен?

Можно.

Или как можно организовать такое соединение?

Для этого понадобится java-программист уровня junior в количестве 1 шт.

Вообще это похоже на стандартное тестовое задание на собеседовании на вакансию джуниора, которое кандидат обычно пишет на месте в процессе собеседования.

1. Если characteristic_value привязано к subject_model, characteristic_name (почему бы не назваьть эту таблицу просто characteristics, ведь там может храниться еще что-то кроме имени) можно не привязывать к subject. Этим достигается независимость характеристик от субъекта и отсутствие дублей среди характеристик.
   
2. Что-бы при назначении значения характеристики модели можно было производить проверку на то, возможна ли вообще такая характеристика для субъекта, нужно ввести кросс-таблицу subject_characteristics (характеристики субъектов), которая бы имела внешние ключи к subject и characteristic_name, то есть many-to-many зависимость между ними, через отдельную кросс-таблицу.
   
3. У вас всего два фиксированных уровня иерархии. Что, если на практике потребуется больше? Вы, кажется, стремитесь создать гибкую/универсальную систему. Тогда вам нужна динамическая иерархия категорий.
   
4. Если view служит для представления, то внешний ключ к нему в characrteristic_name не нужен, так как логически характеристика, как единица учета, не подчинена представлению данных. Опять же лучше ввести many-to-many зависимость между характеристиками и представлениями, реализованную через кросс-таблицу. Подсистема представлений при этом остается полностью независимой ото основной структуры данных (ее можно убрать не нарушая структуру).
   

P.S.: Интересно, в каком это смысле дрель (инструмент) может быть субъектом.

для добавления произвольного узла в дерева, следует пройтись по всем узлам для коррекции смещений узлов в файле и перезаписать.

Это в любом случае неизбежно. Единственно что можно сделать для сокращения дискового I/O - это, вместо записи множества кусков (через seek->write->seek->write), использовать встроенные в ОС механизм memory mapping (в Java он реализован через MappedByteBuffer), тогда проблема оптимизации кеширования и сброса буферов на диск ложится полностью на ОС.

Количество потоков не равно количеству открытых сокетов. Расходовать на каждое подключение отдельный поток ни в коем случае нельзя. Но синхронно закрывать сокет после обработки подключения совсем не обязательно. Сокет - просто значение ячейки массива (или карты) будет взято и использовано когда понадобится в любом потоке (работа с конкретным сокетом, конечно, должна быть обернута в соответствующий синхроблок). Единственно, о чем не следует забывать это - KeepAlive пинги (отдельный пул потоков и таймера под них, например), которые обеспечивают сразу две задачи: 1) помогают удержать неактивное соединение (умные роутеры любят закрывать "мертвые" соединения, и клиент, в зависимости от реализации, может делать то же). 2) очищают список сокетов от реально мертвых.

Так делается для того, чтобы оставить за собой возможность впоследствии поменять реализацию не меняя интерфейс. Например, в будущем может потребоваться заменить реализацию ArrayList на LinkedList, если бы в качестве типа переменной был указан конкретный класс, то к тому времени код мог бы уже обрасти различными обращениями к, специфическим для конкретного класса, методами, выходящими за границы интерфейса List. В таком случае при замене реализации на LinkedList пришлось бы выискивать в коде и выкорчевывать оттуда все обращения к специфике ArrayList. На сколько это адски сложная задача знают все, кому приходилось работать над крупными проектами. Поэтому люди, знакомые с этой проблемой, предпочитают предупреждать подобные проблемы заранее, то есть во всех местах, где возможна смена реализации в будущем (то есть почти везде), стараются пользоваться исключительно интерфейсами, вместо того, чтобы опираться на конкретные реализации. В данном примере, если в качестве типа переменной был бы использован интерфейс List, то смена реализации ArrayList на LinkedList решалась бы заменой всего одной строки не зависимо от масштабов проекта.