Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What are some examples of these legacy features?

Overwhelmingly, I see complaints that java has been too simple compared to virtually all other languages. I agree that cognitive load is important. However, it feels really strange to me to suggest that java has reached the complexity of other similar languages. What am I missing?



for example Java went through several generations of IO evolution, so some simple task like reading text file line by line can be done in many different way in current standard library:

- using DataInputStream

- using Scanner

- using Reader

- using Files.readLines

and they all suck.


I see. Is it fair to say that most of the issues area related to jdk included libraries vs language features itself? I also find a lot of the included libraries to be cumbersome, but I see these syntax improvements to be a welcome change in contrast.


> Is it fair to say that most of the issues area related to jdk included libraries vs language features itself?

I think they all connected, for example with added lambdas they also added streams, so collections library now allows to do the same thing using old iterators or new streams APIs, and somehow those APIs are not compatible, it is not easy to produce stream from iterator.


Iterator is a very narrow API that needs to remain compatible with a lot of third party code, but streams rely on spliterators for concurrency. You can sort of get a stream from any collection (or a spliterator from any iterable and make a stream), but it will probably do all work sequentially.


> but streams rely on spliterators for concurrency

which I never seen anyone uses and it makes everything more complicated

they probably should've have some ParallelStream interface


That’s not language, but ecosystem. And I much prefer this to randomly breaking previously working code.


its standard library.

core ecosystem, e.g. apache commons will add several more ways.


IO has so many usecases that frankly, it makes sense. In a way a language with only one way of doing it is missing out on some another use case.


python and c++ both have the same API for 20-30 years I think, and they are both more robust than Java's APIs imo for 95% of cases.


Agree to disagree on that one.

Java’s standard library is one of the best stdlibs out there.


Evidence of opposite in that example:

programmers in 95% cases want something like following to read lines from text file:

for s in open('file.txt'): print(s)

Java has 5 different io APIs and no one provides such construct, you need to stack various verbose abstractions to just read text file.

How it is the best? Ergonomics and brain load is very bad.


I'm mostly write embedded code. But when I have to deal with files and associated API's I'm always like why does anyone tolerate this stuff.

  string[] lines = ReadFile("path", "filename");
Why is the above somehow hard?


actually your code is not well designed too:

- it will produce OOM if file is very large

- iterating array is usually verbose in many of languages (at least in Java)

- not sure why you would want to have path and filename as separate params

In Java, it would be more ergonomical if they add something like following:

Iterable<String> Files.readAllLines(String fileName);


  - it will produce OOM if file is very large
A well designed API won't give you an OOM it'll throw a 'this file is too big'

  - not sure why you would want to have path and filename as separate params
Throws path not found. Throws file not found. Why does the programmer need to deal with twee-fiddly path magic for say each file in a directory of config files?

  Iterable<String> Files.readAllLines(String fileName);
Oh sure that's totally more readable.

  I think in python it will lazely iterate through the file,
I wrote a program to suck in a list of log files and generate a bunch of metrics and display them. Users liked to select a dozen 100MB log files. Lazy iteration was way way too slow. Fastest was suck each one into memory and call split.


> A well designed API won't give you an OOM it'll throw a 'this file is too big'

this is possible solution, still it doesn't allow to iterate lines one by one and handle large files

> Throws path not found. Throws file not found.

I think it is some very niche use cases when you need to distinguish between these cases. From another hand there are many places in the code which operate absolute file paths already, and you force them to split path, which is cumbersome. At least two alternative APIs probably are justified to have.

> Fastest was suck each one into memory and call split.

I really don't think pre-splitting is any kind of performance bottleneck, it is likely 1% of performance compared to all IO stack and subsequent string/objects memory management.


How is OOM not a concern in case of C++, python? Java’s List is much more ergonomic that arrays.

Also, I really don’t understand your last example - that’s literally available in java returning a List of lines. If you add a .stream().collect(joining(“\n”)), you get the whole string in one go.


> How is OOM not a concern in case of C++, python?

I think in python it will lazely iterate through the file, and not load everything at once

> Java’s List is much more ergonomic that arrays.

right, but commenter above proposed array..

> that’s literally available in java returning a List of lines.

current API has two issues:

- OOM if file is large

- it takes Path instance which you need to construct and not "String file" parameter, thus hit on ergonomics


Path.of(yourString)


I know, but why it is necessary?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: