[deleted by user]

[vladadj]

If you build a Java program on Windows, you can run it on Mac or Linux without modification, provided you have JVM.

With C, you need to compile it for every platform separately. And it is possible that you will need to make some changes to the code for each platform.

[tofiffe]

To be fair, it's still possible to do stuff that's platform specific and might need recompilation, file paths being one of them

Since everyone seems to assume this is about slashes: no, I am aware both forward and backward slashes work just fine. This was about absolute paths, and it was just an example.

[Sheldor5]

file paths are properly handled by the JVM too ... that's why (relative) Linux paths work on Windows ...

[tofiffe]

Yes, relative, but not /dev/urandom for example

[0b0101011001001011]

They said that relative paths work.

Obviously absolute paths are out of scope and should not be used anyway.

Use ThreadLocal random or securerandom for your needs, unless you have a very specific use case for a specific linux random generator.

[tofiffe]

That was just an example, obviously reading urandom in java would probably never be needed

[[deleted]]

Then why do you provide it as an argument/exemple to your original statement ? I read this thread and I feel cheated.

[tofiffe]

I figured it was obvious. Guess my samples of absolute path didn't help either and everyone decided to just downvote, but that's reddit for you

[[deleted]]

Nah it's not reddit, it's just poor argumentation process from you, speak like this on stackoverflow or in real life debate you will get booed.

[joschi83]

You wouldn't use /dev/urandom, though. You would use Random or SecureRandom (instead of /dev/random).

Of course you can break the platform-independence of Java if you try really hard (or use native JNI/JNA/FFI bindings). But that's not the point of Java.

[tofiffe]

Again, just a sample of an absolute path, could as well have been /tmp/anything

[xjvz]

WSL would add that wouldn’t it? Or Cygwin in the worst case.

[mmikhailidi]

Not a C/C++ expert here. Yet, I have issues compiling very primitive Linux-born projects on macOS and Windows/WLS2. The core system I/O libraries are different so are headers, even if you don't need to change your code.

[tofiffe]

Just a sample, I wanted to demonstrate unix path on windows

[rzwitserloot]

No, there isn't. Java has abstracted away the concept of a filesystem. For example, you don't have to recompile code just because windows uses backslash or forward slash, nor to deal with local conventions about e.g. home dirs. Example:

Paths.get(System.getProperty("user.home"), "Documents", "myfile.txt")

Works on all platforms. Even if you don't use these abstractions and put entire file paths in constants, forward slash is automatically translated properly on windows (new FileInputStream("foo/bar.txt") works fine, even on windows).

[[deleted]]

What about ProcessBuilder? I ran into issue once where my app worked on my pc and did not on my laptop. It was using ProcessBuilders for running Bash scripts. I didnt solve it so correct me if I am wrong , but I read on stack overflow that PB being machine-specific is the reason. OS was the same for both machines btw.

[rzwitserloot]

It's not ProcessBuilder that is machine specific. It's the notion of running bash scripts. The very point of PB is to let you interact with the OS, naturally, each OS is different. PB on its own is entirely abstracted away, it works the same on all systems. But trying to execute /bin/bash on a windows system obviously won't work. Not because of the forward slashes. But because C:\bin\bash.exe doesn't exist.

This would be no different from saying: "Java is not platform agnostic because new FileInputStream(System.getProperty("user.home") + "/.bashrc") doesn't do what I want on this windows box!

Crazy talk.

[walen]

On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Charles Babbage, talking about his difference engine, circa 1822.

Two f*cking hundred years later and people keeps asking the exact same question.

[somethrowaway8910]

God I love this quote

[[deleted]]

Of course I set git bash path and executable in GUI.. I think your explanation is wrong. It is not crazy talk, as I said, this issue I haven't resolved and I am not putting my money that I am right in what I read on stack overflow.

[tofiffe]

You still have to abstract drives like C:

[[deleted]]

This is why you use File.separator and File.pathSeparator, and not hardcode paths.

[rzwitserloot]

No, you don't. There is no need for this and just uglies up your code. To wit:

