no more primitive data types in Java (JDK 10+). What do you think?

Discussion in 'Java' started by Nasser M. Abbasi, Apr 20, 2012.

  1. According to

    "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"

    (Google the string "To Java SE 8 and Beyond!" and click on
    the PDF file, about the 5th link down the page)

    On page 42, it says:

    "Unified type system (JDK 10+)
    No more primitives, make everything objects"

    I've seen very little discussion on this very important
    subject.

    What do the experts here think of the idea?

    For me, and I am no expert, I think it will be good to have
    a consistent type model (everything is an object), but I am
    worried that the performance will take a hit (computational finite
    elements methods, large meshes, etc...), unless PC's and computers
    will become 1000 times faster by the time JDK 10+ comes in few years
    from now, which might be possible.

    Any one knows more information about this item?
    Any truth to it? Do you think it will really happen?

    --Nasser
     
    Nasser M. Abbasi, Apr 20, 2012
    #1
    1. Advertising

  2. Nasser M. Abbasi

    Arne Vajhøj Guest

    On 4/19/2012 7:27 PM, Nasser M. Abbasi wrote:
    > According to
    >
    > "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >
    > (Google the string "To Java SE 8 and Beyond!" and click on
    > the PDF file, about the 5th link down the page)
    >
    > On page 42, it says:
    >
    > "Unified type system (JDK 10+)
    > No more primitives, make everything objects"
    >
    > I've seen very little discussion on this very important
    > subject.
    >
    > What do the experts here think of the idea?
    >
    > For me, and I am no expert, I think it will be good to have
    > a consistent type model (everything is an object), but I am
    > worried that the performance will take a hit (computational finite
    > elements methods, large meshes, etc...), unless PC's and computers
    > will become 1000 times faster by the time JDK 10+ comes in few years
    > from now, which might be possible.
    >
    > Any one knows more information about this item?
    > Any truth to it? Do you think it will really happen?


    C# has it that way. No performance problem. It should
    certainly be possible to implement.

    (note: everything object does not imply everything
    a reference type)

    I don't know if it will actually happen.

    And I don't think the practical impact will be big
    if it does happen (neither performance nor the way Java code
    is written).

    Arne
     
    Arne Vajhøj, Apr 20, 2012
    #2
    1. Advertising

  3. Nasser M. Abbasi

    Lew Guest

    Arne Vajhøj wrote:
    > Nasser M. Abbasi wrote:
    >> According to
    >>
    >> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >>
    >> (Google the string "To Java SE 8 and Beyond!" and click on
    >> the PDF file, about the 5th link down the page)
    >>
    >> On page 42, it says:
    >>
    >> "Unified type system (JDK 10+)
    >> No more primitives, make everything objects"
    >>
    >> I've seen very little discussion on this very important
    >> subject.
    >>
    >> What do the experts here think of the idea?
    >>
    >> For me, and I am no expert, I think it will be good to have
    >> a consistent type model (everything is an object), but I am
    >> worried that the performance will take a hit (computational finite
    >> elements methods, large meshes, etc...), unless PC's and computers
    >> will become 1000 times faster by the time JDK 10+ comes in few years
    >> from now, which might be possible.
    >>
    >> Any one knows more information about this item?
    >> Any truth to it? Do you think it will really happen?

    >
    > C# has it that way. No performance problem. It should
    > certainly be possible to implement.
    >
    > (note: everything object does not imply everything
    > a reference type)


    And reference type doesn't inherently imply a performance hit. Java's Hotspot famously enregisters and stack-allocates objects under the hood when it deems it felicitous.

    > I don't know if it will actually happen.
    >
    > And I don't think the practical impact will be big
    > if it does happen (neither performance nor the way Java code
    > is written).


    And it is quite likely that computers will be enough faster, if not 1000 times so, before Java 10 comes out. How much longer for even Java 8, and how long was it between 6 and 7? Java usually has had about two years between versions, meaning that Java 10 might be out in 2017. The very paradigm for computing might render the notion of "primitives" irrelevant by then. Even assuming current computing models, Moore's Law hints that we might see an eightfold increase in computer power by then.

    There is a movement in the Java community for value objects, as opposed to references, in support of Arne's point.

    There's also the point that source distinctions might look different in bytecode or machine code. What we might think of as an 'int' object at the source level might be treated as an ordinary machine integer at the lower level.

    --
    Lew
     
    Lew, Apr 20, 2012
    #3
  4. On 12-04-19 08:27 PM, Nasser M. Abbasi wrote:
    > According to
    >
    > "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >
    > (Google the string "To Java SE 8 and Beyond!" and click on
    > the PDF file, about the 5th link down the page)
    >
    > On page 42, it says:
    >
    > "Unified type system (JDK 10+)
    > No more primitives, make everything objects"
    >
    > I've seen very little discussion on this very important
    > subject.
    >
    > What do the experts here think of the idea?
    >
    > For me, and I am no expert, I think it will be good to have
    > a consistent type model (everything is an object), but I am
    > worried that the performance will take a hit (computational finite
    > elements methods, large meshes, etc...), unless PC's and computers
    > will become 1000 times faster by the time JDK 10+ comes in few years
    > from now, which might be possible.
    >
    > Any one knows more information about this item?
    > Any truth to it? Do you think it will really happen?
    >
    > --Nasser


    I think the main idea is a good one. I'd like everything to be an object.

    I trust that the language experts can work out the details of optimizing
    arrays of objects. I wouldn't restrict it merely to arrays of
    single-primitive-value-holder (SPVO) type of objects, but also arrays of
    objects that would provably reduce to being composites of such SPVO
    objects (this could be recursive); anything in other words where a
    sizeof() type of operation would be the same for every object in an array.

    I'm not so sure that I'd want to see an actual struct versus reference
    distinction as we have in C#. I'd like to think that the objects of a
    given class could be situationally value or reference types, not always
    be one or the other. Again, it might boil down to the compiler checking
    the array type to see if it can be so optimized.

    All literals would now be objects, so there'd be common sense syntax
    changes there. In terms of my hypothetical scheme there'd also be
    questions related to mutable types.

    In the final analysis, if the language people can't work out something
    acceptable then they are not trying very hard. This is the teens of the
    21st century after all.

    On a related note I'd like to see some thought put into null. If we go
    over to all objects, I'd like to see that uninitialized variables of a
    "value" type get the sensible default, not null. So

    Integer ints[] = new Integer[10];

    would be 10 objects of a value type Integer(0).

    AHS
    --
    A fly was very close to being called a "land," cause that's what they do
    half the time.
    -- Mitch Hedberg
     
    Arved Sandstrom, Apr 20, 2012
    #4
  5. On 4/19/2012 6:27 PM, Nasser M. Abbasi wrote:
    > According to
    >
    > "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >
    > (Google the string "To Java SE 8 and Beyond!" and click on
    > the PDF file, about the 5th link down the page)
    >
    > On page 42, it says:
    >
    > "Unified type system (JDK 10+)
    > No more primitives, make everything objects"
    >
    > I've seen very little discussion on this very important
    > subject.


    First off, this is listed as an idea (explicitly differentiated from the
    earlier bullet points which were presented more as "we really want this
    to get in").

    > What do the experts here think of the idea?
    >
    > For me, and I am no expert, I think it will be good to have
    > a consistent type model (everything is an object), but I am
    > worried that the performance will take a hit (computational finite
    > elements methods, large meshes, etc...), unless PC's and computers
    > will become 1000 times faster by the time JDK 10+ comes in few years
    > from now, which might be possible.


    The Java language was designed when JIT technology was still moderately
    weak. Thanks in large part to Java, the performance of JITs has
    drastically improved over the last two decades, while the onset of
    JavaScript as a major performance target for JITs has also focused some
    of the research into improving performance in those cases. Note that
    JavaScript doesn't distinguish between integers and floating points (all
    arithmetic in JS is 100% double!), not to mention the problems related
    to weak and dynamic typing. This means that the performance assumptions
    of what would be slow aren't necessarily the case.

    A lot of it depends on how the "removal" of primitive types work,
    especially considering the need for backwards compatibility in Java. If
    they decide to make minimal changes to the VM spec (which, given
    history, has been the case), then it may just be compiler sugar for
    certain operations. Then again, the slides also indicate a more forceful
    modification to the Java type system.

    The change, in short, strikes me much more of a "let int be treated as a
    subclass of Object." Theorizing possible implementation strategies, it's
    extremely feasible [1] to let the cost of this change in terms of
    performance be limited entirely to where int is actually used as an
    Object--i.e., where it would need to be boxed/unboxed. Given that the
    JVM is already capable of optimizing away boxing/unboxing even now, I
    suspect that the cost would be even lower than that. In other words,
    it's a feature you won't pay for unless you use it.

    [1] Basic implementation idea: make a shell class (i.e., the internal
    int.class object) otherwise unobservable that inherits from Object.
    Whenever you "convert" int -> Object, wrap it in that shell class. It's
    fairly simple to implement--I ended up doing something similar in an
    undergrad compilers course.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Apr 20, 2012
    #5
  6. On 4/19/2012 8:45 PM, Peter Duniho wrote:
    > On Thu, 19 Apr 2012 20:02:12 -0400, Arne Vajhøj wrote:
    >> On 4/19/2012 7:27 PM, Nasser M. Abbasi wrote:
    >>> According to
    >>>
    >>> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >>>
    >>> (Google the string "To Java SE 8 and Beyond!" and click on
    >>> the PDF file, about the 5th link down the page)

    >
    > WTF? If you downloaded the doc yourself (and so obviously must have the
    > link), just provide the damn link here.
    >
    > (And no, I was unable to track down the PDF using either Google or Bing...I
    > did try for a few minutes to follow your ridiculous instructions, to no
    > avail).


    http://qconlondon.com/dl/qcon-londo...r_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf

    >>> On page 42, it says:
    >>>
    >>> "Unified type system (JDK 10+)
    >>> No more primitives, make everything objects"
    >>>
    >>> I've seen very little discussion on this very important
    >>> subject.
    >>>
    >>> What do the experts here think of the idea?

    >
    > It depends on what they mean by "no more primitives, make everything
    > objects".
    >
    >> [...]
    >>> Any one knows more information about this item?
    >>> Any truth to it? Do you think it will really happen?

    >>
    >> C# has it that way. No performance problem. It should
    >> certainly be possible to implement.

    >
    > I haven't seen the context, so I don't know if they elaborate or not.
    > Certainly the statement quoted does not provide enough detail to know
    > whether they mean a C#-style design or not.
    >
    > Note that while C# (actually, .NET...the same type system is shared by all
    > the .NET languages) unifies the types through a common base System.Object
    > type, that's not the same as having a completely unified type system.
    > Value types are still fundamentally different from reference types, and
    > there are most certainly real differences between primitive types in .NET
    > (which do exist in spite of the unified type system) and user-defined value
    > types, as well of course between all value types primitive or otherwise and
    > reference types.
    >
    > If the original reference simply means introducing something like what .NET
    > has, then I'd agree it shouldn't cause any sort of performance problem, nor
    > should be all that disruptive to the Java community itself.
    >
    > But if the original reference means going further than that, where every
    > single type is fundamentally the same, where there are genuinely no types
    > that can be considered "primitive" (i.e. handled in ways by the compiler
    > that are special to those types and unavailable to user-defined types),
    > then doing that without sacrificing some performance could in fact be
    > harder or even impossible.


    Let me copy a bit more from page 42:

    <quote>
    * Unified type system (JDK 10+)
    * No more primitives, make everything objects
    * Other type reification (JDK 10+)
    * True generics
    * Function types
    * Data structure optimizations (JDK 10+)
    * Structs, multi-dimensional arrays, etc
    </quote>

    It sounds as if it could be relative close to the C# way.

    Arne
     
    Arne Vajhøj, Apr 20, 2012
    #6
  7. Nasser M. Abbasi

    Arne Vajhøj Guest

    On 4/19/2012 8:35 PM, Arved Sandstrom wrote:
    > On 12-04-19 08:27 PM, Nasser M. Abbasi wrote:
    >> According to
    >>
    >> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >>
    >> (Google the string "To Java SE 8 and Beyond!" and click on
    >> the PDF file, about the 5th link down the page)
    >>
    >> On page 42, it says:
    >>
    >> "Unified type system (JDK 10+)
    >> No more primitives, make everything objects"
    >>
    >> I've seen very little discussion on this very important
    >> subject.
    >>
    >> What do the experts here think of the idea?
    >>
    >> For me, and I am no expert, I think it will be good to have
    >> a consistent type model (everything is an object), but I am
    >> worried that the performance will take a hit (computational finite
    >> elements methods, large meshes, etc...), unless PC's and computers
    >> will become 1000 times faster by the time JDK 10+ comes in few years
    >> from now, which might be possible.
    >>
    >> Any one knows more information about this item?
    >> Any truth to it? Do you think it will really happen?

    >
    > I think the main idea is a good one. I'd like everything to be an object.


    It is obviously a good idea.

    I just don't think it will be that important.

    > I'm not so sure that I'd want to see an actual struct versus reference
    > distinction as we have in C#. I'd like to think that the objects of a
    > given class could be situationally value or reference types, not always
    > be one or the other. Again, it might boil down to the compiler checking
    > the array type to see if it can be so optimized.


    They do mention the term "struct", so ...

    > All literals would now be objects, so there'd be common sense syntax
    > changes there. In terms of my hypothetical scheme there'd also be
    > questions related to mutable types.
    >
    > In the final analysis, if the language people can't work out something
    > acceptable then they are not trying very hard. This is the teens of the
    > 21st century after all.
    >
    > On a related note I'd like to see some thought put into null. If we go
    > over to all objects, I'd like to see that uninitialized variables of a
    > "value" type get the sensible default, not null. So
    >
    > Integer ints[] = new Integer[10];
    >
    > would be 10 objects of a value type Integer(0).


    I would expect "backwards compatibility" to be a concept
    frequently mentioned in the design discussions.

    :)

    Arne
     
    Arne Vajhøj, Apr 20, 2012
    #7
  8. On 4/19/2012 7:45 PM, Peter Duniho wrote:
    > On Thu, 19 Apr 2012 20:02:12 -0400, Arne Vajhøj wrote:
    >
    >> On 4/19/2012 7:27 PM, Nasser M. Abbasi wrote:
    >>> According to
    >>>
    >>> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
    >>>
    >>> (Google the string "To Java SE 8 and Beyond!" and click on
    >>> the PDF file, about the 5th link down the page)

    >
    > WTF? If you downloaded the doc yourself (and so obviously must have the
    > link), just provide the damn link here.
    >


    Hello Peter,

    The reason I did not put the link, is because Google has some way of
    making some links so very long (it seems to encode them somehow?),
    so that the link was very long. If I have put the link I was
    using at the time, people here would have screamed at me, and the link
    would also have broken anyway, since my Thunderbird news reader that I use
    does not allow more than 132 long lines.

    Here is the link I was looking at

    http://www.google.com/url?sa=t&rct=j&q="to java se 8 and
    beyond!%22%20&source=web&cd=5&ved=0CEQQFjAE&url=http%3A%2F%2
    Fqconlondon.com%2Fdl%2Fqcon-london
    2012%2Fslides%2FSimonRitter_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf
    &ei=K8WQT43LI9Octweh-ZnqBA&usg=AFQjCNF8M1Xi7sGluyZu-lMDVQksqqm1sg&cad=rja

    Googling a string is just as easy. I am not sure where you could
    not find it. Here is a screen shot when I Google the string, and
    you can see the PDF file is right there, the 5th link as I said

    http://12000.org/tmp/april_19_2012/screen_shot.png

    Sorry for any trouble that my instructions have caused you,
    but I hope you understand more now why.

    --Nasser
     
    Nasser M. Abbasi, Apr 20, 2012
    #8
  9. Nasser M. Abbasi

    Lew Guest

    Arved Sandstrom wrote:
    > This is the teens of the 21st century after all.


    Quibble: Not until next year.

    --
    Lew
     
    Lew, Apr 20, 2012
    #9
  10. On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
    >
    > On page 42, it says:
    >
    > "Unified type system (JDK 10+)
    > No more primitives, make everything objects"
    >
    > I've seen very little discussion on this very important
    > subject.
    >
    > What do the experts here think of the idea?


    It's impossible. Whatever they mean when they say "remove primitives"
    cannot possibly be what those words actually mean. Just think, how would
    it be possible to state a = a + 1 without the number 1? Ok, so you can
    use .add(Integer x). But how precisely do you call it? .add(1)? There's
    still a 1. And what's worse is if numbers act like objects, which
    introduces it's own dangerous problem. Is the number 5 really 5, or is
    it something else? Treating primitives like objects, without them
    actually being objects, is UN-neccessary and confusing.

    5.length() or 5.size()? Well if 5 is an object I should be able to
    over-ride it.

    Class 6 Extends 14 {}

    Is that what they mean, or do they mean they will just treat numbers
    /like/ objects? I guess I need more information. In the absence of a
    good reason, I don't believe such a change will ever actually make it
    into Java.
     
    Tsukino Usagi, Apr 20, 2012
    #10
  11. Nasser M. Abbasi

    Stefan Ram Guest

    Tsukino Usagi <> writes:
    >Is that what they mean, or do they mean they will just treat numbers
    >/like/ objects? I guess I need more information. In the absence of a
    >good reason, I don't believe such a change will ever actually make it
    >into Java.


    I suggest, you might learn some Smalltalk or at least Ruby.
     
    Stefan Ram, Apr 20, 2012
    #11
  12. On 12-04-20 03:27 AM, Tsukino Usagi wrote:
    > On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
    >>
    >> On page 42, it says:
    >>
    >> "Unified type system (JDK 10+)
    >> No more primitives, make everything objects"
    >>
    >> I've seen very little discussion on this very important
    >> subject.
    >>
    >> What do the experts here think of the idea?

    >
    > It's impossible. Whatever they mean when they say "remove primitives"
    > cannot possibly be what those words actually mean. Just think, how would
    > it be possible to state a = a + 1 without the number 1? Ok, so you can
    > use .add(Integer x). But how precisely do you call it? .add(1)? There's
    > still a 1. And what's worse is if numbers act like objects, which
    > introduces it's own dangerous problem. Is the number 5 really 5, or is
    > it something else? Treating primitives like objects, without them
    > actually being objects, is UN-neccessary and confusing.
    >
    > 5.length() or 5.size()? Well if 5 is an object I should be able to
    > over-ride it.
    >
    > Class 6 Extends 14 {}
    >
    > Is that what they mean, or do they mean they will just treat numbers
    > /like/ objects? I guess I need more information. In the absence of a
    > good reason, I don't believe such a change will ever actually make it
    > into Java.


    However they do things there will be problems and concerns. What you
    talk about is not likely to be one of them. In a system where all things
    are objects, numeric literals are objects: they are syntactic sugar.

    a = 2;

    really means

    a = new Integer(2);

    and

    a = a + 1;

    means that a is some Number and you're adding Integer(1) to it. Who
    cares that underneath the hood the compiler translates that to (int)13 +
    (int)1?

    Just because you've got literals doesn't mean that you need primitives.

    As for instance calls on a literal, you and I already do that with
    String literals. E.g. "some string".length().

    I think you can see that in your example '5' is an instance; Java is
    class-oriented for inheritance/extension, not object-oriented, so you
    won't be extending an instance. But yes, we'd expect that you could do
    5.someMethod(), for instance methods that make sense.

    AHS
    --
    A fly was very close to being called a "land," cause that's what they do
    half the time.
    -- Mitch Hedberg
     
    Arved Sandstrom, Apr 20, 2012
    #12
  13. Nasser M. Abbasi

    Roedy Green Guest

    On Thu, 19 Apr 2012 18:27:43 -0500, "Nasser M. Abbasi" <>
    wrote, quoted or indirectly quoted someone who said :

    > "Unified type system (JDK 10+)
    > No more primitives, make everything objects"


    This is the way Eiffel works, but under the covers there are still
    primitives. Perhaps what they have in mind for Java, more intelligent
    boxing. At least at the low levels of the JVM you need primitives.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
     
    Roedy Green, Apr 20, 2012
    #13
  14. On 4/20/2012 3:36 PM, Stefan Ram wrote:
    > Tsukino Usagi<> writes:
    >> Is that what they mean, or do they mean they will just treat numbers
    >> /like/ objects? I guess I need more information. In the absence of a
    >> good reason, I don't believe such a change will ever actually make it
    >> into Java.

    >
    > I suggest, you might learn some Smalltalk or at least Ruby.
    >


    I can see myself learning smalltalk for the bragging rights, but there's
    no need to bring ruby into this. Ruby has serious problems and I don't
    understand why they don't just fix them.
     
    Tsukino Usagi, Apr 20, 2012
    #14
  15. On 4/20/2012 7:04 PM, Arved Sandstrom wrote:
    > On 12-04-20 03:27 AM, Tsukino Usagi wrote:
    >> On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
    >>>
    >>> On page 42, it says:
    >>>
    >>> "Unified type system (JDK 10+)
    >>> No more primitives, make everything objects"
    >>>
    >>> I've seen very little discussion on this very important
    >>> subject.
    >>>
    >>> What do the experts here think of the idea?

    >>
    >> It's impossible. Whatever they mean when they say "remove primitives"
    >> cannot possibly be what those words actually mean. Just think, how would
    >> it be possible to state a = a + 1 without the number 1? Ok, so you can
    >> use .add(Integer x). But how precisely do you call it? .add(1)? There's
    >> still a 1. And what's worse is if numbers act like objects, which
    >> introduces it's own dangerous problem. Is the number 5 really 5, or is
    >> it something else? Treating primitives like objects, without them
    >> actually being objects, is UN-neccessary and confusing.
    >>
    >> 5.length() or 5.size()? Well if 5 is an object I should be able to
    >> over-ride it.
    >>
    >> Class 6 Extends 14 {}
    >>
    >> Is that what they mean, or do they mean they will just treat numbers
    >> /like/ objects? I guess I need more information. In the absence of a
    >> good reason, I don't believe such a change will ever actually make it
    >> into Java.

    >
    > However they do things there will be problems and concerns. What you
    > talk about is not likely to be one of them. In a system where all things
    > are objects, numeric literals are objects: they are syntactic sugar.
    >
    > a = 2;
    >
    > really means
    >
    > a = new Integer(2);
    >
    > and
    >
    > a = a + 1;
    >
    > means that a is some Number and you're adding Integer(1) to it. Who
    > cares that underneath the hood the compiler translates that to (int)13 +
    > (int)1?
    >
    > Just because you've got literals doesn't mean that you need primitives.
    >
    > As for instance calls on a literal, you and I already do that with
    > String literals. E.g. "some string".length().
    >
    > I think you can see that in your example '5' is an instance; Java is
    > class-oriented for inheritance/extension, not object-oriented, so you
    > won't be extending an instance. But yes, we'd expect that you could do
    > 5.someMethod(), for instance methods that make sense.
    >
    > AHS


    I get what your saying, my point was exactly that requiring Integer(1)
    is ridiculous. If your going to type "1", type "1" and be done with it.
     
    Tsukino Usagi, Apr 20, 2012
    #15
  16. On 04/20/2012 02:31 AM, Lew wrote:

    > There's also the point that source distinctions might look different in bytecode or machine code. What we might think of as an 'int' object at the source level might be treated as an ordinary machine integer at the lower level.


    As an additional data point: Ruby MRI works like that. Basically
    integers (instances of class Fixnum) look like ordinary objects but
    under the hood the value is encoded in the reference and there is no
    object on the heap. You get a nice consistent model for the language
    user but avoid the overhead of GC. Ruby is still not a racing car
    compared with other PL - usual trade offs apply. The concept is
    described here:
    http://en.wikipedia.org/wiki/Tagged_pointer

    It could require a signicifant (nice typo, sounds like an animal) change
    in the JVM definition though.

    Kind regards

    robert
     
    Robert Klemme, Apr 20, 2012
    #16
  17. On 04/20/2012 03:16 PM, Tsukino Usagi wrote:
    > On 4/20/2012 3:36 PM, Stefan Ram wrote:
    >> Tsukino Usagi<> writes:
    >>> Is that what they mean, or do they mean they will just treat numbers
    >>> /like/ objects? I guess I need more information. In the absence of a
    >>> good reason, I don't believe such a change will ever actually make it
    >>> into Java.

    >>
    >> I suggest, you might learn some Smalltalk or at least Ruby.
    >>

    >
    > I can see myself learning smalltalk for the bragging rights, but there's
    > no need to bring ruby into this. Ruby has serious problems and I don't
    > understand why they don't just fix them.


    I don't know what "serious problems" you are talking about and this is
    probably not the place to discuss them either. But Stefan's hint was a
    good one in this context because MRI has a clean object model for the
    user with not too bad performance for primitive numbers. (see ref to
    Wikipedia article elsewhere in this thread)

    Kind regards

    robert
     
    Robert Klemme, Apr 20, 2012
    #17
  18. Nasser M. Abbasi

    Stefan Ram Guest

    Tsukino Usagi <> writes:
    >>a = new Integer(2);

    >I get what your saying, my point was exactly that requiring Integer(1)


    It's »Integer.valueOf( 1 )«, not »new Integer( 1 )« and
    surely not »Integer( 1 )«.

    Arithmetics and similar actions on integer objects can
    and probably will be optimized to use effectively the same
    processor operations as on primitive values whenever possible.
     
    Stefan Ram, Apr 20, 2012
    #18
  19. On 04/20/2012 03:17 PM, Tsukino Usagi wrote:
    > On 4/20/2012 7:04 PM, Arved Sandstrom wrote:
    >> On 12-04-20 03:27 AM, Tsukino Usagi wrote:
    >>> On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
    >>>>
    >>>> On page 42, it says:
    >>>>
    >>>> "Unified type system (JDK 10+)
    >>>> No more primitives, make everything objects"
    >>>>
    >>>> I've seen very little discussion on this very important
    >>>> subject.
    >>>>
    >>>> What do the experts here think of the idea?
    >>>
    >>> It's impossible. Whatever they mean when they say "remove primitives"
    >>> cannot possibly be what those words actually mean. Just think, how would
    >>> it be possible to state a = a + 1 without the number 1? Ok, so you can
    >>> use .add(Integer x). But how precisely do you call it? .add(1)? There's
    >>> still a 1. And what's worse is if numbers act like objects, which
    >>> introduces it's own dangerous problem. Is the number 5 really 5, or is
    >>> it something else? Treating primitives like objects, without them
    >>> actually being objects, is UN-neccessary and confusing.
    >>>
    >>> 5.length() or 5.size()? Well if 5 is an object I should be able to
    >>> over-ride it.
    >>>
    >>> Class 6 Extends 14 {}
    >>>
    >>> Is that what they mean, or do they mean they will just treat numbers
    >>> /like/ objects? I guess I need more information. In the absence of a
    >>> good reason, I don't believe such a change will ever actually make it
    >>> into Java.

    >>
    >> However they do things there will be problems and concerns. What you
    >> talk about is not likely to be one of them. In a system where all things
    >> are objects, numeric literals are objects: they are syntactic sugar.
    >>
    >> a = 2;
    >>
    >> really means
    >>
    >> a = new Integer(2);


    Rather

    a = Interer.valueOf(2)

    as it is done already today with autoboxing. But yes, the literal can
    be translated to anything.

    >> and
    >>
    >> a = a + 1;
    >>
    >> means that a is some Number and you're adding Integer(1) to it. Who
    >> cares that underneath the hood the compiler translates that to (int)13 +
    >> (int)1?
    >>
    >> Just because you've got literals doesn't mean that you need primitives.
    >>
    >> As for instance calls on a literal, you and I already do that with
    >> String literals. E.g. "some string".length().
    >>
    >> I think you can see that in your example '5' is an instance; Java is
    >> class-oriented for inheritance/extension, not object-oriented, so you
    >> won't be extending an instance. But yes, we'd expect that you could do
    >> 5.someMethod(), for instance methods that make sense.
    >>
    >> AHS

    >
    > I get what your saying, my point was exactly that requiring Integer(1)
    > is ridiculous. If your going to type "1", type "1" and be done with it.


    I am sorry, but that statement proves that you did not get the point.

    Cheers

    robert
     
    Robert Klemme, Apr 20, 2012
    #19
  20. Nasser M. Abbasi

    BGB Guest

    On 4/19/2012 11:15 PM, Peter Duniho wrote:
    > On Thu, 19 Apr 2012 19:22:33 -0700 (PDT), Lew wrote:
    >
    >> Arved Sandstrom wrote:
    >>> This is the teens of the 21st century after all.

    >>
    >> Quibble: Not until next year.

    >
    > Yeah, but you have to take into account the kind of people who insisted
    > that the new millennium started on Jan 1, 2000. :) The concept of "teens"
    > may be more, um...flexible to some people than to others.
    >
    > (For the record, I'm with you, but I hardly ever try to explain this sort
    > of mistake to people who make them any more :) )


    I think for many, "teens" starts at 10 (rather than 13), so 2010-2019
    would be the "teens" of the new millennium.

    nevermind, many people apparently believe that the world will end in a
    few months from now.


    as for the topic:
    I just kind of find it funny, I express some annoyances with the JVM:
    lack of value types, awkward FFI, ...
    people then make a fuss about it, counter-arguing (unnecessary, wouldn't
    help, ...).

    Oracle then goes stating plans to go work on it.

    even more funny would be if they added extensions for pointers and RAII
    and similar, but this seems less likely.


    it was not stated what sort of FFI design Oracle is considering.


    in my own VM/language, I did like this (a boilerplate-free FFI), and
    used an HLL-level interface for importing roughly like:

    native import C.stdio; //import C's "stdio.h"

    actually, it doesn't directly import the header (the actual mechanism is
    more convoluted, as it aliases the header-name to a target-specific
    library-name, and imports the library instead, and the contents of the
    "headers" are aliases to a DB keyed with the same name as the library).

    (say, "C.stdio" maps to "msvcrt.dll", and loads the "msvcrt_meta" DB).

    the "C." prefix basically indicates the intended target language (of
    which, C is the currently only supported option).


    exporting works more like:
    native package C.foo
    {
    struct SomeStruct
    {
    ...
    }

    ...

    function somefunc(x:int):void //takes int, returns void
    {
    ...
    }

    //takes C-string, returns struct pointer
    function somefunc(str:cstring):*SomeStruct
    {
    ...
    }

    ...
    }

    with anything declared within the package being exported to C land, and
    expected to conform to C-friendly rules (the language also has pointers,
    for sake of easing C interfacing, which have a syntax like "x:*void;").
    pardon the strange syntax.

    the mechanism in this case currently involves using a tool which spits
    out headers and C-based glue-code though (which are then compiled and
    linked with native code), as I do not yet know of a clearly better
    option here (C lacks late-binding...).


    a Java analogue could be, say:
    public native class Foo
    {
    ...
    public static void somefunc(int x)
    {
    ...
    }
    }

    with any static methods within the class being exported as native C or
    C++ functions or similar.

    maybe also doing direct cross-language class-to-class mappings, like in
    GCJ (where class-members can be identity-mapped across the language
    boundary).


    or such...
     
    BGB, Apr 20, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jesper Sahner
    Replies:
    13
    Views:
    654
    Alberto
    Nov 16, 2004
  2. Replies:
    7
    Views:
    628
    Victor Bazarov
    May 9, 2005
  3. howa
    Replies:
    17
    Views:
    607
    ~kurt
    Jul 1, 2007
  4. Daniel Pitts
    Replies:
    7
    Views:
    521
  5. David Mark
    Replies:
    17
    Views:
    269
    David Mark
    Mar 23, 2010
Loading...

Share This Page