Weekly Edition
Return to the Development page
| |||||||||||||
Haley: We're doing an ARM64 OpenJDK port!
We're a bit late in noticing, but Andrew Haley has announced plans to develop a free Java for 64-bit ARM systems. "There are two versions of HotSpot, the VM that OpenJDK uses, for the
current (32-bit) ARM. The one written and owned by Oracle is
proprietary, and the other (written for ARM) is free. The proprietary
VM performs better than the free one. The latter uses a lightweight
small-footprint just-in-time compiler that can't compete with the
might of Oracle's JIT. We really don't want this situation for A64,
so we're writing a port that will be entirely free software. We'll
submit this as an OpenJDK project, and we hope that others will join
us in the work."
(Log in to post comments)
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 25, 2012 23:39 UTC (Thu) by jcm (subscriber, #18262) [Link]
Andrew and Andrew, and the team are epic awesome people! Very excited we announced this :)
No thanks. Posted Oct 26, 2012 0:55 UTC (Fri) by ncm (subscriber, #165) [Link]
Why can't we let Java rot in peace? Is has no more relevance in the Free Software world than C#, whatever its importance to the Android-app, corporate-drone, and web-framework markets. COBOL's public face is a model to emulate.
Wait just a moment... Posted Oct 26, 2012 1:56 UTC (Fri) by pabs (subscriber, #43278) [Link]
I need OpenJDK for JOSM and parts of LibreOffice.
Wait just a moment... Posted Oct 26, 2012 3:59 UTC (Fri) by ncm (subscriber, #165) [Link]
That seems fixable.
I wonder if merkaartor is usable. I've found the Java bits of LO supremely dispensable, ymmv.
Wait just a moment... Posted Oct 28, 2012 23:17 UTC (Sun) by pabs (subscriber, #43278) [Link]
merkaartor is usable, but JOSM was better last time I used them. Before that merkaartor was better, so who knows which one I will need next time.
No thanks. Posted Oct 26, 2012 4:29 UTC (Fri) by cyanit (guest, #86671) [Link]
Well, if you want to get rid of both Java and C#, what are you suggesting to use as a mainstream fast strong-typed garbage-collected language?
No thanks. Posted Oct 26, 2012 4:41 UTC (Fri) by imgx64 (guest, #78590) [Link] I like Go myself.It might be too early for Go to replace either Java or C#, as it doesn't have their "enterprisey" support. But then, it's only three years old.
No thanks. Posted Oct 26, 2012 4:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Go's garbage collector is shit. Its reflection and dynamic code loading support is poor.
Besides, Go itself is, well, kinda stupid. Well, not just kinda but very stupid.
No thanks. Posted Oct 26, 2012 7:07 UTC (Fri) by danieldk (guest, #27876) [Link]
I have been writing a lot of Go lately, and I have to agree. It feels like its authors have ignored thirty years of development in programming languages. It's garbage collector is weak, it does not have parametric polymorphism (no, using interface{} everywhere with introspection is not the solution), no good facilities to write DSLs, contrived error handling, etc. Even Objective-C looks great in comparison.
No thanks. Posted Oct 26, 2012 11:21 UTC (Fri) by juliank (subscriber, #45896) [Link]
Well, of course they ignored much of the recent developments, as they're old UNIX people! :)
No thanks. Posted Oct 26, 2012 16:20 UTC (Fri) by cmccabe (guest, #60281) [Link]
Go's current implementations use a partially conservative garbage collector, which has some advantages but might ignore some memory that actually should be freed. In practice, this does not seem to be a problem on 64-bit systems, but it is one on 32-bit. They are looking at improving it, but it will take time.
I feel like it's unfair to blast Go for this. It's a new language; its GC is not going to beat HotSpot on day 1. A lot of the languages Go is often compared to, like Python, have far worse GC (CPython _still_ can't collect datastructures which have cycles, if any of them has a finalizer).
Google is using Go in production (see Vitess for an open source example).
As far as error handling goes, the designers of Go thought about it for a long time. You may or may not agree, but calling it "contrived" is disingenuous. Basically, a lot of people have used and grown to dislike the confusion of routine errors and exceptions that prevails in languages like Java. Joel Spolsky wrote a good article about it: http://www.joelonsoftware.com/items/2003/10/13.html. I'm sure you can find many more. The tl;dr version: don't believe the hype. You want exceptions only for signalling fatal errors.
re: domain specific languages. In general, I feel like you've got two approaches to follow when using DSLs. The first one is to use an extremely dynamic language like Lisp, Ruby, etc. and use eval-based tricks. The second is to create something like lexx or yacc-- a preprocessor that converts source in $DSL to C, C++, Golang, etc. Both are perfectly valid approaches. I don't feel like the colleciton of macro tricks and templates often glorified as "a DSL" in C++ requires any comment, other than: please, make it stop.
With regard to generics: if you find yourself using interface{} everywhere, you're doing something wrong. If you program Go like it's Java, you're not going to be happy. Java is best programmed in Java. But if you program Go like Go, you just might find that you have what you need. With that being said, generics might be added to the language at some point.
No thanks. Posted Oct 26, 2012 19:55 UTC (Fri) by danieldk (guest, #27876) [Link]
> In practice, this does not seem to be a problem on 64-bit systems, but it is one on 32-bit.
You seem to be referring to the problem where (since the address space on 32-bit machines is small) some values may be identified as valid pointers. But that isn't the only problem with the garbage collector. It performs badly when lots of short-lived small objects are created. Eventually, it'll need a better collector.
> They are looking at improving it, but it will take time.
That's the standard answer. But currently, its GC is weak.
> A lot of the languages Go is often compared to, like Python, have far worse GC (CPython _still_ can't collect datastructures which have cycles, if any of them has a finalizer).
Here, the discussion was about Java and C#.
> As far as error handling goes, the designers of Go thought about it for a long time. You may or may not agree, but calling it "contrived" is disingenuous. Basically, a lot of people have used and grown to dislike the confusion of routine errors and exceptions that prevails in languages like Java.
Every serious chunk of Go code is interwoven with if statements to check for errors. It breaks the logical flow of functions. Besides that, it's not mandatory to bind the return values of a function. So for side-effecting functions, it's easy to accidentally ignore errors. And then there is the whole 'nil may equal be nil' issue:
http://golang.org/doc/go_faq.html#nil_error
> You want exceptions only for signalling fatal errors.
I want errors as values, *without* having to check the result of every function call. This has long been solved in option types that are also monads, see e.g. Maybe and Either in Haskell. Java checked exceptions are not too bad either: they don't clutter the flow, but you cannot silently ignore them (you have to catch them or indicate that your method might throw that particular exception).
Go doesn't differ much from C wrt. to error handling. Except that in C I know that -1 is always -1 or 0 is always 0.
> Both are perfectly valid approaches. I don't feel like the colleciton of macro tricks and templates often glorified as "a DSL" in C++ requires any comment, other than: please, make it stop.
Right, I was referring to the latter (EDSLs). So, what facilities does Go provide to support the latter? I haven't seen any real EDSL in Go. DSLs have been done in static languages before, without the horror of C++. E.g. Hamlet is a EDSL in Haskell for producing HTML in a type-safe manner:
http://www.yesodweb.com/book/shakespearean-templates
Hakyll is an EDSL for constructing static site generators:
http://jaspervdj.be/hakyll/index.html
> With regard to generics: if you find yourself using interface{} everywhere, you're doing something wrong.
Sorry, I was being sarcastic there. It's the standard answer you will get on various Go fora: Go doesn't need generics, because there is interface{}. Anyway, the criticism still stands: Go doesn't have parametric polymorphism, so you either:
- If you are lucky, use non-empty interfaces.
E.g. consider writing the Haskell function:
replicate :: Int -> a -> [a]
(Repeat a value n times.)
A Go equivalent is:
func replicate(n int, val interface{}) []interface{}
Not only does this completely throw away type safety, it's also an example of Go's tediousness. If you call, say replicate(20, 10), you cannot directly cast the result to an []int, because []interface{} is obviously something different.
By all means, don't take my word for it. I encourage people to read Mark Summerfield's Programming in Go. If you use a modern static language such as C#, Haskell, or whatever on a daily basis, you'll be thinking "heh, I could do this in X more elegantly in a far smaller number of lines" every half page or so.
The only great feature of Go is gofmt.
No thanks. Posted Oct 26, 2012 21:55 UTC (Fri) by cmccabe (guest, #60281) [Link]
I programmed for Android back in the 1.1 days. I'm pretty familiar with the problem of lots of creating lots of small objects. That problem is now effectively solved on the newer versions of Android, due to Dalvik updates. I feel confident that Go will tread a similar path.
> Go doesn't differ much from C wrt. to error handling. Except that in
This is really unfair. Numeric types are strongly typed in Go.
Also, in C, 0 may not always be 0. Technically pointer NULL is a logical representation, not a physical one, so casting a NULL value for a pointer to an int may result in something other than 0. As someone invoking the name of Haskell, you should know this :)
No real-world C compilers that I know make use of this liberty. As usually, C++ "outdoes" C in the amount of implementation-dependent crud. Specifically, NULL values for pointer to member functions are usually not represented by the bit pattern 0. Check this out for some nifty implementation dependent spew:
#include <stdio.h>
class Foo {
static union {
int main(void) {
I agree that the way in which interface values are compared to nil in Go is a little weird. Since the interface types are represented by a tuple internally, it would have been nicer to force developers to write out that tuple when comparing an interface to a constant.
We are going to have to agree to disagree about error handling. I could point out a lot of other notable programmers who prefer error codes to exceptions, not just Joel Sposky. From the Google C++ coding standard, to Raymond Chen, to Linus Torvalds. But what do those guys know anyway? Java checked exceptions are the way and the light (hint: they're not.)
Comparing Go and Haskell is comparing apples and oranges. Go isn't intended to be a functional programming language. We already have a ton of those already (OCaml, Scala, Clojure, etc.) Maybe for algorithms work it's good, but for systems-level work I think those are all very uninteresting.
No thanks. Posted Oct 26, 2012 23:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
You might note that Scala and Clojure both require a JVM (see the referenced news article). And in fact if you want a cross-platform static typesafe language that is not C/C++ then your choices are quite limited.
Basically, it's Java or GTFO. At most you can make do with Mono. There are no other viable choices.
No thanks. Posted Oct 26, 2012 23:54 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> I want errors as values, *without* having to check the result of every function call.
I have found that in practice the moment one wants to add more context to errors the good old return flags to indicate unexpected return status results in least cluttered code.
For example, in Java stack traces in log files by themselves can be rather useless for problem diagnostics. To facilitate the analyzes it is often necessary to log state information from quite a few call sites. But in Java that results is rather ugly
try {
With return error codes the extra clutter is minimal - one just needs to add log_extra_error_state(); on the error path.
Now, I presume in Haskell such annotated error reports should be rather simple to implement using Either. But even in Haskell checking for errors after return is inevitable if one wants to add the context information only on error paths.
No thanks. Posted Oct 27, 2012 6:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah, sure. So with error code you basically get:
> 42. Program failed. Now try to find out why, mwahahah!
In Java you can _rethrow_ exceptions, without losing the cause. I.e.:
No thanks. Posted Oct 27, 2012 8:30 UTC (Sat) by ibukanov (subscriber, #3942) [Link]
> Yeah, sure. So with error code you basically get:
> 42. Program failed. Now try to find out why, mwahahah!
No - with consistent error logging one gets in C very useful stack-like information about the error state without the noise of deep Java stack trace.
Clearly in Java one can do the same and have a stack trace in addition, but even in C it is possible to get the stack trace. Yet the C solution brings less clutter to the server code where it is desirable to log on errors (and only on errors) the maximum information about the state.
RuntimeException ftw Posted Oct 27, 2012 10:41 UTC (Sat) by man_ls (subscriber, #15091) [Link] With well coded programs a stack trace is all that is needed 99% of the time, or at least that is my experience. You can save the bit about "consistent error logging" and still spot errors.There are weird occasions where e.g. the Android platform eats up your stack trace and generates its own, but that is not usually the case. As to checked exceptions, they look good but in practice lead to byzantine exception hierarchies and hyper-delicate error handling, not well suited for humans (or for teams). Unchecked exceptions are good in that you don't need to handle all possible situations. In a web application you can just catch them at the root level, log them and print an HTTP 500 page; the user is not going to care at the moment as to why you are not showing the info they want, and the admins get a nice stack trace -- see above.
RuntimeException ftw Posted Oct 28, 2012 0:09 UTC (Sun) by cmccabe (guest, #60281) [Link]
Go has exceptions, it just calls them "panics" and doesn't make an attempt to give them elaborate type hierarchies. So if your program does something _really_ bad, it will abort with a stack trace.
As far as spewing stack traces for normal errors-- people who want this are not thinking clearly. Unless you are a developer, you shouldn't need to read stack traces.
If you do want stack traces in your logs, you can easily get them with: http://golang.org/src/pkg/runtime/debug/stack.go
It's really nice to have stack traces in the language-- lack of them in the language is awkward in C/C++, although there are libraries that can help a lot.
RuntimeException ftw Posted Oct 28, 2012 8:48 UTC (Sun) by man_ls (subscriber, #15091) [Link] Unless you are a developer, you shouldn't need to read stack traces.Absolutely true, I did not want to imply that the stack trace is shown to the user. The server displays a regular, nice 500 page (with no mention of "HTTP 500" either); but the stack trace is stored in the logs for further analysis. Exceptions are good also to return from APIs, as long as they are documented: they come out in tests, are easy to spot and understand, and easy to deal with.
RuntimeException ftw Posted Oct 29, 2012 18:31 UTC (Mon) by cmccabe (guest, #60281) [Link]
I disagree that exceptions should be returned from APIs (shouldn't that be "thrown"?) The caller shouldn't have to understand the internal implementation of your library to use it. A null pointer exception 10 levels deep in library code is not a friendly API, even for programmers.
If you can fail, document how you can fail, and come up with return codes or another API to handle it cleanly. If you can't fail, then return void and be done with it.
Checked exceptions were an attempt to make exceptions "work like return codes." But it failed. Every method in the world ends up throwing IOException, and it basically functions exactly like unchecked exceptions.
RuntimeException ftw Posted Oct 29, 2012 18:50 UTC (Mon) by man_ls (subscriber, #15091) [Link] Sorry, I meant "Exceptions are good also to throw from APIs, as long as they are documented".But throwing a NullPointerException is not what I said; that is obviously a bad idea in any case. Just declare an unchecked exception for every failure condition (with an umbrella super-exception) and document them. That way you can throw them from any point in your code. This is not different from your description: "document how you can fail, and come up with return codes or another API to handle it cleanly". Unchecked exceptions are a wonderful way to handle failures cleanly; in effect these exceptions become another part of your API. IMHO, avoid checked exceptions like the plague because they become, without exception, a mess. In a recent Android app I thought I could get off with a checked exception for offline mode to force implementors to deal with it, but in the end I had to change it back to unchecked.
No thanks. Posted Oct 27, 2012 17:37 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah, sure. So now you're proposing to do LOGGING from basically every level of stack. And where are you going to log things? If you say 'stderr' then I'm going to come and burn down your house.
No thanks. Posted Nov 9, 2012 2:34 UTC (Fri) by HelloWorld (guest, #56129) [Link] http://www.joelonsoftware.com/items/2003/10/13.html Joel doesn't have a clue, and that article is a perfect example of that. Exceptions don't create any new exit points for a function; if you handle all possible errors in the way he suggests, you'll end up with just as many possible exit points. And also his other point about exceptions being invisible in the source code is a complete red herring, because you know what's invisible and hard to find with code inspection too? Missing error code checks. And there's even more nonsense. He's right in that you can't write With regard to generics: if you find yourself using interface{} everywhere, you're doing something wrong. Yes, and I know what: you're using Go. With that being said, generics might be added to the language at some point.Deferring that to "some point" just shows utter cluelessness. The type system is the cornerstone of a programming language. It's an exercise in futility to try to bolt something as important as parametric polymorphism onto a language as an afterthought. And it's not like its are something new and mysterious. ML had it 40 years ago and the theory behind it (System F and its variants like System F<:) is well-understood.
No thanks. Posted Nov 9, 2012 8:00 UTC (Fri) by paulj (subscriber, #341) [Link]
He's stated it in terms that aren't correct, but I think he means exceptions increase the number of possible control-flow branch points in the code. Without exceptions, the branch points in a block of code are visually obvious. With exceptions, there may be multiple branch points per statement - and they are *implicit*, you can't see them.
This certainly raises the bar to fully understanding the behaviour of exception using code.
No thanks. Posted Nov 9, 2012 9:33 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. Exceptions force you to restructure you code to be exception-sane.
I.e. if you open a resource then you should do it in a try-finally block (or its analog). In C++ you should wrap in automatic object.
Error codes, on the other hand, promote sloppy design. Certain error codes are almost always ignored, like printf() return result (do you know that it can be used to process SIGINT gracefully?) or close().
No thanks. Posted Nov 9, 2012 9:47 UTC (Fri) by paulj (subscriber, #341) [Link]
Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such. That you can disagree with my comment on that point suggests either that you do not understand how exceptions are implemented, or else you somehow ignored the content of my comment in replying to it.
That coping with this requires structuring code in certain ways when using exceptions is true, but a different point, and it is still non-trivial at times because of the prior point. Just have a look at discussions on exceptions in C++ in constructors and destructors.
Note that I was not advocating for error return codes. That's a strawman argument you're incorrectly attributing to me.
No thanks. Posted Nov 9, 2012 10:22 UTC (Fri) by hummassa (subscriber, #307) [Link]
That is the point:
> Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such.
THAT IS NOT A FACT AT ALL.
Those implicit control-flow branch points WILL HAVE TO BE DEALT WITH ANYWAY, they were already there. Only without exceptions you have to deal with them all at all positions in your code. Explicitly. You are writing code that is scaffolding code, not code that does what the program actually needs to do.
When you use exception, you write only the code that does what the program actually needs to do, with some sanity checks here and there. You follow the sanity rules, you are safe.
For instance, every time you open a file things can go wrong. Supposing you have a function call hierarchy main -> f -> g -> h, and h() wants to open a file, one of the following will happen:
1. you (generic "you", ok?) won't check open() results, will proceed as if the file was open, and undefined and terrible things will happen;
2. (try#2) you will check open() results, return an error code, g() does not check for the error code and proceeds, hilarity ensues;
3. (yes it finally works) g() checks h() error code, f() checks g() error code, main() checks f() error code, prints a suitable message.
4. (despair happenning) you have to call i() from g() and j() from f() and both have to open files. At this point, if you don't forget anything (you have to do every of these checks yourself, manually) you have a program that is at least 25% scaffolding.
With exceptions, one of those will:
1. open() throws, _main() aborts and prints "unexpected exception". The program already works.
2. (let's make this pretty) you put a catch() block on main(), print a pretty message cerr << "file " << name << " could not be open". The program still works.
3. (down the road) you have to add i() and j() and the program still works. No need to repeat step 2.
> Note that I was not advocating for error return codes.
No, but you are differentiating "implicit control-branch points" from "explicit" ones and it does give that impression. My point is that: implicit control-branch points are there anyway (you open a file, things can go wrong in the process), and dealing with them implicitly is better then explicitly.
Yes, dealing implicitly with exceptions means that sometimes you have to be exceptionally (ha!) safer (constructors/destuctors). But it just helps you to clarify your code and tell better when things can go wrong.
No thanks. Posted Nov 9, 2012 10:29 UTC (Fri) by paulj (subscriber, #341) [Link]
So the control-flow branch points which you disagree exist have to be dealt with anyway? So they don't exist but they do.
There are other ways to deal with errors, besides exceptions or error return codes. You can design the underlying, called-into code to explicitly follow a state machine, and have idempotent error state. Calling code then do a number of operations on such objects, and check at the end whether they succeeded or not, and if not, query the reason for the error.
No thanks. Posted Nov 9, 2012 16:35 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> So the control-flow branch points which you disagree exist
Did you even read what he wrote? He didn't say they don't exist, he said that they exist regardless of whether you use exceptions or error codes to handle errors.
No thanks. Posted Nov 9, 2012 23:40 UTC (Fri) by nix (subscriber, #2304) [Link]
Each statement? If only it were so easy. At each statement, each function call, and each potentially overloadable operator. The number of abnormal edges can get ridiculous. There could be *dozens* in a single thing that looks like one statement.
No thanks. Posted Nov 10, 2012 3:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. The number of statements where special exception handling is needed is SMALL. Basically, only the code that works with external or shared long-living resources.
No thanks. Posted Nov 10, 2012 10:21 UTC (Sat) by paulj (subscriber, #341) [Link]
There you go again saying "Nope" to something that is factually correct. At this stage it's hard to conclude anything other than that you simply don't understand how exceptions work under the hood.
No thanks. Posted Nov 10, 2012 16:10 UTC (Sat) by nix (subscriber, #2304) [Link]
It's clear he's never written any significant body of exception-safe code in C++, that's for sure. (Hint, Cyberax: consider a simple RAII object which allocates some memory in its constructor, in two tranches, with a single assignment between. Now consider that memory allocation can throw bad_alloc, as can the invocation of the assignment operator, if not elided by the compiler, as it can sometimes be -- and consider that if this is templated, you have to consider that *every possible point* that might throw exceptions, will throw exceptions, since you don't know what types you'll eventually be dealing with.
That memory allocation is not a shared resource except inasmuch as the heap is shared -- in which case you have to consider almost *everything* a use of a shared resource -- but you still need to consider the semantics of exceptions in order to figure out how to avoid a memory leak. And this soon gets thoroughly unobvious.)
No thanks. Posted Nov 10, 2012 21:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] >Hint, Cyberax: consider a simple RAII object which allocates some memory in its constructor, in two tranches, with a single assignment between.
#include <stdio.h>
#include <memory>
#include <stdexcept>
class tracer
{
public:
tracer() { printf("Constructing\n"); }
~tracer() { printf("Dying\n"); }
};
class tester
{
std::auto_ptr<tracer> t1_;
std::auto_ptr<tracer> t2_;
public:
tester()
{
t1_=std::auto_ptr<tracer>(new tracer());
throw std::runtime_error("Test");
t2_=std::auto_ptr<tracer>(new tracer());
}
};
int main()
{
try
{
tester t;
} catch(const std::runtime_error &ex)
{
//Print exception info
}
return 0;
}
cyberax@cybmac:~/work$ ./a.out
Constructing
Dying
And your point is?
Consider that you have to deal with exactly the same crap if you DO NOT use the exceptions. EVERY function you invoke can cause error conditions (such as out-of-memory). Now please rewrite my example without exceptions, providing the same level of guarantees and functionality.
No thanks. Posted Nov 10, 2012 23:06 UTC (Sat) by nix (subscriber, #2304) [Link]
You really don't understand, do you?
Consider just these three lines of your example:
t1_=std::auto_ptr<tracer>(new tracer());
Let's replace the stupid throw with something more likely to be actually seen in practice, say:
t1_=std::auto_ptr<tracer>(new tracer());
Now... if any of those constructors but the first throws, what do you do about it? If, for whatever reason, you cannot use auto_ptr (which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work) how do you prevent the earlier-allocated ones from leaking? That's right, you have to free at appropriate times in a catch handler. Now figure out which bits can throw. It's hard. It's very, very hard. I recommend Scott Meyers's Effective C++ books for more than you can possibly stomach on this (I wish I could reread mine, but I loaned them out and they never came back, I'm sure you know how it is).
No thanks. Posted Nov 10, 2012 23:22 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Try it. I really mean it - try it. It would work just fine. Everything will be correctly destroyed.
>If, for whatever reason, you cannot use auto_ptr (which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work) how do you prevent the earlier-allocated ones from leaking?
Of course, if you really don't want to do it then you'll have to do the try..catch dance. Exactly like in C where ALMOST EVERY function might result in error and the most common pattern of error handling is "goto err_exit". That's actually why glibc handles OOM by calling abort() - it's simply too complicated to make everything in C error-safe.
PS: I had actually written a simple model verifier to verify my own collection library for upholding exception guarantees. That means that I've obviously read Sutter, Meyers, Stroustroup, Alexandrescu and quite a lot of other C++ writers.
No thanks. Posted Nov 10, 2012 23:25 UTC (Sat) by foom (subscriber, #14868) [Link]
> Now... if any of those constructors but the first throws, what do you do about it?
You don't have to do anything, because auto_ptr's destructor takes care of it for you.
> If, for whatever reason, you cannot use auto_ptr ( which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work
That's the whole point! You *always* just use auto_ptr (or another smart pointer, e.g. unique_ptr) to take care of it for you! That's exactly why RAII is so nice, and has been best practice in C++ for years!
No thanks. Posted Nov 11, 2012 9:32 UTC (Sun) by paulj (subscriber, #341) [Link]
That smart pointers are required exemplifies the "non-trivial" observation made of exception using code. And remind me again, how long have these been available as part of the standard C++ environment?
No thanks. Posted Nov 11, 2012 10:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Since at least 80-s. The problem was mostly in old C programmers who don't know better.
No thanks. Posted Nov 11, 2012 12:53 UTC (Sun) by paulj (subscriber, #341) [Link]
Rubbish. I have books from the 90s on C++ that fail to mention smart pointers anywhere, written by C++ committee members.
Could good C++ programmers have created their own smart pointers in the 80s? I guess so. My strong impression though is that C++ programmers would have been *way* ahead of the state of understood wisdom in the C++ world at that time. My impression
To claim smart pointers are trivial, widely understood techniques since the 80s stretches credibility somewhat. If they're so trivial, so widely understood for so long, why did it take 20+ years to standardise some? Why is an only relatively recently standardised form of smart pointer already being deprecated in the next C++ standard? (auto_ptr for unique_ptr). My sense is that smart pointers are so trivial that even C++ standards committee members hadn't really fully grokked the implications of copying, moving and sharing them until relatively recently - but I guess they're just "old C programmers who don't know better".
Unfortunately, in the real world, many programmers just aren't quite as brilliant as you.
No thanks. Posted Nov 11, 2012 13:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> Rubbish. I have books from the 90s on C++ that fail to mention smart pointers anywhere, written by C++ committee members.
[citation needed]
> Could good C++ programmers have created their own smart pointers in the 80s? I guess so. My strong impression though is that C++ programmers would have been *way* ahead of the state of understood wisdom in the C++ world at that time. My impression
http://www.stroustrup.com/bs_faq2.html#finally
>If they're so trivial, so widely understood for so long, why did it take 20+ years to standardise some? Why is an only relatively recently standardised form of smart pointer already being deprecated in the next C++ standard? (auto_ptr for unique_ptr).
However, Boost and other libraries had no shortage of various smart pointers.
No thanks. Posted Nov 11, 2012 14:56 UTC (Sun) by paulj (subscriber, #341) [Link]
Herbert Schildt, "C++ Nuts & Bolts for Experienced Programmers", Osborne McGraw-Hill, 1995. (Yes, Schildt has gotten flack for technical errors / flaws on C++ in his books, and yes, this book wasn't intended to be a reference).
When was Boost created? late 90s. Before Boost there was the HP and SGI STL, which I gather inspired the standardised STL (and Boost?), and iostream. That work dates from the early 90s AFAICT. The SGI STL page doesn't seem to have any kind of smart pointer, dated 1994. C++98 has the auto_ptr, but it apparently is flawed. The early Boost pages reference this: http://web.archive.org/web/19991222182604/http://www.boos... which references books discussing smart pointer programming *patterns* from '92, '94.
I know this stuff is all trivial to you, but it does seem to me that it took about 10 to 15 years (80s to mid/late 90s) for leading C++ programmers to agree on patterns for dealing with exception safety, such as RAII, then getting some kind of smart pointer support in the language (standard or generally available libraries) in order to cope with remaining pitfalls in C++ RAII+exceptions. That smart pointer support then needed further refinement in the mid/late 90s and early 2000s to get to where we are today.
That doesn't quite suggest to me that this stuff is quite as trivial as you suggest to is. Finally, even with smart pointers, I still don't find exception handling code that uses them to be non-trivial! However, you do seem be a superior breed of programmer to the rest of us, so perhaps that's the reason for the discrepancy in views ;). (Intended as a gentle jibe, I hope you'll accept it in that spirit).
No thanks. Posted Nov 12, 2012 2:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Herbert Schildt, "C++ Nuts & Bolts for Experienced Programmers", Osborne McGraw-Hill, 1995. (Yes, Schildt has gotten flack for technical errors / flaws on C++ in his books, and yes, this book wasn't intended to be a reference).
He's not a member of C++ committee.
>When was Boost created? late 90s. Before Boost there was the HP and SGI STL, which I gather inspired the standardised STL (and Boost?), and iostream.
Exceptions appeared in GCC 2.7 in 1997, I think. Before that there was little reason to use them and to create best practices for them. Though the usefulness of RAII was understood earlier.
In Java exceptions with try..finally also appeared at about the same time. But without RAII.
No thanks. Posted Nov 12, 2012 14:35 UTC (Mon) by paulj (subscriber, #341) [Link]
Well, Schildt's wikipedia page says he was involved in C++ standardisation in the 90s. I don't know myself if that's correct or not.
As for exceptions, they were developed in the late 80s, standardised in the early 90s, and there were commercial compilers supporting exceptions since at least '92 apparently. See: http://www.stroustrup.com/hopl2.pdf. The release history of GCC possibly isn't that relevant, a number of proprietary implementations of C++ had more significant usage than g++ back then iirc.
Anyway..
No thanks. Posted Nov 12, 2012 14:38 UTC (Mon) by paulj (subscriber, #341) [Link]
Oh, the '95 Schildt book has a section on exceptions.
No thanks. Posted Nov 9, 2012 23:38 UTC (Fri) by nix (subscriber, #2304) [Link]
Consider how long it took after the introduction of exceptions into C++ to figure out how to write truly exception-safe code. It took *decades*. Doing it is not remotely obvious.
No thanks. Posted Nov 10, 2012 3:25 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. The way to write exception-safe code has been clear from the start (modulo a few foulups in the Standard). That's why there's no "finally" keyword in C++.
The main problem was that exceptions were added quite lately in the game, and they were not reliable and/or generally available until at least early 2000-s. So we're stuck with huge amount of legacy non-exception-safe code.
But that's a poor excuse for creating a new language without exception support.
No thanks. Posted Nov 10, 2012 16:06 UTC (Sat) by nix (subscriber, #2304) [Link]
Well it's curious the way I have multiple whole books which have about a third of their total page count discussing how to write exception-safe code in the presence of copy constructors, assignment operators, operator() and other such things which throw exceptions (throw in the possible elision of temporaries if you want to make it really fun).
Perhaps I was hallucinating and e.g. Herb Sutter's writings on the subject do not in fact exist, and it was 'clear from the start'. That would explain it, but I don't think that's so.
No thanks. Posted Nov 10, 2012 21:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
And the whole books should have been written on writing safe C code in presence of errors.
A simple question - how do you deal with errors in the ubiquitous "goto error_exit" pattern in C?
No thanks. Posted Nov 10, 2012 23:08 UTC (Sat) by nix (subscriber, #2304) [Link]
I actually solved this once with a really ugly exception-unwinder (implemented mostly in macros with one fugly bit of arch-dependent code). A few years later I had to port it to a new platform and wished I'd done something else.
(btw, I wish you'd be less bloody combative all the time. You turn every discussion on LWN into a minor war.)
No thanks. Posted Nov 11, 2012 0:45 UTC (Sun) by hummassa (subscriber, #307) [Link]
Kettle, meet pot. :-D
But j/k, I love your discussions. From both of you. I learn a lot.
No thanks. Posted Nov 11, 2012 5:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>I actually solved this once with a really ugly exception-unwinder (implemented mostly in macros with one fugly bit of arch-dependent code).
Yup. Each sufficiently complex error handling system is indistinguishable from exceptions.
> (btw, I wish you'd be less bloody combative all the time. You turn every discussion on LWN into a minor war.)
No thanks. Posted Nov 11, 2012 9:54 UTC (Sun) by paulj (subscriber, #341) [Link] You can structure your code (in C, C++, Java, etc) so that you only have to check for errors at object creation, and thereafter only where it is convenient - i.e. you can do as many operations on the objects as you want without having to check for erros, without any use of control-flow branch points exploding exceptions:
do {
var f = foo_new ();
var b = bar_new ();
if (!f || !b)
break;
f.twiddle ();
b.jiggle ();
<do as many more operations as you want on f and b,
without need for checking for errors>
if (f.state == ERROR || b.state == ERROR)
break;
<do whatever updates to this objects internal state,
and update its .state appropriately>
return;
} while (0);
if (f)
foo_delete (f);
if (b)
bar_delete (b);
<set this object to its error state>
return;
You do this by having the objects keep a finite state machine internally, with an idempotent error state. You could do more sophisticated error recovery by also tracking the prior state, that transited into the error state and potentially other more detailed info, e.g. with:
if (b.state == ERROR) {
switch (b.prev_state) {
...
}
}
Most of the same benefit of exceptions - of being able to move error handling out of the primary flow of code - but without the control-flow explosion (no need for goto either).
No thanks. Posted Nov 11, 2012 10:03 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
So you now have to prefix ALL methods of f's class with "if (error) return error;". Nice.
And of course, you can forget about doing "b.twiddle(f.jiggle())".
And it'll be especially vexing in code that might be reused in several parts of a project. Additionally, your deleters (foo_delete, bar_delete) might in turn cause errors, how are you going to process them?
It's amazing to what lengths people would go just to avoid using exceptions. Why, they'd even re-invent exceptions without all their nice properties and with all the bad ones.
No thanks. Posted Nov 11, 2012 11:01 UTC (Sun) by paulj (subscriber, #341) [Link]
Whether you do or don't use exceptions, it's far from a bad idea for objects to always check their internal consistency on entry from external callers. As for dealing with errors in clean up, remind me again how exceptions improves on that? Would you throw an error from a destructor?
Also, you seem to be suffering from some kind of binary thinking - that people are either for or against something - and projecting that onto others. I have not at any stage expressed an opinion on whether exceptions should be avoided or not.
No thanks. Posted Nov 11, 2012 11:20 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>Whether you do or don't use exceptions, it's far from a bad idea for objects to always check their internal consistency on entry from external callers.
That's a bad idea because of a several reasons. All reliable systems should be built on the idea of invariants and contracts. The violation of the contract/invariant should be treated as a fatal error.
So putting "assert(someInvariantState==43)" in method's body is fine as a purely debugging tool to find programmer's error. However, doing "if (someInvariantState!=42) return -ERR;" is a big NO-NO.
>As for dealing with errors in clean up, remind me again how exceptions improves on that? Would you throw an error from a destructor?
No thanks. Posted Nov 11, 2012 15:29 UTC (Sun) by paulj (subscriber, #341) [Link]
From my perspective, programming network services, where inputs may come from bad actors, and where the last you want to do is to allow a bad actor to cause your system to deny service to the good actors, I flatly disagree that violation of contracts should result in fatal errors - termination of that service to that actor, in a clean way, yes, fatal end of programme and all service: absolutely the wrong goal. (Invariants should be fatal, but that's a different thing).
And if you think I've been arguing that errors should be returned and caught and handled at each method call you've simply not read my comments, and you're just arguing with a figment of your own imagination. Good luck with that :).
No thanks. Posted Nov 11, 2012 15:57 UTC (Sun) by raven667 (subscriber, #5198) [Link]
Fatal termination of the program might be the only safe bet if the internal state is compromised by a bad actor, I would be distrustful of claims to "cleanly" recover or try to "handle" errors that they actually can't handle. That's why long-running processes should be run under high availability supervision like daemontools or systemd.
I'm no expert on implementation details but the idea of Exceptions seems right to me, errors can't be ignored, they have to be handled or the program dies, which seems better to me than having your program jump the track and keep stupidly barreling along mowing through your data, driving through your living room window 8-)
No thanks. Posted Nov 11, 2012 16:19 UTC (Sun) by paulj (subscriber, #341) [Link]
If the internal state is compromised yes. However, you want to reject the bad actor's input before that happens. Parsing things with state machines and related automata, and cleanly rejecting invalid input (and dispensing with associated state) is not rocket science. (Note that method calls related to some piece of state can be viewed as inputs/transitions on an automaton).
Asserting and crashing should be a last resort in daemons that must provide shared-state services to multiple actors. While it is preferable to assert than to allow a security critical error, asserting itself may be a security critical error - handling errors cleanly is again preferable to the assert. A better approach is to have multiple layers of defence, with asserts against critical inconsistency errors at lower layers (e.g. forcing all IO through checked, bounded buffer abstractions), and well-defined automata at higher layers to provide clean error semantics (potentially multiple levels of such). You can't just restart, because of the shared-state. If you externalise the shared-state so that the code can be restarted, you still need to ensure that shared-state can never be manipulated into an inconsistent state.
All the world is a state machine, even the functional programming world. ;)
No thanks. Posted Nov 11, 2012 10:39 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Oh, and if "f.twiddle ();" returns with an error and "b.jiggle ();" depends on some side effects of "f.twiddle()" that hasn't happened then you get a very nice "wish you happy debugging!" moment.
No thanks. Posted Nov 11, 2012 10:55 UTC (Sun) by hummassa (subscriber, #307) [Link]
And more -- good look synchronizing the FSMs for 42 instances of each of 42 different types of objects (think a *simple* payroll application). THAT is full of happy debugging moments.
No thanks. Posted Nov 11, 2012 12:36 UTC (Sun) by paulj (subscriber, #341) [Link]
Pretty much all non-trivial objects (composites, or ones with implicit constraints on fields that can't be expressed in the type system or language) have an FSM, at a minimum the 2-state FSM of "Internal state is consistent" and "Internal state is not consistent". You have to deal with that reality one way or another. Tracking that consistency internally through an explicit FSM is one way. Dealing with invalid use of that object after errors through an idempotent error state or assertions or exceptions all have their pros and cons.
You don't have to synchronise all the FSMs. Or at least, if you do, then it wasn't because you added an explicit FSM - you had to effectively be synchronising their state already anyway. All it does is crystalise and making explicit (inc making it queryable to outside users) requirements that are already there.
No thanks. Posted Nov 11, 2012 13:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
That's about THE WORST possible system to write software. It combines everything:
1) Hidden state, affecting execution silently. 2) Completely decoupling the error site and the place where error is detected/handled. 3) Possible unforseen interactions through side-effects. 4) Mutable objects. 5) Non-thread safety by design.
No thanks. Posted Nov 11, 2012 15:07 UTC (Sun) by paulj (subscriber, #341) [Link]
1. Many state+code objects in software have hidden state - it's called encapsulation.
2. Decoupling error handling from the error site (in terms of the programming language syntax) is exactly what exceptions do!
3. You could level this argument at pretty much any OOP code, you'd have to be writing pure functional code to avoid this charge.
4. Ditto.
5. Thread safety is completely orthogonal. Making it thread-safe is no different to making other stateful objects thread safe.
You're just throwing accusations blindly in the hope some stick, methinks. :)
No thanks. Posted Nov 12, 2012 1:52 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>1. Many state+code objects in software have hidden state - it's called encapsulation.
Normal designers try to MINIMIZE it. You are not only add it gratuitously, but also introduce non-trivial interdependencies between objects.
For instance:
What if j.jiggle() takes 10 minutes to complete? Then your code would just be losing time if "f.twiddle()" is in error.
>2. Decoupling error handling from the error site (in terms of the programming language syntax) is exactly what exceptions do!
Not error handling, but error _detection_. You can simply forget to check that f's state is OK after the loop. Then there's a problem with compounded errors.
> 3. You could level this argument at pretty much any OOP code, you'd have to be writing pure functional code to avoid this charge.
Nope. Good modern OOP code tries to minimize mutability (it's OK to use mutable objects where it's necessary) - a lot of new OOP languages even have variables that are immutable by default, for example.
> 5. Thread safety is completely orthogonal. Making it thread-safe is no different to making other stateful objects thread safe.
No. For instance "f" object might be immutable except for its "error" state.
BTW, I think that there should definitely be a death penalty for those who abuse do..while loops to emulate "goto".
No thanks. Posted Nov 12, 2012 10:05 UTC (Mon) by paulj (subscriber, #341) [Link]
No dependencies have been added between objects.
In extreme cases, such as j.jiggle () taking 10 minutes, then you might want to check before it. I gave a sketch of a programming pattern - it wasn't intended to be an exact solution for every possible programming problem. If you use it, you will still need to apply some intelligence of your own.
Note further, I was not even claiming that this is *THE* pattern to solve all error-handling. I was just giving it as an example, for consideration, as you earlier had asked for examples of error handling without exceptions (well, you asked for a goto error-exit pattern example, but I assumed other examples would also be allowed).
Object mutability: If an object is immutable, then its state doesn't change and will be immutable. Clearly there is little point in applying state-tracking patterns to single-state objects. This pattern applies to objects with a finite multiplicity of states. Despite your contention, I am fairly sure programming is full of such objects.
Even if you use a series of immutable objects and transition between them, you will still have an FSM with mutable state at a level above those immutable objects, implicitly or explicitly.
No thanks. Posted Nov 11, 2012 12:27 UTC (Sun) by paulj (subscriber, #341) [Link]
You have to query the state of the objects FSM before using any of its other state in this pattern, yes. For other querying methods, returning state other than the FSM state, you can make that a terminal exception (in the "assert()" sense) if such other state is queried for when the object is reached its error state, or you could throw an exception.
No thanks. Posted Nov 9, 2012 8:08 UTC (Fri) by ekj (guest, #1524) [Link]
While I agree with much of your critique, you're being overly harsh on him on one point.
Here's what he said:
"I think the reason programmers in C/C++/Java style languages have been attracted to exceptions is simply because the syntax does not have a concise way to call a function that returns multiple values"
Notice that's he's talking of the *syntax*, and functionally the tuple-unpacking that some languages allow do come close to being equivalent to being able to return multiple values.
handle, errcode = open('blah.dat')
This is prettier than the all-too-common functions that do things like "this function will return the count of Widgets, or -1 if something went wrong", also it's less error-prone because with the above you can't accidentally treat an error_code as valid data. (and proceed as if there where really -1 Widgets, say)
No thanks. Posted Nov 9, 2012 22:25 UTC (Fri) by HelloWorld (guest, #56129) [Link] I didn't say that tuples were useless for error handling (although sum types (aka algebraic data types) are much more useful for that), I said that they don't help solving the "result = f(g(x))" problem.
No thanks. Posted Nov 9, 2012 9:28 UTC (Fri) by renox (subscriber, #23785) [Link]
Your analysis of Joel's article seems quite shallow, I think that you are prejudiced against him and you should reread his article, his points aren't bad.
Also why do you consider returning a tuple different from returning multiple values?
No thanks. Posted Nov 9, 2012 15:49 UTC (Fri) by HelloWorld (guest, #56129) [Link] Your analysis of Joel's article seems quite shallow,Feel free to write a rebuttal. Until then, I'll consider my points valid. Also why do you consider returning a tuple different from returning multiple values?I consider them different because they are different (duh). Let's say you have a function that duplicates its argument. In Haskell using a tuple, that's dup x = (x,x)Now assume a multiply-add function: mad a b c = a*b+cHow can you combine these to write a function that returns x*x+x? In a language like Haskell you can't easily do it with for example composition, you have to do something like foo x = mad x x xotoh, PostScript actually allows you to return multiple values, and there it's trivial: /mad { mul add } def
/foo { dup dup mad } def
(dup is a builtin in PostScript)
No thanks. Posted Nov 9, 2012 16:14 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
You know you're on LWN when a language war leads to a comment extolling PostScript over Haskell...
No thanks. Posted Nov 9, 2012 21:33 UTC (Fri) by HelloWorld (guest, #56129) [Link] It was the most well-known language I could think of that actually supports returning multiple values. Lua supposedly allows it too, but it's limited. Simple things workfunction dup(x) return x, x end function add(x,y) return x, y end print(add(dup(3))) -- prints 6but more somplex examples, such as function dup(x) return x, x end function mad(x,y,z) return x*y+z end print(mad(dup(dup(3))))don't. I'm not sure it can work in a non-stack-based language.
No thanks. Posted Nov 10, 2012 0:22 UTC (Sat) by hummassa (subscriber, #307) [Link]
works perfectly in perl:
sub dup { $_[0], @_ }
No thanks. Posted Nov 10, 2012 14:09 UTC (Sat) by HelloWorld (guest, #56129) [Link]
This works because your version of dup returns excess arguments unmodified. Most perl functions don't do that, so it's not quite the same thing.
No thanks. Posted Nov 11, 2012 0:44 UTC (Sun) by hummassa (subscriber, #307) [Link]
It does that because I modelled it after the postcript/forth example. In perl, is actually quite easy to adopt this style of programming:
sub mad { my($a, $b, $c, @rest) = @_; $a*$b+$c, @rest }
So you can use @_ as the forth/postcript stack...
No thanks. Posted Nov 9, 2012 17:50 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Intimidating, but:
compose :: (Num t) => t -> t
Basically, the `const' adds a fourth (ignored) parameter to `mad' and then we uncurry that function to get it to take a tuple of tuples and then `dup . dup' the input to make `((x, x), (x, x))'. Granted, this looks nasty, but is also something that lamdabot might have been able to generate when asking for how to rewrite the obvious implementation in a point-free way.
No thanks. Posted Oct 26, 2012 16:48 UTC (Fri) by cmccabe (guest, #60281) [Link]
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().
No thanks. Posted Oct 26, 2012 19:59 UTC (Fri) by danieldk (guest, #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.
No thanks. Posted Oct 27, 2012 12:36 UTC (Sat) by epa (subscriber, #39769) [Link]
Even if Go is better, I think Stroustrup is right. It takes ten or twenty years for a language and its implementations to become mature enough for widespread use. Java, and to a lesser extent C#, have the advantage that they have been around for a while, are well understood, and have a reasonable collection of libraries. If those things aren't important, there are surely other languages which are even better than Go in theory, but lack its momentum.
No thanks. Posted Oct 27, 2012 21:54 UTC (Sat) by cmccabe (guest, #60281) [Link]
I have some good news for you then. In 3 years or so, a hot new programming language called Java will be ready for you to use! (It came out in 1995, 17 years ago.) C# is still 8 years in your future, unfortunately.
On a more serious note: no, it does take 20 years for a programming language to become mature. Go already has a good collection of libraries and is adding more all the time. It will take more time to get a good, precise, compacting GC that can go toe-to-toe with HotSpot. But not 20 years.
No thanks. Posted Oct 26, 2012 16:03 UTC (Fri) by shmerl (guest, #65921) [Link]
Rust is the future probably. But you can just use C++(11) and implement memory management cleanly. Garbage collection is often overrated.
No thanks. Posted Oct 26, 2012 19:08 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
Perl6?
Except that it's not especially mainstream, not strictly strongly typed and not entirely finished. Minor details, surely.
Since you asked Posted Oct 26, 2012 21:06 UTC (Fri) by ncm (subscriber, #165) [Link]
A "mainstream, fast strong-typed garbage-collected language"?
C++, for the present.
Not garbage-collected, you say? If what you want from a garbage-collected language is no "delete" statements, you already have that. It's entirely possible -- indeed, recommended -- to write large systems in C++ with no delete statements at all. The standard library provides all you need, starting with smart pointers. (Technically, smart-pointer implementations have delete statements, but you never need to see them.) Other libraries provide database handles, transactions, windows, and what-have-you.
If you know what you're about, you don't really want garbage-collection anyway, because it interacts badly with destructors. Without destructors, exceptions lose most of their value. The whole point of exceptions is so you don't have to hand-write exception-handling code everywhere. Besides being tedious, scattered exception-handling code, whether in catch blocks or under "if (rc)", is poorly exercised, so often buggy. It's better to collect up exceptions at subsystem boundaries with all the local cleanup already done. Destructors do that cleanup. They get exercised all the time, so you can trust them. Most of your what your destructors do, such as rolling back transactions, closing files, and freeing memory, is generated by the compiler from library code, so you never see it, and it's right every time. Memory management comes for free.
The Glorious Successor to C++, whatever it turns out to be, will also not need garbage collection.
Since you asked Posted Oct 26, 2012 21:26 UTC (Fri) by Jandar (subscriber, #85683) [Link]
If there are pointer-cycles in the data-structures you have to be *very* careful or nothing can be freed in c++. I'm a fan of c++ and think it's the best of the bunch of similar languages like java or go, but to say it's easy to write without delete and gc is unrealistic. This considered I'm rather careful and have a deterministic behavior than rely on a kind of magic behind the scene. E.g. managing resources with RAII is pleasant.
Since you asked Posted Oct 26, 2012 23:01 UTC (Fri) by ncm (subscriber, #165) [Link]
This cycle detection problem is always trotted out, but it never seems to happen in real programs. (Anyway it's never happened to me.) The corresponding problem in GC systems, of stale pointers to garbage preventing collection, is responsible for uncounted exabytes of leaked memory at any moment, and for my browser running no faster than Netscape on a 486.
The world needs a systems-programming language as powerful as C++, but without the cruft. (Cruft being the C type system, and failed experiments like exception checking and virtual functions.) It is unfortunate that current efforts at language design are almost always contaminated with CONSes. A sign of the strength of a language design is that library components do what had to be built into weaker languages. Virtual function support should be a library facility in the Glorious Successor to C++.
Since you asked Posted Oct 27, 2012 6:43 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Cycles happen all the time in any non-trivial program. In fact, a lot of non-trivial C++ programs now contain some form of cycle detection (Firefox, Chrome) or GC (gcc).
Since you asked Posted Oct 28, 2012 16:32 UTC (Sun) by nix (subscriber, #2304) [Link]
OK. I have to ask... 'contaminated with CONSes'? Presumably this isn't a reference to Lisp, so what is it?
No thanks. Posted Nov 1, 2012 16:43 UTC (Thu) by jtc (subscriber, #6246) [Link]
"Well, if you want to get rid of both Java and C#, what are you suggesting to use as a mainstream fast strong-typed garbage-collected language?"
Well, if you eliminate Java and C#, about all that's left is Eiffel.
No thanks. Posted Nov 1, 2012 19:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Ei...what? I've seen exactly one program in it. And it was a "Hello, world".
No thanks. Posted Nov 1, 2012 19:43 UTC (Thu) by bronson (subscriber, #4806) [Link]
I think that was tongue in cheek, like saying "if we don't buy any food we'll have to eat the furniture."
Eiffel ain't mainstream.
No thanks. Posted Oct 26, 2012 4:42 UTC (Fri) by eru (subscriber, #2753) [Link] From where I sit (a largish IT services company), those applications that are not implemented in Microsoft-spesific technologies tend to be in Java and related technologies. It may well be the new COBOL, but in that case it is still in its ascending phase.So if the free software community tried to ignore Java, it would cut itself out of substantial and important application areas. Consider also the world domination strategy: It is way easier to port Java-based applications to run on Linux, than to do so for applications based on C# or other MS framework-du-jour. Java was at least designed with portability in mind, even if that aspect is not as perfect as advertised.
No thanks to trolls. Posted Oct 26, 2012 5:30 UTC (Fri) by jensend (guest, #1385) [Link]
Please leave these kinds of moronic flamebait remarks at the door. You've been around LWN long enough to know better than to try to trash its signal-to-noise ratio with this kind of crap.
There's more software under Free Software compatible licenses in Java than in any other languages except C and C++. Such software, along with Java software under all kinds of other licenses, is used on the majority of Linux systems.
Just because you don't like to use it doesn't mean it has no relevance. Nor does it mean you can write off everyone who uses it (who greatly outnumber you and those with similar hostile attitudes) as corporate drones. You have no right to demand that subjects relevant to them not receive coverage from LWN. You most definitely have no right to dictate how developers spend their time and efforts.
No thanks to trolls. Posted Oct 26, 2012 6:28 UTC (Fri) by alankila (subscriber, #47141) [Link]
In a different tone, it's not like I personally have a love affair with Java, but I use it because it seems to be the best among a whole host of poor choices for the specific needs I have. I'm grateful it exists, but simultaneously a little disappointed that nobody has managed to make anything better.
No thanks to trolls. Posted Oct 26, 2012 7:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Microsoft did. C# is massively better compared to Java.
However, it's not cross-platform (yeah, I know about Mono).
No thanks to trolls. Posted Oct 26, 2012 8:22 UTC (Fri) by khim (subscriber, #9252) [Link] I think both C# and Java were giant waste of resources, but the fact remains: it's all in the past. Today there are a lot useful programs written in Java and it's much better to port OpenJDK rather then rewrite all these programs.
No thanks to trolls. Posted Oct 26, 2012 12:22 UTC (Fri) by alankila (subscriber, #47141) [Link]
As an old linux user, and current OS X user, I doubt I find C# to be quite strongly tied to the Windows environment. While things like Monodevelop exist, they have proven to be quite rough to use in practice, and the free class library documentation was also rather lacking. I haven't looked at the situation recently, but around 2 years ago the conclusion was inescapable: Mono is nowhere near ready enough.
No thanks to trolls. Posted Oct 26, 2012 16:36 UTC (Fri) by cortana (subscriber, #24596) [Link]
These days Mono is used in preference's to Microsoft's own .NET implementation by some developers who are targeting Windows (e.g., Bastion).
No thanks to trolls. Posted Oct 26, 2012 17:20 UTC (Fri) by khim (subscriber, #9252) [Link] Bastion uses Mono because it was not developed for Windows. Chrome (NaCl) and Mac ports were planned relatively early thus it made sense to use Mono. If you use recent versions of C# then it's basically impossible to use Mono.
No thanks to trolls. Posted Nov 9, 2012 3:14 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> If you use recent versions of C# then it's basically impossible to use Mono.
Yeah right, except that Mono fully implements the current C# 5.0 specification.
No thanks to trolls. Posted Nov 9, 2012 4:35 UTC (Fri) by bronson (subscriber, #4806) [Link]
Yeah, and Microsoft is known for strictly adhering to specifications.
No thanks to trolls. Posted Nov 9, 2012 15:50 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Name a place where Microsofts C# compiler deviates from the spec.
No thanks to trolls. Posted Nov 9, 2012 18:08 UTC (Fri) by bronson (subscriber, #4806) [Link]
If a standards-compliant compiler were all that mattered, Mono might have a chance.
All this has been beaten to death elsewhere so I'll leave it here.
No thanks. Posted Oct 26, 2012 20:25 UTC (Fri) by drag (subscriber, #31333) [Link]
> Why can't we let Java rot in peace? Is has no more relevance in the Free Software world than C#,
This isn't true at all.
> whatever its importance to the Android-app, corporate-drone, and web-framework markets. COBOL's public face is a model to emulate.
Might as well try to declare the same thing for Perl or C++ for all the accuracy of these statements.
I was missing one Posted Oct 26, 2012 21:20 UTC (Fri) by man_ls (subscriber, #15091) [Link] Ah, a language flamewar, we had been without one for at least a couple weeks.Actually, the worst bits of Java were corrected in Android: AWT, Swing and the stupid virtual machine with unbearable delays every few seconds. On Android Dalvik works under constrained memory resources (well, constrained for these days, but still) without noticeable delays (unless you do weird stuff) and with a nice sane graphical toolkit. There is still the annoying verbosity: Transmogrifier transmogrifier = new Transmogrifier(); transmogrifier.transmogrify();that doesn't let you forget you are in the Kingdom of Nouns. The anal retentive behavior of warnings, case in point @SuppressWarnings("unused"), which generates another warning if the variable below is actually used!, we can play this game forever. The idiotic difference between objects and primitive types. And so on and so on. But they are relatively minor annoyances compared with the above, which were showstoppers. At least Google doesn't insist on creating getters and setters for everything, or declaring all variables as final unless they are modified later on -- talk about doing compiler micro-optimizations by hand. The worst part is that companies may enforce these stupid recommendations believing they are doing themselves a favor. I wish Sun had worked on these things before. Still, for a strongly-typed language Java is not bad. Of course I will take the crazy crazy world of JavaScript any day. As to the necessity of JVMs for ARM64, they are just that: a necessity for some situations. I am very unhappy with certain branches of the Spanish administration because they require Java for signing documents; when I install IcedTea it refuses to run on 64 bit JVMs. So I have to borrow my girlfriend's Windows XP netbook for a short while, which is embarrassing. Whew, I needed to vent that, thanks for being still there. Back to on-topic: any server which doesn't have a JVM will not be considered as "serious" to large segments of customers, so it is a hard requirement. Grandparent may not like it, but enterprise customers do like Java, and that has relevance for Free Software.
I was missing one Posted Oct 26, 2012 22:31 UTC (Fri) by ncm (subscriber, #165) [Link]
I guess you could say Java still has relevance for non-free uses of Free Software. But if its main value is for non-free uses, it seems as if those users ought to arrange to pay for maintaining and porting it. That won't happen without somebody experiencing pain first, so maybe it would be better to wait for some.
On the other hand, I'm betting that when the first AArgh64 chips come out, if the code doesn't run right, the chips will be considered wrong, and they'll change the spec to match the code. That seems about equally likely to be good as bad. Probably the people doing the code generator should get in touch with any malcontents from the Aargh64 design team and see which of its choices ought to be overturned that way.
I do like that in the Dalvik execution model, your program must be prepared to be killed off at any moment, and to then jump up, Inspector Clouseau style, if anybody happens to look.
I was missing one Posted Oct 27, 2012 10:45 UTC (Sat) by man_ls (subscriber, #15091) [Link] IME Java is mostly relevant for in-house development, which is neither here nor there -- it cannot be considered "non-free" since it is not published, only run internally. Even the FSF allows to run GPL code internally without publishing source code.I suppose that, if the JVM implementors have half a brain, they will just publish a preliminary version of the code pending a real processor; the JVM should get updated then and everyone will be happy. If that is not the case, well, you cannot blame the Java language for that.
I was missing one Posted Nov 9, 2012 3:08 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> it cannot be considered "non-free" since it is not published, only run internally
Being free software has nothing to do with being published. A program is free software if its users have permission to run, copy, distribute, study, change and improve the software. That is probably not the case for internal-use applications, so they're not free software.
I was missing one Posted Nov 9, 2012 11:13 UTC (Fri) by hummassa (subscriber, #307) [Link]
When a software is run internally in an enterprise (especially if it is run for the enterprise's purposes), its user is the enterprise, not each individual users... the enterprise can modify it, but it does not have the obligation to send the source code to each employee, and it can put rules in place to prevent that.
I was missing one Posted Nov 9, 2012 22:20 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> When a software is run internally in an enterprise (especially if it is run for the enterprise's purposes), its user is the enterprise, not each individual user
Sorry, but that doesn't make any sense to me.
I was missing one Posted Oct 30, 2012 18:31 UTC (Tue) by gnu_andrew (subscriber, #49515) [Link]
"when I install IcedTea it refuses to run on 64 bit JVMs" - I take it you mean the applet won't work on a 64-bit JVM, whether that's the IcedTea-Web one or the proprietary one? I've seen that with a video-conferencing application too and sadly, there's not much that can be done if the applet writers are going to rely on 32-bit native libraries only.
I was missing one Posted Oct 30, 2012 21:17 UTC (Tue) by man_ls (subscriber, #15091) [Link] Exactly, the applet refuses to run on a 64-bit JVM. I don't even know how it can be -- native libraries to sign a document?
I was missing one Posted Oct 30, 2012 21:37 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
lots of commercial java applets include 32bit-only libraries. Those libraries aren't loaded by the 64 bit JVM, so the applet fails due to missing libraries.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 4:37 UTC (Fri) by imgx64 (guest, #78590) [Link]
I didn't even know ARM64 exists. What devices in the market are ARM64?
Googling around netted lots of press releases and Linux patches but no devices.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 5:09 UTC (Fri) by butlerm (subscriber, #13312) [Link]
Devices on the market? None. There apparently aren't even any prototypes yet. These guys are using an emulator to do initial development with:
>"Rather than waiting for real hardware we decided to write a simple CPU simulator, which we're using for development testing. We're pretty confident that it models the architecture as described, but there will inevitably be some gotchas that we discover when we run on real hardware for the first time."
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 5:28 UTC (Fri) by aryonoco (subscriber, #55563) [Link]
There are none. And it's actually technically called AArch64 (though I'm certainly glad that people are just referring to it as ARM64).
No devices on the market yet but ARM Holdings just finished its design late last year and is now working with fabs (TSMC, GlobalFoundaries, etc) on its production. Expect first devices to be servers from the likes of Calxeda in 2014. Consumer devices should show up sometime in 2015.
It's actually an extremely interesting design and much more of a clean break than AMD64 is compared to x86/IA32. In a way I think it's the last of the original RISC architectures to have gone 64-bit, but perhaps the only one that might be available in a few years time (I'm really not sure how much longer POWER and Sparc are gonna be around...)
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 6:28 UTC (Fri) by imgx64 (guest, #78590) [Link]
> It's actually an extremely interesting design and much more of a clean break than AMD64 is compared to x86/IA32.
That's a bit worrying. I hope it doesn't end up as a second Itanium.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 8:42 UTC (Fri) by khim (subscriber, #9252) [Link] Itanic was doomed from the onset not because it had radically different 64-bit mode, but because it's 32-bit mode sucked (and still sucks: original one was so bad it was eventually just removed and emulation is still slow as hell). From what I'm seeing ARM does not plan to repeat that mistake.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 9:12 UTC (Fri) by arnd (subscriber, #8866) [Link]
I work on ARM stuff, so you can call me biased, but I certainly don't expect it to end up that way. Itanium's fault wasn't that it diverged from the older 32 bit architecture, but that it did a lot of extravagant things that had not been tried before in mainstream computing and that turned out to be a bad design choice in hindsight.
64-bit ARM is by comparison the most boring architecture you can imagine, it takes the 32 bit design, and replaces most of the oddities of that architecture with more common ideas from other RISC designs. Nothing to see here really, and that's how we like it!
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 9:55 UTC (Fri) by nhippi (subscriber, #34640) [Link]
few differences:
1) During Itanium time, people still had lots of binary-only proprietary server applications, thus binary compatibility was much more needed. These days most server apps are in some kind of interpreted languages (java, php, python, ...). Also, many people will porting to Arm64 from mips, ppc, x86, etc, so break between a32 and a64 is not relevant to them.
2) While lack of proper backward compatibility was one reason of Itaniums demise, the other was just pure business failure. Itanium was just too expensive, Opteron and Xeon offered much better bang for buck. The whole idea was "Let's make people replace expensive UNIX RISC servers with expensive Itanium servers running UNIX". Customers were more like "Umm no thanks, let's rather replace them with cheap x86_64 servers running Linux". A lot will depend on what bang/buck and bang/watt a64 offers compared to competitors.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 23:21 UTC (Fri) by aryonoco (subscriber, #55563) [Link]
A few things to note:
1) Though AArch64/ARM64 is not backwards compatible with AArch32, the chips that will be produced will themselves be running ARMv8, which does support running both Aarch32 and AArch64 code (without emulation or anything like that). They will run both codes just fine next to each other. This PDF from ARM is a good overview of ARMv8 http://goo.gl/2u8X2
2) Since people seem to be interested in ARM64 and what path its designers have taken, I highly recommend having a look at http://www.realworldtech.com/arm64/ The conclusion says: "Like x86, ARMv7 had a fair bit of cruft, and the architects took care to remove many of the byzantine aspects of the instruction set that were difficult to implement. The peculiar interrupt modes and banked registers are mostly gone. Predication and implicit shift operations have been dramatically curtailed. The load/store multiple instructions have also been eliminated, replaced with load/store pair. Collectively, these changes make AArch64 potentially more efficient than ARMv7 and easier to implement in modern process technology. "
3) As for Itanium, let's not forget that Itanium is a $4 billion business that's also highly profitable. Sure $4 billion might be peanuts for Intel and it certainly didn't live to the (very) high expectations that the industry had of it in late 90s, but many businesses would be perfectly happy with a $4 billion, profitable "side business".
Power and energy Posted Oct 27, 2012 11:13 UTC (Sat) by man_ls (subscriber, #15091) [Link] A lot will depend on what bang/buck and bang/watt a64 offers compared to competitors.Also, the bang/watt·hour: while the power (watts) requirements may be the same, a processor may consume less while idle and thus eat up less energy (watts·hour) overall. Given their history, it would not be surprising if this was the sweet spot for ARM64: you don't need to run all processors at close to 100% all the time to save energy. I am thinking about a service like Amazon EC2 which needs to have a reservoir of idle machines to handle traffic spikes (to be really elastic) and will have to eat up their energy costs while idle. Energy costs are nowadays the highest cost of running a server. Given that reserved instances may be half the price of on-demand instances, and that spot instances may be something like 5 times cheaper, I suppose that Amazon would be grateful to reduce costs. I can't wait to rent an AMD64 instance actually!
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 8:29 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> And it's actually technically called AArch64
And I keep reading it as "AArgh64".
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 28, 2012 17:01 UTC (Sun) by nix (subscriber, #2304) [Link]
AArch64 actually gives me a lift whenever I see it, because I read the Arch not as the sterile-as-hell 'Architecture' but as a callback to ARM's youth, Acorn: "Archimedes'. And those were lovely machines.
(Sure, it isn't, but we can pretend it is.)
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 11:26 UTC (Fri) by juliank (subscriber, #45896) [Link]
Don't forget MIPS!
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 21:32 UTC (Fri) by ncm (subscriber, #165) [Link]
MIPS is an interesting case. MIPS has had a 64-bit design for a long time, and it's not bad, mostly. Unfortunately, its memory model suffers from the same problems as the Alpha: you can't count on anything happening in order, as seen from another processor, so you can't program a MIPS SMP without somebody else making guarantees beyond the architecture spec. x86 has the opposite problem: it promises so much that a 16-way x86 might spend most of its time waiting at barriers for memory state to settle, just in case. The Power64 and Itanic designs hit workable (but different) compromises. We can only hope the AArgh64 architects took advantage of hindsight, because without it maybe only Power64 has MP legs.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 23:26 UTC (Fri) by aryonoco (subscriber, #55563) [Link]
Ah! MIPS, yes I did forget that. Though I wonder if that's my fault, or a reflection of MIPS completely disappearing from the radar (other than in a few niche markets).
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 26, 2012 19:20 UTC (Fri) by butlerm (subscriber, #13312) [Link]
> And it's actually technically called AArch64
Marketing fail.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 27, 2012 0:48 UTC (Sat) by cesarb (subscriber, #6266) [Link]
ARM is as bad at that as Sun. The ARM11, which is an ARMv6, is older than the A5, which is an ARMv7. If you compile something for ARMv7 or later, it will not run on an ARM11. And do not confuse ARMv7 with ARM7 - the later is an ARMv3, or later an ARMv4 or ARMv5.
The ARMv7 family has the A5, A7, A8, A9, and A15. Let's hope it does not get near A32, else things will get even more confusing.
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 31, 2012 2:02 UTC (Wed) by wookey (subscriber, #5501) [Link]
Debian and Ubuntu are calling the arch 'arm64'. The upstream GNU triplet remains 'aarch64-linux-gnu'.
If you really care there is a doc somewhere carefully distinguishing the names of the architecture, 64-bit instruction set, 32-bit instruction set, etc. But I reckon most people without marketing droids standing behind them will just call it arm64 (or armv8).
I've been having fun with bootstrapping: http://wiki.debian.org/Arm64Port
You can install a quantal amd64 chroot with cross toolchain and start building stuff.
Linaro have OE image builds that can be run on ARM's free-beer 'Fast' Model (which is not at all fast) http://www.linaro.org/engineering/armv8
Haley: We're doing an ARM64 OpenJDK port! Posted Oct 27, 2012 1:28 UTC (Sat) by jcm (subscriber, #18262) [Link]
I'm with Arnd on the implementation. I like "boring". The thing I love about ARMv8 is that it is exactly as boring as you need in a modern architecture. They learned a lot from history, from extensive profiling, from being very smart about low power all the way through. I've made ARMv8 something of an obsession for the last 18 months, right down to memorizing instruction encodings for fun. Having Java on v8 is key for it to be successful. Like Java or not, it is a key requirement for servers, and that problem will be addressed.
|
|||||||||||||