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

Friend of mine says the great thing about Java is when things go sideways you can just quit and get another gig.


Java's secret sauce was that it liberated a whole generation of Microsoft sharecroppers. Microsoft has since clawed some back via its C# marketing, but cannot dictate a new "framework" every second year as it once did.


Java's actual secret sauce was that it was mostly like C/C++, but with no unsafe memory accesses. It was essentially the Rust of the late 1990s, only a whole lot slower and clunkier than real Rust. There was a lot of enterprise software being rewritten from C++ to Java as a result.


Nobody at the time gave a hoot about "unsafe memory accesses". That is a wholly recent conceit. Nobody then cared about security. Sendmail was how e-mail was delivered, and was, believe it, widely admired.

Java was just enough like the C++ of 1990 to compete, but with garbage collection and a big library, and without confusing pointers, so lower-skilled programmers could use it. That is all. Computers were literally thousands of times slower than today. Java was considered just barely fast enough.

But without freeing programmers from the Microsoft frameworks treadmill, it would have sunk without a trace.


> Nobody at the time gave a hoot about "unsafe memory accesses".

No, that was much of the point. Memory leaks, pointer overruns, use after free bugs were a huge time sink. In addition to portability, industry wanted a language without these problems.


I think it’s mostly semantics here. Companies didn’t care about it for security. They cared about it for productivity.

Enterprise development is always about delivering features first. Performance, security, reliability, etc. come after that.


So here's an interesting story of how I became a C programmer. Around 1990-1991, I was deeply into TinyMUD and similar games. An acquaintance had forked TinyMUCK and developed it into a programmable system using a derivative of Forth. Here's the catch: up until this point, development had been done on 4.2BSD VAX, and dereferencing NULL pointers was no big deal there.

I was tasked with porting to SunOS 4, where if you deref NULL you crash with SEGV. Therefore I had to get real good at GDB real fast and chase every instance of NULL usage, where I'd put in an initial check first. I did my job alright and before long, our server code was running smoothly cross-platform, and I'm fairly sure that my patches had far-reaching effects beyond the SunOS platform I'd developed on.

My colleagues and I were at the forefront of a wave of new Internet users in the early-to-mid 90s, and the embedded programming language environment of a simple text "adventure game" was conducive to many people learning how to program in a simple and forgiving environment. Those of us who hacked clients and servers were a somewhat elite vanguard; I decided to specialize in systems administration and had an interesting career soon afterwards.

And it all started because some VAX programmer had thought it was no big deal to dereference NULL pointers in a pervasive way throughout the ANSI C codebase of a game server.


What happened on VAX when you inadvertently overwrote the contents of memory location 0 ? Was it guaranteed not to be anything important there?


It was a read-only page of zeroes.


Classic old school problem would be your bug overwrites a pointer with garbage. And then whatever that points to, like OS code or data, gets trashed next. Your computer starts acting 'weird'. Worse changing random unrelated things would make the problem go away.

Huge time sink.


As I said, it was needed for low-skilled coders.


Yes because there exist high-skill programmers who never wrote a bug in C.


according to James gosling (the creator of Java) in a interview from a year or two ago with lex Friedman he said he wanted a C++-like language but without its pitfalls: pointers bugs and bad concurremcy/synchronization primitives. This was to bring enterprise programmers (who mainly used c++ at that point) to the JVM ecosystem. He expected an explosion of jvm languages after that which, sadly, didn't happen. I think there were more pitfalls which I don't remember now.

Maybe he is saying bull now to look more cool, but he sounded rather convincing in the interview. I'd recommend to listen to it


That may be why it was designed, but GP was talking about why it was adopted. Those are such totally different things that it's not worth comparing them. Lisp?


Gosling's chief skill always was to sound convincing. (Lord knows language design wasn't it.) The contempt he had for Java coders is hard to miss in writings from the time.


That sounds suspiciously like Rob Pike and Go coders.


Rob is a careful student of history.


> The contempt he had for Java coders is hard to miss in writings from the time.

