User: Password:
|
|
Subscribe / Log in / New account

No thanks.

No thanks.

Posted Oct 26, 2012 16:48 UTC (Fri) by cmccabe (guest, #60281)
In reply to: No thanks. by Cyberax
Parent article: Haley: We're doing an ARM64 OpenJDK port!

I know I shouldn't reply to an obvious troll post, but I can't help myself.

Go has excellent reflection. See the reflect package for details. This makes sense because one of the criticisms the Go authors had of C++ was the lack of good reflection support.

Its dynamic code loading support is not poor, but nonexistent. Go doesn't support loading modules at runtime. In general, loading modules into a giant monolithic program is often a poor design. It's bad for robustness and often bad for security too. It's usually better to structure your design in terms of communicating processes. Go makes that easy by supporting Go globs, protocol buffers, JSON, etc. etc.

I use Java every day at work. One of the big hassles is setting up your CLASSPATH and making sure you have all the jars you need, but not the ones you don't. It's not just possible but common for different versions of the same jar to fight with one another when you have multiple projects dumping jars into the dumping ground-- er, sorry, runtime classpath. It's funny that Java, often held up as the pinnacle of static-ness, has one of the most dynamic loading systems out there.

This extremely dynamic loading system was also implicated in some of the recent Java security vulnerabilities. Basically some pretty cool guy, eh, managed to get access to something very much like eval().


(Log in to post comments)

No thanks.

Posted Oct 26, 2012 19:59 UTC (Fri) by danieldk (subscriber, #27876) [Link]

> It's bad for robustness and often bad for security too.

It's ironic to speak of security, when you do static linking *all the time*.

No thanks.

Posted Oct 27, 2012 21:11 UTC (Sat) by cmccabe (guest, #60281) [Link]

Java's extremely dynamic binding did not save it from problems resulting from stale versions.

It's normal for enterprise environments to be a few versions of Java behind. Some of the build tools, like Maven, encourage this anti-pattern by allowing people to specify library dependencies on specific versions. In fact, I think it issues a warning message in some cases if you fail to specify an explicit version dependency.

The underlying problem is that there's no concept of a version number API in Java. In C there are library name conventions that allow you to ask for the newest version of the library that implements a given API. But Java never developed those conventions, so your only safe course of action is to peg to a specific version.

By the way, JDK7 is still considered new and untested by most enterprise Java users. I don't even have it installed yet because what would be the point? It's still experimental in the context of Hadoop.

Another thing to note is that there are going to be a lot fewer security issues in managed code than in C/C++ libraries. I enjoy programming in C and C++, but let's not kid ourselves. I think Go's model is fine. If there's a big security flaw discovered in some Go library, it will trigger a lot of binaries to be re-downloaded from Linux distros. But I don't expect that to happen that often.

No thanks.

Posted Oct 28, 2012 16:29 UTC (Sun) by nix (subscriber, #2304) [Link]

Not only are there library name conventions, but many C environments also support versioned symbols, so you can fix bugs in a function without breaking old programs that may depend on that bug.

The irony is that the original implementer of this feature (before GNU souped it up by adding default symbol versions) was... Sun, and it has stood them in very good stead over the years. I have no idea why on earth the Java people didn't learn from the people across the hall in this area.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds