OT Java stuff [was Using D]

[Chris via Digitalmars-d]

On Tuesday, 26 August 2014 at 09:45:15 UTC, Russel Winder via 
Digitalmars-d wrote:
> On Tue, 2014-08-26 at 08:46 +0000, Chris via Digitalmars-d 
> wrote:
> […]
>> The problem was that Java didn't behave as expected on 
>> Windows. Things that worked fine on Linux and OS X didn't work 
>> on Windows (even simple things like deleting files). User 
>> reported all sorts of problems, one of them being that the 
>> Java Access Bridge didn't work. Why, nobody knows. The lack of 
>> a proper sound API / library. Then there was the versioning 
>> hell with JRE/JVM and having to tell users what version they 
>> had to download (the non tech savvy crowd). I know that MS 
>> doesn't make it easy for Java either. Well, I could have 
>> sorted the problems out with Java web start, SWT and all that 
>> kind of stuff. Instead, I learned D which I can compile and 
>> run on each platform without a problem.
>
> If your users are having to install things then the problem is 
> your
> deployment mechanism not the JVM dependency hell system. Java
> deployments are actually really quite easy. Either you package 
> a total
> system with all dependencies and provide entry scripts, or you 
> use Maven
> Central (or increasingly BinTray) for accessing dependencies.

If I need deployment mechanisms like the ones above, then there's 
something wrong with the language. All these crutches and 
patches. To set up and test a deployment mechanism takes as long 
as writing the program. No thank you.

> This is
> not to say there are not portability and dependency problems, 
> there are,
> but it is good to blame the right reason at the right time.

See answer above.

> I am surprised by the platform dependency problem you cite. Yes 
> there
> are platform issues with the Java Platform but I had thought 
> all the
> ones you are alluding to were fixed by Java 1.4.2.

It was long after 1.4.2.

> Media APIs for Java have always been a bit of a pain. With any 
> luck
> JavaFX, and the far more important GroovyFX, will cause a 
> resurgence of
> interest in media APIs on the Java Platform, and this time get 
> them
> right.

"With some luck". I can't wait that long. That's exactly what I 
mean: you have to wait ages and hope and pray that you can write 
a useful program someday. No thanks. With D I grabbed existing 
C/C++ audio frameworks and moved on to more important issues.

>> In my opinion, if a technology like Java needs so many 
>> crutches to make it work on different platforms, then it's 
>> useless for cross-platform development. Also, once you need 
>> interaction with the system or other (native) applications, 
>> then it becomes frustrating pretty soon. D solved all these 
>> problems for me and more, in fact it helped me to design a 
>> better product, because it opened doors for me as regards both 
>> programming patterns and interaction with the system and 
>> various libraries. That there are other languages with which I 
>> could have achieved similar things, I do not doubt. But I do 
>> doubt that it would have been so easy, and the fact that new 
>> languages that aim for what D already stands for are still 
>> being invented (cf. Nimrod) shows that existing mainstream 
>> technologies like Java, C++, C# don't meet programmers' 
>> demands yet.
>
> I am pleased D is working for you when you feel Java didn't at 
> that
> time. Things move on though: what may have been true about Java 
> then may
> not be now. Decisions must always be being reassessed after a 
> while.

Why on earth should I reassess this decision now? D works for 
_me_ (maybe not for everybody). Why should I rewrite the whole 
thing in Java or use Java for new projects, when I know there are 
still issues that are absolute deal breakers for me (like the 
sound API)? Java is just not a good language to write 
cross-platform programs that have to be integrated into the 
system or (native) 3rd party applications. So why bother?

> All
> languages have some platform dependent issues unless they are 
> only
> working on only a single platform. Java, Python, Ruby, etc. 
> generally
> depend on the virtual machine and support libraries to get 
> things right,
> but allowing platform dependent application code as well. C, 
> C++, etc.
> put essentially all of the portability issues into the 
> programmers hands
> and hence lots of build sophistication or #if.

At least you have control over it.

> Then there is the dynamic link library problem creating a mass 
> of pain.
>
> D and Go ran away from this by having statically linked code 
> only, at
> the expense of 2–10MB executables!

I have no problem with that, still better than delivering a 40 MB 
Java package for an otherwise tiny plug-in. The DLL I have in D 
is 855.6 kB, the whole package with libs and various resource 
files is ~4.2 MB download size as zip and ~8 MB when installed.

> With shared libraries becoming an issue in D again, that set of
> dependency and platform problems will raise their heads.