Java versus other languages

[Adam Chalkley]

Hey guys,

for the past year mainly I have just been using C++,I have taken a slight detour from Java reason being this year my course focuses more on C++ rather than Java which was the first 2 years,

my question is not really a technical question but more so an opinion based one,So since this is a Java forum why do you prefer Java over other languages?

I can see some advantages such as Javas garbage collector,no out of bounds array indexing and mainly the JVM which is a huge plus.

There are some notable difference between C++ and Java,such as Java seems to create all objects on the heap where as in C++ you can declare objects on the heap or stack,operator overloading does not exist in Java,C++ makes you manage your own memory,Java does not have structs,In Java everything must be in a class so does not support functional programming.

What makes you choose Java over languages like C/C++?

There are some things I like and dislike,the thing I like about Java as I mentioned is the JVM something I don't like is it's swing and AWT gui libraries the layout manager is quite tricky and a pain to get right.

So with C++ being a faster language in general and having more options what makes Java appealing? I mean both languages syntax wise are almost identical and I would say it's actually not too hard to make the switch from one to the other.

In the future I plan on making android apps which are mainly Java based.

but if you were writing a desktop which language would you generally choose C++ or Java?

thanks

[Carey Brown]

I developed with C++ for almost 15 years before switching to Java. Now I'm approaching almost 20 years with Java. I would take Java over C++ any day. Java in its infancy was not particularly fast but that has mostly been taken care by JIT compilers.

Java pros:

Write once run anywhere. (somewhat ... depends on how you write your code)

Lots of run time checks that you don't have to implement yourself: bounds checking and casts for instance.

Lots of classes come with the Java distribution.

Doesn't have the pitfalls of pointer arithmetic.

Strings are more efficient because they don't depend on the character value zero to mark the end.

I don't really miss operator overloading.

GUI support.

Java cons:

On rare occasions I miss destructors. They were handy in instrumenting the life cycle of an object for debugging. (They were also a source of many bugs.)

Stupid but handy things are missing, like: __FILE__ and __LINE__.

Operating systems don't treat an executable jar file like any other command. (Batch/script files somewhat work around this.)

I wish Java didn't permit the int array[] = new int[0]; syntax. Note position of "[]".

I wish java (or an IDE) had a tool to look for violations of the Java naming conventions.

[Tim Holloway]

I think it may have been Alan Kay who once described Java as "C++ without the mace and knives".

Having been a pioneer in C++, I was inclined to agree.

C++ is very powerful and I'm using it a lot lately on the Arduino platform, where it's basically the native language. But C++ can be a real pain, especially early C++, when there were fewer standard libraries. Java's rich set of built-in classes and its many widely-supported add-on libraries make it a lot more fun than having to re-invent all that stuff from scratch - or learn multiple library sets.

A lot of people also have gotten themselves into big trouble in C/C++ because they didn't take enough care with new/delete operations. It's never been a problem for me personally, but I'm weird.

I'm currently trying to shoehorn some special functionality into the Domoticz home automation system. Domoticz is primarily written in C++, I think, and that includes a written-from-scratch webserver. Love it or hate it, at least Java has the J2EE/JEE standard and a wealth of different implementations of it, from simple jetty and Tomcat up to WebLogic and WebSphere. That means that a whole lot of a Java application is noth even part of the application source, so there's less code to puzzle over. And when you factor in all the third-party libraries that JEE webapps typically employ, from logging, to email, to database persistence to general resource management (for example, Spring) and on to UI subsystems, it really makes me a lot more productive.

In fact, when it comes to web applications, C++ is probably my last resort. For heavy lifting and high security, my choice is Java, for quick-and-dirty, it's generally NodeJS or PHP. For something intermediate, I might go with Python and the Django framework - Python also has a rich standard infrastructure. Then there's Perl CGI.

Note to Carey:

There are tools available that can check Java code for violations of shop/industry standards. Also, __FILE__ and __LINE__ aren't really applicable in Java since Java doesn't have a pre-processor like C or C++. The file and line information are stored as part of the class for use in stack traces.

