Первый релиз Java 11

Учите Groovy, если нужна «перегрузка операторов».

Вообще Groovy очень дополняет Джаву.

И этот клоун и дегенерат называл Kotlin (который в разы лучше Groovy) недоязычком, а Жабу - самодостаточным языком. Бугага!

Определить, какая именно перезагрузка используется в данном случае - трудоёмкая операция. Гарантировано найти именно те места, где используется данный оператор для данного типа - вообще невозможно

... если не пользоваться предназначенными для этого инструментами.

Перегрузку операторов не завезли? Закапывайте!

В Котлине давным давно завезли. Я лично реализовал векторную арифметику на Котлине.

internal operator fun Array<BigDecimal>.plus(other: Array<BigDecimal>) = this.arithmetic(other) { x, y ->
    x + y
}

internal operator fun Array<BigDecimal>.minus(other: Array<BigDecimal>) = this.arithmetic(other) { x, y ->
    x - y
}

private fun Array<BigDecimal>.arithmetic(other: Array<BigDecimal>, operator: (BigDecimal, BigDecimal) -> BigDecimal): Array<BigDecimal> {
    return if (this.isNotEmpty() && other.isNotEmpty()) {
        val thisSize = this.size
        val otherSize = other.size
        val maxSize = maxOf(thisSize, otherSize)
        val result = Array<BigDecimal>(maxSize) {
            BigDecimal.ZERO
        }
        for (i in 0 until maxSize) {
            result[i] = operator(this[i % thisSize], other[i % otherSize])
        }
        result
    } else {
        emptyArray()
    }
}

object Main {
    
    @JvmStatic
    fun main(args: Array<String>) {
        val a = arrayOf(BigDecimal("0.5"), BigDecimal("0.6"), BigDecimal("0.7"))
        val b = arrayOf(BigDecimal("0.8"), BigDecimal("0.9"), BigDecimal("1.0"))
        println(Arrays.toString(a + b))
    }
}

К тому же не совсем очевидно почему += должен конкатенировать а не складывать поэлементно, как это принято в математике.

Ну да, вопрос семантики.

Кстати, есть другая либа для такого: https://www.boost.org/libs/numeric/ublas

Ну и уже упомянутый std::valarray так делает.

Кстати, у меня зачесалось заимплементировать оператор для конкатенации векторов (ШАЯИІИ6: засилие std::): https://wandbox.org/permlink/QsnxPIObYIthjLzF

Как минимум томкат в дебиане кастрированный.

В каком месте?

И этот клоун и дегенерат называл Kotlin (который в разы лучше Groovy) недоязычком, а Жабу - самодостаточным языком. Бугага!

Kotlin на столько же лучше жабы, на сколько модель с глянцевого журнала лучше самодостаточной личности c PhD.

есть понятие «java platform»: язык + jvm + библиотеки + тулинг + стандарты на всё вышеперечисленное + документация и хорошие практики

идея «java platform», как её ещё Sun придумали - write once, run anywhere

чтобы это стало возможно хоть в какой-то степени, были придуманы безумно сложные стандарты и тесты, кототорым должно отвечать нечто, чтобы называться Java

самая важная ценность, из-за которой и Sun, и Oracle, и остальные компании годами бьются насмерть - это единство и нефрагментация платформы. Самое большое зло - фрагментация платформы.

андроид - это не Java. Он даже стандарту языка до конца соответствует.

но Гугл совершил еще и два важных преступления:

а) он фрагментировал платформу

б) он превратил жизнь андроид-разработчиков в ад, потому что всё что работает в Java обычно не работает на Android

раньше я очень злился на оракл за этот иск, а потом разобралися и понял, что гугл неправ просто по всем статьям. Придолбаться формально к ним сложно, потому что они нигде и не говорили, что «андроид - это java». Но по смыслу это капец

Причем тут Котлин?

Котлин:

«Kotlin (Ко́тлин) — это статически типизированный язык программирования»

Groovy:

«сновные возможности языка, отличающие его от Java: как статическая, так и динамическая типизация»

«Язык может использоваться в любом Java-проекте или как скриптовый язык.»

Учите матчасть.

https://causecode.com/kotlin-vs-groovy/

