[quote=“Best_Username_Ever,post:180,topic:39645”]
The “religious war” aspect comes because people have different weightings for the same merits.
I’ve configured my IDE to highlight @Nullable issues as errors and it’s quite surprising how much code is affected when you annotate something with it. Like Riven said, it’s similar to how generics code propagates. I agree that NPEs are relatively easy to solve, but not always. I find that @Nullable considerably reduces how much time I spend hunting down NPEs and also forces me to think twice about when and where I use nullable fields/arguments/return values. It’s often better to refactor code and use more immutable classes.
[quote=“Best_Username_Ever,post:180,topic:39645”]
In Kotlin, nullable primitives compile down to the corresponding wrapper class. Example:
val a: Int = 1 // primitive
val b: Int? = 1 // java.lang.Integer
Except references, Kotlin allows you to specify nullability to array/collection parameters as well. That’s where it gets interesting and really useful:
val foo = array("a", "b", "c") // type is Array<String>
val bar = array("d", null, "f") // type is Array<String?>
println(foo[0].length) // works
println(bar[0].length) // compile-time error
println(bar[0]?.length) // works, the expression type is Int?
val s = bar[0] // type is String?
if ( s != null )
println(s.length) // works with auto-cast from String? to String
@pjt33 Makes sense, but that’s the main reason why I think multiple languages should exist rather than focusing on “X should look like Y.”
@Spasi It seems alien to me. In my experience the number of errors even involving null are extremely rare relative to other programming logic errors. I think the only times I’ve had that exception have been in test projects with only one class file (where I don’t pay attention as well as I do in normal projects and failed to initialize a String or something) and in one other case where I wrote return null; instead of something like throw new RuntimException("This method will need to be written later."); in an unused function in a recently redesigned enemy character class and forgot one class after reimplementing all the rest. It ended up having the same end result as if I had thrown an exception because it was clear that the new character caused the problem and the empty method body was as conspicuous as the exception thing. It must be because of some programming habit, but the only null reference problem I’ve encountered in years in a serious project was that one case. No matter what the case is, it’s usually because I am being lazy and neglect to conform to what the third part class doc or my own designs specify for parameters and return values.
Actually, NPEs is the most common exception in Java programs. You don’t have to believe me, just do a google search and compare NPE-related results to other runtime exceptions.
The bits are the same regardless so it doesn’t really matter.
[quote]2# Hate unavailable change some bytes of big variable
[/quote]
Like this :
int a = 00FF00FF
a byte[0] add AA
that’s easy do in memory but for Java need separate bytes :(
int b = a & 0xFF000000
int c = a – b; // Why would you need this?
b /= 0x01000000 // hm?
b += 0x000000AA; // ?
b *= 0x01000000 // ?
a = c + b; // ? :L
[quote]or simple add to int a += 0xAA000000;
but i want add byte not int =)
[/quote]
I don’t understand. It seems you are not aware of bitwise operators? http://en.wikipedia.org/wiki/Bitwise_operation
What do you mean? Unless you want them all to be the same colour, of course you’re going to need a separate byte for the Red, Green and Blue values.
[quote](remember solution, use bytebuffer, get from it vice/versa int[] and byte[],
don’t remember why I not using it, maybe because byte signet pf ;S, or it slow, hm)
Update(check, bytes signets, and I can’t convert bytebuffer to char array vise/versa, for unsigned byte :()
[/quote]
an unsigned byte and signed byte holds the same data (bits).
class ByteTest {
public static void main(String[] args) {
byte byte1 = (byte) -1;
byte byte2 = (byte) 255;
System.out.println(byte1 == byte2);
/*
* Output: true
*/
}
}
[quote]3# Want do more then 1 parent for class, interfaces not help some times.
(don’t need explanation ^^)
[/quote]
You do need to explain. Either make your parent inherit from another object or use interfaces. Interfaces work just as fine and are more flexible. You don’t need to (shouldn’t need to) make an object extend itself from multiple objects.
[quote]4# Function pointers =))
(or mega insane goto outside functions XD)
[/quote]
Isn’t this just the same as calling a method?
[quote]5## Also want normal goto, not strange label breaks XDDDD
[/quote]
Want != need != useful. A goto wouldn’t make sense in java (or in most modern programming languages).
[quote]6## and function for manual delete Objects ^^
[/quote]
Object = null;
GC will do the rest. If you want to optimize GC you need to look into JVM optimization.
[quote]7## and working ASM code (JNI? Hm want integrated code (^;^)/)
[/quote]
… WHY? Why do you play with the Nintendo if all you seem to want is to play with sticks and stones?
That’s probably a fallacy. The Java language and JVM are so good at preventing all the other problems that plague other systems that the next most common thing to happen, when it does happen, is an NPE. Still, I’m all for a language change that forces us to declare whether a value can be nulllable.
@Icecore - most of your suggestions seem completely mental, except the ability to have unsigned bytes (and also, the ability to write byte literals easily!)
Cas 
I was speaking about errors (small ‘e’). This includes things like off by one errors, leaving out a minus sign, precision and rounding issues with floating point numbers, changing a collection while iterating through it, infinite loops, assigning null to a variable incorrectly in a context where exceptions are still avoided, etc. And what about checked exceptions, including IOExceptions? Even if I weren’t skeptical of the fact, it’s a meaningless statistic. Are instances of NullPointerExceptions evenly distributed among all Java programmers? How much experience does each programmer have? Are they users or the authors of the software. Plus, Google search results are a poor metric for anything. They’re based on how many copies of the phrase are found and are a very inaccurate estimation. (And by estimation I mean approximate number many orders of magnitude off from the number of links it actually can give you.)
Stuff I can live without in Java:
Autoboxing
Generics
Abstract classes
IOC for everything
Casting to Interfaces for non IOC classes.
Inner classes
Anonymous classes
static classes (I don’t mean singletons)
Most collections since they are too slow.
Stuff I can’t live without:
Properties
Methods
Classes
Primitives
Arrays
Interfaces
Strings
Stuff I want to see in Java:
OSGI and/or Modules aka Jigsaw
Faster (Yes I know it is already fast enough.)
It’s because it’s a runtime error not a compile time error like it could be if non-null was the default.
I think that nullable is one of the contracts they’re talking about in that annotations on types proposal (which is slated for an upcoming release).
[quote=“jonjava,post:185,topic:39645”]
I think that what he means is that he wants the language to treat an int as a vector of 4 bytes so that he can manipulate packed RGB values with fewer operations. However, this is virtually useless: the only operation that you could usefully do like that would be addition with some carry bits ignored, like MMX’s paddb. For practical purposes the thing to use is to use masking by 0xff00ff00 and 0x00ff00ff and operate with split sets of bytes.
[quote=“Best_Username_Ever,post:187,topic:39645”]
How’s a NPE any different from the “errors” you describe? A bug is a bug. Even if we ignore NPE related bugs, just think about how much overhead there is in documenting (non-)nullable arguments, coding guard statements against null values, etc.
I also didn’t claim scientific/statistical accuracy, my point was that NPEs is a common issue. You make it sound like it never happens. I agree that you can’t expect any random google search to provide decent results, but try something like “nullpointerexception issue github”.
(Btw, I’m only arguing that compile-time null-safety is a useful feature to have. Not saying that we can’t live without it.)
[quote=“Roquen,post:190,topic:39645”]
Indeed. Actually, lack of type annotations is currently an issue for Kotlin-Java interop. Kotlin assumes that anything that comes from Java is nullable by default, unless a @NonNull annotation is present. But you can’t have annotations on generic type parameters atm. There’s IDE support to work-around it (external annotations and Kotlin signature mapping), but I don’t know if/how that could be implemented outside IDEA, e.g. in the Eclipse plugin.
But… can you imagine the verbosity?
@NonNull Map<@NonNull String, @Nullable Foo> map
ARGB pixel
float r_mult = 0.5f;
float g_mult = 1;
float b_mult = 1;
int r1 = (int)((pixel & 0x00FF0000) * r_mult);
r1 = r1 & 0x00FF0000;
int g1 = (int)((pixel & 0x0000FF00) * g_mult);
g1 = g1 & 0x0000FF00;
int b1 = (int)((pixel & 0x000000FF) * b_mult);
b1 = b1 & 0x000000FF;
pixel = r1 + g1 + b1;
pixel = pixel | 0xFF000000;//add alpha 255
if pixels in byte array then simple (unsigned ^^)
Ar[1] *= r_mult;
Ar[2] *= g_mult;
Ar[3] *= b_mult;
Ar[0] = (byte)255;
Yes but - Function pointers: really good optimize code.
It will take long time to explain, and who need explanation, java don’t have them XD
Interface don’t have dynamic variables.
Example
Walk type ground class, and walk class water type,
You need rewrite them in new one class, you can’t use 2 parents.
Class walk{
int speed = 10;
int get_Speed_Walk(){return speed ;}
}
Class swim {
int speed = 20;
int get_Speed_Swim(){return speed ;}
}
Class Mob extends walk, swim{
int ground_Speed = get_Speed_Walk();
int water_Speed = get_Speed_Swim();
}
If they same why I can’t do them unsigned; why I must do this B & 0xFF to convert to int =)
and
byte a = 140;
byte b = 10;
byte c = (byte)(a / b);
14 == -11 ? =)
WRT: Function pointers…they’re easy to fake with minimal boilerplate, so I don’t find it a big deal.
WRT: Annotations/contracts: meta-data is awesome. Like any other high level language feature people are gonna use-em in screwy ways or ways that some of us won’t like. That doesn’t make them less awesome. For contracts, I’ve always looked at them as they’re something joe average or beginner can pretty much ignore but open up things that are otherwise impossible.
In my opinion the fact that someone can (and well) write really bad code with a given feature is of about zero interest. Once you reach the complexity of a macro assembler you’ve already given programmers plenty of ways to shoot themselves in the foot. People go on about operator overloading…but think about this: asserts. I can’t count the number of times I’ve seen asserts written which have side-effects and cause very difficult to track down bugs. for-loops, with side-effect in the inc or condition block?
You are using OOP/extends wrong in that example.
You don’t have a firm grasp of bit manipulation and bitwise operators (they can be confusing).
Maybe you right, I don’t say that I am right on all 100%
If you can optimize this with bitwise
Its really helps my software rendering .
public int TextureData[];
public void set_Pixel_Color(int pos, int pixel, float r, float g, float b){
int r1 = (int)((pixel & 0x00FF0000) * r);
r1 = r1 & 0x00FF0000;
int g1 = (int)((pixel & 0x0000FF00) * g);
g1 = g1 & 0x0000FF00;
int b1 = (int)((pixel & 0x000000FF) * b);
b1 = b1 & 0x000000FF; //can be deleted , i know ;)
pixel = r1 + g1 + b1;
pixel = pixel | 0xFF000000;
Texture_Data[pos] = pixel;
}
And this ^^
public int TextureData[];
public void set_Pixel_Alpha(int pos, int pixel){
int alpha = pixel & 0xFF000000;
if(alpha != 0xFF000000){
if(alpha == 0)return;
float a1 = (float)((alpha >> 24) & 0xFF) / 255;
float a2 = 1 - a1;
int org_pixel = TextureData[pos];
int r1 = (int)((pixel & 0x00FF0000) * a1);
int r2 = (int)((org_pixel & 0x00FF0000) * a2);
int g1 = (int)((pixel & 0x0000FF00) * a1);
int g2 = (int)((org_pixel & 0x0000FF00) * a2);
int b1 = (int)((pixel & 0x000000FF) * a1);
int b2 = (int)((org_pixel & 0x000000FF) * a2);
r1 += r2;
r1 = r1 & 0x00FF0000;
g1 += g2;
g1 = g1 & 0x0000FF00;
b1 += b2;
b1 = b1 & 0x000000FF;
pixel = r1 + g1 + b1 ;
pixel = pixel | 0xFF000000;
}
TextureData[pos] = pixel;
}
You want to put R, G, and B into 1 int?
int pixel = (0xff << 24) | ((r & 0xff) << 16) | ((g & 0xff) << 8) | (b & 0xff);
Then to add 2 pixels together:
int pixel = (0xff << 24) | (((r1+r2) & 0xff) << 16) | (((g1+g2) & 0xff) << 8) | ((b1+b2) & 0xff);
That’s my question for you. Why ignore every bug besides null reference errors? Do we also need special syntax for @NonZero to prevent divide by zero errors?
Let’s say you’re a total noob. If you make a mistake because you leave a variable uninitialized and its value defaults to null, you are going to eventually encounter a NullPointerException. It’s going to be hard to track down because it’s not the same line where null was assigned, but finding bugs is going to take a long time for you no matter what. The only debugging technique you know is to go through the code line by line. It may take a long time to find, but it’s going to be way easier to find than a sign error. Not a noob? Look at the stack trace, see if you went wrong by intentionally passing null to a function that explicitly states “parameter must not be null.” If so, there’s your problem. If not, then go back down the stack trace, create a bunch of regular and conditional breakpoints, and see where you assigned null when you didn’t mean to. Of course, none of that may even be necessary if you understand the code at a macro level. That’s an easy bug to track down and fix for experts.
Can’t use null? Okay, let’s try an empty String, an empty List, a dummy value defined locally to this class, or use a Null Object pattern. A noob runs the program. Hmm. It doesn’t work right, but there’s no error message. A noob still makes the same class of mistakes and the only bug finding tool available to them is still tracing the execution of the entire program. It won’t save them any time and it makes errors less likely to be found straight away. Now consider the expert making a mistake. Yes, the expert is human so even noobish mistakes will happen, just a lot less often. Well, all the tests work. The individual classes and methods involved all work correctly. It’s only when you run the entire project that you have a problem. Let’s try debugging? That’s not as useful because I can’t narrow down where the bug is coming from. Let’s try adding assert statements? But what do you test for? Well, now you have to trace almost the entire project. Just like the noob, but with a much, much larger project.
Nulls and NullPointerExceptions are hugely under appreciated. They let you fail early, which is a good thing. People complain about it, but people also complain about buffering, BSODs, and sneezing. I think “null safety” is a misnomer. If you adopt coding styles that avoid breaking the contract of an API at all costs, then your chances of having null reference errors and many other problems decrease to near zero. Not coding cautiously will inevitably lead to shooting yourself in the foot. Null safety would be like using a powerful anesthesia on your foot from the start. I know having it won’t necessarily encourage bad habits, but the opposite isn’t true either. If I could only make one compiler change and had a choice between null safety and another solution to catch certain bugs as early as compile time, then I would leave nulls for all reference types and require all object fields to be initialized in line or in the constructor of an object, the same way final fields are.
Not really 
In first code I want set color brightness.
And in second - combine 2 pixels with alpha (original pixel alpha 255 always)