Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Paving the on-ramp to Java

openjdk.org

Post reply on HN
Print view View original

111–120 of 156 posts

Re: Paving the on-ramp to Java

#111

Post by shagie »

hibikir wrote: post #106
Sankozi wrote: post #95

Earlier quoted context omitted.

They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.

I suspect that the issue that the GP is discussing is not that they are hard to unit test, but that they are hard to mock: If you don't want to call the static method, either some relatively unfortunate thing has to be done to your mocking classes, or you have to inject it, which is uncommon in this kind of situation in your typical Spring application. Now, what I'd say to that kind of argument is that a good static…

If they're not modifying or accessing some state, then the occasions that one would need to mock them is drastically cut down.

Re: Paving the on-ramp to Java

#112

Post by patrickthebold »

hibikir wrote: post #106
Sankozi wrote: post #95

Earlier quoted context omitted.

They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.

I suspect that the issue that the GP is discussing is not that they are hard to unit test, but that they are hard to mock: If you don't want to call the static method, either some relatively unfortunate thing has to be done to your mocking classes, or you have to inject it, which is uncommon in this kind of situation in your typical Spring application. Now, what I'd say to that kind of argument is that a good static…

The thing I have been bitten by is when requirements change, and a static method used in 100 places no longer should be static.

Re: Paving the on-ramp to Java

#113

Post by Sankozi »

hibikir wrote: post #106
Sankozi wrote: post #95

Earlier quoted context omitted.

They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.

I suspect that the issue that the GP is discussing is not that they are hard to unit test, but that they are hard to mock: If you don't want to call the static method, either some relatively unfortunate thing has to be done to your mocking classes, or you have to inject it, which is uncommon in this kind of situation in your typical Spring application. Now, what I'd say to that kind of argument is that a good static…

If static method behaves like a function I see very little reason for mocking. Do people mock also calls to complex constructors (which are too static methods)?

I think some people put unit testing to the extreme by not wanting to test logic outside of the unit tested (which is not possible to do fully). They write additional code for mocks so their tests could be less useful but more "pure".

Re: Paving the on-ramp to Java

#114

Post by cies »

pron wrote: post #59
cies wrote: post #21

Kotlin's syntax is cleaner in some most places, more explicit in some places (no implicit nulls, and wrt generics) and much terser when using naked functions etc. Did Java's papa get jealous?

I always find it funny when people bring up Kotlin in the context of Java's evolution. It's not one of Java's main competitors, and while Java has borrowed many features from other languages [1], to date it has not adopted a single feature from Kotlin [2]. In fact, almost at every turn -- from data classes, through async/await, to string interpolation (JEP 430) -- Java has opted for a different approach. Is Kotlin th…

> Is Kotlin the only other language they know?

On the JVM: I'd say yes.

Scala, Groovy, Jython, JRuby, and what not came and went.

I'd say Clojure is the third, and it take a nice place in the design space.

But Kotlin to me is so close to Java that it is basically Java 2.0: the Java that Java cannot be due to intended organizational slowness.

> Python is one of Java's main competitors, and when it comes to teaching a first language it is the main competitor.

Yes it probably is. The changes outlines in the article are not going to help here I'm afraid.

But I'm weird. I'd say the best lang without static typing for noobs is a LISP (so that every student is likely equally confused). When learning a language with types go for Rust or Idris. All not exactly competitors of Java :)

Re: Paving the on-ramp to Java

#115

Post by UncleMeat »

qsort wrote: post #15
Sakos wrote: post #11

Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…

I agree. Ironically, Java the language doesn't have any more boilerplate than, say, C++ or Go, which people are apparently okay with? It does however have some stuff that's plain dumb (can't have functions outside classes, public static void main(String[]), ...) some of it isn't even fixable (default visibility should be private, final should be like const in C++, or even better like const in D). This is a change tha…

C++ boilerplate is criticized all the time. Just being able to pass a range rather than begin and end iterators was such a huge improvement in wordiness and is a widely loved change, for example.

Re: Paving the on-ramp to Java

#116

Post by ptx »

Sounds like great improvements. I would wish for the ramp to be extended a little bit to also do something about packages, for example allowing a common prefix like "com.company.project.whatever" to be elided, so that we don't have to go from "src/Hello.java" straight to navigating the maze of "src/main/java/com/company/project/whatever/hello/Hello.java".

Re: Paving the on-ramp to Java

#117

Post by 0x445442 »

hibikir wrote: post #106
Sankozi wrote: post #95

Earlier quoted context omitted.

They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.

I suspect that the issue that the GP is discussing is not that they are hard to unit test, but that they are hard to mock: If you don't want to call the static method, either some relatively unfortunate thing has to be done to your mocking classes, or you have to inject it, which is uncommon in this kind of situation in your typical Spring application. Now, what I'd say to that kind of argument is that a good static…

But Java has a solution for the “good static methods” you’ve described in the Function interface. I’d submit that a FooLib class with these static methods could be replaced with a foo.lib package with the corresponding Function implementations. This allows great flexibility with unit testing because you don’t even need a mocking framework. Instead, you just provide a dummy implementation of the Function the unit under test depends on.

In fact, dependence on mocking frameworks is a huge code smell because it covers over the common practice of not coding to an interface. If you want to expose poor design in a code base, remove the mocking decencies and see how hard it is to rewrite the tests.

Re: Paving the on-ramp to Java

#118

Post by pjmlp »

pron wrote: post #52
pjmlp wrote: post #42

Earlier quoted context omitted.

I beg to differ, as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway. And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated. Like it happens with all guest languages that target the JVM pretending to be Jav…

> as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway. The problem isn't the set of things students will need to learn, but the order in which they encounter them. Students write a one-file program before they write a two-file one, but because Java is optimised for large programs, today they encounter things like accessibility rules -- which exis…

Lets see how much better it gets over C# 10 then.

Re: Paving the on-ramp to Java

#119

Post by lmz »

pron wrote: post #52
pjmlp wrote: post #42

Earlier quoted context omitted.

I beg to differ, as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway. And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated. Like it happens with all guest languages that target the JVM pretending to be Jav…

> as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway. The problem isn't the set of things students will need to learn, but the order in which they encounter them. Students write a one-file program before they write a two-file one, but because Java is optimised for large programs, today they encounter things like accessibility rules -- which exis…

If we're talking beginners / students here couldn't this all be hidden by a specialized IDE? Why the need to put it into "real Java"?

Re: Paving the on-ramp to Java

#120

Post by 0x445442 »

i386 wrote: post #43
sz4kerto wrote: post #39

Earlier quoted context omitted.

You can't really mock static methods though, so it makes testing harder.

Static methods should be treated like functions. Same input same output. Keep them small. If you find yourself needing to mock them they are doing too much.

But even here you’re testing the same code twice. One directly with the tests for the class the static methods live in and once accidentally when you test the class that includes the util class as a dependency. This situation can be fixed by replacing the static methods with Functions.
Post reply on HN