Odissey Nemo

Для обработки (парсинга) XML есть два идеологически различающихся подхода:
а) DOM, когда считывают весь XML в память, строя в ней полную иерархию структуры и
б) SAX - когда проходят по файлу вдоль него, посещая все элементы один раз, причём последовательно.

DOM хорош только для небольших файлов с внутренними зависимостями элементов, когда может потребоваться обратиться к данным произвольных элементов в любой момент времени.

SAX работает максимально быстро (на 1-2 порядка быстрее, чем DOM) но может потребовать реализации сложной логики хранения нужных данных, если логика задачи также потребует возврата к данным предыдущих элементов.

И DOM и SAX имеют устойчивые и надёжные реализации для всех языков и операционных систем мира. Выбор между ними зависит только от задачи и среды разработки.

Есть и смешанные подходы, в частности JAXB - когда с помощью SAX считывают и помещают данные XML не в DOM объект, но в примитивные объекты классов языка, на которых уже и реализуется конкретная бизнес-логика. Проблема JAXB в том, что он может обрабатывать ТОЛЬКО уже известные ему структуры XML, т.е. практически это компиляция XSD в Java/C# и т.д. код. Поменялась XSD - меняй и Java/C# и т.д. код и адаптируй логику программы под новые данные. Зато - максимум достижимой эффективности в процессе работы.

Я лично всегда выбираю SAX, т.к. однажды, лет 10 назад, наблюдал большие затруднения по работе с многосотмегбайтными XML при использовании DOM. При том, что внутри были просто сотни тысяч отдельных мелких логически независимых единиц информации (телефонные счета для рассылки клиентам). А на SAX решили эту же задачу тупо и в лоб, по API документации, без каких-либо хитростей и проблем.

В чём проблема больших объектов DOM? В том, что им требуется много-много маленьких кусочков памяти. А это есть самый плохой случай доступа к данным, как для оперативной памяти, так и для дисковой. Каждый наблюдал это явление, когда запись файла может занимать в десятки раз больше времени, чем его считывание. Собственно, вся обработка данных чисто исторически затачивается на считывание многих данных (кэширование!!!) и запись немногих (write through). Один раз обновил - считывай сотни раз. Именно под такую логику и разрабатываются и оптимизируются процессоры, память, диски, софт!

Насчёт многопоточности - это вопрос не обработки одиночного XML, а а способов слияния результатов обработки отдельных XML в общую БД. Так и так каждый отдельный XML объект может быть обработан ТОЛЬКО в одном потоке. Так уж он устроен. Если представить себе какой-то гигантский XML, структура данных которого позволяет параллельную обработку, то всё равно хотя бы раз его придётся полностью пройти в одном потоке, чтобы разделить на автономные единицы параллельной обработки.

Кстати, Oracle умеет достаточно эффективно обрабатывать поля своей БД, содержащие XML. И делает это именно через SAX )))

Пробовал писать ГИП в JIdea. Не понравилось. Теперь пишу только руками. Через Swing. Это обеспечивает полный контроль над графикой. Но комментариев надо писать тоже много. Чтобы не потерять нить логики построения ГИП.

Для задач, разрабатываемых на одной платформе, а работающих на других. В частности, писал модули (без графики, естественно) для сервера ФМС РФ на винде (JIdea), а работали они, без малейших нареканий, на IBM'овском сервере по Юниксом. Java была 4-й версии)))

Вообще для кросс-платформенных приложений Java - пока лучший язык, вернее, среда исполнения. Да, С или С++, если не использовать разные ненужные хитрости и прибамбасы, можно без особых усилий компилировать на той или иной платформе. Но чтобы программа шла просто переносом бинарных файлов - это к Java.

Назови по русски (или на том языке, на котором мыслите), а потом переведите на английский. Так, чтобы было понятно тебе, в первую очередь. Иногда Гугль или Яндекс дают неплохие переводы, а иногда - отвратные. Для скорости можно использовать их, но обязательно и тщательно проверять смысл ими содеянного.

И старайтесь называть покороче, используя общепринятые сокращениями, на английском, конечно. Button == Btn, Rectangle == Rect, Point = Pnt, Control == Ctrl|Cntrl etc. RectangularButton == RectBtn, EscapeButton == EscBtn etc etc etc.

Возможно, ваш исходник на диске в кодировке Windows-1251. Сохраните его как UTF-8 (без BOM, скорее всего)). Если так и было, то, по кр. мере, теперь вся выводная строка будет в единой кодировке. И должна выводиться или искажаться равномерно)))

