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.

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.

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

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.

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)

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.

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:

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.

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.

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"?

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.

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.

Thank you for the thumbs up and the link and example. I have bookmarked the link. My brain is a little overfull--reading about the math for curves and having to keep going back and reviewing things like how to invert matrices. Tomorrow morning should be fresher and able to read the enum link.

I thought I was doing okay with enums until I hit an example certification question pertaining to the "constant specific class body" at which point my brain went tilt. (Some of the questions in Sierra/Bates SCJP are just nasty hard.)

It is a lot easier to deal with classes if the rules for classes stay the same, rather than have special cases and exceptions. This is why Clojure appeals to me so much more than Scala. (Haven't checked out the other new language people are mentioning here...ugh tired, can't recall it's name.)

Mostly, I think Java is the best. I am perfectly fine with verbose and explicit. (Can you tell from my tldr posts?) I also am coming from a Microsoft background, and find that world very frustrating and arbitrary. Consistency is a good thing, not at all a hobgoblin, in language design.

The important thing about enums in Java is that they are consistent. It's all implemented under the hood just like ordinary classes and prior to Java 5 that's what everyone did. What enums do is just take out all the boilerplate and do it all for you and make sure you can't trip over the various gotchas that befall you if you do it manually (eg. forgetting to make them serializable properly)

Enums never seem to quite fit my specific needs when I look at them, but I'm blaming the lackluster reference I often have to work with.

If I may go on a bit of a tangent, it bothers me a lot when I'm researching for a way to solve a problem using Java, and most documentation I find settles for the least effort most generic approach (and thus less flexible), barely scratching the surface of what the language is capable of.

I think I'm going to start pointing people to this thread so they realize how little they really know about Java. (I'm saying this as someone who is humbled by the knowledge on display here)

Certainly, but there are situations when the requirements go beyond the possibilities of the standard solutions.

For example, most tutorials and books on Java Game Programming I've come across usually rely on Java2d objects for image presentation. That is fine and dandy for most users, but I may want to do some manipulation that goes beyond what those classes can handle, and it becomes frustrating when a sizable portion of the community simply state that it isn't possible, when in reality they mean "I don't know".

And in case you're wondering, my frustrations in this regard come from the StackOverflow forums mostly.

You can get most of the way there with the @NonNullByDefault annotation - you can apply this at the package, type or method level so it's not a lot of work to cover the entire codebase, and you can leave bits out if you want.

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

Good idea, sad that I can't implement its with alpha I also understand that’s main time eat work with array, for exampleCode by link takes 2594962 ns in (for 1000000)Clear for eat 2101255 ns;While simple int pixel = ar_Ints[0]; 3466137 ns in same forAnd you need three of array access: two for get pixels and one for put back; 5512280 nsLike you see main problem not in math calculation Thanks all, I really tiered trying optimize rendering at this point its work 9482898 ns =)And give in game 100-300 fps

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