Things you disagree with in the java language

[ra4king]

@nsigma

@ra4king

Then to add 2 pixels together:

int pixel = (0xff << 24) | (((r1+r2) & 0xff) << 16) | (((g1+g2) & 0xff) << 8) | ((b1+b2) & 0xff);

Without wishing to hijack this thread (which I’m finding quite interesting) with a further discussion on pixel bit operations, that example from ra4king is wrong (doesn’t do clamping). I recommend this old thread which contains loads of working pixel blend modes based on bit shift operations. Maybe start a new thread if you want to discuss further - I’d be tempted to claim it’s off-topic, though this thread seems to be pretty much everything goes. ;D

Oh damn I forgot about clamping!

int pixel = (0xff << 24) | ((clamp(r1+r2,0,0xff) & 0xff) << 16) | ((clamp(g1+g2,0,0xff) & 0xff) << 8) | (clamp(b1+b2,0,0xff) & 0xff);

public static int clamp(int value, int low, int high) {
    return Math.min(Math.max(value, low), high);
}

[Icecore]

@Roquen

As an aside: a fair number of unsigned ops are already in JDK8 mainline.

I become happy on 1 min ,before I don’t see this
http://cr.openjdk.java.net/~darcy/4504839.2/raw_files/new/src/share/classes/java/lang/Byte.java

public static int toUnsignedInt(byte x) {
        return ((int) x) & 0xff;
}