А потом снова вылезайте на форум - очередную копипасту генерить про «легковесные и модульные решения»(С) -

Как там Kotlin поживает? (комментарий)

Ты теоретик-дилетант, это тебе следует матчасть изучать. Груви - динамический язык. Ущербный ламерок, дает ссылки,смысл которых даже не знает. Заходим и читаем:

Kotlin is statically typed language whereas Groovy is dynamically typed language. This means that the type of a variable should be known at compile time.

Что и требовалось доказать. Флудераст как всегда сел в лужу.

а в чём проблема? неясен тип операнда?

К примеру, как мне найти в коде все места, где используется перегруженый для базового класса оператор <<?

Есть куча унаследованных классов, как найти все места где этот оператор вызывается?

Буду весьма благодарен, если кто-то подскажет как это сделать в емаксе.

Какие инструменты это могут? Мне бы пригодилось.

И? Ты думаешь как-то умело сумеешь скрыть от IDE свои злостные намерения, и она ну никак не сможет найти перегруженные операторы? А во вторых ничего не известно про область действия таких операторов, может они ограниченны одним классом а не пакетом. Равняться нужно на среднего программиста а не на слабых, слабые даже с помощью вселенной ничего дельного не сделают. В общем я не знаю нужна ли перегрузка операторов в явке, но то что это не значит что-то плохое это точно.

Вместо апплетов теперь браузерные API

угу, вместо нормальной технологии теперь корявые костыли, для единственного браузера от единственного вендора. Vendor Lock-in в чистом виде
Причем костыли использующие тоже VM, но отстающую лет на 10 по фичам от JVM

Кульхацкеры не понимают одной простой вещи.

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

Первая мысль ответственного руководителя - а где я найду хипстерочков-креативщиков от программирования на хайповый язык Y, если язык Y менее распространен, чем пусть и тяжеловесный и «устаревший», однако, знакомый в компании язык X.

Хайп на недоязычки и хейт Java - это маркер, по которому на ЛОРе можно сразу определять кульхацкеров с повышенным ЧСВ и пониженной востребованностью на рынке труда, не нашедших себе работу в крупных компаниях.

Но то, что кулькакеры _всегда_ ошиваются на тредах про Java и пытаются кидаться какахами - это хорошо. Иначе было бы скучно.

Это говорит только об огромной популярности и востребованности Java и Java-программистов.

Где я отрицал, что Groovy - динамический язык программирования?

если потребовался конкатенирующий +=, то зачем ещё добавлять оператор +, который к тому-же не симметричен по отношению к своим аргументам (что как-бы наводит на размышления)

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

Хайп на недоязычки и хейт Java - это маркер, по которому на ЛОРе можно сразу определять кульхацкеров с повышенным ЧСВ и пониженной востребованностью на рынке труда, не нашедших себе работу в крупных компаниях.

Ор выше гор.

Java - это один из языков под JVM. Это раз.

Программирование на «недоязычках» - не освобождает от знания Жабы и всей ее экосистемы. Это два.

Жабу никто не хейтит, лживый слизень. Просто она устарела и есть более продуманные языки, как Котлин, например. Это три.

Первая мысль ответственного руководителя, а не идиота, вроде тебя - любой JVM язык осваивается менее чем за неделю, если есть опыт и знания в программировании на Жабе. Тот-же Котлин или Скалу можно изучить вдоль и поперек менее чем за неделю. Это четыре.

Ты думаешь как-то умело сумеешь скрыть от IDE свои злостные намерения, и она ну никак не сможет найти перегруженные операторы?

И будет яростно подсвечивать мне это место, а компилятор сыпать варнингами, намекая что я делаю что-то не так.

Равняться нужно на среднего программиста а не на слабых

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

Где я отрицал, что Groovy - динамический язык программирования?

Слизняк изворотливый, ты утверждал, что Груви - статический язык. А не отрицал, что Груви динамический. Разницу ощущаешь?

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

Где я это утверждал?

зачем в динамических языках перегружать операторы

Ну, видать, мой анонимный друг имеет больший практический опыт, чем Джеймс Стрэчен.

Умничать будете на собеседованнии.

Или в собесе.

---------

Для адекватных.

Обычно на собеседовании, если кто мнит себя великим знатоком Groovy, даю задачку (модификация моего предыдущего примера).

