I said a similar thing. No comments. I guess the fanboys don't see corporate environments as important.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Discontinuing Java Installation Packages for Mac OS X?
- Thread starter MacRumors
- Start date
- Sort by reaction score
I said a similar thing. No comments. I guess the fanboys don't see corporate environments as important.
Any speculation like yours is simply FUD at this point.
As it stands today, OS X has Java installed on every machine. This will remain the case at least until Lion is released next summer.
All Apple has said thus far is that they MAY drop it from Lion. A final decision has not been made. The most probable scenario is that Oracle will pick up the torch and provide a JRE/JDK for their product. In either case I would expect a reply from Oracle soon since it impacts the viability of Java as a platform for distributing apps to users.
If Oracle refuses to support OS X and user demand is high enough, Apple will need to take that into consideration. However, the way I see it, if Oracle does not value Java enough to create an OSX JDK, like they do for every other platform, then Apple is probably justified in dropping it also.
If, for whatever reason Java is dropped entirely from OS X, your Credit Union should take note and revise their site to no longer require Java for login. Not just because of the impact to OS X customers, but because Oracle would have demonstrated a lack of commitment to Java as a write once run anywhere solution and like wise Java in general.
Yea I'm with you... While I'm sure there is a case where java performs well... I've never come to experience it. On the topic of ui heavy user centric java apps... I'd rather have a gulp.. Realbasic version instead.
Microsoft developed their own JVM even though Sun was providing one for Windows. Microsoft's JVM introduced Java incompatibilities (intentionally, BTW to fragment Java) and Sun actually sued them over it. Totally different story.
This is not what computers should be:
Dude get used to it. That is the future. You kids will be using computers like that and tell family stories like "Daddy use to write code and only use a keyboard and mouse."
Yes yours is. Anyone with "Num Nums" in the name lost it. You didn't even produce a complete sentance!
A Num Num (or Num Numius in Greek) is a generally stupid and unevolved form of a person. A usual num num can only say the words num num but more advanced num nums are capable of speech.
I'm sorry, but he's right. From your comments, you obviously have no kept up to date on what Java is right now. Forget the 90s and Java as an applet/desktop technology using SWT. Java is leaps ahead of that, especially in the performance department (which has a lot to do with the JIT compiler and optimizations it performs on the fly).
The impression persists because despite those optimizations, UI Java applications are still generally slow to launch and have a dated look and feel. Modern Java does a lot of things right, but user experience isn't one.
It's ok for low requirement backend work but fails in mid-high end data processing due to poor memory management limiting the practical RAM allocation to ~2G (even under 64 bit).
It make me sad when I look at our farm of servers with 96GB RAM each, with at least 90GB free at peak load.
I know why it happens, but you'll never convince me that it's easier to leave it alone than fix it—at least if you're going to be the one who has to maintain it.
That's all I'm trying to say. Really, I was mostly explaining how I work. I wasn't telling you what to do.
No, that's true, but you should if you're using it (unless it's jQuery, that framework is like dark magic).
The question is what do you gain by going back and fixing it and compared to the amount of work it will take to do it.
Also as projects get more complected or a block of code is reused that if you go back and repair it you risk putting in a lot of new errors and screw things up even more.
Errors being renames you missed in other parts of the program.
Right, but as I explained in my post, I work in such a way that my code isn't spread across multiple files. It'll either be in my main library, or in a class/include somewhere. I have to look in two places at most. And we're talking about function name changes, so it's really not that difficult to do a simple find and replace. YMMV.
What do I gain by fixing it? By not having to look up the original function to see what it does (or use it and have to go back and recode something to fix bugs because I thought it was something else) I save my time. That's kind of valuable to me. It's the one resource that I can't get more of.
I wonder why you're not already on my buddy list. I haven't laughed this hard in a long time.
I wonder why you're not already on my buddy list. I haven't laughed this hard in a long time.
Enjoy the LP records while you are at it too.
Hey, that's a small cluster, if I want to impress chicks I tell them about the *big* machines...
...and then my g/f tells me to shut up and stop being a dork
You used "*big* machines" and "girlfriend" in the same post. Epic win!
The only sad thing there is your purchasing department. You over-specced your machines if you have so much free RAM under peak load. Maybe you should try hardware consolidation. Your CPUs are also probably idling like there's no tomorrow.
My 128 GB machines under peak load need to resort to swapspace. The slight performance gain (over long periods of time, peak load does not occur that often) wasn't worth getting more RAM in there.
For all the people that are not devs and are saying this is a good thing, you have NO idea what you are talking about.
While Java may not be a prime choice on the OS X desktop scene it is very strong in enterprise, educational environments, and handhelds (phones, point of sale systems, etc).
The last 2 projects I have worked on have been SpringMVC, Webflow, Java, and JSTL related. I am working on, maintaining, and improving a Java based Point of Sales system for a world wide corporation right now (ALL there new stores are linux based machines running java based point of sales applications).
I ALWAYS chose java when I had a choice for my projects at college. It was the easiest to transfer back and forth between the windows environment at school and my computer. I could ave done straight C/C++ but who wants to put themselves through that torture.
IF Oracle picks up Java then great... if not then OS X as a dev platform for me will slowly dwindle and I will be forced to run a VM with Linux/Windows much more often.
While Java may not be a prime choice on the OS X desktop scene it is very strong in enterprise, educational environments, and handhelds (phones, point of sale systems, etc).
The last 2 projects I have worked on have been SpringMVC, Webflow, Java, and JSTL related. I am working on, maintaining, and improving a Java based Point of Sales system for a world wide corporation right now (ALL there new stores are linux based machines running java based point of sales applications).
I ALWAYS chose java when I had a choice for my projects at college. It was the easiest to transfer back and forth between the windows environment at school and my computer. I could ave done straight C/C++ but who wants to put themselves through that torture.
IF Oracle picks up Java then great... if not then OS X as a dev platform for me will slowly dwindle and I will be forced to run a VM with Linux/Windows much more often.
I wonder why you're not already on my buddy list. I haven't laughed this hard in a long time.
You will never be on my buddy list. Single income source types are not in my league.
Incorrect, .NET is compiled int MSIL (Microsoft Intermediate Language) which is the .NET equivalent of Java bytecode. As for 'interpreted' no Java run time environment has used interpret mode for at least a decade - everyone is using JIT these days. Yes you can compile .NET code form MSIL to native code but you can do the same with Java using GNU toolchain and compile Java bytecode into native code but the performance boost is negligible at best.
As for Java, it has its strengths but the problems most people face have to do with bad programming and it being used in the wrong places than anything necessarily being something wrong with the language and environment per-say.
Dont assume we haven't looked into our options. Unfortunately the technically correct solution is not always the 'right' solution. This is the required spec for machines according to the vendor. If we bought less, they would not support us to the level required by our external auditors. Your right that the CPU is also underutilize and the bottleneck is the SAN as datasets are continuously reloaded. Consolidation isn't an option due to licensing terms tieing back to physical cores on the host, even under VM. This means consolidation of hardware would actually result in higher licensing costs that would exceed the value of the under utilized hardware. One month of maintenance costs for the software already exceed the hardware cost. Fighting with the vendor doesn't make financial sence since if it delayed us by even a month, the point would be moot.
The case I mentioned is a financing exception where over-provisioning hardware was the cheapest option in the end. However the reason we can't ramp up the per-server performance is because of the memory management in Java. We have worked with Oracle to attempt to improve the situation, but the heap size just doesn't scale up much past 2G in a single Java thread.
They are working to change the software to run multiple instances, but the restrictions of the code make this difficult since the datasets will need to be largely duplicated in RAM.
I see, so your best solution would probably have been to switch vendors, but I can relate to historical reasons tieing to an old vendor. We have the same problem with our archival system which is absolutely crap and we can't get rid of it for another's vendor solution because of historical purposes.
Most of our Java stuff though is not so tied down. Our WebSphere based applications are mostly in-house stuff, run on consolidated VMs and we run many on the same VM.
At least you can get comfort in not having to do performance tuning on the box.