23 ms·

Java 9 with GPU processing, Java 10 will be all-OOP without primitives

194 points by Mitt 15y ago

bromagosa 15y ago
All-OOP? So functions will be objects too? And classes? And contexts? Not meaning to start a flame, just saying the title's a bit inaccurate IMHO...
- c4n4rd 15y ago
  This is a very good point. If functions become objects, interfaces would become literally useless. Somehow it seems that it would not be the case since this would be a drastic change (even thought getting rid of primitives are as well.)
  - CodeMage 15y ago
    Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?
    - yummyfajitas 15y ago
      I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a ]
      - CodeMage 15y ago
        I'm genuinely curious: is this because Haskell is generally hard to learn[] or because of some inherent property of Haskell that makes type classes unnecessary when you have first class functions? [] This statement is based purely on my own experience. I find the Haskell documentation a bit unfriendly with its "academic" style. The content is great, but the form makes it a bit hard to assimilate. Monads were especially painful.
      - xyzzyz 15y ago
        Once Haskell introduced first class functions, everyone stopped using typeclasses. What do you mean? From what I've seen, everyone uses typeclasses in Haskell.
      - calpaterson 15y ago
        I don't think typeclasses were in from day one, they were added quite late in the development of the language (but some years before H98). I don't think they're in Miranda, for example. Here's a paper introducing them. http://dl.acm.org/citation.cfm?id=227700 http://dl.acm.org/citation.cfm?id=227700
        yummyfajitas 15y ago
        I stand corrected. I guess Haskell before H98 was a very different language than it is today.
        SamReidHughes 15y ago
        Type classes were in Haskell 1.0. See http://webcache.googleusercontent.com/search?q=cache:rtFsiQCtqxYJ:www.haskell.org/definition/haskell-report-1.0.ps.gz+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:rtFsiQC...
    - hythloday 15y ago
      Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"): void init() { void mouseClick(MouseEvent e) { println(e); } mouse.setClickListener(mouseClick); } given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller. This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?
      - eropple 15y ago
        I bounce between Java and C#. I'm not sure at all what he's talking about. I use interfaces all the time in C#. I even specify delegate properties (as distinct from events, when I don't want them to be multicast) in interfaces. I think both concepts are probably independent of one another.
      - bermanoid 15y ago
        First class functions pretty much have no bearing on whether or not interfaces are useful. Sure, one use case for inner classes is to implement interfaces in-place in situations where what you really want to do is just pass a function, and in those cases it's probably better to use a function instead, but the equivalence doesn't go the other way. There are plenty of cases where you really need to pass an object to a function and know that the object supports multiple operations, for instance take a look at Map<K,V>: http://docs.oracle.com/javase/6/docs/api/java/util/Map.html http://docs.oracle.com/javase/6/docs/api/java/util/Map.html There are 14 methods there, and when I write code that takes a Map object, I really mean it - I'm not just using the interface as a hack because I want a function pointer, I need an object that supports all of those methods, and I'm probably going to be using several of them.
  - cynicalkane 15y ago
    Clojure has both function objects and interfaces (called 'protocols'). In fact, it encourages the use of interfaces while strongly discouraging the traditional object inheritance model. Most people who've tried it AFIAK consider Clojure a well-designed language.
    - jemeshsu 15y ago
      Clojure, Golang, Scala and Rust all implement similar interface.
  - Roboprog 15y ago
    While I agree that I hate interfaces with one method, what about interfaces that actually define several methods (e.g. - perhaps a driver for something that needs to do operations like "open", "close", "get", "put")? Interfaces still serve a purpose bundling together related operations with replaceable implementations. They're just a nuisance for single-purpose functions/functors (e.g. - "run").
