| |||||||||||||
It runs everywhere!It runs everywhere!Posted Aug 21, 2012 14:12 UTC (Tue) by fb (subscriber, #53265)In reply to: It runs everywhere! by man_ls Parent article: Kamp: A Generation Lost in the Bazaar
Sure, Java and the JVM did not solve every deployment problem on earth. News at 11.
Compared to the possible amount of deployment/running errors you can get running C/C++, I'd say that Java (and all the associated tooling around it) actually brought a great deal of sanity to the table.
(Log in to post comments)
It runs everywhere! Posted Aug 21, 2012 15:01 UTC (Tue) by man_ls (subscriber, #15091) [Link] It is not just that Java did not solve every deployment problem; in fact Java has created additional deployment problems on every platform it runs on, which are just a handful. To name just a few issues: download a gigantic runtime, deploy a specific version of the JVM, deploy associated libraries (which may or may not conflict with those in the JRE), reserve a lot of memory for it (often more than the JVM provides by default) and make the whole thing run in a sensible way for end users without having to type an arcane command. A configuration nightmare. Compare with Python: a small runtime, standard library locations in the system, a simple way to run scripts, runs truly everywhere.As to runtime errors, you are right about C/C++, but there is a reason why people put up with them. And Java is not without issues. I don't know if you have ever been in jar hell: looking for an error which manifests only on the web server, caused (supposedly) by a specific version of one the libraries installed, but you have no way to find out whether it was embedded in the JRE, loaded from the classpath, from the library path, or embedded in the .war file. (Normally you assume it is using the .jar in the .war, and only after a lot of head-scratching you work up from there.) For development you need not only a way to manage all of the above, but also an alien build system (Ant, alien even to the JDK) and a way to manage dependencies (Maven), and then you have a lot of random packages not integrated with anything else -- not even with those already in the system. No wonder the only way to do sane development with Java is from within Eclipse, which provides a lot of the missing pieces -- but good luck trying to package and run that code elsewhere.
Makes autotools look like something easy. At least you run a standard set of commands:
It runs everywhere! Posted Aug 21, 2012 15:19 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>download a gigantic runtime, deploy a specific version of the JVM
That's not true. JVM is incredibly backwards-compatible, up to the point it becomes excessively so. That means you simply need a recent enough version of JVM.
>make the whole thing run in a sensible way for end users without having to type an arcane command. A configuration nightmare.
But it's the same problem with Python, you have to package a Python app separately for Linux, Windows and Mac OS X.
Three answers in one Posted Aug 21, 2012 16:23 UTC (Tue) by man_ls (subscriber, #15091) [Link] But it's the same problem with PythonNot really. Python runs source code files directly, without compilation, so you can just git clone a repo and run it (double click on Windows): no need to package. If you want to package software, Python includes Distutils, which make installing software a breeze. Finally, Python has the official repo PyPI, and a tool called pip to download third party libraries. All that as part of Python itself, as officially supported tools. Hard to beat.
Three answers in one Posted Aug 21, 2012 22:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Try to beat Java WebStart. I simply give you a link and it downloads and starts application (with all its dependencies).
Now try that with Python. On Windows.
Go on, do it. You'll have to install Python first, or you won't be able to run anything. After you've installed it you might notice that clicking on a script results in an ugly console window (even though you might have a GUI app), so you need some sort of runner.
Three answers in one Posted Aug 21, 2012 23:16 UTC (Tue) by man_ls (subscriber, #15091) [Link] But to use WebStart you need to install the JRE first. How is it different than installing Python, except that Python is much smaller and available for many more platforms (and pre-installed on Mac OS X and most Linuxen)? Once installed I can beat your single link with a single command:pip install package. I can dictate it to aunt Tilly over the phone.
I don't know much about WebStart, but I have not seen it used for anything remotely serious. For packaging, distributing, installing and using software on a regular basis, and for basic configuration management, Python is great; I don't know the steps needed to package something using WebStart though.
Three answers in one Posted Aug 22, 2012 2:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>But to use WebStart you need to install the JRE first.
Go to http://java.com and download it. Big deal.
>Once installed I can beat your single link with a single command: pip install package. I can dictate it to aunt Tilly over the phone.
- Pip? Is it a character from the Great Expectations? Do you want me to reread this awful novel? How dare you!
Once you say "command line" you are WAY outside the realm of acceptable for end-user apps. WAAAAAAY too far.
> I don't know much about WebStart, but I have not seen it used for anything remotely serious. For packaging, distributing, installing and using software on a regular basis, and for basic configuration management, Python is great; I don't know the steps needed to package something using WebStart though.
Java has a package management system, it's called Maven. It's somewhat similar to pip/setuptools except that it works at _build_ _time_. And as a result you can generate Java WebStart packages, self-installing executables, etc.
The greatest problem with Java really is its 'heavy' JVM. Sun missed the opportunity to make it lightweight, alas.
Apache's role in all of this Posted Aug 22, 2012 10:13 UTC (Wed) by man_ls (subscriber, #15091) [Link] So, both WebStart and Python require the user to download it before using it. Unsurprisingly. From there Python is more geared to professional users, for which I am grateful (since amateurs are not going to use WebStart or pip anyway).Maven is not in Java, it is an outside package. Which brings us to another one of Java's treats: the big ecosystem of Apache software. But wait, why is such a big corpus of code necessary at all? To provide for Java deficiencies, which means the 50MB+ JRE monstrosity is not even enough to have a decent set of collections. Each useful third-party package you find out there is likely to depend on a few Apache libraries, meaning that you will be soon managing tens of .jar files. To bring this into perspective, there are 39 Apache Commons projects, which are supposed to provide foundation libraries. Which is why Maven is needed. Whew! Apache code is maintained by the ASF foundation which is at odds with Oracle. I guess that the worst problem here is that Java is controlled by Oracle, a hostile corporation. Compare with Python, Perl, C or even JavaScript (which seems to be in the hands of a handful of browser vendors, but at least they cooperate).
Apache's role in all of this Posted Aug 22, 2012 15:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>So, both WebStart and Python require the user to download it before using it. Unsurprisingly. From there Python is more geared to professional users, for which I am grateful (since amateurs are not going to use WebStart or pip anyway).
Actually, it is possible to install Java using browsers' automatic plugin detection.
>To provide for Java deficiencies, which means the 50MB+ JRE monstrosity is not even enough to have a decent set of collections.
Please, stop repeating nonsense. Commons-collections is a dead project, it hadn't been necessary for a loooooooong time. Sun JVM in fact has one of the best collection libraries, including parallel and non-blocking collections which you'd be hard-pressed to find in other languages.
You also might actually browse the list of apache-commons libraries. About a half of them are either thin wrappers over several other libraries and/or long-dead projects.
Apache's role in all of this Posted Aug 22, 2012 16:12 UTC (Wed) by man_ls (subscriber, #15091) [Link] I was not repeating anything, it is just my own recollection. If the situation has improved nowadays, good for them!
It runs everywhere! Posted Aug 21, 2012 15:44 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Sun missed the boat with regard to tooling: back in the early days of Java, had Sun made javac just that little bit more powerful, it could have solved many of the build solution needs there and then. Instead, people probably used Makefiles for a while before Apache Ant came along.
And the best retort to "install a JRE" is, of course, "which one?" I have to run stuff which only works with Sun's Java - it can't be anything like IcedTea that most probably implements the breadth of the required functionality - and so the practice of industry hacks targeting a single, narrow, effectively proprietary platform continues, but everyone can claim that they're using open standards.
Oh, and those industry hacks will all be working in a cathedral-style project up to their necks in dodgy code and with "security through obscurity" being one of the project value statements.
But I agree with you that high-level languages with managed environments can and should provide significant simplification over systems programming languages like C and C++. The emergence of stuff like Maven indicates that there's plenty of complexity remaining, however.
It runs everywhere! Posted Aug 21, 2012 16:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
> And the best retort to "install a JRE" is, of course, "which one?"
And the best retort to it is, of course, "the most recent one". Sun JVM is very backwards-compatible.
It runs everywhere! Posted Aug 21, 2012 16:39 UTC (Tue) by man_ls (subscriber, #15091) [Link] Sun JVM is no more; Oracle JVM comes with a very annoying binary license:Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software.Remember where we are writing: we may be forgiven for disliking these restrictions. Besides, Oracle only distributes JVMs for a very limited set of 8 operating system and processor architecture combinations: Linux x86, Linux x64, Mac OS X, Solaris x86, Solaris SPARC, Solaris x64, Windows x86, Windows x64. Considering that ARM systems probably outnumber all these combined, it is a great limitation. In all this discussion I haven't even brought out the most annoying point of Java development: its "native" graphical toolkits AWT and Swing, which are not integrated with any environments and look alien everywhere. Luckily there is SWT, but it does not precisely simplify the configuration management problem.
It runs everywhere! Posted Aug 21, 2012 22:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Just use OpenJDK. It's fully functional for 99% of applications.
It runs everywhere! Posted Aug 22, 2012 9:21 UTC (Wed) by cortana (subscriber, #24596) [Link]
Or fully function for 99% _of_ an application. Like Wine. :)
It runs everywhere! Posted Aug 22, 2012 14:54 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Actually, I was impressed with Wine running a fairly old, but still 3D-based, game that I thought would be a migration show-stopper recently. Even the fancy joystick controller worked as intended.
Meanwhile, with Java runtime environments, if you don't want to run the Sun JRE or just can't, even if OpenJDK should do the job because of its common heritage and proximity to the Sun JRE, that's no guarantee it will work. As I noted, people in certain industries are great at touting the supposed openness of a technology while deploying something that only works with one vendor's specific product.
It also doesn't inspire confidence that Oracle as a vendor, ignoring the reputation currently enjoyed by the company after its recent behaviour, still lives on pre-Internet time with respect to security updates. That said, I do wonder how much attention any of the JREs get in comparison to widely-used open source projects.
It runs everywhere! Posted Aug 22, 2012 15:07 UTC (Wed) by cortana (subscriber, #24596) [Link]
Unlike with most Java programs, which are only tested on the Sun^WOracle JRE, at least there is a large community of users who try out Windows programs on Wine, and file bugs/send patches to get things fixed. :)
It runs everywhere! Posted Aug 22, 2012 1:07 UTC (Wed) by pflugstad (subscriber, #224) [Link]
FWIW, Sun/Oracle JVM is available on ARM (and PowerPC), but it's only free for trial use:
<http://www.oracle.com/technetwork/java/embedded/downloads...>
I've had a lot better luck with those than I have with the various IcedTea incantations on ARM/Linux.
It runs everywhere! Posted Aug 22, 2012 8:48 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
Java didn't bring any sanity to the table, nor did it solve any deployment problem.
SUN used its 'rewrite everything in Java' mantra to create an ecosystem with no legacy code to manage, and apps so balkanized they could never grow to a full system, and then exploited this situation to avoid thinking about deployment.
In fact, it promoted bad engineering for years to postpone as much as possible tackling the deployment problem, and the attitude got so pervasive it infected SUN Java competitors (don't reuse code, copy it, don't propagate fixes, fork libs, everyone should hardcode classpath dependency chains, use maven to download specific binary artifacts to avoid thinking about code lifecycle, use osgi to pile up jar files without having to sort them, only successful commercial environment: application servers with dedicated sysadmins to sort the mess and the app server trying to salvage deployment because core Java is unable to do it).
As a result more than a decade later, when enough Java code accumulated SUN/Oracle finally has to tackle deployment, they've hit a hard wall of technical debt, and the modularization of Java gets postponed from release to release (it will be in Java 7, oops, let's split java 7 in 7 and 8 with the modularization in 8, oops, 8 will ship without it wait for 9 instead, etc).
|
|||||||||||||