Bitshifting doesn't shift bits?

[Skiller]

What does bitshifting do in Java? In C++ is moves the bits left or right and fills the sides with 0s, in Java it seems to do something contrary to the docs that I can't figure out :(.

Basically my specific problem is that this just doesn't work and I can't figure out why:

byte value = (byte)(10 << 4);
value = (byte)(value >>> 4);

Value should end up being 10 again, but instead it's -6 which as far as the docs on >>> are concerned just shouldn't be possible.

[Skiller]

Found the problem, apparently Java implicitly converts the byte value to an int before the bit shift and not just after like I was expecting. So the solution is just to mask only the bits I wanted as all the ones left of those wouldn't be what I wanted:

byte value = (byte)(10 << 4);
value = (byte)((value >>> 4) & 0x0F);

I've never used such a duplicitous language as Java before, people say it's easier than C/C++ and it's true for simple applications but at the same time for harder or more complicated applications it's a hell of a lot harder to use than C/C++, it's a similar case with memory management, for simple stuff it's simple but for more complicated stuff it's a real pain in the ass and a lot more work to get it right. At least that's been my experience so far, there's just so much stuff missing from Java that's in C++ and apart from the libraries included with the language C++ has everything that Java has (it's fairly easy to write a simple garbage collector in C++).

[gcalvin]

Correct, Java is not a great choice for applications that involve complex memory management. Is this a surprise to you?

-Gary-

[Skiller]

Correct, Java is not a great choice for applications that involve complex memory management. Is this a surprise to you?

Not really, but I've barely heard anything bad said about Java and lots of praise for it so I'm a little surprised at how limited Java actually is. I guess it's just my expectations of Java were raised to high by what I'd heard of it especially since a lot of people on forums and what not had claimed it was better than C/C++, and though I can see it is in some circumstances IMO C/C++ is better in general, especially in my field of expertise (games).

[Tolls]

And that's the thing.
If you were working on large business apps for example then I suspect you'd find Java a lot easier to work with.

[quad64bit]

"I'm a little surprised at how limited Java actually is."
Thats part of the reason its so great. Not having to deal with memory management or overloaded operators, forced OOP principles, strict typing, platform independence, these are all things that make it great. Not to mention just in time compilation, run-time optimization, bytecode & virtualization. Now if you want powerful, why not use assembly? I argue it will do anything any language does, its more powerful, and has a very simple syntax. See my point?

[Skiller]

Thats part of the reason its so great. Not having to deal with memory management or overloaded operators, forced OOP principles, strict typing, platform independence, these are all things that make it great. Not to mention just in time compilation, run-time optimization, bytecode & virtualization.

See this is the misleading kind of post I see everywhere that raised my expectations :(.

You DO need to deal with memory management, you just don't have access to memory so you need to write extra code to avoid leaks and it's MUCH easier to create leaks because it's not always obvious if you need to manually clean up references or not to avoid leaks. In C++ if I leak I get told I have a leak and exactly where the leak was created in Java you can't even reliably find out if you are leaking or if the GC just didn't want to clean up something.

Operator overloading can make classes easier to use when done correctly, and if you find them too difficult to write then you don't need to, IMO hardly a good thing for Java not to have them.

Forced OOP is quite nice and does help keep the language consistent so that is a lot better than in C++ :).

I'm not sure what exactly you mean by strict typing since C++ is about the same as Java in that you can't use the wrong types in the wrong places, so I'm assuming you mean the way Java lacks a way to reinterpret data as whatever you want. I had several issues without the ability to reinterpret which has already caused me many headaches and ultimately led to greatly increased memory requirements of one of my apps so IMO not having it makes Java harder to use.

Platform independence is nice, but it's at the cost of being on fewer platforms, I don't know of any platforms that have a Java VM but no C/C++ compiler. Actually now that I think about it there are Java compilers aren't there? So maybe there is such a platform.

"Just in time compilation, run-time optimization, bytecode & virtualization" just mean that you can't rely on run-time results to be consistent and can lead to near impossible to find bugs that only show up if things happen a certain way that you have no control over. I had a problem where the position of the declaration and assignment of an int (int variable = 5; ) must have been changing what the JIT compiler compiled, my frame rate would be 50ish frames per second if the int was declared above a certain line but a dismal 10ish frames per second if declared below it, and there's no way in Java to ensure that the right code is compiled. Fortunately I caught that quick as it was the only change I'd made between runs, but the result was mostly repeatable when I swapped them back and forth so I just left the declaration above.

Now if you want powerful, why not use assembly? I argue it will do anything any language does, its more powerful, and has a very simple syntax. See my point?

Actually assembly is not always more powerful than C/C++, at least some C/C++ compilers (notably GCC and the MS Visual C++ compiler which are probably the 2 major ones) can embed assembly instructions directly into the C/C++ source giving C/C++ all the power of assembly and then some, so you are probably still better off using C/C++ in such cases.


The other thing that gets thrown around alot is that Java with a JIT compiler is just as fast as C++, but that's only true under conditions that heavily favor Java and it's still a little slower as the JIT needs time to compile at run-time. I wish there was a place that more objectively pointed out and compared in detail the advantages and disadvantages of each language, would have save me some disappointment.


If I'd been told how poorly some of these "advantages" work in Java I probably wouldn't have had as much trouble adjusting as I have, but most Java users just say they are great and coming from C++ IMO it's not really true as they are only great under specific circumstances :(.

Still just to be clear, even though IMO C/C++ is better I still find Java to be very good, I love that I don't need to sit around waiting for builds as much since it lets me get more actual work done and there are lots of little things that do make life alot easier and safer in Java like the length variable on arrays (though I still sometimes forget to use it ;) ).

Anyway this has gotten a little off topic so I'll leave it at that ;)

[Tolls]

See this is the misleading kind of post I see everywhere that raised my expectations :(.

You DO need to deal with memory management, you just don't have access to memory so you need to write extra code to avoid leaks and it's MUCH easier to create leaks because it's not always obvious if you need to manually clean up references or not to avoid leaks. In C++ if I leak I get told I have a leak and exactly where the leak was created in Java you can't even reliably find out if you are leaking or if the GC just didn't want to clean up something.

I can only pick up this bit, but you do not need to deal with memory management, short of ensuring you have enough for the maximum needed by your system, plus a bit of wiggle room.

You do not need to write extra code, you simply need to write good code. That is code that is generally compartmentalised and simple. Do not try and second guess the JVM. That way tends to lead to some poor design decisions.

The idea that you have to manually clean up something is plain wrong.

It's easy to figure out if you have a leak...that's what the Java memory tools are for (jhat, jmap and Eclipse MAT).

You are clearly coming into Java and trying to get it to work like C++. It isn't. You have to learn a different language, I'm afraid., and that involves writing your code in a different way.

[Skiller]

I can only pick up this bit, but you do not need to deal with memory management, short of ensuring you have enough for the maximum needed by your system, plus a bit of wiggle room.

It's not really memory management I was referring to but I guess reference management, just making sure you don't have references to stuff you need freed to allow for new stuff. Callbacks in particular tripped me up early on as I'd been used to unhooking them in destructors and Java doesn't have those, I looked for callback design patterns in Java but couldn't really find any consistently used patterns so I just created a clean up function that you have to manually call to ensure the class unhooks all callbacks and nulls any references in them when the instance of the class is no longer needed. If there's a better way I'd love to know it :). I tried using weak references in some callbacks but found the constant checking and overhead of the weak references to be more trouble that it was worth :(.

You are clearly coming into Java and trying to get it to work like C++. It isn't. You have to learn a different language, I'm afraid., and that involves writing your code in a different way.

I'm just trying to get it to be efficient, if it's possible to make Java efficient without trying to bend/break Java to do things the way C/C++ (and more importantly the CPU) does things then please let me know how as that would help a heap :).

[Tolls]

It's not really memory management I was referring to but I guess reference management, just making sure you don't have references to stuff you need freed to allow for new stuff. Callbacks in particular tripped me up early on as I'd been used to unhooking them in destructors and Java doesn't have those, I looked for callback design patterns in Java but couldn't really find any consistently used patterns so I just created a clean up function that you have to manually call to ensure the class unhooks all callbacks and nulls any references in them when the instance of the class is no longer needed. If there's a better way I'd love to know it :). I tried using weak references in some callbacks but found the constant checking and overhead of the weak references to be more trouble that it was worth :(.

You'd have to show us what you'd done, because I've never had a problem with callbacks and correctly scoped variables. It sounds to me like you're still thinking in terms of C.

Reference management is also a pretty alien concept. Keep things in their proper scope and you shouldn't have a problem.

I'm just trying to get it to be efficient, if it's possible to make Java efficient without trying to bend/break Java to do things the way C/C++ (and more importantly the CPU) does things then please let me know how as that would help a heap :).