- kirinan 15y ago
  I think similar to C# where the primitives are objects is what they want, terribly misleading title I agree. However, I cringe when I think of what this does to performance. The memory overhead of objects in java is pretty high (relative) while primitives are very memory efficient. If they can make the primitives just as efficient, it would be awesome, but I guess its a wait and see. I don't currently mind using the static classes on the object representation of the primitives to do things.
  - chrisb 15y ago
    In C# primitives are not objects, but they can be boxed into objects. So if you have a class: public class X { public Int32 i; public Int32 j; public Int32 k; } Then it takes 12 bytes + single object overhead (which in MS .NET I believe is two pointers). But if you assign a primitive (e.g. Int32) to an variable of type 'object' then it will be boxed and then require the object overhead. A neat thing about C#/.NET is that generics are baked deeply into the platform, so using primitive (actually, any value-type struct) types as generic arguments will not require object memory or casting overheads.
    - bad_user 15y ago
      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 declared, not when it's used. Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL). In my experience, all discussions about what is or isn't an object are counter-productive. What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.
- CodeMage 15y ago
  Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the way Ruby blocks work (i.e. block is not an object).
  - rukkyg 15y ago
    Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?
    - eternalban 15y ago
      No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.
      - riffraff 15y ago
        would you care to explain why this is not enough? You can pass them around, invoke them, get their properties. The interface may be bad but I'm not sure what is missing.
        eternalban 15y ago
        In the original comment, I was merely addressing the misunderstanding of the GP regarding the reflection packages constructs. The interface is your basic (irreducible) disconnected/unbound procedure invocation API, with all the positive/warts associated. I agree that in principle, we have enough information in the reflection data structure to allow a (specific) JVM implementation to provide a non-standard 'method object' feature. Consensus, possibly? (Good question, really. C. Nutter is one to hit with that one.)
  - EdiX 15y ago
    I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.
JunkDNA 15y ago
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.
- CodeMage 15y ago
  Maybe I'm too cynical, but I don't think you can seriously plan releases so far in future. What you can do is delude yourself (which happens all the time at big bureaucracies) or make it look like you're planning seriously in order to appear responsible and visionary.
  - lapusta 15y ago
    It pretty much depends on industry. Look at mobile, 2007: J2ME, Symbian, Windows Mobile, BlackBerry -> 2012: iOS, Android, Windows Phone. Now look at the web: it was more of a evolution than revolution. What happened at back-end, like server-side functionality of business apps? They didn't really change and probably won't change for a longer period of time. Even stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM. It's hard to say what devices we'll have in 5 years, or what internet would look like, but i'm pretty sure servers would run good old Java.
    - ajross 15y ago
      Even on the "evolutionary" web, I don't think anyone in 2007 would have predicted the rise (and now... fall?) of MVC frameworks or the explosion of jQuery, both of which existed and were relatively popular at the time. Likewise the NoSQL rebellion was a surprise. Five years from now, we'll all be using WebGL-based dyanmic UIs. Or will we? I think the point is more that 5+ year planning in the tech industry is simply pointless, not that all technologies will be replaced. Sure, there are some constants. We can all safely predict that in five years we'll still be writing drivers and middleware in C, still be using zlib and libjpeg, etc...
      - 15y ago
yummyfajitas 15y ago
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 here. Given referential transparency, the compiler can transparently unbox Integers and translate method calls. So if Oracle does it right, rather than slowing down unboxed code, this might just speed up boxed code.
- cynicalkane 15y ago
  They don't say how they're implementing it. Given the compiler always knows the actual type of a primitive at compile-time, they can probably implement most of the Object functionality by plugging in the class meta-info at compile-time. When a primitive would need to be boxed, Java programmers are already used to the performance implications of this. The only object functionality I can think of that would be hard to implement on primitives is wait/notify/synchronization, but I don't actually know how those are done in the JVM either. Even if these things turn out to be impossible to optimize at compile time, they're probably then betting on JIT functionality to detect primitive objects that are only used as primitives.
  - repsilat 15y ago
    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.
    - cynicalkane 15y ago
      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.