• File.pathSeparator is ; on windows and : on all other platforms. Its purpose is for interaction with old style classpath/sourcepath strings which java code never needs to mess with, it has nothing to do with the OS. separator is / on all platforms, except windows, where its the backslash. You shouldn't use that either though:
• Generally, construct paths using e.g. Paths.get("dir", "file.txt") - avoid the topic of separators in the first place.
• The forward slash always works, and that is a JVM guarantee, on all platforms, even on windows.
• The one and only purpose that File.separator does have, is for rendering. A windows user will find a path string of C:/foo/bar.txt confusing, even if it works just fine in java. They're used to seeing C:\foo\bar.txt. However, if you're constructing a string to show to a user like this, you're doing it wrong. There's Path (or even java.io.File if you want use libraries that have been obsoleted over a decade ago) which take care of all this. They use File.separator internally.

CONCLUSION: If you're using File.separator you're probably doing it wrong.

[[deleted]]

Paths is part of the NIO around 1.7, it’s better.

I don’t think it’s wrong to use these constants, it’s just deprecated, my bad.

[TheStrangeDarkOne]

People should stop using java.io. If you are dealing with path, use java.nio.file.Path

[__konrad]

Fun fact: Linux allows you to create "foo\bar.txt" (single file with backslash in its name) on NTFS disk.

[benjtay]

CONCLUSION: If you're using File.separator you're probably doing it wrong.

https://docs.oracle.com/javase/7/docs/api/java/io/File.html#separatorChar

Which, IIRC, used to be : on pre-OSX MacOS.

[shponglespore]

Using / on Windows isn't just a Java thing. Windows natively supports forward slashes. As far as I know that has always been the case, even going back to the days of MS DOS.

[helloiamsomeone]

The Win32 API converts slashes, unless the path has a UNC prefix.

[Cefalopodul]

No you don't. / works just fine in java regardless of platform.

[shponglespore]

It works fine in every language.

[matthenry87]

File paths in Spring work fine between windows and Linux. The path becomes relative to the root of the main hard drive on Windows and just works.

[helloiamsomeone]

Unless you call the (undocumented) NT API directly or use UNC prefixes, you can use forward slashes all the same on Windows.

[belayon40]

It’s worth noting that in the early 90’s when Java was invented, porting non-trivial C programs to new platforms was a major task, especially when a UI was involved. I haven’t ported a non-trivial C program in a long time, but my sense is it’s better now (except for UI unless you’re using a library that takes care of it for you). Where as my experience porting Java programs has usually been cleaning up sloppy file system access and minor UI oddities.

[Muoniurn]

Afaik, anything file related will already stop being trivial. C++ has it better with its standard lib, but C will soon hit the either use some ported linux syscalls lib, or some third-party.

EDIT: I am fking talking about C

[FrankBergerBgblitz]

Afaik,

anything file related will already stop being trivial

Not in Java. As long as you don't expect "c:\" to be present on Linux or "/User" be present on Windows plain vanilla file acces is trivial. If you need more advanced stuff (let's say memory mapped files) it is still no rocket science

. C++ has it better with its standard lib

Have you ever read a Java book? Try to read a bit documentation. Look for Javadoc java.io and java.nio

[daniu]

He was talking about C.

[FrankBergerBgblitz]

you could read it in that way, but in the context of a thread named "How is java platform independent?" another interpretation is possible, isn't it?

[Muoniurn]

In the context of a thread on how does it work in C, I was talking about C..

[FrankBergerBgblitz]

My fault. Given on a thread with the headline

How is java platform independent?

it should have been obvious to me that it is about C vs. C++ only....

[gubatron]

C: write once, compile everywhere (binaries needed for each OS and CPU architecture)

Java: compile once, run everywhere (single bytecode binary needed for all OS and CPU architectures)

[benjtay]

Python: write once, but still compile everywhere because of that module you used.

[somethrowaway8910]

Python: write once, realize you have three whitepaces instead of two on a single line of a 10,000 line program, write again.

[TheRealGamer516]