On the other hand, lack of destructors means that certain types of resource leakage can be very hard to detect. Especially those involving open files or database connections.

[Campbell Ritchie]

But there are design principles for closing files and databases.

[Tim Holloway]

Campbell Ritchie wrote:But there are design principles for closing files and databases.

Yeah. And a lot of people manage to thwart them by failing to close when an exception bypasses the normal flow and they don't have an exception or finally handler. One reason why I learned to love Spring. Let it worry about that stuff.

I also inherited an app from an experienced programmer who thought that the garbage collector would do the closing. Which it should. Eventually.

[Ivan Jozsef Balazs]

The try-with-resources construct is useful for resource management.

By the way constructors and destructors are useful, even though you could argue against them saying "there are design principles for proper initialization and deinitialization".

[Tim Holloway]

Ivan Jozsef Balazs wrote:The try-with-resources construct is useful for resource management.

It is very useful. Unfortunately, it's also relatively recent, so a lot of old code has had to make do without it. Some of that code managed better than others.

[Campbell Ritchie]

Tim Holloway wrote:. . . the garbage collector would do the closing. Which it should. Eventually.

Is that before or after you reboot your computer ?

[Campbell Ritchie]

Tim Holloway wrote:[try-with-resources is] also relatively recent . . .

Yes, so many tutorials showed a plain simple close(); call but you really needed it in a finally block.

[Tim Holloway]

Campbell Ritchie wrote:

Tim Holloway wrote:[try-with-resources is] also relatively recent . . .

Yes, so many tutorials showed a plain simple close(); call but you really needed it in a finally block.

And the close in turn should be in a try/finally block, since a close could potentially throw an exception as well.

[Carey Brown]

Tim Holloway wrote:.... Also, __FILE__ and __LINE__ aren't really applicable in Java since Java doesn't have a pre-processor like C or C++. The file and line information are stored as part of the class for use in stack traces.

The __FILE__ and __LINE__ were macros in C/C++ but wouldn't have to be in Java. Yes, you can get those from stack trace information but that has run time overhead that a compute at compile time needn't have. With Java I end up with something like this, but I'm open to better solutions.

public class TryStackTrace
{
	public static void main( String[] args )
	{
		print( new Throwable() );
	}

	static StackTraceElement getTopOfStackTrace( Throwable throwable )
	{
		return throwable.getStackTrace()[0];
	}
	
	static void print( Throwable throwable )
	{
		StackTraceElement		elem = getTopOfStackTrace( throwable );
		System.out.printf( "Class=%s   Method=%s   File=%s   Line=%d%n",
				elem.getClassName(),
				elem.getMethodName(),
				elem.getFileName(),
				elem.getLineNumber() );
	}
}

Output:

Class=TryStackTrace   Method=main   File=TryStackTrace.java   Line=5

[Tim Holloway]

Actually, __FILE__ and __LINE__ were more likely to get used to fake out "overlay" code. For example, the original C++ translator converted C++ to C, but the C++ source line numbering often didn't match the generated C code line numbering to this was how you got it resolved. I think some of the YACC ilk fudged things similary.

I'm not sure why you expect there to be more overhead in Java using its class-internal line numbers than any other way. All they effectively are is unnamed class members and I'd expect the same overhead as with named class members.

[Carey Brown]

FILE and LINE would become String and int constants which I presume to be cheaper than creating a Throwable object at run time.

[Tim Holloway]

Carey Brown wrote:FILE and LINE would become String and int constants which I presume to be cheaper than creating a Throwable object at run time.

That's assuming that the compiler didn't optimize all of that out.

However, since the example takes a Throwable as an argument - meaning ANY throwable, not just the indicated location, the Throwable is really a container for statement context variables.

Anyway, not sure what high-frequency use you'd have for knowing what line number you're at.

[Ivan Jozsef Balazs]

Tim Holloway wrote:__FILE__ and __LINE__

Nobody prevents us from running Java (pre-) code through a C(++) precompiler :-)

[Tim Holloway]

Ivan Jozsef Balazs wrote:

Tim Holloway wrote:__FILE__ and __LINE__

Nobody prevents us from running Java (pre-) code through a C(++) precompiler :-)