jt2190 15y ago
Marta Jasinska posted her notes: http://kreskasnotes.blogspot.com/2012/03/qcon-2012-future-of-java-platform-java.html http://kreskasnotes.blogspot.com/2012/03/qcon-2012-future-of... These slides were posted last November, so they're probably a bit stale, but might give some insights: http://www.slideshare.net/JAX_London/keynote-to-java-se-8-and-beyond-simon-ritter http://www.slideshare.net/JAX_London/keynote-to-java-se-8-an...
floppydisk 15y ago
I'm curious how they're going to handle the GPU thing since there really isn't a unified GPU architecture, yet (by 2015, who knows but still). Have vendor specific translations or try to rally around something like OpenCL? I'd love it if GPU coding would become more available and vendor agnostic, so I'm really curious about this. I know the article didn't mention it, I also wonder what the memory bloat will look like when they turn all primitives into Objects and introduce object overhead just to track int i in a for loop.
codedivine 15y ago
Anyone have a link to the actual slides from Oracle?
- woky 15y ago
  Not sure, but maybe this: http://qconlondon.com/dl/qcon-london-2012/slides/SimonRitter_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf http://qconlondon.com/dl/qcon-london-2012/slides/SimonRitter... I hate those articles not mentioning sources.
nyellin 15y ago
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.
- ShardPhoenix 15y ago
  On the other hand, not acknowledging what everyone is saying can make you look out of touch.
- meepmorp 15y ago
  It somewhat surprises me that they'd not want Java to become the new COBOL. COBOL is still alive, still runs large systems, and still sells hardware and software. Owning the new COBOL has the potential to be quite lucrative in the long term.
  - kamaal 15y ago
    I don't think so, Although I agree with you that COBOL is still alive and kicking. That is totally different that being used for awesome projects and by start ups. If Oracle's plan is to keep Java alive as a glue for their DB that strategy would work fine. But it would be a long term disaster in terms of overall innovation, and long term viability for choosing everyday projects.
    - nknight 15y ago
      It's never occurred to me to think of Oracle as being a company concerned with any of those things. It seems totally outside their character, everything they do screams "huge, established customers only".
      - mgkimsal 15y ago
        The current crop of smaller companies and bootstrappers will evolve in to the next generation's "established" companies. No one is starting a company today with COBOL. How many are starting today with Java? Not rhetorical - I know some are - just wondering how this will play out over time...
elbac 15y ago
I'd really like to see some of the deprecated parts of the JDK removed.
- deleted 15y ago
  [deleted]