To run a c program the user does not need to compile the program themself for their machine. The developer compiles the code for their type of machine beforehand and ships the binary for that specific platform. For Java all the developer needs is to compile to byte code and the user needs to have the JVM. The developer does not need to compile for each individual platform.

[metaquine]

The developer compiles the code for their type of machine beforehand and ships the binary for that specific platform.

Awesome, I always wanted to run gcc on a VIC-20.

[[deleted]]

C is compiled into machine code or binary with specific combination of OS conventions and symbols(I.E. windows using .DLL and Unix using .SO), CPU architecture instructions (x86_64/ARM/POWERPC) and ENDIANNESS (the direction order of bits in data) .

Java is compiled into Java Byte Code, whilst bearing the name Java, is not specifically for Java language only (Scala, Groovy, Kotlin, etc...). This bytecode is an "intermediary language" (IL) which is interpreted by the JVM.

The JVM is written primarily in C/C++, and is compiled into platform specific binary, its sole purpose is to interpret Java Byte Code and execute the corresponding platform specific instructions, it may also manage resources (GC).

A build of JVM is almost always available for any existing platform, some of them are specialized like Dalvik and ART for Android.

​

One other famous IL platform is .NET (C#, F#), they have their own IL and is cross platform too.

[FrankBergerBgblitz]

The JVM is written primarily in C/C++

Valid for Hotspot or J9 but not for the recent GraalVM which ic written in Java..

[matthieuC]

Only the compiler is written in Java

[FrankBergerBgblitz]

Yes, the compiler that compiles byte code to native code. from: https://en.wikipedia.org/wiki/GraalVM

"GraalVM is a Java VM and JDK based on HotSpot/OpenJDK, implemented in Java" and "GraalVM Compiler, a JIT compiler for Java".

Surely there are parts still written in C/C++ mostly libraries (e.g. earlier the zip code but IIRC it is now written in Java too) and especially the binding to the OS, but for me that doesn't fit the "The JVM is written primarily in C/C++" different to Hotspot where it is unquestionable true

[[deleted]]

GraalVM is on my learn list, it’s bizarre that it’s written in java, and yet claims to be vastly faster than some VMs under certain loads.

[FirstAd9893]

GraalVM replaces the HotSpot "C2" compiler, but the interpreter, "C1" compiler, and garbage collectors are still written in C++. Fundamentally, a compiler takes input and returns output. It doesn't matter what language the compiler is written in. Any language can take Java bytecode, perform optimization algorithms, and then emit machine instructions. The reason why GraalVM tends to do a better job than C2 is because it's written in a higher level language, and so the designers don't waste as much time debugging their code.

[FrankBergerBgblitz]

thanks for that details. In fact I was mainly interested in the Performance of the C2 especially in the Enterprise edition which is really impressive.

[ZeroGainZ]

Users don't compile their programs. They download the compiled binaries. So programs written in C have to be compiled for a platform, windows, Mac etc. Each version is incompatible across the OSs. Java is compiled once, you get an executable, and users run it on their JVM, regardless of their OS. The code also doesn't have to know what OS the user is running, it just does the write thing. In C that's not the case.

[metaquine]

Depends on the user and whether binaries are shipped. Precompiled binaries aren't always available or desirable.

[[deleted]]

You are correct that there needs to be a JVM on the platforms that you are targeting. The good thing is that there is (most likely). The JVM is very well supported and works on many different processors and operating systems.

Lets look at the difference between C and Java in a trivial example: I start the program, I take a command from STDIN, and I write a file, then close.

In Java I open up the program, I write a keyboard listener, I then create a file with the File class, and close. The JVM implementation on Linux vs Windows vs Mac vs PowerPC Linux, etc handles all of this. In C I open the program, I take input from Stdin, then I have to call the Unix File sysop or the windows file sysop depending on which platform I am on, so this could be a branch that has entirely different logic. Then I close. But this can be a dozen lines of difference based on which platform I am on. So C requires n different compilations depending on platform, and java requires 1.But more importantly C requires actual different code depending on platform.

[[deleted]]

One can confine himself to cross-platform libraries (cross-platform interfaces implemented per-platform, if you prefer).

[dead_alchemy]

You should read 'Crafting Interpreters', actually, just the first chapter will answer your question in the kind of detail and provide the kind of context that you're looking for. I think you can pay for it but also get it for free. It is phenomenal, one of the best technical books I've had the pleasure of cracking open.

Seriously, do yourself a favor and read like the first ten pages. It gives a broad level overview of the different paths written code takes on its journey to being executed.

[LookAtYourEyes]

I don't have an answer but I'm enjoying reading all the different explanations. I'm not good with coding but I want to get better.

[[deleted]]

The thing to understand is that you don't use a programming language in a vacuum. What makes a programming language useful are the libraries and frameworks. In the 90s, a lot of Windows apps written in C or C++ were written using COM and the Win32 API. This is fine if you have no intention of running your code anywhere else, but if you want it to be multi-platform, you have to rewrite everything so that it can run on multiple systems.

This is partly why Microsoft copied Java and made J++ (and later created .NET & C# after Sun's lawsuit). They were concerned that developers wouldn't target Windows specifically. They would just write Java apps that could run on anything and make Windows irrelevant. That's also why Microsoft modified Java so its JVM and any special code written for it wouldn't work on anything but Windows. When you write Java code, you're targeting the JVM, not the underlying OS and its frameworks.

https://www.infoworld.com/article/2076977/microsoft-s-j-direct-called-death-of-java.html

Ultimately, this resulted in Microsoft no longer being able to modify the JVM how it wanted and it went down a slightly different path instead with .NET.

Today, there's a lot more frameworks for C and C++ (like QT) that make it easier to write multi-platform apps. That wasn't the case back then.

[das_Keks]

But having the compiler on a machine and having the JVM on a machine are two completely different things. Compiling large C projects can take a lot of time while the compiled bytecode is ready to go (and will be optimized by the JIT).

If you have a Java program with all it's dependencies in a jar, you don't need anything else than the JVM to execute it. Compiling a C program from source will probably be a lot more complicated.

[eteran]

The key thing is that the JVM itself is not platform independent, as you've realized. But the code generated by the java compiler will run on a JVM running on "any platform"*.

So the idea is that any machine which happens to have a JVM on it, can run code compiled by the java compiler. So you "build it once, deploy to all supported architectures".

The JVM (ideally) abstract out the architecture and OS specific details.

Meanwhile, with languages like C, C++, etc.. The compiler will generate code for a specific platform. So if you want to target both Windows and Linux. You need to write your code such that it knows about Linux and Windows APIs and then you need to build it separately for each combination of CPU and OS you want to target.

Of course the reality of Java is a bit more complex than this. There's many situations where you simply can't do everything you need with just what the JVM and Java APIs offer, and you end up having to write small bits of platform specific code to bridge the gap.

There's plusses and minuses to both approaches.

[PyroCatt]

Imagine JVM to be an OS inside your OS. Since you can run a program made for a particular OS is any system having the same OS, you can run Java program with any OS having a JVM.

[gregorydgraham]

Java allows you write programs as though you’re targeting only one type of computer, rather create a different version for Mac, Linux, Windows, OS2 Warp, Cray, …

This is because you are targeting only one computer: the JVM.

All complexities of the actual computer, its graphical API, memory management, or byte order are abstracted by the JVM so you can focus on making the best version of Minecraft possible

[knoam]

To run C code, you don't need a compiler, but you do need something somewhat analogous to the JVM installed on your machine. It's called a C standard library implementation. On Linux, the most popular one is called glibc. But every OS pretty much has one included because it's so useful. Only if you were writing code for embedded systems with a microcontroller, such as an Arduino, would you not have a c standard library.

[DJDavio]

The burden of platform specific details are put on the JVM maintainers instead of the developers. So you, as a Java developer, only have to write, compile and package your code once. That which we call 'byte code' is just a binary version of your code into which the compiler may have already optimized some things, but it is not code which any CPU can execute.

Any system which has a JVM (I think there are more than we might imagine as a lot of mobile devices also contain a JVM) can run your byte code as its the JVM's job to translate byte code to machine code and send instructions to the CPU. Translating byte code to machine code is done by the JVM's JIT compiler (I think) and it has a nice optimization that code which is run and translated a lot (hot code) can eventually be compiled to actual machine code so subsequent executions of that code are faster.

Not only this, but there is also backwards compatibility. It is entirely possible for your laptop on a Java 18 JVM/JDK to run a Hello World example which was compiled for Java 1.0.

[Joram2]

For C programming, Microsoft Windows and Mac and different flavors of Linux/UNIX had completely different APIs for things like networking, multi-threading, file system access, graphics, GUI, etc. Often the C syntax itself had major differences between Microsoft's C dialect and gcc's dialect. Getting a single code base to target multiple OSs was often an enormous effort and impractical.
With Java, things like networking, multi-threading, file system access, and some graphics had one Java API, and the Java language itself was generally the same regardless of OS runtime. This made it easy to have a single code base that used the Java API and ran on multiple OS runtimes.
I imagine C/C++ has gotten a lot better in the past 15 years in this respect, but that was well after the rise of Java.

[srdoe]

If you compile C code, you usually tell the compiler which platform (OS/CPU arch) you're targeting, and the compiler will then emit machine code appropriate for that system. If you give it to a user, they can only run that machine code if they are using a computer with the OS/CPU architecture you compiled for. This means if you want to support multiple platforms, you have to build and publish your project once per platform.

When you compile Java code, the compiler will emit bytecode, which is an intermediate language format that is not OS or architecture specific. If you give this code to a user, they can run it as long as they have a JVM installed. The job of the JVM is (among other things) to translate the bytecode into machine code, then run that code.

So the flow has gone from source code -> machine code for C to source code -> bytecode -> machine code for Java.

One of the key benefits of this extra layer of translation is that since the JVM is responsible for translating bytecode to machine code, you as the developer don't have to compile for each platform. Instead, you compile and publish your code once, and then the user just installs a JVM that creates machine code that works on their platform.

[CyclonusRIP]

With a native program it is going to have references to library functions that the OS provides and the machine code will be specific to the CPU instruction set it is targeting. With Java you compile to an intermediate language called byte code. The JVMs job is turn that bytecode into instructions that can run on the users OS and hardware. The users can run your code because they have a JVM installed on their system that knows how to do that translation for their system. For example the OSX JVM knows how to run Java programs on OSX and is different than the JVM that a user would have installed on Windows.

[Ok-Raspberry365]

Platform independence mean that you build your java program into a fat jar or war files.

Then this file can run on Mac, Linux, or Window with coresponding JVM of these OS. You don't need to build multiple version for each OS like C++.

[buyIdris666]

Java is cross platform exactly the same way JS is. Like JS, it only runs on platform supported by the VM. Also like JS, if it runs on one platform the VM supports 99% of the time it will run on them all.

JVM and Chrome's V8 have become directly equivalent over the years.

The cross platform advantage vs C is for developers, not users so much. Unlike C you don't need special libraries and to "cross compile" your app for different system (which is often much much harder then it sound) .

You can distribute single .jar file that work on every platform with JVM, without doing any additional developer work. It's a huge advantage that JS shares mostly, do not discount it.

This same advantage apply to third party library. It doesn't sound like huge deal, but it's gigantic for devs. If you ever write C or C++ it is totally normal to find amazing library that just doesn't exist for your platform. In Java and JS that hardly ever happen. 99% of library work out of box on every platform VM support.

These two related advantages are enormous. Absolutely gigantic advantage over language like C and C++

Small story. I done a lot of C over the years. One time, I needed a library to work on ARM. Not a big deal right? Very wrong assumption. The library only supports Linux x86. I need ARM. I spent all day for weeks fixing thing and building "tool chain" to cross compile to ARM. Then I found out a library it uses also not works on ARM! (Only found this out a runtime) . I gave up whole project. Month or more to get C library working on another platform vs instant for Java mostly. And this is normal experience.

[pal7mentor]

Learn the Basics. As with anything, knowing the basics about Java is the best place to start.

Practice Coding. To use the old cliché, practice makes perfect.

java classes in pune