Java

[Loada]

That's dependency injection - it's all the rage these days (at least in Java and C#). Both can use Spring, a library that does all the hard work of resolving the classes at runtime via xml configuration.

[Dungeon-Dave]

Erm.. surely that's only dependency injection if the codebase fails to work when no config file is encountered (or is corrupt, wrong permissions, etc) - this could be avoided by having a set of defaults and using the config file (if exists) to override those.

I know of some *nix systems that adopt this approach, sometimes to my confusion when I wonder where the hell it reads those settings from ("useradd -D" sitting on Solaris, I'm looking at you)

[the2bears]

Right tool for the job, etc. I'd never be able to go back to a language without dynamic class loading.

Why not?

Mainly because it's a feature that I use, a lot. Most of the projects/libraries I end up working on have this ability at the core of their design. Think distributed systems and network services.

Bill

[the2bears]

Java allows you to load classes at runtime. For example JDBC uses this sort of thing with database drivers which allows you to specify the appropriate database driver class at runtime, perhaps from a config file without recompiling.
By default as long as the class is in the class path somewhere, Java can resolve a name to a class and load it for you. In fact you can write your own class loaders to pull in classes from anywhere you want (over a network connection, or from encrypted storage for example).

That sounds a feature working only with interpreted languages ..

So you are kinda telling that "you can call function X / use class Y in your code withouth the need to link with lib Xyz and
the program 'automagically' will load and link the lib for you as you run it ?".

Well no, on a second tought you could implement it in various ways .. "a bit more evolved than a DLL" I'd say yet
fundamentally "same kind of idea" .. I can see pros and cons in this .. one 'pro' could be "I can update/change the class
under your arse without you needing to know about it".

I am not sure but I think you could do some kind of mechanism of that kind in C++ .. it would be nice if you could do
"all the loading / link you need" at startup all in once and then "once is all there, run full speed" otherwise I can see
potential for serious performance issues.

It is indeed "a bit more evolved than a DLL", but you describe it correctly when you say it will "load and link the lib" for you at run-time. What it basically means is that the implementation of a library/interface/contract need not be known at compile time. This allows for bug fixes and updates to happen over the network and without stopping the rest of the VM operations (such as the case with OSGi based applications). Think of this part as hot-swapping of a component. Want to change implementations? Easy to do, all at run-time.

C++ can surely do this, as move JVMs would be written in C/C++. Problem is, it's difficult, and requires the extent of a native interface that Java already provides. As far as performance goes, doesn't seem to be an issue with JIT (Just in Time) compilation being very effective. Though Java is certainly not for every project, maybe not even for "quite a lot" of them.

Bill

[the2bears]

That sounds a feature working only with interpreted languages ..

I don't see how.

If I apply a service pack that updates DLLs on a machine, applications dependent upon those libraries don't need to be recompiled.

(and the fact it works with Java suggests that it definitely works with compiled languages, rather than interpreted... although I predict the thread digressing into the definition of how the JVM deals with bytecode any min now....)

Heh... just so happens I work at a company that makes CPUs/MPUs and Java bytecode is actually the native instruction set. So when I say I run compiled Java I truly mean it in every sense of the word

Bill

[Dungeon-Dave]

Heh... just so happens I work at a company that makes CPUs/MPUs and Java bytecode is actually the native instruction set. So when I say I run compiled Java I truly mean it in every sense of the word

Wow - embedded systems? What happens when there's a new Java release - are some of your chips able to process (for example) Java2 and not Java5?

How do you program the chips themselves - burn the JARs into some mem location and let the CPU boot off main() in a specific class?

[princec]

well, there's the nifty thing about Java... the bytecode itself hasn't changed in over 10 years

Cas

[the2bears]

I think most programs are not portable because they never meant in the first place to be and they never been designed
to be as that in the first place, not because "of a limitation of C++", clearly if I do a WIN32 program that to open
a window and print in requires certain things in a certain way and then I'd want to do into an iPhone that comes out
totally different but not because of C++ but because I don't have an "standard lib" that says "OpenWindowAndPrintIn (text)"
on both machines with the same parameters and call.

This is exactly the case. Portable C++ means, at least to me, that it's written such that it can easily be compiled for other hardware. So C++ programs are (almost?) never written to be runtime portable such as Java is. It's simply a case of having a particular use available and then making use of it.

I think they grab Java because "all they have to do is hope to implement a good enough JVM" and have all the rest
"already done by someone else" probably some Java 'compiler' got from somewhere in Taiwan who knows who ever made it
"I heard that it works fine".

Trust me, not from Taiwan. They do hardware well but not software - I have first hand knowledge from living and working there!

Bill

[the2bears]

I think most of the problems with Java are the number of bloated over-engineered frameworks that sprung up everywhere and half the world believing they needed full on J2EE for everything.

This, and the fact that J2EE generally sucks. I consider myself lucky to have never really used it and that I can thus avoid any recruiter looking for such experience.

Bill

[the2bears]

Heh... just so happens I work at a company that makes CPUs/MPUs and Java bytecode is actually the native instruction set. So when I say I run compiled Java I truly mean it in every sense of the word

Wow - embedded systems? What happens when there's a new Java release - are some of your chips able to process (for example) Java2 and not Java5?

How do you program the chips themselves - burn the JARs into some mem location and let the CPU boot off main() in a specific class?

What Cas said re:bytecode format. It's generally unchanged (though there are some considerations). There's also microcode to handle certain things (like the creation of custom bytecode if a customer wants it, but that obviously limits portability). For example, we have custom bytecode for java Thread primitives (allowing us additional granularity in scheduling and priority, and micro-second context switching, for real-time(!) Java).

The chips themselves are programmed using fairly standard embedded methods - load directly into SDRAM via a JTAG pod while debugging, then burn into Flash memory (NAND/NOR) for deployment (at which time the application copies itself to SDRAM from the Flash). The micro-kernel then boots to a static entry point (the static main(...) method).

Bill

[Orangy Tang]

I think most of the problems with Java are the number of bloated over-engineered frameworks that sprung up everywhere and half the world believing they needed full on J2EE for everything.

Yeah, this. Java's a nice neat, elegant language with fantastic tool support (Eclipse and Netbeans are both faaaar more advanced than Visual Studio, and anyone who tells you otherwise hasn't spent serious time with either of the former). But the 'enterprisey' libraries are horrible to use.

When a good library comes along (like Slick and Processing) they're a joy to use (and the popularity of Slick and Processing are directly related to that). I suspect that most popular 'enterprisey' libraries are written by big bureaucratic teams who don't actually use what they produce, and only get chosen because they've got a big name company backing them.