Java 1.0 Turns 25

As an honest estimate, I'd give about 2-4 more years. But it's definitely further along than I thought it would be.

See: https://cr.openjdk.java.net/~briangoetz/valhalla/sov/

The key difference is that fields and methods maintain all their names in the bytecode; in C, non-public symbols are usually stripped leaving only the calls to libraries present.

EDIT: Oh, just realized... it's probably a misunderstanding on my part. "Java 8 to (Java 9 and beyond)" is the intended reading, probably. My bad.

----------- DO NOT READ BEYOND THIS POINT ----------

Maybe it's just a phrasing issue, but...

The Java 8 -> Java 9 (or 11, in practice) transition was special in a few ways (modules, mainly), but I don't see why any future transition should be quite as disruptive? Do you have anything concrete in mind, because if you do, I'd like to know about it!

We got pretty draconian and went for a "class changes can be "additive" only, so that the capabilities could be forward compatible with new classes.

Sadly, politics got in the way of shipping it so I ended up with only a couple of patents and a later Javaworld column out of it and most of work never saw the light of day.

[1] For example you might have a File class with a write() method that you wanted to be part of a write capability, but there might also be a update_metadata() method that effectively wrote something to the file so you needed that to be part of the capability, and that method might be looking at static member data of meta data flags, which were also part of the read() capability.

Edit you're right, C# and J# coexisted. I think its still the theme of MS using their own JVM then moving it to dotnet.

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

C++ also does not rely on type erasure.

Immutables has its own set of problems, but at least it uses the standard Annotation processor and has a clear separation of generated code and the interface you write.

Haven't used Java's new record's yet, so don't really know anything about that.

Kotlin does have some nice additions. But it is very much a kitchen sink language. I wish I could take some of those nicer additions and leave the sink.

Which makes a lot of sense, if you look at it through the lens of cultural anthropology. Enterprises dictate approaches like this, because the alternative is leaving the choice to the individual programmer — and these same enterprises don’t hire experienced-enough programmers to trust their judgement. And so all the programmers who work for these enterprises end up absorbing this approach as a social norm, just “something you do”, rather than “independently rediscovering the need for it” in a way that would lead to them actually knowing when it’s useful. So, even when not locked into an enterprise that forces it on them, they just keep doing it, because that’s the culture that’s been inculcated on them (and how all the examples look, how all the libraries do it, etc.)

Personally, I’m not in theory against “unilateral” use of getters/setters, either. I just kind of which they worked in Java the way they work in Ruby: where referencing a field on any object other than `this` would actually just be sugar for a call to the getter/setter. Where the Java optimizer would then take special care to optimize-away the call frame for known-‘trivial’ getters/setters.

If you ever need to change something about that value, do additional logic before returning (I e. emit metrics), or model a data class with an interface having getter methods makes these so much easier.

But for some dumbass reason it's not "the Java way".

One factor I’ve thought about is how many Java programmers seem to have learned design by looking at things like the Java core libraries or a few open source frameworks, without recognizing that most people are not writing code intended to be generally reusable by millions of projects and that popularity means those projects cannot modernize their style easily, either. People write new code on new projects today as if it still needs to be compatible with the early 2000s because much of the code they learned from ossified around that time, and will claim it’s “best practice” because otherwise why would this Oracle/Apache API still use it?

    p.x = p.getY() + p.z;
    p.setY(p.x + p.z);

Another thing why getters/setters are preferable is because when you need to replace field with computed value, you would need to replace all your code.

Proper approach would be to use properties which are available for every language but Java. They invented records, which somewhat fill that niche.

But nobody actually does it.

If you use getters and setters, you have more future options without breaking backward compatibility. When you are making libraries that lots of other projects might depend on, this is probably more important than when making apps, especially relatively small apps.

“Getter/setter from the start” optimizes for induced maintenance cost on dependent code.

Now, in some other languages, access via getters/setters is at least source-compatible with field access, which makes this less of (or not at all, for dynamic languages, or if it is object and not just source compatibility) an issue. But that's not the case with Java.

    public record SomeViewModel(String name, int age) { }

