Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (806)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6 ... 8
  ignore  |  Print  
  Interesting proposals: Java 9 and beyond  (Read 105521 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Reply #90 - Posted 2015-12-04 20:51:40 »

Early prototype of JVM support for arbitrary machine code loading and execution.
Offline Icecore
« Reply #91 - Posted 2015-12-05 00:25:47 »

Very exciting )

IMHO: but examples code quality makes me cry Sad
http://hg.openjdk.java.net/panama/panama/jdk/file/091cdacf28e5/test/panama/snippets/CPUID.java
http://pastebin.java-gaming.org/af8c110923c11
pss.. it's not only in examples such code

With such code quality Java Doomed https://www.youtube.com/watch?v=fqcn_TPu4qQ

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline theagentd
« Reply #92 - Posted 2015-12-05 09:35:30 »

Can I have a TL;DR of this? What are the potential gains of this?

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 798



« Reply #93 - Posted 2015-12-05 10:26:32 »

Can I have a TL;DR of this? What are the potential gains of this?
Faster JOML matrix operations -> higher FPS in WSW Cheesy
Offline theagentd
« Reply #94 - Posted 2015-12-05 10:31:34 »

>higher FPS in WSW

If this is not in the Java 9 change log I will be disappointed.  Tongue

Myomyomyo.
Offline Spasi
« Reply #95 - Posted 2015-12-05 10:50:22 »

Can I have a TL;DR of this? What are the potential gains of this?

The main benefit is that you don't need JVM intrinsics anymore. Anything that required an intrinsic before can now be done by anyone. It works with raw machine code, so you have access to everything the hardware provides, for example vector instructions or the x86 PAUSE instruction for spin loops. Single instructions are not a problem (the worst-case for JNI).

If this is not in the Java 9 change log I will be disappointed.  Tongue

Project Panama won't make it to Java 9, even with the delayed schedule.
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #96 - Posted 2016-03-16 08:13:19 »

I know this topic is quite a bit older but it might still be interesting to somebody. Just gave a talk about the after-unsafe area and in-flight proposals. Obviously lots of information share the same base as the original post on infoq, anyhow the slidedeck has some more details in certain parts and will be updated more frequently when new proposals come around: http://de.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world

PS: What's your opinion on JEP 286? http://openjdk.java.net/jeps/286 Did you vote already, if not please do, last day: https://www.surveymonkey.com/r/KGPTHCG

Offline Roquen

JGO Kernel


Medals: 518



« Reply #97 - Posted 2016-03-16 09:25:13 »

My thoughts are:  Just yesterday I said java would never consider type inference.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #98 - Posted 2016-03-16 09:42:32 »

I am absolutely not a fan of type declaration obfuscation - which is what they're basically proposing here. When I read code I want to understand what assertions a programmer is making about the nature of the things they are dealing with and this "var" keyword does exactly the opposite: it lets the compiler figure it out for me (yay!) but then it hides all that extra rich information from my own internal brain compiler which I use to reason about code with (shit). It's almost like the exact opposite of what generics was trying to achieve: List<String> gives me information about the kinds of things that I'm expecting to have inside a list, where a plain List does not and the Java language correctly identified this as an area where we could add visible reasoning to our types instead of just hiding it all away.

What I would like to see is type inference to remove irrelevant casting:
1  
String x = (String) thing.foo(); // What is the point of the (String) cast here?

might just as expressively be written
1  
String x = thing.foo();

because the cast is implicit. Implicit casting can easily be inferred from the code and will fail at compile time from impossible casts eg. due to previous narrowing assertions on type.

Cas Smiley

Offline nsigma
« Reply #99 - Posted 2016-03-16 09:55:12 »

Just yesterday I said java would never consider type inference.

Just yesterday, if you'd bothered to follow the link in my comment before responding you'd have found the JEP!  Tongue

I think this whole proposal is horrible - it's a needless reduction in verbosity which really reduces legibility.  @noctarius, thanks for the SurveyMonkey link, I've registered my dislike.  And, yes, I'm an old fuddy-duddy! Smiley

@princec - interesting you mention generics - I compared this to the diamond operator in my response, which I think is useful and reduces verbosity while maintaining intent.  Not sure about your implicit casting.  It's not the impossible casts that bother me, it's the unintended ones.  Mind you, I remember seeing an idea for an instanceof block that combined that with implicit casting - that would be better.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #100 - Posted 2016-03-16 09:59:14 »

I'm naughty like that.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #101 - Posted 2016-03-16 10:10:28 »

What I would like to see is type inference to remove irrelevant casting:
1  
String x = (String) thing.foo(); // What is the point of the (String) cast here?

might just as expressively be written
1  
String x = thing.foo();


We're making the compiler infer everything + dog, it can properly analyze arbitrarily complex control-flow and notify me of variables that are potentially null at any point i'm using the variable, but it still does not figure out the most trivial of control-flows:
1  
2  
3  
if(obj instanceof String) {
   String str = (String)obj; // seriously? I have to cast here?
}
Maybe using 'var' here will finally resolve this 2 decade old annoyance Smiley