dkarl 15y ago
Video and slides of the same presentation by the same presenter in October 2011: http://lanyrd.com/2011/jax-london-autumn/sgzyx/ http://lanyrd.com/2011/jax-london-autumn/sgzyx/ It's mind-blowing that they plan on having GPU and FPGA support before they offer arrays of structs and multidimensional arrays. Frustrating, too. I guess I can't complain, since clearly somebody is paying for all this, and it isn't me.
michaelhoffman 15y ago
At first I thought this might be an early April Fool's Day joke. But I don't think it is.
friendlytuna 15y ago
More discussion from Java vets: http://java.dzone.com/articles/oracle-discusses-features-java http://java.dzone.com/articles/oracle-discusses-features-jav...
andersh 15y ago
I'm assuming 'everything is an object' will be done by copying C#. i.e. value-types, autoboxing.
nivertech 15y ago
April 1st in two days, but I guess some people can't wait ;)
zanny 15y ago
I just want passable functions, or even better, first class functions in module namespace. I still find it hilarious how even Swing shows how crippled the language is without that feature, where adding event listeners is complicated like new EventListener(Event e) { @override onEvent... etc. When just overriding some declared event handler method would be so much clearer.
shareme 15y ago
I think I will switch to Google Go
6ren 15y ago
They can plan like this because they are the new cobol - they have an assured install base. If they make 100% back-compatible, and definitely better, everyone will upgrade. As for the very vague improvements mentioned (GPU, no primitives), these can be seen in response to clear technology trends. Even the embedded GPUs in x86 are getting pretty powerful, though not every business has them - but by 2015 most will. Java has primitives primarily for performance and memory efficiency. Absolutely crucial at Java's inception, they though remain important today, many applications can get away without them (e.g. ruby apps). By 2017. even more apps will be in that category. Most of the others are similarly responses to clear trends, such as hypervisor-aware and large data support. However, true generics seems problematic because it would break back-compatibility. My prediction: if they plan to break back-compatibility they will change their mind.

194 points by Mitt 15y ago

All-OOP? So functions will be objects too? And classes? And contexts? Not meaning to start a flame, just saying the title's a bit inaccurate IMHO...

c4n4rd 15y ago
This is a very good point. If functions become objects, interfaces would become literally useless. Somehow it seems that it would not be the case since this would be a drastic change (even thought getting rid of primitives are as well.)
- CodeMage 15y ago
  Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?
  - yummyfajitas 15y ago
    I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a ]
    - CodeMage 15y ago
      I'm genuinely curious: is this because Haskell is generally hard to learn[] or because of some inherent property of Haskell that makes type classes unnecessary when you have first class functions? [] This statement is based purely on my own experience. I find the Haskell documentation a bit unfriendly with its "academic" style. The content is great, but the form makes it a bit hard to assimilate. Monads were especially painful.
    - xyzzyz 15y ago
      Once Haskell introduced first class functions, everyone stopped using typeclasses. What do you mean? From what I've seen, everyone uses typeclasses in Haskell.
    - calpaterson 15y ago
      I don't think typeclasses were in from day one, they were added quite late in the development of the language (but some years before H98). I don't think they're in Miranda, for example. Here's a paper introducing them. http://dl.acm.org/citation.cfm?id=227700 http://dl.acm.org/citation.cfm?id=227700
      - yummyfajitas 15y ago
        I stand corrected. I guess Haskell before H98 was a very different language than it is today.
      - SamReidHughes 15y ago
        Type classes were in Haskell 1.0. See http://webcache.googleusercontent.com/search?q=cache:rtFsiQCtqxYJ:www.haskell.org/definition/haskell-report-1.0.ps.gz+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:rtFsiQC...
  - hythloday 15y ago
    Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"): void init() { void mouseClick(MouseEvent e) { println(e); } mouse.setClickListener(mouseClick); } given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller. This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?
    - eropple 15y ago
      I bounce between Java and C#. I'm not sure at all what he's talking about. I use interfaces all the time in C#. I even specify delegate properties (as distinct from events, when I don't want them to be multicast) in interfaces. I think both concepts are probably independent of one another.
    - bermanoid 15y ago
      First class functions pretty much have no bearing on whether or not interfaces are useful. Sure, one use case for inner classes is to implement interfaces in-place in situations where what you really want to do is just pass a function, and in those cases it's probably better to use a function instead, but the equivalence doesn't go the other way. There are plenty of cases where you really need to pass an object to a function and know that the object supports multiple operations, for instance take a look at Map<K,V>: http://docs.oracle.com/javase/6/docs/api/java/util/Map.html http://docs.oracle.com/javase/6/docs/api/java/util/Map.html There are 14 methods there, and when I write code that takes a Map object, I really mean it - I'm not just using the interface as a hack because I want a function pointer, I need an object that supports all of those methods, and I'm probably going to be using several of them.
- cynicalkane 15y ago
  Clojure has both function objects and interfaces (called 'protocols'). In fact, it encourages the use of interfaces while strongly discouraging the traditional object inheritance model. Most people who've tried it AFIAK consider Clojure a well-designed language.
  - jemeshsu 15y ago
    Clojure, Golang, Scala and Rust all implement similar interface.
- Roboprog 15y ago
  While I agree that I hate interfaces with one method, what about interfaces that actually define several methods (e.g. - perhaps a driver for something that needs to do operations like "open", "close", "get", "put")? Interfaces still serve a purpose bundling together related operations with replaceable implementations. They're just a nuisance for single-purpose functions/functors (e.g. - "run").
