There’s a school of thought that says tests are papering over the cracks in design specification.
I’m one of those people who actually rather likes design-by-contract but I don’t reckon will see anything like that any time soon.
Cas 
Although certainly kind of possible, it is veeeery hard to test every possible existing case. Anyone who used parameterized tests, worked with test ranges etc knows that the code in test is the foundation where the testability has to be enabled first. Good code is testable and one should have a good reason to do it otherwise.
But if we’re talking about statically typed languages, it would be inappropriate to for example return Object everywhere, because it would make the type system useless and hence a burden. If we transfer it to the example of above, the called code should return an interface. Of course, this could be specified beforehand somehow. And static typing is the tool to have the contract in the code, no need to specify it otherwise.
Yes it is)
Same as separate Code for modules – and use only interfaces from it,
Its remove direct dependence and isolate code in it.
Its hard - and the larger the project, the harder it is to test it and separate code on modules.
up:
I also can’t write TDD(Test-Driven Development) (write Test before code)
But I can write Raw working code
then make conceptual Tests(Test on what I want it to be, and not for “current Raw code passes”)
– and transform that code in to final code that pass all Tests
(Test also grows during code updates)
How about ?
if (a matches SubClassOfMyClass s) {
s.useSubClassMethod();
}
If you read the pattern-matching link I posted earlier, that’s what’s on the cards, hopefully for Java (10 / 18.03) in March.
That’d be a massive boon for Java. And when you think about it, it’s like a best-of-both-worlds approach to my particular bugbear with casting assignments.
Cas
Yes, my first post of the link was in response to your bugbear! 
Also planned to be supported in switch - eg.
String formatted;
switch (obj) {
case Integer i: formatted = String.format("int %d", i); break;
case Byte b: formatted = String.format("byte %d", b); break;
case Long l: formatted = String.format("long %d", l); break;
case Double d: formatted = String.format("double %f", d); break;
case String s: formatted = String.format("String %s", s); break
default: formatted = obj.toString();
}
That examples a bit odd, but I like one of the aims (as I said before) to get rid of the damn visitor pattern.
The visitor pattern does indeed suck, and switching on class would be very nice (I already enjoy switching on Strings now - how long did we wait for that…)
Cas
Kotlin has those casts already and Something called sealed class, representing a fixed hierarchy. In whens over sealed classes, No else part is needed.
But i thought visitor pattern should replace large if-blocks. Seems if we got back to our roots^^any performance guy here?^^
That’s the plan on the Java side too. The best thing about Kotlin is that in a year you won’t have to move to Kotlin! ;D
I forgot I wanted to post something regarding generics, because this is a very pleasing topic in Kotlin In fact they adopted C#'s system with in and out. I can understand that years of Java style producerextendsconsumersuperstuff (https://stackoverflow.com/questions/2723397/what-is-pecs-producer-extends-consumer-super) kind of ruins peoples comprehension for in and out (did mine too). It’s not that Java’s generics are something “bad” at all, I am glad that generics do exist at all. But in and out kind of “fix” a big problem with Java’s generics, and thats called use-site variance and invariant generics. I don’t know why you think the keywords don’t mean anything, because they really mean exactly what they spell:
out means a type is only produced (it is given out)
in means a type can be put in
One can best see the advantage with a distinction of mutable and immutable collections that Java doesn’t support with interfaces, but with exceptions at runtime. I will start with a Java example that’s not fun:
Container<SubClass> containerOfSubClass = new Container<>(new SubClass());
Container<SuperClass> containerOfSuperClass = containerOfSubClass; // Won't compile
This won’t compile because in Java Container is not a subtype of Container. The question is why? Because otherwise, we couldn’t guarantee runtime safety, as we weould have the same problems as with Java’s arrays. We could add a SubClass2 instance to the container that actually is a Container. Fail. What doesn’t work either is something like this:
static void doSomething(JavaContainer<SuperClass> input) { // do something }
...
doSomething(containerOfSubClass); // won't compile
The library writer of doSomething could write
static void doSomething(JavaContainer<? extends SuperClass> input) { }
and the user could then use wildcards on the use-site and write
Container<? extends SuperClass> containerOfSuperClass = containerOfSubClass;
You can now get SuperClass instanctes out of the container. However, there’s still the problem that you can not add for example a new SubClass() because of the very same problem as with Java’s arrays. So it’s prohibited and this won’t compile.
JavaContainer<? extends SuperClass> containerOfSuperClass = containerOfSubClass;
SuperClass bla = containerOfSuperClass.get(0);
containerOfSuperClass.add(new SubClass()); // won't compile
On the other side, the same works with “super” instead of “extends” in the wildcard type. Then, you can get items out of the container, but you cannot add them. This literally stinks like the distinction between consumer and producer.
Kotlin std has interfaces for mutable and immutable collections. If a collection couldn’t add objects, it is a producer. Otherwise it’s a consumer. Or both (will explain later). This makes the following possible for a producing container out of the box:
class Container<out T>
val containerOfSuperClass : Container<SuperClass> = containerOfSubClass
No need for the user to do anything. Same for consuming containers (in).
However, the tricky part is mutable containers like a simple array, that can both consume and produce things. In Java it’s complicated for the user to write… for example a method that adds a list of subclasses to a list of superclasses. I don’t have enough patience to do it in Java (just try it, to see why it sucks), so no example. But, Kotlin has type projections. And the solution looks as simple as
public interface List<out E> : Collection<E> // defined in std
fun copy(from: List<SubClass>, to: MutableList<in SuperClass>) {
to.addAll(from)
}
val source : MutableList<SubClass> = ArrayList()
val target : MutableList<SuperClass> = ArrayList()
copy(source, target)
See how wo use mutable lists with type projections to solve the problems. In Kotlin, Arrays do exactly this, hence they don’t suffer Java’s problems in this regard. One good thing is, that the user of your library doesn’t have to bother wildcards, ? captures, subtypes bla blubb. Makes sense?
I’m sure there are good examples of this feature, but unless I’m missing something that doesn’t seem like one?
List<SubClass> subClasses = new ArrayList<>();
List<SuperClass> superClasses = new ArrayList<>();
superClassses.addAll(subClasses);
Can you try this with List<? super SubClass> and List<? extends SuperClass> ?
Why? Like, seriously, provide an example of why you’d be doing that? I do get the thoughts behind this feature, but your screed up there is either things I can’t understand any reason for doing, or are an example that I just showed works fine in Java thanks very much. ;D
I always just end up using every combination of super, extends and ? till it compiles 
More seriously, most of the issues with generics boil down to type erasure or not being able to use primitive types, rather than the slightly unintuitive way their class hierarchies work, and they’re moving towards fixing erasure and primitives in Java anyway.
Cas
Late to the discussion here - sorry!
I’ve been seriously considering moving to Kotlin recently, or, at least, evaluating it. In fact, I’ve been thinking of moving away from Java to another JVM language for a while and, to be honest, the main reason is Oracle - along with a little bit of boredom. I actually still really love Java, although I really should learn another language after coding for so long (C# doesn’t count since it’s basically a broken version of Java imho!). Many of the things about Java that others don’t like such as verbosity, jar dependency "hell and checked exceptions don’t bother even a little bit - I actually like checked exceptions as a feature, although I’ve long resigned myself to the fact that no-one else seems to and they won’t be a feature in any other new langauges. Anyway, as I say, I’d like my future to be less controlled by Oracle, plus boredom and pragmatism make me feel like I should learn something else.
I was interested in looking at Clojure because everyone I know who uses it raves about it and I’ve heard repeated comments about how beautiful Lisp is. Having recently looked into it a little bit more, though, it looks like Clojure simply doesn’t have the same level of support (community or otherwise) or the same number of online examples. Not a deal breaker, but a significant negative.
So Kotlin looks like a good possibility. I’ve been reading around, although I figure the only way to really evaluate it is to give it a go.
The good bit of news about java is that oracle is handing a lot of it over to the community, j2ee will be moving to the eclipse foundation, java (from what i understand) will be more managed by the openjdk project and the netbeans ide is moving to Apache (alpha release of the open sourced version should be released soon).
Sounds like Google is promoting kotlin (as well at jetbrains who are the maintainers of the language) so i can see the language improving in positive ways. From a distribution perspective it won’t matter whether you use java or kotlin. I also believe someone is writing some bindings for lwjgl to work with kotlin rather than java (I could be wrong here as I haven’t been tracking things much here).
I’m hoping with java being managed by the openjdk community some good things will happen to the language. But kotlin does sound fun to get in to as an experiment.
To be clear, NetBeans was pretty much always open source. And just because it’s moving to Apache, don’t assume Oracle are less invested - I’ve heard there are more people working on NetBeans related work since the move than before.
Likewise, “handing” a lot of Java over to the community suggests they’re disinvesting, and I’m not sure that’s the case. I’ve heard this multiple times now (paraphrased) “Oracle is not Sun. Oracle wouldn’t have open-sourced Java. But as it is open-sourced, we’re going to make the most of that”.
And there are some massively good things happening to the language … ;D
I find that extremely easy to believe and it’s part of the reason I don’t like them.
Actually, over 55% of LWJGL is already written in Kotlin. I was surprised to find that out (I found it by chance when looking for Open Source Kotlin projects a while back).
I personally have loved developing in Kotlin over the past year or so. It’s been really fun, it’s really made me aware of NPEs in my other code, and it’s made numerous tasks easier with some of the functions in the standard library. The ability to easily add extension/global functions is immensely helpful. The way that functions are treated as objects is so useful. The way that it forces certain “best practices” did annoy me at first, but I’ve found that it has helped me program with less “duh” errors (not none, but certainly less). I also like how it removes a lot of boilerplate code and how handles things like data classes for me.
One of the other things I enjoy about it is how it is being made to compile to JVM, JS, and Native, meaning that for my projects that already exist cross-platform, I can reduce some of the basic functions.
Obviously, everyone has their own preferences, some people prefer PHP for Pete’s sake.
I can dislike leisure-suit Larry and his yachts as much as the next person, but I’d rather have their blatant commercialism than Sun’s token lip-service to open-source. At least when Oracle does open-source it does it properly, even if it is in its own self interest (like the massive contribution to the Linux kernel, rather than Sun’s licensing everything GPL incompatible so Linux can’t “steal” it). Java (and the JVM) feels in a far healthier position now than under the last few years of Sun.
And don’t think that JetBrains’ development of Kotlin is some sort of altruism - it’s the same blatant commercialism to strengthen sales.