Can you send some examples? Curios to read those.


Yeah no one ever saw a Java NullPointerException before hey?

No memory leaks and portability were the main benefits we were sold on at the time


> Yeah no one ever saw a Java NullPointerException before hey?

At least you get an error message. Silently continuing when things go wrong is worse.


And web page Applets being perfectly secure, iirc - due to the JVM sandbox.


> Nobody at the time gave a hoot about "unsafe memory accesses"

Right. We had Purify for that.


That came later. Then valgrind ate its lunch. Some people still use that! Sanitizers, now.


For me it was no more malloc and free for every stupid little thing inside every function I had to write (string processing, arrays, etc.) But I was already using Perl for web development (no malloc no free) and I wasn't overly interested in Java. I made some money out of it later on, probably none past 2012. Then always languages with garbage collection, possibly interpreted. I don't like to have to compile and build to deploy.


I think Java's real secret sauce was the library. It had everything - much more than the standard C/C++ library.

> ... but with no unsafe memory accesses.

Mostly true. But you could still get a null pointer exception in Java - which is especially weird because Java doesn't have pointers.


In essence all you have for objects in Java is pointers.

For the primitive types, like long, you can't get a null pointer exception, because there really is no pointer, but for any object type it's actually a pointer, the object itself lives on the heap and you're given a pointer to it, if the object is null, that's a null pointer. They don't feel much like pointers from a language like C because you're not provided with pointer arithmetic - you can't try to add my_object + 16 as you could in C - and because Java was a modern language which knows what you mean when you write foo.bar, unlike C and C++ which expect you to remember whether foo is a pointer and write foo->bar so that the poor compiler needn't figure it out.

For modern Java the compiler does escape analysis and may conclude an object cannot "escape" in which case it may be created as part of the stack frame of the code which uses it instead of on the heap, but it's still basically a pointer.

This is all rather awkward, for example Java's 64-bit double precision floating point number is a primitive, always 8 bytes on your stack no need for a pointer to anything - but if you want your custom four 16-bit integers type (maybe representing RGBA) that's an Object so it is treated differently even though it's also just 8 bytes. C gets this part right, your custom types (struct, and to a lesser extent enum and union) aren't treated so much worse than the language built-in types.

Anyway, it's Memory Safe because the null pointer exception is essentially the same behaviour as if you try to unwrap() a None in Rust, the JVM isn't going to let you just "press on" as you might in C, you've got a programming error and must either recover from that or your program aborts.


longtime C/C++ guy who became a longtime Java guy:

the most time I've ever spent dealing with invalid addresses and memory leaks, in production /enterprise code, has been in Java, not C or C++

my personal theory is because despite how much safer Java was by design, culturally, beginning in the early 2000s, it also opened the floodgates to a big wave of lower caliber programmers "just doing it for steady jobs" and so a "99% right? ship it! someone will file a ticket next week if needed" mentality was more common

not the fault or credit of the langs, just the type of people they attracted, at large scale

Java: "I'm super friendly! Just click here!"

C: "Here's a razor blade. Here's a razor blade. Another. Another. Now assemble to build a maze. Also the maze is invisible. Oh and our manual is 50 pages."

(I appreciate both in diff ways.)


The initial Java release didn’t even have a regex library. As a Perl programmer I found that incomprehensible.


Most other programmers probably find your code incomprehensible, if it was Perl :^)

But seriously, is there any modern language other than Perl where regular expressions feel so… natural? I reach out for Perl less and less, but always sigh when I need to handle any regex in Python.


Closest thing would probably be JS, which has regex literals (and you can just call methods on them, or pass them in places).

Example: /.*a.*/.test("this is a string") // returns true


Ruby?


or a function sort(), but it was clear by 1997 that there was a lot of money thrown around for everyone knowing how to write a backend in Java.


The library was utterly necessary, purely because the people the language was meant for would have been completely at sea without.

The contempt Java's designers held for its users fairly drips, in what they write about it.




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

Search: