News for hackers. Stuff that matters.
Re:.NET Framework 4.6.2 by iamcreasy on Tuesday August 02, 2016 @06:04PM (#12213783)
Anybody knows if/when Java will have this feature?
Re:.NET Framework 4.6.2 by benjiweber on Wednesday August 03, 2016 @01:56AM (#12215899)
SAP's JVM implementation has NullPointerExceptions that tell you where the null originated from, which is neat.

See slide 17 of https://oracleus.activeevents.com/2014/connect/fileDownload/...

Re:.NET Framework 4.6.2 by meddlepal on Tuesday August 02, 2016 @11:18PM (#12215329)
I doubt believe it will ever or at least not anytime soon. I don't think the JVM preserves identifier names in the bytecode in a way that it can be accessed easily.

Though I do recall a long time ago reading about some JVM switches that allow that data to be accessed but with performance issues. Can't recall where I read that.

Re:.NET Framework 4.6.2 by iamcreasy on Wednesday August 03, 2016 @02:04AM (#12215922)
> JVM switches that allow that data to be accessed but with performance issues. Can't recall where I read that.

Would love to know how to do that.

Re:.NET Framework 4.6.2 by meddlepal on Wednesday August 03, 2016 @05:33PM (#12221704)
Use the "-g:vars" switch on javac and then use a classfile reader library to inspect the LocalVariableTable.
Re:.NET Framework 4.6.2 by kodfodrasz on Wednesday August 03, 2016 @01:25AM (#12215788)
Sadly (as one developing a lot in Java) i think it won't happen anytime soon, and the community will ideologize it as "it is even better that we don't have it". :(

I hope I will be wrong.

ps: a language where non-nullable references are the thing would be the best.

Re:.NET Framework 4.6.2 by lmm on Wednesday August 03, 2016 @05:41AM (#12216773)
Java has finally got options, so at least it's theoretically possible to start a migration path to non-nullable. It will take decades though.
Re:.NET Framework 4.6.2 by kodfodrasz on Wednesday August 03, 2016 @07:41AM (#12217228)
I tried to use the java Optional<T>, but the API has some points, which make it inconvenient for some usecases. (Some of these are addressed in Java 9)

As I see: unfortunately without algebraic types you cannot solve this properly, even if you address the lacking points in Optional<T>