Legacy code is everywhere on the world, only a selected few get to work on shiny things from scratch. Even cool startups eventually turn into legacy.

I wonder what technology used at enterprise level, doesn't suffer from those bullet points.

Its pretty horrible, but by no mean java-specific. It can be achieved in any object-oriented language, and to some extent also in others.

How much time (and money) do they invest? Do you have numbers comparable to java? :)

I hope their generics turn out nice because there are lots of interesting decisions to make in their design.

Let's hope it doesn't end the same way as error did

True. Also, Odersky and Wadler's Pizza language [1] was available as early as 1996 and the language designers at Sun were well aware of it and keen on adding it to Java. Odersky mentions this here[2]:

  Bill Venners: How did Scala come about? What is its history?

  Martin Odersky: Towards the end of my stay in Zurich, around 1988/89, 
  I became very fond of functional programming. So I stayed in research 
  and eventually became a university professor in Karlsruhe, Germany. 
  I initially worked on the more theoretical side of programming, on 
  things like call-by-need lambda calculus. That work was done together 
  with Phil Wadler, who at the time was at the University of Glasgow. 
  One day, Phil told me that a wired-in assistant in his group had heard 
  that there was a new language coming out, still in alpha stage, called 
  Java. This assistant told Phil: "Look at this Java thing. It's portable. 
  It has bytecode. It runs on the web. It has garbage collection. This 
  thing is going to bury you. What are you going to do about it?" Phil 
  said, well, maybe he's got a point there.

  The answer was that Phil Wadler and I decided take some of the ideas from 
  functional programming and move them into the Java space. That effort became 
  a language called Pizza, which had three features from functional programming: 
  generics, higher-order functions, and pattern matching. Pizza's initial 
  distribution was in 1996, a year after Java came out. It was moderately 
  successful in that it showed that one could implement functional language 
  features on the JVM platform.

  Then we got in contact with Gilad Bracha and David Stoutamire from the Sun 
  core developer team. They said, "We're really interested in the generics stuff 
  you've been doing; let's do a new project that does just that." And that became 
  GJ (Generic Java). So we developed GJ in 1997/98, and six years later it became 
  the generics in Java 5, with some additions that we didn't do at the time. In 
  particular, the wildcards in Java generics were developed later independently 
  by Gilad Bracha and people at Aarhus university.

  Although our generics extensions were put on hold for six years, Sun developed a 
  much keener interest in the compiler I had written for GJ. It proved to be more 
  stable and maintainable than their first Java compiler. So they decided to make 
  the GJ compiler the standard javac compiler from their 1.3 release on, which came 
  out in 2000. 

[2]: https://www.artima.com/scalazine/articles/origins_of_scala.h...

Not sure what's that about, JBuilder was great, so was Eclipse. I know people love IDEA but feature wise I consider it subpar to Eclipse even today.

IntelliJ was first released in 2001. Those days it was a closed-source paid product. It competed with JBuilder, Visual Age (which became Eclipse), Forte (which became Netbeans) etc.

map : (A -> B) -> [A] -> [B]

It's quite clear from the above type signature what this function does and does not do. It can only use the supplied A's to create B's using the supplied function. It cannot do anything else with the A's and the B's. To me, that is clarity.

Compared to Java 9, which was a big regression from Java 8 in terms of startup time. And Java 8 in turn was slower to start than Java 6.

What good is this when roughly half of the java programs I had to ever use required the official sun / oracle jvm to work

Amazon, SAP, Alibaba, IBM and Microsoft are more than comfortable with it.

No. (Or how come I can do `apt install openjdk-17-jdk` on my Debian machine then?)

> Oracle has changed the license for >11 that also gives me pause

Yes, except that it's only for the Oracle JDK, not for OpenJDK.

Memory: As far as I see, there is a built-in profiler within the app showing the memory usage. It has a high limit to 1gb and I see it rise quickly to about third of the way and repeated (quickly, about every 2 seconds) garbage collect down to 200mb. So it appears memory consumed very fast and than it garbage collects. Then repeats.

https://www.infoq.com/interviews/Milinkovich-past-present-fu...