4 ms·

Java reversed that route around Java 5 when they added a crapton of language features (generics, annotations, autoboxing, enumerations, varargs, foreach) that c

• unscaled 7y ago
  I keep hearing this myth about how Java pre-5 used to be a pristine language, until it was touched by annotations and generics - and I doubt it, because I was there. Before annotations, Java libraries were basically using gigantic XML files to configure things like dependency injection and routing. I don't like the way Java libraries use exceptions at all, but you can't seriously say you want to get to the early J2EE days. Look at the mess that was required to create an Employee entity: https://docs.oracle.com/cd/A97688_16/generic.903/a97677/ejb11cmp.htm https://docs.oracle.com/cd/A97688_16/generic.903/a97677/ejb1... Before generics, foreach and autoboxing Java was code was littered with ugly code like this: List incrementIntList(List input) { List result = new ArrayList(); for (int i = 0; i < input.size(); i++) { Object obj = input.get(i); if (obj instance of Integer) { Integer int = (Integer)obj; int i = int.intValue() + 1; obj = new Integer(i); } result.add(obj); } return result; } While in Java 5 you could finally write: List<Integer> incrementIntList(List<Integer> input) { List result = new ArrayList<Integer>(); for (Integer i : input) { result.add(i + 1); } return result; } with Java 8, we even got arguably better: List<Integer> incrementIntList(List<Integer> input) { return list.stream().map(i -> i + 1); } I fail to see how the first version is more readable. Yes, the Java compiler had to become more complex to accommodate this, but every other Java codebase in existence became considerably simpler. I can't see how this is not a win. The forces pushing for the same kind of ergonomic improvements in Go are not outside forces, but very much the Go designers themselves. This draft your written by Ian Lance Taylor and Robert Griesemer and it looks like a complete overhaul of the contract mechanism proposed by Russ Cox. These people are part of the Go core team.
  • Crinus 7y ago
    I wasn't referring to libraries, i was specifically referring to the language itself and the language was simpler. Also i never worked with J2EE, in fact i worked with the complete opposite: J2ME. While it had a lot of pains, these were largely with the implementations not the language nor the APIs both of which were very simple. Though even before J2ME i mainly dabbled with applets which again were mostly simple (that was Java 1.1 btw thanks to MS Java). Also i've written a lot of Java at the past and most of it was during the pre-1.5 days and i do not remember ever writing anything like the example you used as an ugly one, that looks contrived. For starts, i think i've only stored multiple object types in an array list very few times, most of the time it only stored a single type so i didn't need to check for the instance. Furthermore these array lists were most often hidden behind a higher level API, so you'd get "addFoo(Foo foo)" and "removeFoo(Foo foo)" that would add the object to the list (and often do additional bookkeeping, like set some flag or call a method in foo). And of course i do not remember ever needing something like incrementing an integer list. Sure you can make a mess of a codebase, but doesn't mean you have to. Just because someone (apparently a lot) believe that a SomethingFactoryFactory is a good way to approach things it doesn't mean that you have to follow it. Often a plain old "new" is just enough. Also when i refer to outside forces i do not refer to whoever writes those drafts, i refer to those who ask for features that cause the drafts to be written.