Sorry for being offtopic.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #102 - Posted 2016-03-16 10:36:16 »

That's on topic!

My idea of simply using implicit casting seems to solve all the problems. You wouldn't have to cast inside the "if" because String str = obj implies obj must be cast to a string anyway.

The diamond operator is great and works in a very similar way - you've already declared the type in code, visible right next to where you're using it - why type it again.

Cas Smiley

Offline nsigma
« Reply #103 - Posted 2016-03-16 10:44:36 »

1  
2  
3  
if(obj instanceof String) {
   String str = (String)obj; // seriously? I have to cast here?
}
Maybe using 'var' here will finally resolve this 2 decade old annoyance Smiley

Think I found the instanceof thing I mentioned previously from the Project Coin list, although it seems more verbose than I remember.

1  
2  
3  
4  
5  
switch (obj) instanceof {
  case String:
    // obj is now String
    obj = obj.trim();
}


Mind you, using switch suggests you'd have a chain of options, which is a real code smell!  Undecided

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline theagentd
« Reply #104 - Posted 2016-03-16 10:46:49 »

That's on topic!

My idea of simply using implicit casting seems to solve all the problems. You wouldn't have to cast inside the "if" because String str = obj implies obj must be cast to a string anyway.

The diamond operator is great and works in a very similar way - you've already declared the type in code, visible right next to where you're using it - why type it again.

Cas Smiley
I think the biggest problem with this is that a lot of newbies are gonna accidentally cast things all the time without realizing it. Implicit casts should only be permitted when the variable is proven to be of a certain class... which probably means only in the trivial if(instanceof) --> cast case.

Myomyomyo.
Offline nsigma
« Reply #105 - Posted 2016-03-16 11:05:02 »

Actually, Project Coin proposal moved on to

1  
2  
3  
if instanceof (String obj) {
  String s = obj.trim();
}


which is more like I remember.  Also some examples of why using existing syntax (as @Riven) was problematic.

Anyone interested - http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/thread.html

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #106 - Posted 2016-03-16 11:10:57 »

I think the biggest problem with this is that a lot of newbies are gonna accidentally cast things all the time without realizing it. Implicit casts should only be permitted when the variable is proven to be of a certain class... which probably means only in the trivial if(instanceof) --> cast case.

I don't know how that'd be a problem... the compiler is simply inserting the cast for you. You have already declared the type - why repeat what you have just typed? You've already explicitly declared the type, right there, in code, in front of you: this means you don't have to pointlessly repeat your declaration. Illegal casts are still illegal. Runtime CCEs are still possible. There's just less code to look at, type, and maintain.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 798



« Reply #107 - Posted 2016-03-16 11:23:49 »

@theagentd is right. You cannot simply make EVERY variable definition using an assigned value of an incompatible static type to be an implicit/hidden cast.
That would defer type error checking from compiletime to runtime, and you would end with dynamic languages like JavaScript...
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #108 - Posted 2016-03-16 11:25:50 »

This "var" thing is just change for change's sake. I wouldn't willingly use it.

I hate the if-instanceof-then-explicitly-cast-anyway pattern. How about an explicit "assign with cast" operator? Some thing like:

1  
2  
/*old*/ int x = (int)floatyNum;
/*new*/ int x := floatyNum;


An "assign with cast" operator like := would be trivial to implement of course and have no wider language implications.

Offline Icecore
« Reply #109 - Posted 2016-03-16 11:42:30 »

1  
2  
3  
if(obj instanceof String) {
   String str = (String)obj; // seriously? I have to cast here?
}


i also think about that all time writing "instanceof ", and after i see Question here i find answer in couple sec ^^

Up:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
   Object aaa = "Q";
   String s = Cast_Me(aaa, String.class);
   Integer i = Cast_Me(aaa, Integer.class);
+   Integer i2 = Cast_Me(s, Integer.class);
+   static public<E, T extends E> T Cast_Me(E Obj, Class<? super T> cl){  
      if(cl.isInstance(Obj)){
         return (T)Obj;
      }
      return null;
   }


p.s Lol i'm so good solving someone else problems XD, but not my own Sad

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #110 - Posted 2016-03-16 11:52:50 »

How is

1  
String s = Cast_Me(aaa, String.class);


...better or shorter than:

1  
String s = (String)aaa;

Offline Icecore
« Reply #111 - Posted 2016-03-16 11:54:09 »

How is

1  
String s = Cast_Me(aaa, String.class);


...better or shorter than:

1  
String s = (String)aaa;

if wrong Instance return null)

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #112 - Posted 2016-03-16 11:55:51 »

I don't want my reference nullified, in this case I usually want the error.

Online Abuse

JGO Ninja


Medals: 73


falling into the abyss of reality


« Reply #113 - Posted 2016-03-16 11:58:04 »