Nothing prevents you from running anything through a C(++) precompiler. Although with Java, it's kind of awkward to interject other processes into compiles on account of how the process cross-consults multiple source files.

Still, it's not really __FILE__ and __LINE__ I miss in Java, it's #if/#elif/#endif and the #ifdef.

Although I have more or less reconciled myself to that. With Java, it's hazardous to have multiple incarnations of a class, and if you just want to kill dead logic, the compiler is smart enough to do that off of ordinary Java code. Early C compilers weren't that smart, nor did they have the highly-tunable logging support that modern languages do. So #if frequently handled enabling/disabling debugging, OS dependencies (no write-once/run-anywhere in C!) and other things that Java has more explicit mechanisms for.

[Junilu Lacar]

I see it from a much higher level than what you guys are talking about. I subscribe to Jack Reeves' proposition that code *is* detailed design and the act of coding itself is a design activity.

Many programmers who write code, i.e. design software, in Java already fall quickly into the trap of thinking about implementation detail too much. It takes a lot of discipline and skill to be able to write clear and expressive code that makes the design and program structure very evident. That means extricating your mind from the bog of implementation detail and really thinking about intent and purpose.

How much more in C++, where the language constructs are much closer to the bare metal? The language practically traps you in that implementation detail mindset. To see evidence of that, just look at all the kind of things you guys have been talking about so far.

Admittedly, I haven't programmed much in C++ and I'm sure there are programs written in it that are very expressive. But I don't know if even those approach the expressiveness you can have in equivalent Java code.

But if you're talking asbout expressiveness, even Java pales in comparison to other newer languages. It's trying to keep up and stay relevant with new features that support functional style programming but I think it's also being held back by its nature as a general purpose programming language.

Just my $0.02

[Tim Holloway]

Good point. As someone who's done a lot of both C/C++ and Java - and assembler, COBOL, Fortran, PL/1, Forth, Smalltalk, ...

Java has been very liberating to me. Because it's very abstract and because I can depend on it doing a high level of optimization at both compile and run times, I like Java because it has less guilt.

In the older languages, I worried about every byte and every machine cycle with each line of code I laid down. It was an especially hard hit for me because I have often worked all the way down to the bare metal doing real-time processors, OS exit routines and interrupt services, and other stuff that gets executed very, very frequently and/or absolutely must not fail. Java's very opacity has set me free, since there's really no way to compute precise memory usage or CPU consumption. I code to the abstraction and then tune - which is ideally how programming should be done. Although it's a lot easier to do when the entire system RAM isn't 1MB of mainframe core!

[fred rosenberger]

I think the question should be re-phrased to "WHEN do you prefer java...".

Java is a tool.  It does some thing well, and some things not so well. Just like a hammer, wrench, and drill are all tools. They all excel at some tasks, and are horrible for others.

[Harry Kar]

Not to pile on to what's already been pointed out (Junilu's dicit ) from my perspective here are two distinct points to consider:
1. Subjective point: When i use C/C++ i have a special feeling dunno how to express it better but Is like when you pilot a Ducati or Aprilia, Augusta, Benelli (Italian motorbikes) instead of a BMW(german motorbike) or a Jap Bike.You know that isn't reliable and perfect as a Jap or BMW but at the same time you know and moreover feel that you can do incredible things more easily than with others. That's the sensation/feeling

2. Objective point: The Language is not the target(i.e. make software) but one of the means/tools to achieve it. Apart the subjective point you or someone else have to choose the right language for the project at hand

I share the Junilu's & Tim's point Java is more expressive from an Software Engineering point of view than C++ but on the other hand there are also newer languages as outsiders that predate Java

[Harry Kar]

Who's interested about (basic knowledge on)  formal language's evaluation criteria (and not only Java Vs world -but are applicable in Java as well-) take a look here  (work in progress but planned to finish today so press frequently F5-refresh page- on your browser )

[meenal deshpande]

It depends on what are you trying to achieve. I'd say Java has a bit wider scope.