Что будет

class ArraysAdd {
    public static Collection plus(Collection a, Collection b){
        [a, b].transpose().collect{x, y -> x+y}
    }
}

use (ArraysAdd) {
   assert [11, 22, 30] == [10, 20, 30] + [1, 2]
}

и почему.

возможно я не правильно понял проблему, но самый простой способ - закомментировать перегрузку оператора << для базового класса и попробовать собрать проект. Ошибки компиллятора покажут все нужные места.

если потребовался конкатенирующий +=, то зачем ещё добавлять оператор +, который к тому-же не симметричен по отношению к своим аргументам (что как-бы наводит на размышления)

А то, как операторы «+» и «+=» работают со строками, на размышления не наводит?

А если складывать 2 массива как в математике, а у них внезапно длины разные? Дополнить короткий массив нулями? Или обрезать тот, что подлиннее? А дополнять или обрезать с конца или с начала? А если дополнять - почему именно нулями, а не, например, первым или последним элементом коротокого массива?

По-моему, конкатенация - как раз наиболее интуитивное действие для большинства программистов. А меньшинство и сомневающиеся могут почитать документацию на API и проверить как правильно.

если потребовался конкатенирующий +=, то зачем ещё добавлять оператор +,

Для универсальности. А еще operator + не определяет автоматически operator +=

который к тому-же не симметричен по отношению к своим аргументам (что как-бы наводит на размышления)

Всмысле, что не можно переставить аргументы местами (в случае если LHS не вектор)?

Политика ass-saver: ограничился лишь случаями когда вектор есть RHS. Логически, чтоб другой контейнер был в качестве RHS, надо для такого контейнера уже определять свои операторы.

А если все же наделать еще std::vector<T> operator+(Container &&, std::vector<T>) то скорее всего возникнет ambiguous overload.

Какие инструменты это могут? Мне бы пригодилось.

Для емакса не знаю, знаю проприетарь которая может. Но такое может быть сделано и на основе clang, если еще не.

А возвращаясь к яве - у нее с инструментарием намного лучше, и операторы никакой проблемы точно не составили бы.

Ошибка компилятора покажет первое нужное место, ну может ещё пару мест в файле. А с остальными как быть?

А как насчёт второй задачи?

Для емакса не знаю, знаю проприетарь которая может.

Как называется? Хотелось бы посмотреть.

может быть сделано и на основе clang

А может быть и не сделано...

Наверное можно пытаться прикрыть косяки языка с помощью суперумных IDE. Однако если за 30 лет основные IDE этому не научились...

у нее с инструментарием намного лучше, и операторы никакой проблемы точно не составили бы

Обоснуйте.

В таком стиле -

http://beust.com/weblog/2009/04/12/why-java-doesnt-need-operator-overloading-...

А то «титиретиков» много - a найти хорошего, реально могущего создавать практические программы, Java-программиста даже за 3 .. 4 килобакса в месяц в ДС трудно.

Для емакса

Ага! Самый подходящий инструмент для реального enterpriZe программирования.

За 3-4 килобакса только говнокодеры вроде тебя работают. Может ещё идейные.

То бишь JS?

А какая разница? По Эскобару — совершенно никакой.

Зато окучивают правительственные структуры США.

Ну а в неправительственных структурах, много ли новых проектов на Sencha?

Не потерял - https://vaadin.com/success-stories

Аналогичный вопрос.

Гвит намного проще, чем Spring MVC или Apache Wicket.

На сколько я помню, там примерно такой же подход, как в Swing.

Сейчас, правда, тенденция такова, что меня переключили только на backend, а frontend должны создавать молодые креативные специалисты по JS.

Очень хорошая тенденция, ибо full stack - это зло.

вы уверены ? не вижу причин не показать все места в данном случае

А зачем гнаться за хайпом, если и так все работает.

А не чиню, то, что не сломалось.

------

Ну, а JS я подключил просто.

Очень просто.

Вышло примерно так (я здесь чуть упростил реальный код) -

public class MyCopyClipboard {
    public static native void nativePutText(String s) /*-{
		var clipboard = {
			data : '',
			intercept : false,
			hook : function(evt) {
				if (clipboard.intercept) {
					evt.preventDefault();
					evt.clipboardData.setData('text/plain', clipboard.data);
					clipboard.intercept = false;
					clipboard.data = '';
				}
			}
		};
		window.addEventListener('copy', clipboard.hook);
		clipboard.data = str;
		if (window.clipboardData) {
			window.clipboardData.setData('Text', clipboard.data);
		} else {
			clipboard.intercept = true;
			document.execCommand('copy');
		}
    }-*/;
}

любой JVM язык осваивается менее чем за неделю, если есть опыт и знания в программировании на Жабе.

Видел Groovy код «изучивших» его Java программистов. Они просто продолжают писать как в Java, лишь изредка используя какие-то особенности Groovy.

Перегрузки операторов не будет потому, что не нужна в Java. Авторы Java стремились к повышению надёжности программ, которая особенно важна для серверных приложений

много лет назад обсуждалось.

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

там примерно такой же подход, как в Swing

Да, но пара ML + Java в Wicket не опциональна, а в GWT только стартовый файл нам нужен. Хотя можно и весь ML вынести, если есть хороший дизайнер.

Самое интересное, что был такой продукт

https://en.wikipedia.org/wiki/WebObjects

Да, именно Apple был с своё время первым!

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

full stack - это зло

Абсолютное зло. Сопровождать и расширять такой продукт трудно. Очень трудно.

Поэтому и перевели GXT и Vaadin в разряд фреймворков для small & mid-size задач.

Хотя и такие неожиданные enterpriZe вакансии для жабабыдлокодеров существуют -

https://jobs.raytheon.com/job/st-petersburg/full-stack-java-developer/4679/85...

У меня не работает. Только что проверил. a + b вводит как есть и подчёркивает как ошибку. a.add(b) ни во что не преобразовывает. Или это где-то в настройках включается?

Я не работаю с IDEA, но видел такую фичу, сейчас загуглил и нашел вот такое https://plugins.jetbrains.com/plugin/7224-java-operator-overloading-support Но вроде оно из коробки должно работать.

Как называется?

Решарпер под студию под винду.

Еще https://code.woboq.org, там что-то свое на clang. Например: https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.h.html#1346, смотрим «Show Uses».

А может быть и не сделано

Это же поиск узла AST с вызовом конкретного оператора, что тут может быть не сделано?

Честно, не понял в чем тут косяк языка.

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

Обоснуйте. В таком стиле -

К чему тут эта статья? Я говорю что инструментальная поддержка операторов для явы никакой проблемы не составила бы, ибо не отличается от такой поддержки методов.

В Котлине давным давно завезли. Я лично реализовал векторную арифметику на Котлине.

кода чото слишком много. в groovy лучше + в нем BigDecimal по умолчанию.

То есть использование операторов над объектами - это немного более сложная вещь, чем просто вызов их методов.

сложность проектирования или реализации языка

Но ведь ничто не мешает разрабатывать гуевые приложения на JavaFX? Поддержка современных языковых средств, таких как enum, стильный-модный-молодежный лук, всякие графики. Чего она не взлетает?

Там нельзя писать на HTML, CSS и использовать DOM API. Поэтому Electron, будучи убер херовее джавы по жору ресурсов - взлетает. А упоротое легаси пытается гнуть свою линию, но время даже таких упоротых, подпитываемых оракловскими бюджетами, расставит по местам.

В C++ это давно спроектировали и реализовали. Значит дело не в сложности проектирования или реализации языка.

Многие и на Java 8 еще не перешли.

Надо «через коленку» себя ломать - курить

https://www.ozon.ru/context/detail/id/28001133/

На Groovy надо просто поставить задачу - DSL!

лишь изредка используя какие-то особенности Groovy

И постоянно совершенствовать (такой типа «рефакторинг» в DSL) код.

Но про таинственные «легковесные фреймворки»(С), которые могут посрамить Spring + Hibernate и Jakarta EE, я от нашего кульхацкера-«философа» ответа не получил.

Видать эти супер-пупер хайповые инфраструктуры только для хелловордистов и админов локалхостов - бывших гуру в VBA.

в groovy по умолчнию типизация динамическая, так же есть @CompileStatic. т.е можно выбирать.