81–90 of 138 posts
Earlier quoted context omitted.
Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?
Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html
Earlier quoted context omitted.
Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html
"You are wasting an outlandish amount of money writing code that already exists." On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.
At this point oracle can't rewrite Java. If they don't support the current programs, nobody would use it, if they do, they will really be rewriting code that already exists.
Earlier quoted context omitted.
Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap. A parallel can be drawn with C++ in which the user of a class decides on declaration/initialization where to store the object (either on the stack, or on the heap). The difference with C++ is that in C# the author of the class decides where instances of it should be stored, so this decision happens when the class is declar…
> Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap. You have it backwards, they're not value types because they're allocated on the stack, structs are allocated on the stack because they're value types. See Eric Lippert's article "The Stack is an Implementation Detail": http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-s...
Also Eric Lippert nails it when he answers the question of why reference types are not stack allocated and value types are ... “because they can”.
I do agree with the article, but with all due respect to Eric Lippert, C#/.NET was meant to be reasonably fast for all kinds of user-land applications and if structs weren't added, then they had to add special cases (primitives) for dealing with integer and floating point arithmetic, just as Java did.
I do agree that structs have semantic value, but the implementation itself allows the available primitives to be described in terms of structs, which is a really elegant and cost-effective solution to a problem that the JVM engineers are trying to solve with complicated tricks like escape analysis. If you remove the performance/efficiency benefit, there isn't a lot of value left in structs - at least nothing that can't be solved by immutable data-structures and/or a better type system.
Nice article btw, thanks.
Earlier quoted context omitted.
The "boxed primitive" types (Integer and so on) should be `final`. This means no inheriting from them, which means no polymorphism, which means their sizes and all operations on them are known statically. This means you can store them as values in the object with no fuss, and you can inline all of their access functions.
Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.
I do not know whether the standard currently allows for code that is guaranteed to produce Double's with equal values that are not object.Equal to each other, but I doubt that making that impossible will introduce many problems.
Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.
> Wow, how can you seriously plan releases of a programming language out to 2021? "A plan is useless, but planning is essential" [1] More true than ever, if you ask me. Sure, you make plans, why wouldn't you? But you also retain the flexibility to adapt the plan as the environment changes. You don't chisel the damn plan into a stack of stone tablets and render it immutable for all time. I don't see any conflict whats…
The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.
Freud somewhere talks about a primitive tribe where the punishment for saying "The king is not an ass" is the same as for saying "The king is an ass". Edit: I remember reading this years ago and have been unable to track it down. Would love it if somebody did.
It seems to me that eliminating primitives could be a really bad idea. If you have a class: public class CompoundObject { int i; int j; double k; } This class's data members are all a few bytes away from each other, so once the object is loaded into the CPU cache, all operations should be fast. With boxed types, you might get 3 cache misses when accessing i,j,k. On the other hand, referential transparency can help he…
For example Dylan language doesn't have primitives as such. The d2c compiler passes objects around as a two-element struct containing a type tag and a value (in practice values get passed around in a pair of registers). Now, if you have a field with the declaration , and you store a in there, then the field will consist of two words: a type tag and the double itself. However, if the field is declared as a , then the field will be stored as just the double, and the field accessor code will add the (constant) type tag as the field is read.
It seems to me that eliminating primitives could be a really bad idea. If you have a class: public class CompoundObject { int i; int j; double k; } This class's data members are all a few bytes away from each other, so once the object is loaded into the CPU cache, all operations should be fast. With boxed types, you might get 3 cache misses when accessing i,j,k. On the other hand, referential transparency can help he…
Such a thing could be done in Java if Oracle added structs. They're basically just "unboxed objects". I believe there's more to it than that, but that's the basic idea.
Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.
Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?
Earlier quoted context omitted.
Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?
Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html
Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself.
Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.