Java can be used for desktop applications which don't need overly sophisticated interfaces, and it will work on many different platforms, and you don't need to invest any effort
Java is a good server-side language (forget PHP!)
Android framework is based on Java, and by knowing Java you can start writing Android apps in no time
It's a verbose, OOP language and everything is based around classes
You don't need to worry about memory and pointers, and leave that to the garbage collector
C++, on the other side:

gives you more control over your code (that means you may manage allocating/freeing memory manually, etc)
is faster, and the main advantage is that it is compiled to machine code directly. Java can be on par, but only with long-running processes (I believe even that C++ can be a bit faster if done correctly)
is usually used for game engines, as you need every millisecond you can get
is used for writing operating systems, because you need to have full control over the computer, and to be as fast as possible
tries to incorporate many different things into one language, making it confusing for beginners
makes shooting yourself in the foot very easy, and recovery from the shot very hard
Knowing one is a solid foundation for learning the other, though be advised that even if their syntax is very similar, they work in a different way and preferred ways of doing things will probably differ.

[Campbell Ritchie]

meenal deshpande wrote:It depends . . .

Agree there.

C++, on the other side:
. . . is faster. . . .

What evidence do you have for that?

is used for writing operating systems . . .

Because it supports direct manipulation of pointers.

makes shooting yourself in the foot very easy . . .

Hahahahahahahahahaha!

Knowing one is a solid foundation for learning the other, though be advised that even if their syntax is very similar, they work in a different way and preferred ways of doing things will probably differ.

I have seen so many people who think that C++ and Java® work the same way, when they don't.

[Harry Kar]

meenal deshpande wrote:..C++ and Java both are the Object oriented programming language, which one is the best it’s tough ...

As a rule of thump C++ today can be used whenever Java is used and the opposite is also true but that's only a rule of thump  

[Tim Moores]

As a rule of thump C++ today can be used whenever Java is used and the opposite is also true

I disagree. It's true in the sense that both languages are Turing-complete, and there's nothing that one of them can do that the other can't do in principle. But the lack of a running JVM in many environments where C++ code is used (like device drivers, OS kernels etc.) would make the use of Java impractical. And the JVM sandbox makes efficient low-level access to system internals impossible (unless we're talking about all-JNI all the time, but even then you'd need a JVM), which rules out Java's use in such environments.

[Tim Holloway]

Harry Kar wrote:

meenal deshpande wrote:..C++ and Java both are the Object oriented programming language, which one is the best it’s tough ...

As a rule of thump C++ today can be used whenever Java is used and the opposite is also true but that's only a rule of thump  

Actually, the term is "rule of thumb. It's based on the idea that you can use your thumb as a rough unit of measurement - handy if you don't have the Pharoah's foot handy.

Java requires a virtual machine to run in, so it doesn't work very well at the lowest OS levels - you'd need the VM to be implemented in the machine's very microcode. Which has been done, but that's not how Intel X86 CPU's work. Actually, I used to work on a machine that had special instructions to support the Fortran language in it, and the last decade or so of IBM mainframes have had much of the C standard library in microcode, but it's still more the exception than the rule. Fun fact - reprogrammable CPUs were the product of the company that Linus Torvalds first worked for when he came to the USA.

There has been some work on native Java machinery at BEA/Oracle and IBM, but nothing mainstream.

Actually, even C/C++ strain to work at the very lowest OS levels, since that's where the really specialized instructions are used and they are rarely tied to specific high-level language constructs. Most OS's either have a small assembly-language core or there's an "escape" mechanism in the compiler to code raw machine instructions. In C/C++, that's usually a #pragma.

People "know" that C, C++ and assembly are faster than Java, because they generate raw machine instructions. However, that's not necessarily so. For a long time now, Java has supported JIT - the Just-in-time compiler, which, for the one-time-cost of compiling hardware-independent bytecodes at runtime can be just as fast as those languages. Bytecodes require a lot less effort to parse and analyze than raw source code does. And Java has one advantage that statically-compiled languages do not. A sufficiently-intelligent JVM can monitor code, see how it's being used, and recompile that code to result in a more efficient set of machine-language instructions.

You have to have a fairly large, long-running program to really see the benefits of JIT compiling/optimizing, but that's exactly what a lot of web-based systems are.