kirinan 15y ago
I think similar to C# where the primitives are objects is what they want, terribly misleading title I agree. However, I cringe when I think of what this does to performance. The memory overhead of objects in java is pretty high (relative) while primitives are very memory efficient. If they can make the primitives just as efficient, it would be awesome, but I guess its a wait and see. I don't currently mind using the static classes on the object representation of the primitives to do things.
- chrisb 15y ago
  In C# primitives are not objects, but they can be boxed into objects. So if you have a class: public class X { public Int32 i; public Int32 j; public Int32 k; } Then it takes 12 bytes + single object overhead (which in MS .NET I believe is two pointers). But if you assign a primitive (e.g. Int32) to an variable of type 'object' then it will be boxed and then require the object overhead. A neat thing about C#/.NET is that generics are baked deeply into the platform, so using primitive (actually, any value-type struct) types as generic arguments will not require object memory or casting overheads.
  - bad_user 15y ago
    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 declared, not when it's used. Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL). In my experience, all discussions about what is or isn't an object are counter-productive. What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.
CodeMage 15y ago
Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the way Ruby blocks work (i.e. block is not an object).
- rukkyg 15y ago
  Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?
  - eternalban 15y ago
    No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.
    - riffraff 15y ago
      would you care to explain why this is not enough? You can pass them around, invoke them, get their properties. The interface may be bad but I'm not sure what is missing.
      - eternalban 15y ago
        In the original comment, I was merely addressing the misunderstanding of the GP regarding the reflection packages constructs. The interface is your basic (irreducible) disconnected/unbound procedure invocation API, with all the positive/warts associated. I agree that in principle, we have enough information in the reflection data structure to allow a (specific) JVM implementation to provide a non-standard 'method object' feature. Consensus, possibly? (Good question, really. C. Nutter is one to hit with that one.)
- EdiX 15y ago
  I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.

JunkDNA 15y ago

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.

CodeMage 15y ago
Maybe I'm too cynical, but I don't think you can seriously plan releases so far in future. What you can do is delude yourself (which happens all the time at big bureaucracies) or make it look like you're planning seriously in order to appear responsible and visionary.
- lapusta 15y ago
  It pretty much depends on industry. Look at mobile, 2007: J2ME, Symbian, Windows Mobile, BlackBerry -> 2012: iOS, Android, Windows Phone. Now look at the web: it was more of a evolution than revolution. What happened at back-end, like server-side functionality of business apps? They didn't really change and probably won't change for a longer period of time. Even stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM. It's hard to say what devices we'll have in 5 years, or what internet would look like, but i'm pretty sure servers would run good old Java.
  - ajross 15y ago
    Even on the "evolutionary" web, I don't think anyone in 2007 would have predicted the rise (and now... fall?) of MVC frameworks or the explosion of jQuery, both of which existed and were relatively popular at the time. Likewise the NoSQL rebellion was a surprise. Five years from now, we'll all be using WebGL-based dyanmic UIs. Or will we? I think the point is more that 5+ year planning in the tech industry is simply pointless, not that all technologies will be replaced. Sure, there are some constants. We can all safely predict that in five years we'll still be writing drivers and middleware in C, still be using zlib and libjpeg, etc...
    - 15y ago

yummyfajitas 15y ago

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 here. Given referential transparency, the compiler can transparently unbox Integers and translate method calls. So if Oracle does it right, rather than slowing down unboxed code, this might just speed up boxed code.

cynicalkane 15y ago
They don't say how they're implementing it. Given the compiler always knows the actual type of a primitive at compile-time, they can probably implement most of the Object functionality by plugging in the class meta-info at compile-time. When a primitive would need to be boxed, Java programmers are already used to the performance implications of this. The only object functionality I can think of that would be hard to implement on primitives is wait/notify/synchronization, but I don't actually know how those are done in the JVM either. Even if these things turn out to be impossible to optimize at compile time, they're probably then betting on JIT functionality to detect primitive objects that are only used as primitives.
- repsilat 15y ago
  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.
  - cynicalkane 15y ago
    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.

jt2190 15y ago

Marta Jasinska posted her notes: http://kreskasnotes.blogspot.com/2012/03/qcon-2012-future-of-java-platform-java.html http://kreskasnotes.blogspot.com/2012/03/qcon-2012-future-of... These slides were posted last November, so they're probably a bit stale, but might give some insights: http://www.slideshare.net/JAX_London/keynote-to-java-se-8-and-beyond-simon-ritter http://www.slideshare.net/JAX_London/keynote-to-java-se-8-an...