Again, you're thinking in terms of C. Write simple code. Attempting to second guess the JVM is almost always the road to failure.

Not knowing what you're trying to do it's hard to say where to go.

[quad64bit]

Actually assembly is not always more powerful than C/C++

You missed my point. All code becomes assembly before being assembled into machine code. Thus, assembly can do anything any higher level language can do. But that alone is not a good reason to use it, as it is very very very verbose.

[quad64bit]

Platform independence is nice, but it's at the cost of being on fewer platforms, I don't know of any platforms that have a Java VM but no C/C++ compiler

Also, just because you can compile c/c++ doesn't mean your app will compile. Many many c++ apps reference native libraries. Java does not (most of the time). An app written in 100% java will run on any platform with a jvm. 100% c/c++ cannot make the same claim.

[quad64bit]

Long story short, you are approaching java completely the wrong way. Making statements like

mean that you can't rely on run-time results to be consistent and can lead to near impossible to find bugs that only show up if things happen a certain way that you have no control over.

are very misleading. Can you provide an example of this? In all the years I have been doing java code, I have never had a bug I couldn't trace, let alone because of JiT. You get runtime exceptions, which have a stack trace.

If you're writing a driver for a video card, then c/c++ might be great. If you are trying to spend time developing rather than worrying about releasing references, differentiating between pointers, values, primitives, etc... then java is quite nice. If you want your code to run on any jvm without a recompile/port/adjustment, then java is also great. If you work in an enterprise environment where you integrate with many languages, hardware platforms, software platforms, virtual environments, etc... then java is great.

