illuzor

Спецификация - это сухое описание продукта или подхода. ТТХ если хотите. Документация же может содержать советы по применению продукта основанного на спецификации, или наоборот совету по не применению.

По ссылке, которую Вы привели находится спецификация API 8 JDK.

При разработке пользуются в основном гуглом, чтоб найти документацию. К спецификации прибегают в крайне запутанных случаях, например когда мы делаем свою реализацию API чего либо, и нам нужно придерживаться спецификации.

Спецификация языка Java есть по такому адресу: https://docs.oracle.com/javase/specs/.

ИМХО, понять ее не в состоянии даже те, кто ее написал)

Да, новый эмулятор теперь работает очень шустро, намного быстрее чем Genymotion, добавлены полезные встроенные приложения (Google maps, Play Games и др.). Сам эмулятор запускается намного быстрее, так же как и устанавливает и запускает ваши приложения. Никаких фризов, все работает идеально. Теперь отдаю предпочтение новому эмулятору.

Не то что "не зазорен", а даже входит в перечень вопросов в некоторых собеседованиях, в стиле "Что вы будете делать, если не знаете как реализовать вот это, а рядом не у кого спросить?".

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

Стоит сейчас похожая задача, есть pet project по типу КР и других подобных игр. В процессе решения данного вопроса, делаю примерно так:

1. В игре, разумеется, есть некая модель вселенной. В моем случае это звездные системы, которые являются контейнерами для SpaceObject'ов, в которые уже входят планеты/корабли и другие объекты.
   
2. Таким образом, состояние игры можно сохранить как звездные системы и их содержимое, ну и не забыть сериализовать вспомогательные коллекции, типа капитанов кораблей и другой глобальной информации.
   
3. Сериализация вселенной происходит в json. Я пишу игру на unity3d, поэтому мне кажется удобным использовать местный JSONUtility, умеющий проводить сериализацию простых классов (т.е. публичные поля и простые коллекции). Процесс таков: для всего, что я хочу (де)сериализовать, создаю класс-прокси, отражающий в простой форме (без всяких конструкторов, свойств, приватных членов и всего такого) содержимое нужного мне класса, с которым я уже и работаю.
   

Цикл сохранения/загрузки, к примеру, звездной системы, такой:

1. Создаем прокси для StarSystem, он в себя копирует информацию о системе.
   
2. Когда доходим до списка объектов, для каждого из них создаем уже класс-прокси объекта и результирующий экземпляр уже заносится в прокси StarSystem.
   
3. И т.д., пока сложные объекты не закончатся.
   
4. В итоге, имеем матрешку из прокси-классов. С помощью JSONUtility она одной строчкой может быть переведена в json или восстановлена из него.
   
5. Ну а сами сериализуемые классы должны уметь получать информацию из своих проксей при загрузке из сохранения.
   

Собственно, недавно начал это дело реализовывать, т.ч. пока не знаю, насколько оно окажется удобным в использовании. Вполне возможно, многих подводных камней я не вижу, или они всплывут при усложнении игры (например, когда добавятся больше логичесих связей, придется проверять, чтобы не сериализовать одно и тоже по нескольку раз, получая при загрузке разные объекты. Поэтому у всего должны быть некие ID, для предупрежления дублирования).

Раз уж написал, буду благодарен, если более опытные разработчики укажут на крупные грабли в таком подходе, если они есть.

Начните лучше с Java, мой вам совет. Kotlin очень хорош (я как раз сейчас на нём проект для себя разрабатываю), но смущает меня отсутствие официальной поддержки со стороны Google.
Мотивация JetBrains в плане адаптации Kotlin к Android понятна - они хотят зайти на рынок языков под JVM через Android-разработчиков, которые давно уже стонут и плачут от Java 6/7. Непонятно, будет ли эта мотивация такой же сильной через пару лет, когда, например, Google определится с тем, что у них будет вместо Java, и определится не в пользу Котлина (если ещё определится, что, скажем так, вилами на воде написано). Или же Бреслав как главный идеолог проекта потеряет к нему интерес. Или же в JetBrains посчитают расходы/доходы, и решат зарезать поддержку Android. Много чего может произойти, а вам потом проект на нём поддерживать.
Плюс, как правильно отметил в этом треде Денис Загаевский, вакансий мало, и неизвестно, будет ли их больше. А со знанием Java вы себе в обозримом будущем работу Android-разработчика точно найдёте, тут проектов как грязи - выбирай, не хочу.

Update от 17.05.2017: Google объявил об официальной поддержке Kotlin для разработки под Android, так что теперь точно можно начинать вкладываться в него.

это не массивы, а словари (dictionary).

extension Dictionary {
	mutating func merge(other:Dictionary) {
		for (key,value) in other {
			self.updateValue(value, forKey:key)
		}
	}
}

let airports  = ["YYZ": "Toronto Pearson", "DUB": "Dublin"]
let airports2 = ["YYZ2": "Toronto Pearson2", "DUB2": "Dublin2"]
var airports3 = [String : String]()
airports3.merge(airports)
airports3.merge(airports2)

print(airports3)
// ["YYZ": "Toronto Pearson", "YYZ2": "Toronto Pearson2", "DUB": "Dublin", "DUB2": "Dublin2"]

Это происходит потому, что ты пересоздаёшь адаптер каждый раз зачем-то. Тебе нужно добавлять новые элементы в уже существующий адаптер и вызвать метод RecyclerView.Adapter#notifyItemRangeInserted() или RecyclerView.Adapter#notifyDatasetChanged() после этого.

Что по поводу перехода на позицию: RecyclerView#scrollToPosition()