floppydisk 15y ago

I'm curious how they're going to handle the GPU thing since there really isn't a unified GPU architecture, yet (by 2015, who knows but still). Have vendor specific translations or try to rally around something like OpenCL? I'd love it if GPU coding would become more available and vendor agnostic, so I'm really curious about this. I know the article didn't mention it, I also wonder what the memory bloat will look like when they turn all primitives into Objects and introduce object overhead just to track int i in a for loop.

codedivine 15y ago

Anyone have a link to the actual slides from Oracle?

woky 15y ago
Not sure, but maybe this: http://qconlondon.com/dl/qcon-london-2012/slides/SimonRitter_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf http://qconlondon.com/dl/qcon-london-2012/slides/SimonRitter... I hate those articles not mentioning sources.

nyellin 15y ago

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.

ShardPhoenix 15y ago
On the other hand, not acknowledging what everyone is saying can make you look out of touch.
meepmorp 15y ago
It somewhat surprises me that they'd not want Java to become the new COBOL. COBOL is still alive, still runs large systems, and still sells hardware and software. Owning the new COBOL has the potential to be quite lucrative in the long term.
- kamaal 15y ago
  I don't think so, Although I agree with you that COBOL is still alive and kicking. That is totally different that being used for awesome projects and by start ups. If Oracle's plan is to keep Java alive as a glue for their DB that strategy would work fine. But it would be a long term disaster in terms of overall innovation, and long term viability for choosing everyday projects.
  - nknight 15y ago
    It's never occurred to me to think of Oracle as being a company concerned with any of those things. It seems totally outside their character, everything they do screams "huge, established customers only".
    - mgkimsal 15y ago
      The current crop of smaller companies and bootstrappers will evolve in to the next generation's "established" companies. No one is starting a company today with COBOL. How many are starting today with Java? Not rhetorical - I know some are - just wondering how this will play out over time...

elbac 15y ago

I'd really like to see some of the deprecated parts of the JDK removed.

deleted 15y ago
[deleted]

dkarl 15y ago

Video and slides of the same presentation by the same presenter in October 2011: http://lanyrd.com/2011/jax-london-autumn/sgzyx/ http://lanyrd.com/2011/jax-london-autumn/sgzyx/ It's mind-blowing that they plan on having GPU and FPGA support before they offer arrays of structs and multidimensional arrays. Frustrating, too. I guess I can't complain, since clearly somebody is paying for all this, and it isn't me.

michaelhoffman 15y ago

At first I thought this might be an early April Fool's Day joke. But I don't think it is.

friendlytuna 15y ago

More discussion from Java vets: http://java.dzone.com/articles/oracle-discusses-features-java http://java.dzone.com/articles/oracle-discusses-features-jav...

andersh 15y ago

I'm assuming 'everything is an object' will be done by copying C#. i.e. value-types, autoboxing.

nivertech 15y ago

April 1st in two days, but I guess some people can't wait ;)

zanny 15y ago

I just want passable functions, or even better, first class functions in module namespace. I still find it hilarious how even Swing shows how crippled the language is without that feature, where adding event listeners is complicated like new EventListener(Event e) { @override onEvent... etc. When just overriding some declared event handler method would be so much clearer.

shareme 15y ago

I think I will switch to Google Go

6ren 15y ago

They can plan like this because they are the new cobol - they have an assured install base. If they make 100% back-compatible, and definitely better, everyone will upgrade. As for the very vague improvements mentioned (GPU, no primitives), these can be seen in response to clear technology trends. Even the embedded GPUs in x86 are getting pretty powerful, though not every business has them - but by 2015 most will. Java has primitives primarily for performance and memory efficiency. Absolutely crucial at Java's inception, they though remain important today, many applications can get away without them (e.g. ruby apps). By 2017. even more apps will be in that category. Most of the others are similarly responses to clear trends, such as hypervisor-aware and large data support. However, true generics seems problematic because it would break back-compatibility. My prediction: if they plan to break back-compatibility they will change their mind.