For instance, my company makes heavy use of Ruby on Rails (JRuby), Groovy on Grails, pure java, servlets/beans/jsp/enterprise .war's, and virtual environments. Java allows all these things to work together in a clean way - they all run on java based application servers, and on top of jvm instances. This makes scalability a snap, makes switching from solaris to ubuntu to red hat to windows a snap. It makes amazon ec2 work a joy. Try any of this with c/c++ - it just isn't practical.

I mean come on, even c# is just a platform specific port of java (don't say mono). It is very java like in its way of doing things, and from what I hear is the hot ticket in the windoze world these days.

[Skiller]

Long story short, you are approaching java completely the wrong way. Making statements like are very misleading. Can you provide an example of this? In all the years I have been doing java code, I have never had a bug I couldn't trace, let alone because of JiT. You get runtime exceptions, which have a stack trace.

Basically any bugs involving multiple threads where the order they finish in could cause a crash. Obviously if the crash is on your machine it's not going to be a problem, it's when the crash happens on an end users machine it's a pain to find. In C++ the odds of the bug reoccurring will pretty constant since there's the same number of instructions to run each time so if it's a common issue it shouldn't be hard to reproduce, but in Java the odds will be different between runs because the optimization might not be the same, so it might be 1 in 100 on one run then 1 in 1,000,000 the next and you won't be able to tell the difference.

You'd have to show us what you'd done, because I've never had a problem with callbacks and correctly scoped variables. It sounds to me like you're still thinking in terms of C.

Reference management is also a pretty alien concept. Keep things in their proper scope and you shouldn't have a problem.

Rough generic example of a common situation (excuse errors and what not, written in notepad, but should give you the general idea):

public class Callback
{
	private ClassA m_classA;
		
	public Callback(ClassA classA)
	{
		m_classA = classA;
	}
	
	public void Update()
	{
		m_classA.Update();
	}
}

public class ClassA
{
	public int m_count = 0;
	private Callback m_callback;
	private ClassB m_classB;
	private byte[] m_HUGEMEMORY = new byte[12*1024*1024]; //keep in mind Android only has 16mb to play with so that's 3/4 of available ram there
	