Достаточно SE. И учить Android SDK. Он достаточно специфичен и существенно отличается от всего, что было на нормальных ПК.

"Стоит" лист бумаги на столе? Пусть покажут, как они поставят лист бумаги на любое ребро, остальное чепуха.

P.S. Предполагаю, что собеседование было в ГосЦирке.

Сортировка слиянием отсортирует любой объём данных, помещающихся на жёстком или ином диске.

Возможно, имелось в виду и это:
"Знание некоторых принципов легко возмещает незнание некоторых фактов". Клод Гельвеций.

Вот текст статической подпрограммы из собственного класса Files (часто встречающиеся операции с файлами, сбор имён не требовался ), стирающей всё содержимое заданной директории. В т.ч. и рекурсивно (по параметру). Для чего требуется стереть все файлы и во всех вложенных директориях.Переработать в нужном направлении нетрудно, добавив параметр для сбора имён обнаруженных файлов и его заполнение в нужном формате:

/**
	 * Tries to remove all files (and sub-directories optionally) in the designated
	 * directory
	 *
	 * @param dir_path  directory path to clear from other files and optionally
	 *                  directories
	 * @param recursive deletes sub-dirs also if set to {@code true}
	 * @return {@code true} if operation completed successfully that is no errors
	 *         occurs during operation, else {@code false}
	 */
	public static boolean clearDirectory( String dir_path, boolean recursive )
	{
		File dir = new File( dir_path );
		if ( !dir.isDirectory() )
		{
			return false;
		}
		boolean res = true;
		String[] files = dir.list();
		String fdir = Files.resetDir( dir_path );
		String fpath;
		StringBuffer sb = new StringBuffer();
		for ( int i = 0; i < files.length; i++ )
		{
			sb.delete( 0, Integer.MAX_VALUE ).append( fdir ).append( files[ i ] );
			File file = new File( fpath = sb.toString() );
			if ( file.isDirectory() && recursive )
			{
				res = clearDirectory( fpath, recursive );
			}
			else
			{
				try
				{
					res = file.delete();  // TODO: здесь забирать конкретное имя фала в общий выходной массив
				}
				catch ( SecurityException se )
				{
				}
			}
		}
		return res;
	}

Вызываемый дополнительно код ниже:

/**
	 * The system-dependent default name-separator character. This field is
	 * initialised to contain the first character of the value of the system
	 * property file.separator. On UNIX systems the value of this field is '/'; on
	 * Microsoft Windows systems it is '\\'.
	 */
	public static final char FileSeparator = File.separatorChar;

	/**
	 * The system-dependent default name-separator character. This field is
	 * initialised to contain the first character of the value of the system
	 * property file.separator. On UNIX systems the value of this field is '/'; on
	 * Microsoft Windows systems it is '\\'.
	 */
	public static final char FS = File.separatorChar;

	/**
	 * appends system dependent file separator char
	 *
	 * @param FilePath - string to check for file separator existence
	 * @return new string with appended file separator or the same string if it
	 *         already was present
	 */
	public static String appendFileSeparator( String FilePath )
	{
		return appendFileSeparator( FilePath, FileSeparator );
	}

	/**
	 * appends system dependent file separator char
	 *
	 * @param FilePath - string to check for file separator existence
	 * @param sep      character to be a last separator in the input string
	 * @return new string with appended file separator or the same string if it
	 *         already was present
	 */
	public static String appendFileSeparator( String FilePath, char sep )
	{
		if ( Text.isEmpty( FilePath ) )
		{
			return "" + sep;
		}
		char ch = FilePath.charAt( FilePath.length() - 1 );// get last symbol
		if ( ( ch != '/' ) && ( ch != '\\' ) )// check it to be a separator one
		{
			return FilePath + sep;
		}
		else
		{
			return FilePath.substring( 0, FilePath.length() - 1 ) + sep;
		}
	}


	/**
	 * the same as {@link #appendFileSeparator} but with shorter name :o)
	 *
	 * @param path path to append file separator
	 * @return path with trailing current file names separator
	 */
	public static String resetDir( String path )
	{
		if ( path == null )
		{
			return null;
		}
		return appendFileSeparator( path );
	}

Крупных компаний по разработке софта в РФ нет. И вообще крупные компании в РФ - это только по экспорту невозобновляемых природных ресурсов в интересах членов кремлёвского кооператива.

Тот же "Техносерв" - сотня разработчиков самых разнообразных воззрений и эклектических решений. Берутся руководители департаментов, РП и ПМ за всё, что движется, а отвечают за результаты разработчики.
И на чём делать - им всё равно. Работая там, использовал и C# и Java EE.

Писал существенные консольные приложения на Java с разработкой на Windows для могучего IBM сервера ФМС. Всё всегда работало с первого раза. Был приятно удивлён. Java 1.4, нужно отметить. Без enum'ов и прочего блуда. Чистый код, без примесей фреймворков.

На С(++) если писать свою программу любой сложности, то однозначно библиотека potrace. Опен-соурсе к тому же.

Джуниор в американского - левый пацан, которого нужно эксплуатировать. А в русском это начинающий программист, будущий товарищ.

Если джуниор не справляется - уволить без выходного пособия. И нанять другого.

Если начинающий программист не справляется, ему надо помочь. И он быстро станет нормальным разработчиком, благодарным за помощь. Если не видишь у него желания справляться - наказать как либо для его же пользы (воспитательный момент). Если видишь, что лентяй при этом ещё и любит слова типа "джуниор", "сениор" - уволить за профнепригодность для коллектива, с объяснением причины.

Такова разница менталитетов и культур.

На java можно писать всё то, что пишут и на других языках. И базы данных (через JDBC) и приложения с формами (Swing) и обработку графики (через GDAL, например). Это не считая WEB приложений, на которые Java особенно заточена.

Так, за последние 7 лет в в одиночку или содружестве написаны:
1. Ядро ГИС-системы (отрисовка и пространственные запросы.
2. Предобработка спутниковых изображений (любого размера через кэширование по кускам).
3. Быстрая медианная фильтрация однобитовых изображений.
4. WEB сервис для хранения и выдачи разнородных данных. Написан полностью на Java SE, без каких либо JavaScript'ов, Питонов и т.д.. Но с помощью библиотеки Vaadin.

Ядро ГИС писалось, в частности, с целью сравнения скорости работы Java с С и Дельфи. В настольном приложении пользователя потери скорости не обнаружены. Куски карты размером в экран монитора генерировались из векторных данных на диске за десятые доли секунды. При этом память оставалась константного размера независимо от размера данных или одновременно открытых карт.

Отсюда вывод: пишет программист, но не язык, который он использует. И на выбор языка для разработки больше влияют запросы и условия заказчика, а не пристрастия разработчиков.

Наверное, на КОБОЛе программировать сегодня посложнее, нем на Java, C[#] или Fortran, но и язык этот из тех, что закончили своё существование.

Проще всего взять карту известной проекции, пригодной для Ваших целей, и экспортировать её в SVG. Или найти свободно распространяемую карту в "географической проекции" (почти все файлы SHP в ней и создаются) и спроектировать её в удобную Вам и потом уже в SVG. Сделать это можно в любой ГИС (ArcGIS, MapInfo и т.д.).

Теперь трансформируйте координаты своих точек в искомую проекцию и работайте.

А обсуждаемые программы есть. И уже давно. Но не в широком использовании. Представляют они чисто научный интерес. Если и искать их, то в учебных заведениях с картографическим профилем (кафедра картографии МГУ, например).

Числодробительный код на Java примерно в 2-3 раза медленнее, чем на С++ или, скажем, Delphi. Так кажется на собственной субъективном опыте. Т.к. на Java слишком много разных фич пристыкованы в байт-коде чисто механически.

Но писать программы со вполне удовлетворительным быстродействием вполне можно. Даже нумерологические. Скажем, полная обработка растров размерами 10000 на 10000 (бинаризация или другие матричные фильтры) средствами собственного кода (без нативных библиотек) вполне отрабатывает за секунды. Не утомляя пользователя. Но!Тут и встаёт вопрос о знании алгоритмов, вернее, какой где стоит применить.

Strips - это отдельные последовательные блоки в Tiff. Для ускорения доступа к произвольным частям растра.

Использовать в целях всеядности и оптимальности можно GDAL (есть Java коннект) - то натуральный зверь, жрущий всё подряд. Относительно сложен в освоении, но достаточно прост в использовании. Примеров - много.
Т.к. GDAL работает почти с любыми форматами растров, проблем с переделкой существующего кода не будет. Разве только с новым кодом работы с GDAL) И да, он занимает много места (на каждый формат своя библиотека).

Возможно, ради только TIFF и не стоит с GDAL заморачиваться.

Вместо str1 == str2 лучше использовать str1. equals(str2)