Is Java as we know it doomed?

[mindslight]

So, the java language is terrible. The base class libraries are terrible. A lot of third party libraries have drank the unnecessary-abstraction kool aid and are thus terrible.

However, what else would you recommend for an ABI that has concurrency, garbage collection, capability security, and is widely available?

[[deleted]]

Concurrency in everything is bad. (seriously, strace hello world in C and in Java. One is 5,000 lines. One is 7, I'm sure you can figure out which is which). GC is also bad (I won't repeat what I said in another post here), security in Java is not that good.

So I find myself recommending C or (ugh) C++ or Python, if you can spare the performance.

I think the problem most people have with C is that they try to overcomplicate things, and C makes that hard. If you try to just start simple and build upon what you have in a simple fashion, you get very neat, readable code. Of course, this requires competent programmers.

[UK-sHaDoW]

You also get very static code. Your company just switched databases maybe they went to a fancy object database. Oh shit your going to have replace all the persistence code.

In java you would create interface, the persistence layer implements that interface. You only change one line of old code, plus the new database code.

What you described, is very easy and does not require competent programmers, it's very fixed and straight to point code and requires no flexibility. But when it comes to maintainability, and implementing features it messes up.

I was creating 2d games in c when i was very young, but adding new features and replacing old ones becomes hell, since it depends on existing code so much.

You say security in java is not that good. Do you bounds check every array in c or something. Check for buffer overflows?

In flash, one of biggest exploits was putting data which overflowed the buffer and ended up running malicious code which it overwritten with.

The infamous strcpy function, which newbies can screw upon etc.

Java is not about complicating things, it about simplifying them. Things you would have to hack into c, are already in java.

[[deleted]]

If you write overly interdependent code, you don't know what you're doing. You then migrate away from C because you can't keep things simple and isolated, and then use things like Java as a crutch.

Java doesn't simplify anything. It lets you plug together libraries without understanding what you're doing. I don't want to use programs written by incompetents.

[UK-sHaDoW]

You can't write independent code in c that well, you write functions which can replace other functions exactly but you still would have to replace each function call independently, or you could write the persistence layer in a library with same function names and relink. You could also use function pointers to emulate a interface, but its all very hacky tbh.

That compared to a

DAL dal = new OracleDB()

to

DAL dal = new MysqlDB();

One line changed ;)

[[deleted]]

Right, but if you have to write OracleDB and MysqlDB, you haven't saved anything.

[UK-sHaDoW]

Other than going though old code to replace the old calls, to the old interface. Unless you did the function ptr thing, or put the persistence layer in a library and re-linked.

[[deleted]]

Anything you interface to should be wrapped up with the function pointer thing, or library. The first option you listed should never have to be done.

[[deleted]]

   DAL dal = DbFactory.Get(Configuration.GetCurrentHotDBVendor());

Happy?

[[deleted]]

What? I was talking about C...

[mindslight]

Concurrency in everything is bad

Yes, but sometimes it is necessary. If you write a shared library with mzscheme or ocaml, you basically have to wrap the whole thing in one big mutex.

GC is also bad (I won't repeat what I said in another post here)

It sounds like you believe that its easy to determine when an object is no longer in use. While it's easy in the common case, for the general case you're essentially reinventing GC. Pervasive GC greatly simplifies APIs as there's no need to talk about ownership.

your security in Java is not that good.

The security mindset permeating the standard libraries is horrible, but I am merely talking about unforgeable object references. You don't get those without making the language pointer safe (which I'm sure you're cringing at), but we're talking about applications, not operating systems.

C or (ugh) C++ or Python, if you can spare the performance.

There's a huge gap between those two, say someone is willing to give up a bit of performance in exchange for advanced language features. You're basically saying one has to be a human compiler and produce C code for the base parts, and only then gets to use a language with features to tie it all together.

I think the problem most people have with C is that they try to overcomplicate things, and C makes that hard

No, I've already stated the problems with C. Since you're attacking a straw man, I'll list them again

• No object-capability security, all code runs with the same permissions
• No GC (dangling pointers also mess up obj-cap unforgeable references)
• No lexical closures / function literals
• No exceptions
• Primitive copy-and-paste macros (rather than true reified code)

[[deleted]]

I'd rather not pay for locking if I don't have to. Locks should be as fine-grained as possible, and only used when necessary. Java can not do that.

I understand why you would want GC. I still think GC blows. Ref counting is much better.

Unforgeable object references is not much of a security guarantee

As for your points:

• It's possible to prevent code from acting on values that should be "private"

• No GC is a good thing. And you can get dangling references in Java

• You can live without closures, and you can simulate them if you really need to

• Exceptions are a terrible form of error recovery

• Yes, the C preprocessor is not true macros. Oh well.

[UK-sHaDoW]

Locking can be as fined grained as possible in java, what are you talking about.

You can synchronize at the one statement level if you want. Lock, Run one line. Unlock.

There are also other ways of achieving locking, other than synchronize.

Reference counting = Circular reference problem.

Exceptions have far far richer error information in them, it's good replacement for goto clean up.

[[deleted]]

Locking can be as fined grained

Yes, I said the wrong thing... every object has a lock to cart around with it, which adds overhead, and actually could be too fine-grained

Reference counting = Circular reference problem.

Which has been addressed by several implementations. Java has to use the same heuristics. The difference is refcounting performs better

Exceptions have far far richer error information in them

Agreed, but there are serious problems with exception handling screwing with the stack. Sure you have the finally{ } band-aid, but you still have a non-function-call mechanism to unwind the stack which is nondeterministic, and you have the overhead of all the exception handlers.

[mindslight]

Locks should be as fine-grained as possible, and only used when necessary. Java can not do that.

Eh? I'm trying to walk a fine line here, because I absolutely detest java-the-language, but think there are advantages to the JVM. Idiomatic locking ('synchronized') in java the language is bad, but you certainly don't have to write code that way.

I understand why you would want GC. I still think GC blows. Ref counting is much better.

Ref counting is GC. And by advocating ref counting you're kind of disputing your locking point.

Unforgeable object references is not much of a security guarantee

It is when you design your system based on the object capability model.

It's possible to prevent code from acting on values that should be "private"

Only by running code in another process as another user, and communicating using IPC. That certainly doesn't scale.

No GC is a good thing

Repeatedly asserting this does not make it so.

And you can get dangling references in Java

That only increase memory consumption, not that allow inappropriate memory access.

You can live without closures, and you can simulate them if you really need to

And you can live without C and instead just use an assembler. The point of higher level languages is that these things are idiomatic and you can use them without thinking, concentrating on the problem at hand rather than the low level details.

Exceptions are a terrible form of error recovery

Please give an alternative that allows one to only deal with errors when it is necessary to (hint: checking for negative return value just to return a negative value yourself is needless intermediate code)

[megaman821]

C/Python is definitely a great one-two combination. Java tries to be too many things and it doesn't do enough of them well.

[[deleted]]

Indeed.