	public ClassA(ClassB classB)
	{
		m_classB = classB;
		m_callback = new Callback(this);
		m_classB.AddCallback(m_callback);
	}

	public void CleanUp()
	{
		m_classB.RemoveCallback(m_callback);
	}

	public void Update()
	{
		m_count++;
	}
}

public class ClassB
{
	public void AddCallback(Callback callback)
	{
		//Add callback to a list of Callbacks
	}

	public void RemoveCallback(Callback callback)
	{
		//Remove callback from the list of Callbacks
	}

	public void OnEvent()
	{
		//Loop over list
		{
			m_callbackList.get(i).Update();
		}
	}
}

public class AppClass
{
	public void main() //Not sure of entry points in Java apps as I use Android which works a little different
	{
		ClassB classB = new ClassB();
		
		//Some short lived section of the app
		{
			ClassA classA = new ClassA(classB);
			//Does stuff with classA
	
			//Part of app that uses ClassAs is over so clean up or else the callback will keep classA around
			classA.CleanUp();
		}
	
		//Something that needs the memory that classA would have been using
	}
}

If there's a better way to handle that sort of case let me know.

[quad64bit]

Basically any bugs involving multiple threads where the order they finish in could cause a crash.

Why would you write your code in such a way that there are no checks? Thats what thread control and synchronization controls are for - synchronized{} .join() .interrupt() .wait() .sleep() .notify() etc... In the multi threaded apps I've written, either there are many workers (in which case order is irrelevant) or if order matters, then using join, wait, notify, etc... deals with ordering, concurrency issues, and verification.

I don't see how c++ magically spawns threads that somehow would avoid the situation you described. Can you give an actual example? Are you telling me that all c++ spawned threads complete in fixed, known time?

[Skiller]

Why would you write your code in such a way that there are no checks?

You wouldn't that's why it'd be a bug. It's just that it is harder to track down bugs when you can't reproduce them reliably. As I said the same thing does happen in C++ but in C++ the consistency of the bug would be pretty much the same each time you run the app as the native code would not be changing, in Java it's not known if the JIT compiler in that particular execution of the app has compiled things in a way that the bug is likely to occur potentially leading to a lot of wasted time waiting for it.

[quad64bit]

You make it sound like that because the compilation is just in time, somehow the code is different every time you run it. Thats not the case.

[Tolls]

.. snip Callback stuff ...
If there's a better way to handle that sort of case let me know.

That's a Listener (or Observer), not a Callback.
Consequently, as per the way a Listener works, until it's unregistered then it will hang around.

A Callback is a briefly lived interface (usually) so the underlying code has a way of calling back into the original calling code. It isn't registered with the calling code.

So yes, you have to unregister your listener.

[Skiller]

You make it sound like that because the compilation is just in time, somehow the code is different every time you run it. Thats not the case.

Sure the code is the same and unchanged but the point is that the number of instructions is not so the time it takes to execute the code is inconsistent. However maybe it's just for the dalvik VM that Android that uses that the JIT can compile differently each run as I haven't looked into the workings of other JVMs.

That's a Listener (or Observer), not a Callback.
Consequently, as per the way a Listener works, until it's unregistered then it will hang around.

Ahh sorry for the confusion then, didn't realize they were called listeners, it looked similar to how callbacks work in C++ except that it passes a whole class instead of just a function pointer like in C++. I guess that's also why I had trouble finding info on design patterns for them ;).

[Tolls]

Ahh sorry for the confusion then, didn't realize they were called listeners, it looked similar to how callbacks work in C++ except that it passes a whole class instead of just a function pointer like in C++. I guess that's also why I had trouble finding info on design patterns for them ;).

Even in C++ I never stored a callback.
If it ended up being stored it became (as a pattern) an Observer.

Callbacks (in my mind) are a onetime thing. I call method A somewhere and provide a callback so that method A can call something on me, whether as a way of providing results or as a way of getting more information.

So in Java something similar might be:

void methodInMyClass() {
    someObject.someMethod(new MyCallbackInterface() {
        public void update(SomeClass sc) {
            ... do some update work on the object this anonymous class is in.
        }
    }
}

That callback object will then expire once it's out of scope, ie at the end of methodInMyClass().