В одну телегу впрячь не можно
Коня и трепетную лань
А.С. Пушкин
Цель этой статьи предостеречь разработчиков от использования обфускаторов с функцией шифрования class-файлов для защиты своих приложений и от бессмысленной траты денег на них.
В начале месяца появились новости о том, что Red Hat открыла код своей PaaS OpenShift. Те, кто следит за развитием этого проекта, наверное уже заметили, что в Red Hat уделяют OpenShift очень большое внимание. Помимо добавление нового функционала (из недавнего — поддержка Node.js) постоянно происходит и улучшение уже существующего. К последнему можно отнести и новость о переходе в Red Hat двух ключевых разработчиков JRuby.
Уважаемое Хабр-сообщество, хотел бы рассказать об одном из продуктов, который мы разрабатываем — Stringer Java Obfuscation Toolkit (https://jfxstore.com/stringer). Думаю многим Android и Java-разработчикам будет интересно, особенно, в свете подобных публикаций: habrahabr.ru/post/141522. 
public class Test {
static {
//Write some code here
}
public static void main(String[] args) {
Integer a = 20;
Integer b = 20;
assert (a + b == 60);
}
}
Pair<First, Second>), менее часто «тринарными» объектами (Triplet<First, Second, Third>) и более длинными цепочками ассоциированных объектов. В связи с чем всегда удивлялся, почему в JDK (в java.lang.* или java.util.*) до настоящего момента нет стандартной Pair<First, Second> или более длинных конструкций. Думаю многие программисты практикующие на Java имеют свою реализацию «пары». Не исключением являюсь и я.
Oracle: Вопрос не в том, насколько велик ущерб. Вопрос в том, можно ли закрыть глаза на коммерческую выгоду нарушителя исходя из того, что объём нарушений мал.
Кроме того, для меня не ясно, что справедливо сравнение девяти строк кода и 15 миллионов, потому что из них 10 миллионов составляет ядро Linux. Но всё равно, девять строк — это небольшой процент. Тестовые файлы гораздо больше, но они не присутствуют, по крайней мере, в текущей версии Android.
