| |||||||||||||
I was missing oneI was missing onePosted Oct 26, 2012 21:20 UTC (Fri) by man_ls (subscriber, #15091)In reply to: No thanks. by drag Parent article: Haley: We're doing an ARM64 OpenJDK port! Ah, a language flamewar, we had been without one for at least a couple weeks. Actually, the worst bits of Java were corrected in Android: AWT, Swing and the stupid virtual machine with unbearable delays every few seconds. On Android Dalvik works under constrained memory resources (well, constrained for these days, but still) without noticeable delays (unless you do weird stuff) and with a nice sane graphical toolkit. There is still the annoying verbosity: Transmogrifier transmogrifier = new Transmogrifier(); transmogrifier.transmogrify();that doesn't let you forget you are in the Kingdom of Nouns. The anal retentive behavior of warnings, case in point @SuppressWarnings("unused"), which generates another warning if the variable below is actually used!, we can play this game forever. The idiotic difference between objects and primitive types. And so on and so on. But they are relatively minor annoyances compared with the above, which were showstoppers. At least Google doesn't insist on creating getters and setters for everything, or declaring all variables as final unless they are modified later on -- talk about doing compiler micro-optimizations by hand. The worst part is that companies may enforce these stupid recommendations believing they are doing themselves a favor. I wish Sun had worked on these things before. Still, for a strongly-typed language Java is not bad. Of course I will take the crazy crazy world of JavaScript any day. As to the necessity of JVMs for ARM64, they are just that: a necessity for some situations. I am very unhappy with certain branches of the Spanish administration because they require Java for signing documents; when I install IcedTea it refuses to run on 64 bit JVMs. So I have to borrow my girlfriend's Windows XP netbook for a short while, which is embarrassing. Whew, I needed to vent that, thanks for being still there. Back to on-topic: any server which doesn't have a JVM will not be considered as "serious" to large segments of customers, so it is a hard requirement. Grandparent may not like it, but enterprise customers do like Java, and that has relevance for Free Software.
(Log in to post comments)
I was missing one Posted Oct 26, 2012 22:31 UTC (Fri) by ncm (subscriber, #165) [Link]
I guess you could say Java still has relevance for non-free uses of Free Software. But if its main value is for non-free uses, it seems as if those users ought to arrange to pay for maintaining and porting it. That won't happen without somebody experiencing pain first, so maybe it would be better to wait for some.
On the other hand, I'm betting that when the first AArgh64 chips come out, if the code doesn't run right, the chips will be considered wrong, and they'll change the spec to match the code. That seems about equally likely to be good as bad. Probably the people doing the code generator should get in touch with any malcontents from the Aargh64 design team and see which of its choices ought to be overturned that way.
I do like that in the Dalvik execution model, your program must be prepared to be killed off at any moment, and to then jump up, Inspector Clouseau style, if anybody happens to look.
I was missing one Posted Oct 27, 2012 10:45 UTC (Sat) by man_ls (subscriber, #15091) [Link] IME Java is mostly relevant for in-house development, which is neither here nor there -- it cannot be considered "non-free" since it is not published, only run internally. Even the FSF allows to run GPL code internally without publishing source code.I suppose that, if the JVM implementors have half a brain, they will just publish a preliminary version of the code pending a real processor; the JVM should get updated then and everyone will be happy. If that is not the case, well, you cannot blame the Java language for that.
I was missing one Posted Nov 9, 2012 3:08 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> it cannot be considered "non-free" since it is not published, only run internally
Being free software has nothing to do with being published. A program is free software if its users have permission to run, copy, distribute, study, change and improve the software. That is probably not the case for internal-use applications, so they're not free software.
I was missing one Posted Nov 9, 2012 11:13 UTC (Fri) by hummassa (subscriber, #307) [Link]
When a software is run internally in an enterprise (especially if it is run for the enterprise's purposes), its user is the enterprise, not each individual users... the enterprise can modify it, but it does not have the obligation to send the source code to each employee, and it can put rules in place to prevent that.
I was missing one Posted Nov 9, 2012 22:20 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> When a software is run internally in an enterprise (especially if it is run for the enterprise's purposes), its user is the enterprise, not each individual user
Sorry, but that doesn't make any sense to me.
I was missing one Posted Oct 30, 2012 18:31 UTC (Tue) by gnu_andrew (subscriber, #49515) [Link]
"when I install IcedTea it refuses to run on 64 bit JVMs" - I take it you mean the applet won't work on a 64-bit JVM, whether that's the IcedTea-Web one or the proprietary one? I've seen that with a video-conferencing application too and sadly, there's not much that can be done if the applet writers are going to rely on 32-bit native libraries only.
I was missing one Posted Oct 30, 2012 21:17 UTC (Tue) by man_ls (subscriber, #15091) [Link] Exactly, the applet refuses to run on a 64-bit JVM. I don't even know how it can be -- native libraries to sign a document?
I was missing one Posted Oct 30, 2012 21:37 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
lots of commercial java applets include 32bit-only libraries. Those libraries aren't loaded by the 64 bit JVM, so the applet fails due to missing libraries.
|
|||||||||||||