3 ms·

Oh, I don't deny that value types would have helped performance back in '95, just that they were absolutely essential for Java. Smalltalk/Self and Scheme/CL did

by pron 7y ago

Oh, I don't deny that value types would have helped performance back in '95, just that they were absolutely essential for Java. Smalltalk/Self and Scheme/CL didn't have them, and those were probably Java's greatest influences; I don't think VB had them, either. Also, in its first four years, before HotSpot was ready, Java was interpreted, so it had bigger performance problems. I don't know why there was no emphasis on AOT back then. I guess they started with interpreter/JIT, and then there just wasn't much demand for AOT until now.

pjmlp 7y ago
Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in Java Embedded variant for OEMs, probably grudgingly. Common Lisp certainly has support for value types.
- pron 7y ago
  What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.
  - pjmlp 7y ago
    Arrays, structs, fixnums, explicit stack allocation. I can check the respective manuals if you wish. Yep, I did VB programming for a short while. And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems. As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then. So it kind of stayed as a pet peeve of mine. Same applies to .NET, just in a different way.
    - pron 7y ago
      Well, we can disagree about when AOT and value types became critical for Java (and I would argue that they clearly weren't back then because Java has done spectacularly without them), but Java is getting both soon.
      - pjmlp 7y ago
        I would say that it had other factors that contributed to its sucess, so it succeeded in spite of lacking those features. However due to the hardware architecture changes and new kids on the block, it is starting to be an issue. I keep wishing to see them arrive, have watched all the JVM Language Summit, Devoxx and JavaONE talks about them. Meanwhile I can already enjoy them elsewhere. :(
        pron 7y ago
        > Meanwhile I can already enjoy them elsewhere. :( That's perfectly fine. We think that our priorities are right for the workloads Java is used for (e.g. people care more about a low-latency GC like ZGC, and deep low-overhead in-production profiling, like JFR, than about AOT).

by pron 7y ago

pjmlp 7y ago

Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in Java Embedded variant for OEMs, probably grudgingly. Common Lisp certainly has support for value types.

pron 7y ago
What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.
- pjmlp 7y ago
  Arrays, structs, fixnums, explicit stack allocation. I can check the respective manuals if you wish. Yep, I did VB programming for a short while. And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems. As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then. So it kind of stayed as a pet peeve of mine. Same applies to .NET, just in a different way.
  - pron 7y ago
    Well, we can disagree about when AOT and value types became critical for Java (and I would argue that they clearly weren't back then because Java has done spectacularly without them), but Java is getting both soon.
    - pjmlp 7y ago
      I would say that it had other factors that contributed to its sucess, so it succeeded in spite of lacking those features. However due to the hardware architecture changes and new kids on the block, it is starting to be an issue. I keep wishing to see them arrive, have watched all the JVM Language Summit, Devoxx and JavaONE talks about them. Meanwhile I can already enjoy them elsewhere. :(
      - pron 7y ago
        > Meanwhile I can already enjoy them elsewhere. :( That's perfectly fine. We think that our priorities are right for the workloads Java is used for (e.g. people care more about a low-latency GC like ZGC, and deep low-overhead in-production profiling, like JFR, than about AOT).