There are two kinds of drivers: 1. "open source" or KMS-drivers (stands for "kernel mode setting", whereby "mode setting" refers to the capability to configure the displays), and 2. "proprietary" drivers, which require proprietary kernel modules, commonly called "binary blobs".
For all graphics hardware, there are KMS-drivers, that are installed by default in most linux distros and are available in all distro repositories.
Intel only has open source drivers, they don't do proprietary drivers on linux. There are open source drivers for AMD and nVidia, the ones for AMD are developed by a specialized developer paid by AMD to develop those open source drivers, the ones by nVidia are developed by volunteers that have done a campaign on Kickstarter to fund the reverse engineering of nVidia graphics cards to make open source drivers from scratch, and to pay lawyers to fend off the nVidia legal trolls while doing that. The open source AMD drivers usually provide about 80% of the performance and functionality of the proprietary Catalyst drivers, and are getting better almost on a weekly basis, and AMD has confirmed that they will develop open source kernel modules that actually work with the Catalyst driver, so that binary blobs can be avoided, but at the same time, the performance benefit of the proprietary drivers can be had (some functions cannot be integrated in the open source drivers because patents are held by third parties, like for instance technologies that accelerate video encoding and decoding for certain formats, etc...). nVidia on the contrary is opposed to any form of open source or linux development, and therefore, the open source nVidia drivers only perform at about 10-15 % of the proprietary drivers, and offer very poor performance in linux, but are still preferred by many nVidia users because the open source drivers work and won't crash the kernel, unlike the proprietary nVidia drivers, which will crash X with every kernel update.
The AMD and nVidia proprietary drivers are none other than the MS-Windows drivers, hastily ported to linux. These proprietary drivers contain proprietary code that enables the high performance functions of those graphics cards, for which the code is not shared with the open source community.
A linux kernel is basically made by compiling a "queue" of modules. You can select the "features" the kernel should have, and then compile it. Most distros install a precompiled kernel that contains all the modules required for that distro. Most distros only provide open source software by default. That means, that the kernel they provide is not prepared to work with proprietary drivers by nVidia or AMD.
When you install a proprietary driver from the "non-free" repos of your distro, you compile the corresponding proprietary kernel modules in your kernel (the so-called "binary blobs"), and you prevent the kernel from "modesetting". If you're using a MAC or RBAC, the use of binary blobs also forces you to make a general exception that pretty much nullifies the entire benefit of the MAC or RBAC. So for secure systems, using proprietary drivers is just not an option, which means that nVidia GPU's are not an option, because they don't perform well with the "nouveau" driver, which is the open source nVidia driver.
If you're going to game on linux with the Steam Client, you generally have to use either AMD cards up to the RHD7k generation with the open source drivers, or you have to use proprietary drivers with AMD or nVidia cards. If you're not using a dedicated gaming system, the best solution is therefore to virtualise the gaming system entirely, using a PCI passthrough and a dedicated GPU for that container, so that you don't get any of the security and privacy threats of the non-open source software on your main system. SteamOS is a good solution for linux gamers, because it is entirely self-sufficient, has it's own repos with always-working proprietary drivers, and barely ever has software updates because it's based upon Debian Stable, which is really old, and based on the same ages old kernel Debian Stable uses (3.2 I believe, whereas normal linux distros are now at 3.16, a full two years of development further down the line, with many more features and performance, especially on modern hardware). Therefore it's easy to keep a kvm container with SteamOS on a more modern linux machine, keep everything nice and secure and high performance, and be able to easily snapshot the Steam container for easy backup and portability. A snapshot of a virtual container is called an "appliance", and is portable, that means that it can be transposed from system to system, can be backed up, and saves a lot of storage space in the process.
Because of the need for suitable binary blobs specific to the kernel provided by any particular distro, it's usually beneficial to install proprietary drivers (if you chose to install those) from the non-free repositories of your distro, because they will adapt the kernel modules to the specific kernel of that distro. Generally, you can use the AMD installer (as in from the AMD website), and it will usually work without problems, but it's always better to only install from your distro's repositories. Using the nVidia installer (as in, from the nvidia website) for linux will lead to pain and misery, you have to use the nVidia packages from your distro and just hope that it works (usually it takes two days to make the nVidia drivers not crash X after a kernel upgrade, which happens every 7-14 days, so if you use nVidia proprietary drivers, be ready for 10-20% downtime on a modern system, again, it's better to use something like SteamOS in a kvm container with PCI passthrough, because it's based on Debian Stable thus so old that it almost never updates and just works, although not with the best performance).
As to java and flash. Java is not as much of a pain on linux as it is on commercial software consoles, and a lot depends on the IDE that is used to develop java with. Netbeans or Eclipse work just fine, and there are a lot of alternative, which work just fine also. That doesn't lessen the fact that Java is pretty chaotic in se. Adobe flash is not required in linux at all. It's a security risk, it's not being updated by Adobe (it only gets security updates, but then again, security by Adobe is like security by Microsoft, sometimes they mean exactly the opposite, because they're not concerned with the security of the user, only of their wallets), and it just doesn't work like it should. There is a special version of flash for the chromium browser, which needs to be installed separately, and the package is called "chromium-pepper" in most distros. That is a way to ensure pretty decent flash functionality where absolutely needed, but it's still not convincing. For video content that requires flash for playback, there are applications like youtube-dl, which downloads most flash video offerings from most flash-only websites, and from youtube. It automatically sets the best quality, discards the ads, downloads at the best download rate, discards age or identity verification, and also offers audio/video ripping and transcoding options, for instance to rip mp3's off of youtube videos. Whilst YouTube offers non-monetised videos through html5, so you can just watch them through your browser, monetised videos cannot be watched without flash, so have to be watched through youtube-dl. There used to be an application called minitube, which would offer the perfect youtube watching experience, but Google made sure that that applications wouldn't work. Youtube-dl is very well maintained though, has almost weekly updates, and anything Google throws at it to block it, is immediately solved.
Linux by default knows no DRM, so don't go and install flash, because it will reintroduce DRM on your system. Same goes for DRM software like the Steam client, which is also not the be trusted, and should not be permitted to run on your host system.