Omg, is that so hard to add new primitive types ubyte, ushort, uint ? ;( (its rhetoric question)

[ra4king]

They can’t add new primitives, since that would require new reserved keywords. This would break all applications that use ‘ubyte’, ‘ushort’, ‘uint’, and ‘ulong’ as identifiers.

[princec]

No it would require new bytecodes, which is a much bigger issue.

Cas

[ra4king]

@princec

No it would require new bytecodes, which is a much bigger issue.

Cas

Was that to me?

[Riven]

@princec

No it would require new bytecodes, which is a much bigger issue.

Not necessarily. The compiler can accept (the syntax of) the new primitives, use (elaborate) existing bytecodes to make a slow but correct implementation of the unsigned primitives. HotSpot can then optimize it back to native instructions. It’s cumbersome, but doable.

[princec]

I suppose it could. My knowledge of bytecode is miniscule.

Cas

[Roquen]

@Icecore

@Roquen

As an aside: a fair number of unsigned ops are already in JDK8 mainline.

I become happy on 1 min ,before I don’t see this
http://cr.openjdk.java.net/~darcy/4504839.2/raw_files/new/src/share/classes/java/lang/Byte.java

public static int toUnsignedInt(byte x) {
        return ((int) x) & 0xff;
}

Omg, is that so hard to add new primitive types ubyte, ushort, uint ? ;( (its rhetoric question)

Intrinsics

[kaffiene]

@ags1

The thread just gives me sympathy for James Gosling and the other language designers. All the devs at Sun telling them Do This, Do That… A pretty thankless task. All I know is I found C and C++ stressful and Java a joy to work with. As a self-taught programmer, I feel I can do creative things with Java, while with the C-team I spent my time worrying about memory allocation and pointer math.

Heh! I totally agree with you. That’s why a said about a billion posts ago that despite the 1000s of things that are “wrong” with Java, there’s actually not a lot wrong with it and it’s really a very productive language to use. Not to say that I hate C/C++ just that I get-shit-done(tm!) much faster, with less rework, less surprises and easier maintainability in Java than those languages.

[princec]

Everybody goes quiet for a while, and there is much supping and wiping of foam from programmer beardy moustaches.

Cas

[sproingie]

I have to agree with kaffeine there: most of Java’s problems are sins of omission, which is a hell of a lot more than I can say for freakshows like PHP.

[Roquen]

Designing a good language that’s usable is very hard and Java is a quite well designed language. I think that most of us can agree the most of the ‘issues’ are omissions of which the greater part of are due to the reality of timetables…couple with it’s hard to remember “research” which is post some feature. (example: someone said it would have been great if java had generics from the start…sure, but all the research was performed ON java, so without a time machine, it would have been tricky)

BTW: generics are contracts (I don’t think that’s been mentioned)

[sproingie]

Parametric polymorphism has been around since ML in the 70’s. GJ and Pizza (both Java forks) had it well before Java was pushed into supporting it by more or less adopting GJ’s version of generics. Fact is, Java was conceived as a replacement for the Display PostScript system in NeWS, then positioned toward “set top boxes” which were a thing at the time. At no time in the design of Oak was there really any intention of doing anything particularly revolutionary or even all that advanced (it’s harder to write compact bytecode from advanced compilers), so it got caught playing catch-up for a while after it became Java.

One thing that served Java well was that Sun had the good sense to hire smart people or otherwise listen to them, such as hiring back the Self team who had moved on to do Strongtalk and get them to write Hotspot, or listening to Phil Wadler and getting GJ turned into generics. The latter happened because of good relations with the academic community, something I fear Oracle is not going to pull off, if they even bother at all.

[Roquen]

Correct me if I’m mistaken, but I was speaking mechanically.

[philfrei]

I am studying for the basic java certification test on and off. One thing I am finding annoying is that with Enums are “a special kind of class”. Does anyone use them much? Ever take advantage of the benefits of having a “constant specific class body”?

I do write my own final “constants” and use them, but haven’t had or taken many opportunities to use Enum. That is probably why I am having trouble remembering how they work.

+++++++++++

For those of you wrangling about color operations on the int itself, have you checked out the JGO index? Here’s one of several:

Fastest color addition with clamp 0-255 of RGB

Even has Markus_Persson’s stamp of approval. I recall seeing a couple other in our archives, including some “fast” implementations by Markus.

[princec]

I use enums nearly all the time now instead of static final ints.

Cas

[pjt33]

@Riven

@princec

No it would require new bytecodes, which is a much bigger issue.

Not necessarily. The compiler can accept (the syntax of) the new primitives, use (elaborate) existing bytecodes to make a slow but correct implementation of the unsigned primitives. HotSpot can then optimize it back to native instructions. It’s cumbersome, but doable.

The operations are the same as twos complement for everything except division (and modulus, which is really the same thing). The VM would at the very least need bytecodes to convert the unsigned types to the signed ones prior to division and back after.

[actual]

@philfrei

I am studying for the basic java certification test on and off. One thing I am finding annoying is that with Enums are “a special kind of class”. Does anyone use them much? Ever take advantage of the benefits of having a “constant specific class body”?

I do write my own final “constants” and use them, but haven’t had or taken many opportunities to use Enum. That is probably why I am having trouble remembering how they work.

Here is an article that shows you some of the neat things you can do with enums.

[kaffiene]

@philfrei

I am studying for the basic java certification test on and off. One thing I am finding annoying is that with Enums are “a special kind of class”. Does anyone use them much? Ever take advantage of the benefits of having a “constant specific class body”?

Hell Yeah! I love Enums.

Here’s an example:

   
 enum HexType {
        SEA      (Resource.NONE,   new Color(0.5f, 0.7f, 0.9f)),
        PASTURE  (Resource.WOOL,   new Color(0.5f, 0.8f, 0.3f)),
        FIELD    (Resource.GRAIN,  new Color(0.9f, 0.9f, 0.5f)),
        MOUNTAIN (Resource.ORE,    new Color(0.5f, 0.5f, 0.6f)),
        HILLS    (Resource.BRICK,  new Color(0.7f, 0.4f, 0.3f)),
        FOREST   (Resource.LUMBER, new Color(0.1f, 0.5f, 0.1f)),
        DESERT   (Resource.NONE,   new Color(0.8f, 0.7f, 0.6f));
        
        public final Resource resource;
        public final Color    color;
        
        HexType(Resource r, Color c){
            resource = r;
            color    = c;
        }
    }

That allows me to have a collections of hex objects where each hex can tell me what resource type it produces and what color it should be on the map. If I were using constants, I’d need associated lists or maps containing hex->resource mappings and hex-> color mappings. It’s much tidier this way because it keeps all the hex-related info in one place.

[Roquen]

WRT: Unsigned again, no need for new bytecodes. You almost never need new bytecodes. Shifts and masks are trivial transforms and HotSpot is not a simple JIT. Signed/Unsigned conversion has been fast forever. Compares, divides & multiples have harder and more numerous patterns…JDK8 adds methods (with software backup implementations), runtime coverts to a single opcode, done.