1  
2  
3  
4  
5  
6  
7  
      String s = Cast_Me(aaa, String.class);
   static public<T> T Cast_Me(Object Obj, Class<T> cl){  
      if(cl.isInstance(Obj)){
         return (T)Obj;
      }
      return null;
   }


I hope you realize how & why that is really really nasty.

To the other suggestions, I favor if instanceof; it's the one closest to 'fixing' the instanceof operator (it should have never been a binary operator).
Offline Icecore
« Reply #114 - Posted 2016-03-16 12:04:32 »

I don't want my reference nullified, in this case I usually want the error.
Why You troll me Wink
1  
2  
3  
4  
5  
6  
7  
 static public<T> void Cast_Me(Object Obj, Class<T> cl){   
      if(cl.isInstance(Obj)){
         return (T)Obj;
      }
+      throw new IllegalArgumentException("NOooooo..");
-      return null;
   }


Quote from: Abuse
I hope you realize how & why that is really really nasty.
Yes - but there is no problems in Language or IDE for fixing this, in more flexible way)

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline gouessej
« Reply #115 - Posted 2016-03-16 12:34:47 »

noctarius, it's still unclear to me how VarHandle and MemoryRegion drive sun.misc.Cleaner useless. How can I decide when I want to free the native resources used by a direct NIO byte buffer?

Julien Gouesse | Personal blog | Website | Jogamp
Offline CoDi^R
« Reply #116 - Posted 2016-03-16 12:59:04 »

When I read code I want to understand what assertions a programmer is making about the nature of the things they are dealing with and this "var" keyword does exactly the opposite: it lets the compiler figure it out for me (yay!) but then it hides all that extra rich information from my own internal brain compiler which I use to reason about code with (shit).

This!

Also, if I decide to refactor a data type for some reason, I want the compiler/IDE show me all the immediate places I break its contract, not at some obscure point far down the magic var/auto rabbit hole.

Quote from: princec
What I would like to see is type inference to remove irrelevant casting:
1  
String x = (String) thing.foo(); // What is the point of the (String) cast here?

might just as expressively be written
1  
String x = thing.foo();

because the cast is implicit. Implicit casting can easily be inferred from the code and will fail at compile time from impossible casts eg. due to previous narrowing assertions on type.

Personally I prefer the cast, or better a more explicit statement like thing.foo().asString(), for the exact same reason as above. It documents my intention as a programmer. By forcing me to write it down (to please the compiler), it forces me to think about the reason.

Robotality - steamworks4j - @code_disaster - codi^r @ #java-gaming
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #117 - Posted 2016-03-16 13:38:59 »

I just don't want to have to write the same thing twice. Especially on the same line of code. It's absolutely no different in concept to the diamond operator.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 798



« Reply #118 - Posted 2016-03-16 14:15:16 »

It's absolutely no different in concept to the diamond operator.
Hmmm... I thought about it a bit, and there are quite a few differences:
First: The diamond operator can only be used with instantiations of classes of a parameterized type. There is no type error possible in that case when we use the diamond operator instead of repeating the type argument with the constructor call. (even if we forget about type-erasure for a moment, and pretend it wouldn't happen)
Second: If the type argument of the parameterized type declaration of your variable you want to assign to would not be compatible with the type parameter of the parameterized type, then that would be a static compile-time type error.
So, with the diamond operator we never defer type checking to runtime.

EDIT: But I am totally with you, I would like to not having to cast to a type which I previously instanceof'ed.
Offline Spasi
« Reply #119 - Posted 2016-03-16 14:35:46 »

I just don't want to have to write the same thing twice. Especially on the same line of code.

Totally agree. Which is why I like the var/val/auto proposal. I don't get it, how you can dislike redundancy and JEP 286 at the same time? Especially since it's going to be applicable only to local variable declarations, not field declarations like other languages.

Both type inference and smart casts are supported (perfectly imho) in Kotlin, you can give it a try to see how it'd feel like. Needless to say, I'd love to have both in Java. Another thing that Kotlin got right is primitive casts, they are never done automatically (this sounds worse than Java, but no, it isn't). Btw, nothing about all this requires runtime support, it's all done statically and safely at compile time, i.e. any incompatibilities after type/cast inference are reported as compile-time errors.
Pages: 1 2 3 [4] 5 6 ... 8
  ignore  |  Print  
 
 

 
Riven (587 views)
2019-09-04 15:33:17

hadezbladez (5528 views)
2018-11-16 13:46:03

hadezbladez (2410 views)
2018-11-16 13:41:33

hadezbladez (5790 views)
2018-11-16 13:35:35

hadezbladez (1233 views)
2018-11-16 13:32:03

EgonOlsen (4669 views)
2018-06-10 19:43:48

EgonOlsen (5688 views)
2018-06-10 19:43:44

EgonOlsen (3205 views)
2018-06-10 19:43:20

DesertCoockie (4104 views)
2018-05-13 18:23:11

nelsongames (5125 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!