So there's a lot of overlap, and there's not always a clear winner. C and C++ and assembler are generally better at close-to-the-metal, Java is (in my experience) better for Enterprise-grade applications (mostly because of the discipline and support features), Python is my go-to quick-and-dirty command-line tool - except when there's lots of regexes, in which case it's Perl. Javascript and PHP are for quick-and-dirty webapps. I also use Ruby, since that's what Puppet employs, and various other languages as the need suits.

Revisiting what I just said about Java discipline and support, I'm presently working/struggling with Domoticz, which is an open-source home automation monitoring and control system. Domoticz is multi-lingual, some of it's in C++. some of it's in Lua, some of it's in Python. One of the biggest challenges I have with it is that its extension mechanisms are fairly limited and often times things that could have been done abstractly are instead done by mods to the core server itself. And unlike Java, where the server implementation and application are two distinct entities (or even NodeJS, for that matter), the app and server are one here and there's no standard for the architecture of a C++ webserver, only the need to conform to the RFCs. Which can be done in a multitude of ways.

And, as I probably said once or twice before (as have others), Java really is designed to be "write once/run anywhere".

[Harry Kar]

Tim Moores wrote:

As a rule of thump C++ today can be used whenever Java is used and the opposite is also true

I disagree. It's true in the sense that both languages are Turing-complete, and there's nothing that one of them can do that the other can't do in principle...

Yep i referred only regard the linguistic part of the two langs and abstract completely about the technology part -JVM (by the way sure we agree about JVM) sorry my mislead

[Harry Kar]

Tim Holloway wrote:

Harry Kar wrote:

meenal deshpande wrote:..C++ and Java both are the Object oriented programming language, which one is the best it’s tough ...

As a rule of thump C++ today can be used whenever Java is used and the opposite is also true but that's only a rule of thump  

Actually, the term is "rule of thumb. It's based on the idea that you can use your thumb as a rough unit of measurement - handy if you don't have the Pharoah's foot handy.

Sorry was a typo and thanks for "rule of  thumb" semantics; I(not native English) use it as "more or less" is correct that interpretation?  

Java requires a virtual machine to run in, so it doesn't work very well at the lowest OS levels ....

We agree on the whole line

