The high DPI fix is for Swing, so it would depend on the UI toolkit used, but also on how those programs were written (if they did anything with fixed amounts of pixels, that won't scale). SWT already runs fine in high DPI (see Eclipse) and JavaFX does as well.
I'm sure a Debian package will be along shortly for Java 9, but yes, I agree, using the Ubuntu one should be reasonably safe, especially since Java is pretty much self contained and only hooks into the underlying OS at low levels (threading, I/O, etc).
There isn't a single language for which this is true, unless that language only has a 1.0 version and never patched any security holes. Do you want that security exploit that worked on Java 1.0 to work on Java 9? Perhaps you do depending on what business your in, but the rest of the world doesn't.
Java is probably *the* most backwards compatible language ever build, and they didn't make an exception with Java 9. So yes, I do expect it to run almost everything that was ever build for it.
In the cases it doesn't (which I have not encountered in any decently engineered piece of Java) it probably is using undocumented functions or security exploits. I don't think I even want those to keep functioning.
Looks like gross incompetence to me. And so gross incompetent use of Java turned you into a hater of Java, makes perfect sense. I guess you must hate all programming languages then, as I've seen gross incompetence in most of them. How you can even bear to use Windows is beyond me.
Anyway, I'd decompile the software involved, change that "==" into a ">=" (or remove the check altogether) and be on my merry way.
You know, this is actually your own fault as most companies do upgrade. You should have the balls to pack up and leave and work at a company that is with the times (if that is Java 8 or 9 or another language, it doesn't matter). You are limiting your potential and future value by continuing to work with older software.
As a Java dev, I only have to snap my fingers and get 20 job offers... I then only have to pick the one that I like most.
I'm 42, no college degree, started programming at age 12, learned several assembly languages and C before finishing high school, got a job at age 20 for some helpdesk company, worked there for 9 years, then went freelance working at a dozen companies over the last 13 years (which means I seen quite a few different ways of working).
I now still earn about 150k/year doing what I love (programming, mostly Java nowadays), which is easily double of salaried employees with the same skills. I mentor other developers and am usually the lead on the project (it depends on if I'm working with a team of less experienced developers or a team of peers).
I am Java programmer, and I can tell you, you're doing it wrong. Fix whatever is the root cause of having to do a full deployment so you can use hot code replacement like everyone else for Tomcat stuff.
A maven build for every line changed would be ridiculous. In a well setup environment, you never need to run Maven locally. You commit stuff on a branch, build server runs the maven build. During development you use incremental builds and hot code replacement only.
If that is not possible, then make it possible, involve management if needed. I wouldn't even consider working in that kind of fashion. We're programmers after all, lazy by nature. Fix your process.
...hit F5, and error. Fix some syntax/naming/style problem and swap to browser again, F5, another error... rinse repeat until you fixed everything that a compiler would catch right away.
This is so simple. The car should save the occupants, just like any normal driver would have done. Trying to take this to some Asimov "donot cause harm" bullshit will practically require cars to be self-aware, at which point cars may not actually want to serve their masters anymore.
A decent system just generates your password and gives you 30 seconds to remember it. How you can trust people to think of their own 64 character password is beyond me.
You sound like those companies haven't considered that already...
In my experience those outsourced workers are treated very poorly (wage slaves) that can get in big trouble if they don't live up to customer expectations. It's really sad actually that companies that treat their workers with the highest regard turn to outsourcing so they can indirectly treat workers like shit.
A big part of Scrum is actually to find what works for your team. So if daily standups are not working or taking too long or whatever, then after your iteration you re-evaluate and try something different in the next iteration.
In this way, by re-evaluating our process critically we changed many things, including how we keep track of progress, what things can be worked on at the same time, when something is considered "ready to be worked on", even how the stand-up works, what time it will be and what is considered on-topic. Anything is up for discussion, including what tools are used (some QA tools are more trouble then they're worth), how much management should be involved (stupid decisions affect your product) and how things are delivered.
Of course, this requires competent people that want to work as a team and can work without supervision. This requires trust from the management that the team will strife for the best results -- too often things fail because half-baked features are being pushed through on deadlines that the team would never agree on under normal circumstances.
I would *shrug*, realize that it's likely a piece of junk anyway that probably is either spying on me or trying to waste my time, and uninstall that shit.
It's like permissions. Do I like your app? Maybe. Do I like it enough to allow it to place phonecalls, read my CC details, contacts, my browser history, execute arbitrary code in background threads, etc..?
You know, what you just described sounds like the drive behind every security hole in our software these days: to save costs (by making it easier to develop in this case) and to hell with what the user wants.
Please stay away from my phone with your bloated Cordova/PhoneGap/Javascript VM junk -- luckily they work so poorly they're easy to recognize.
I don't think memory fragmentation is a real issue at all. Physical fragmentation is a non-issue with MMU's. If we're talking fragmentation of Firefox internal structures, then a level of indirection can allow it to move structures around to prevent fragmentation.
There is this thing called disk cache. Store the tab on disk. If necessary just dump the entire state (like a VM) so it can be restored exactly as-is. There are solutions, you just have to be willing to look for them.
Instant when I just tested it, but it hasn't been running that long. I've seen tab lag before, I'm not sure if that was solved since the focus was on not using resources when tabs aren't loaded.
When a user can crash your product just by opening a ton of tabs, where it isn't obvious that this would cause problems, then it is still your products fault.
If they know it would cause problems, then the number of tabs should have a limit, or a warning or whatever. There is nothing. Instead, Firefox will happily keep opening tabs until it consumes all RAM (or 2 GB for 32-bit version), then becomes an unresponsive blob that users have to kill. Very user friendly.
And why? All the data is available elsewhere, either in the disk cache, or the remote server itself. Why keep all that shit in memory? Rendering an empty placeholder tab shouldn't take more than a few K, and can be reloaded on demand in fractions of a second.
Apps shouldn't crash, no matter how stupid the user.
Slashdot Mirror
The high DPI fix is for Swing, so it would depend on the UI toolkit used, but also on how those programs were written (if they did anything with fixed amounts of pixels, that won't scale). SWT already runs fine in high DPI (see Eclipse) and JavaFX does as well.
I'm sure a Debian package will be along shortly for Java 9, but yes, I agree, using the Ubuntu one should be reasonably safe, especially since Java is pretty much self contained and only hooks into the underlying OS at low levels (threading, I/O, etc).
There isn't a single language for which this is true, unless that language only has a 1.0 version and never patched any security holes. Do you want that security exploit that worked on Java 1.0 to work on Java 9? Perhaps you do depending on what business your in, but the rest of the world doesn't.
Java is probably *the* most backwards compatible language ever build, and they didn't make an exception with Java 9. So yes, I do expect it to run almost everything that was ever build for it.
In the cases it doesn't (which I have not encountered in any decently engineered piece of Java) it probably is using undocumented functions or security exploits. I don't think I even want those to keep functioning.
I heard if you keep repeating something long enough, it actually becomes true!
Looks like gross incompetence to me. And so gross incompetent use of Java turned you into a hater of Java, makes perfect sense. I guess you must hate all programming languages then, as I've seen gross incompetence in most of them. How you can even bear to use Windows is beyond me.
Anyway, I'd decompile the software involved, change that "==" into a ">=" (or remove the check altogether) and be on my merry way.
You know, this is actually your own fault as most companies do upgrade. You should have the balls to pack up and leave and work at a company that is with the times (if that is Java 8 or 9 or another language, it doesn't matter). You are limiting your potential and future value by continuing to work with older software.
As a Java dev, I only have to snap my fingers and get 20 job offers... I then only have to pick the one that I like most.
I'm 42, no college degree, started programming at age 12, learned several assembly languages and C before finishing high school, got a job at age 20 for some helpdesk company, worked there for 9 years, then went freelance working at a dozen companies over the last 13 years (which means I seen quite a few different ways of working).
I now still earn about 150k/year doing what I love (programming, mostly Java nowadays), which is easily double of salaried employees with the same skills. I mentor other developers and am usually the lead on the project (it depends on if I'm working with a team of less experienced developers or a team of peers).
This is in europe.
A 17 year return on investment, wow, where can I sign up?
I agree that everyone deserves a chance, and their CS degree should not be held against them.
It's great when you can put people into boxes and then apply all your prejudices. What did you study, so I can file you into the proper box as well?
I'm supposed to believe that a fully programmable robot can be created out of just 150 *basic* parts? Whatever this is, I would not call it a robot.
...it will reach 8000 km/hour.
I am Java programmer, and I can tell you, you're doing it wrong. Fix whatever is the root cause of having to do a full deployment so you can use hot code replacement like everyone else for Tomcat stuff.
A maven build for every line changed would be ridiculous. In a well setup environment, you never need to run Maven locally. You commit stuff on a branch, build server runs the maven build. During development you use incremental builds and hot code replacement only.
If that is not possible, then make it possible, involve management if needed. I wouldn't even consider working in that kind of fashion. We're programmers after all, lazy by nature. Fix your process.
...hit F5, and error. Fix some syntax/naming/style problem and swap to browser again, F5, another error... rinse repeat until you fixed everything that a compiler would catch right away.
This is so simple. The car should save the occupants, just like any normal driver would have done. Trying to take this to some Asimov "donot cause harm" bullshit will practically require cars to be self-aware, at which point cars may not actually want to serve their masters anymore.
Sounds like a barrier to me...
That's just not good enough.
A decent system just generates your password and gives you 30 seconds to remember it. How you can trust people to think of their own 64 character password is beyond me.
You sound like those companies haven't considered that already...
In my experience those outsourced workers are treated very poorly (wage slaves) that can get in big trouble if they don't live up to customer expectations. It's really sad actually that companies that treat their workers with the highest regard turn to outsourcing so they can indirectly treat workers like shit.
A big part of Scrum is actually to find what works for your team. So if daily standups are not working or taking too long or whatever, then after your iteration you re-evaluate and try something different in the next iteration.
In this way, by re-evaluating our process critically we changed many things, including how we keep track of progress, what things can be worked on at the same time, when something is considered "ready to be worked on", even how the stand-up works, what time it will be and what is considered on-topic. Anything is up for discussion, including what tools are used (some QA tools are more trouble then they're worth), how much management should be involved (stupid decisions affect your product) and how things are delivered.
Of course, this requires competent people that want to work as a team and can work without supervision. This requires trust from the management that the team will strife for the best results -- too often things fail because half-baked features are being pushed through on deadlines that the team would never agree on under normal circumstances.
Agreed, they lost me at "What did they do for X yesterday..."
There's nothing more boring than hearing what happened yesterday and where everyone gets a turn to speak...
My ideal stand-up goes:
"Anyone currently blocked? No? Get back to work."
I would *shrug*, realize that it's likely a piece of junk anyway that probably is either spying on me or trying to waste my time, and uninstall that shit.
It's like permissions. Do I like your app? Maybe. Do I like it enough to allow it to place phonecalls, read my CC details, contacts, my browser history, execute arbitrary code in background threads, etc..?
No fucking way.
You know, what you just described sounds like the drive behind every security hole in our software these days: to save costs (by making it easier to develop in this case) and to hell with what the user wants.
Please stay away from my phone with your bloated Cordova/PhoneGap/Javascript VM junk -- luckily they work so poorly they're easy to recognize.
I don't think memory fragmentation is a real issue at all. Physical fragmentation is a non-issue with MMU's. If we're talking fragmentation of Firefox internal structures, then a level of indirection can allow it to move structures around to prevent fragmentation.
There is this thing called disk cache. Store the tab on disk. If necessary just dump the entire state (like a VM) so it can be restored exactly as-is. There are solutions, you just have to be willing to look for them.
Instant when I just tested it, but it hasn't been running that long. I've seen tab lag before, I'm not sure if that was solved since the focus was on not using resources when tabs aren't loaded.
When a user can crash your product just by opening a ton of tabs, where it isn't obvious that this would cause problems, then it is still your products fault.
If they know it would cause problems, then the number of tabs should have a limit, or a warning or whatever. There is nothing. Instead, Firefox will happily keep opening tabs until it consumes all RAM (or 2 GB for 32-bit version), then becomes an unresponsive blob that users have to kill. Very user friendly.
And why? All the data is available elsewhere, either in the disk cache, or the remote server itself. Why keep all that shit in memory? Rendering an empty placeholder tab shouldn't take more than a few K, and can be reloaded on demand in fractions of a second.
Apps shouldn't crash, no matter how stupid the user.