PS :
what was the processor who runs Fortran microcode? and
can't remember right now the processor's  name(company's Brand) LT worked on but was an "advanced" one back then as i can remember

[Tim Holloway]

I suppose the best translation of "rule of thumb" would be "this is good enough for discussion, but don't calculate any Martian landings based on it".

The "Fortran" computer was Prime Computer. The (probably garbled) story is that Honeywell developed an OS for NASA - presumably for some project or other. Back then US tax dollars were expected to buy stuff for the US people, not whatever contractor wanted to then privatize and monetize them, so that put the code in the public domain.

But Honeywell at the time wasn't interested in developing minicomputers. A couple of Honeywell engineers, however, thought that there was an opportunity and so they took the code and set up an office in Natick, Massachusetts (later Framingham). They designed a set of circuit boards, about 18 inches square packed with TTL logic chips (LS to be specific, if I remember aright). Like IBM's mainframes, the raw instruction set was not machine language, but rather a matrix of gate logic states to actuate the various components and the machine language was the code that was interpreted to actually command these microcode sequences. You could also write your own custom microcode. This was still the era when computer companies sold service and the hardware and software was generally open-source and often free.

The Prime computers, like IBM's model 1130 did not actually have conditional jump instructions. Instead you'd code a conditional skip instruction which could skip over an unconditional jump. In the case of the Fortran 3-way branch, the comparison against a value (or against zero) resulted in 0, 1, or 2 skips. You could put a NO-OP instruction in one or more of the skip slots if it was convenient and get a 2-way jump for, for example, x not = 0. Or a skip. It was really rather neat. Needless to say, most instructions on the Prime computers were 1 word long, because skipping gets messy on machines with variable instruction lengths like the S/360.

Prime was very popular for a while. In fact, Tom (Dr. Who) Baker did a TV commercial or 2 for them. Ford Motor company was a major user. The Kennedy Space Center had at least one, I can personally testify, since the Prime customer engineer would occasionally come by and steal boards from our college machine as swap-outs for NASA. It's part of how we got the stuff at a discount.

Of course, PCs came out and nuked the minicomputer business big and small and Prime as it was is no more. Like Amiga, I think that they still exist in a vastly reduced form to this day, which, unfortunately means that a lot of interesting technology cannot be re-created the way other older computers has been once the need to keep them proprietary was gone. I do still have my old OS printouts from my tenure in that realm. The OS kernel was a rather fat assembly language file containing the low memory image, task dispatcher, semaphore and interrupt handlers and maybe a few other odds and ends, Just about everything else was stock Fortran.

[Harry Kar]

Tim Holloway wrote:I suppose the best translation of "rule of thumb" would be "this is good enough for discussion, but don't calculate any Martian landings based on it".

Exacty what i had in mind thanks ; by the way my typo probably got off cause a discussion i had local with some guys about Trump lol

The "Fortran" computer was Prime Computer...

Very interesting  Thank you Tim

PS:
1. About Amiga some time ago i remember had read someone patronized to reenter in production(in a limit number) a version of that machine but hae no clue how end up
2. I remember now probably is called meta or something similar the company LT worked (on a similar like "Fortran" processor project)

[Harry Kar]

Tim Holloway wrote:I suppose the best translation of "rule of thumb" would be "this is good enough for discussion, but don't calculate any Martian landings based on it".

Exacty what i had in mind thanks ; by the way my typo probably got off cause a discussion i had local with some guys about Trump lol

The "Fortran" computer was Prime Computer...

Very interesting  Thank you Tim

PS:
1. About Amiga some time ago i remember had read someone patronized to reenter in production(in a limit number) a version of that machine but hae no clue how end up
2. I remember now probably is called meta or something similar the company LT worked (on a similar like "Fortran" processor project)

[salvin francis]

Here's a few points from my perspective about java :

Team programming
I feel that java allows team programming efficiently. Since code is neatly arranged in a packages, every individual can work on his/own tasks with little or no effect on others. Similarly, when a project is broken down into multiple jars, teams can work on individual tasks. There are of-course exceptions to this workflow especially if someone is implementing global changes such as logging.

Code generation
Many IDEs have evolved around time. Today, I can simply create a class Employee along 3-4 fields and that's it. An IDE such as Eclipse can create all setters/getters/constructors/serialization id/documentation/overridden methods/etc with a few keystrokes. This is possible because the Java language itself has the guidelines over what good code should be like, how code should be documented and similar details. I don't know if other languages have a similar javadoc feature.

[Tim Holloway]

Most of my career, I've been Chief Cook and Bottle Washer. The one time I was on a more conventional development team, it was doing C, so Java certainly isn't the only team-suitable language.

In fact, when Fred Brooks introduced the Chief Programmer Team concept, the closest thing to Java or C available was PL/1*, and in fact, a lot of work was assembler, COBOL or Fortran.

The Java IDEs are powerful, but hardly unique. Many people rave about Microsoft's Visual Studio and swear it's the best thing ever. Since last Visual tool I worked with was pre-dot-Net, I can't say. Back then different releases of Visual Studio would break project builds, hastening my migration out of the Windows world.

JavaDocs didn't arise out of nowhere. Commode had a system called AutoDocs that was used to generate their developer manuals and IBM (among others) had had automatic flowcharters and other source analysis tools since at least the 1960s. I developed an AutoDoc-style commenting format that I used on C++ code files back in the early 1990s. It was an AWL script that created source for the Windows Helpfile compiler (and thus hyperlinked).

And of course, we should never forget Donald Knuth's "Literate Programming" system.

In Linux these days, the common standard is Oxygen, which can take source code from a variety of programming languages and build online documentation similar to JavaDocs. It steals heavily from JavaDocs, so expect many of the same annotations.

There's also documenters and standardized documentation style for Python. More languages than not these days support some sort of meta-comments I think.

====
* Algol didn't rate in the USA. It wasn't until Pascal that algol-style languages became common West of the Pond.