patterns on static objects by meta-java means
Consider a Gui, which controls some model. It may have listeners or strategies/templates observerving and reacting on the model changes. By running different programs, you invoke different strategies.
The conventional way for coding two programs in java would be to instantiate a Gui and pass appropriate strategy:
class BasicStreategyGui{
staticvoid main(args){
new Gui(args, basicStrategy);
}
}
class AdvancedStrategyGui{
staticvoid main(args){
new Gui(args, advancedStrategy);
}
}
So, the Gui controller must be an instantiable object, supporting strategy assignment. Occasionally starting off my program, I have realized that a static main program can be shared among strategies. One can point to a strategy to be loaded by the classpath:
class Gui{
publicstaticvoid main(args[]){
// define vars
params = parseCmdArgs(args);
frame =new JForm();
frame.add(new Control);
control.addChangeListener(new Strategy(params));
}
}
// and the instantiating code:
set classpath = .;BasicStrategy
java Gui
//and for another program:
set classpath = .;AdvancedStrategy
java Gui
I think that my approach with statics is better, since it is natural, that is, does not incure the redundancies. I need only one Gui in my program; therefore, I do not see any reason to make the Gui instantiatiable over static. My question is, do you know about any discussions on the trick?
[2446 byte] By [
valjoka] at [2007-10-3 7:24:38]
Why do you think it is better to have two small classes versus messing with the command line start up?Or just combining everything together and using some flag to differentiate the two at run time?
> Why do you think it is better to have two small
> classes versus messing with the command line start
> up?
>
The class path is quite long anyway, so adding one more path is not a big deal. Secondly, The startup script does not require compilation; thus, it is is flexible compared to configuration java-hardcoding. Thirdly, the static binding of classes by classpath allows to avoid redundancy of instantiating singletons., which would be needed in java-configuration:
class Configuration1 {
void main() {
Gui.main(args, new Model1(args));
}
}
class Configuration2 {
void main() {
Gui.main(args, new Model1(args));
}
}
set classpath=cp
java Configuration1
java Configuration2
// vs. just
set classpath=cp;model1
java Gui
set classpath=cp;model2
java Gui
You see, the 2nd, startup script -only approach is much less messy.
Finally, the tricky meta-approach gives extra capabilities to the code. Conventionally, the comunicating parties must have a fixed interface (the protocol). They can access member fields and methods of each other. For example, the the gui may set values on the underlying model:
model.amplitude = 100;
In different configurations you may use different subclasses of the Model, which means you are not allowed to alert the variable amplitude declaration. But what if it is shared by threads in one of the configurations? The variable should be redeclared volatile.
This is exactly the situation I've got: one model was accessing its shared variables only from gui thread while another both from gui and main threads. You see, the static binding that I've brought up allows to modify the member declarations! So that,
class Model { // at path1
public float amplitude;
class Model { // at path2
public volatile float amplitude;
I think it also should be possible to adjust field types, like int to to float. Peahaps, I have invented this kind of binding intuitively provisioning the decalration incompatibility between my models.
These are the advantages I see in establishing the class references by classpath. Actually, the idea of using scripts for (com)bin(d)*** and launching the compiled components is not new. I beleive the scripts, the meta-languages exist exactly for this purpose. I have just realized they can be advantageous glue for Java-written classes.
> Or just combining everything together and using some
> flag to differentiate the two at run time?
The conditional instantiation has two disadvantages:
1) It is not extensible; that is, additional strategies may appear to those two in the future.
2) the BIG SWITCH approach is opposed to OOP , where we establish target objects by reference :).
Certainly, we could provide the "flag" in command line as the identifier for the strategy class to be loaded:
class Gui {
void main(args) {
final Model model ;
try {
model = (Model) Class.forName(args[0]);
} problem {
//
}
}
set classpath=cp
java Gui Model1
// Is it somehow better than simple script:
set classpath=cp;Model1
java Gui
// ?
Additionally, here are two points to consider. At first, from all the alternatives to instruct the ClassLoader about the strategy class to be loaded (1 - by new operator as in Configuration example above; 2 - by setting a reference to it in classpath as in my trick; 3 - by forName), this 3rd alternative is the dirtiest. Though I often use it to load my plug-ins, especially to be switched at runtime, somthing tells me that the first two methods are better for establishing "rigid" configurations.
At second, call it my whim, I prefer setting up the classpath only once and to avoid the requirement to supply the class reference every time you launch the program. Yes, cmd line is intended for configuring programs, as well as the scripts are. But there is a standard classpath means to instruct the ClassLoader about the class to be loaded. So, why should one write extra code to duplicate this funcionality?
>> At second, call it my whim, I prefer setting up the classpath only once and to avoid the requirement to supply the class reference every time you launch the program. Yes, cmd line is intended for configuring programs, as well as the scripts are. But there is a standard classpath means to instruct the ClassLoader about the class to be loaded. So, why should one write extra code to duplicate this funcionality?
well, for starters, if I'm deploying on a machine other than my development workstation ( and anyone writing code for a living does ) I'd rather not trust that the global classpath is going to point to where it should. yes, you could have a script that does it for the user, but what if someone else changes the classpath? what if another application on the global classpath has classes with the same fully-qualified name as yours ( highly unlikely, but still possible ), and in the classpath before your own entries? what if - and this is not unommon - the customer has a security policy in-place that prohibits the setting of system variables on their servers? by far and away the best policy is to give your application the exact classpath it needs when you start it. the only room for error there is your own
> At second, call it my whim, I prefer setting up the
> classpath only once and to avoid the requirement to
> supply the class reference every time you launch the
> program. Yes, cmd line is intended for configuring
> programs, as well as the scripts are. But there is a
> standard classpath means to instruct the ClassLoader
> about the class to be loaded. So, why should one
> write extra code to duplicate this funcionality?
There are any number of ways to do this which do not require using a class name on the command line.
As such I doubt you are going to find any discussions about the way you did it.
> >> At second, call it my whim, I prefer setting up
> the classpath only once and to avoid the requirement
> to supply the class reference every time you launch
> the program. Yes, cmd line is intended for
> configuring programs, as well as the scripts are. But
> there is a standard classpath means to instruct the
> ClassLoader about the class to be loaded. So, why
> should one write extra code to duplicate this
> funcionality?
>
> well, for starters, if I'm deploying on a machine
> other than my development workstation ( and anyone
> writing code for a living does ) I'd rather not trust
> that the global classpath is going to point to where
> it should. yes, you could have a script that does it
> for the user, but what if someone else changes the
> classpath? what if another application on the global
> classpath has classes with the same fully-qualified
> name as yours ( highly unlikely, but still possible
> ), and in the classpath before your own entries? what
> if - and this is not unommon - the customer has a
> security policy in-place that prohibits the setting
> of system variables on their servers?
I do not insist on system-wide settings. It not just is useless, it is impossible to include every class under a single classpath. It is impossible just for the purpose I've brought up here: two mutually exclusive configurations require namesake classes in different directories and classpath is tweaked to switch between them.
I'm telling about specifying the classpath once per session rather than once per launch:
set classpath=path_to_play
play "magic fly.mp3"
play "noam chomsky.mp3"
play "distorted morality.avi"
set classpath=algorithm_1
process dataset_1
process dataset_2
process dataset_3
...
set classpath=algorithm_2
process dataset_1
process dataset_2
process dataset_3
...
You use a script to assemble/glue a program from components. You do it once, then you launch the resulting program many times (with different arguments). You should specify the classpath anyway. What is wrong here? Why should I add extra complexity writing extra code if I can proceed naturally without it?
> by far and
> away the best policy is to give your application the
> exact classpath it needs when you start it. the only
> room for error there is your own
The best policy I was taught on launching programs was to set up the environment such that executable can be accessable from the data-files (current) directory. For instance, I type javac class.java not from the java/bin directory. I run the compiler from the directory where the source files resides. The well-set up environment allows that. If it would not, i had to specify the reference to javac (the path to it) every launch. Do not you agree that configuring environment pror to multiple launches of program is much more convenient than passing configuration to the program every time you launch it? As I've mentioned above, parsing/initializing the configuration by the program requires additional code writing. Not to mention the extra code takes extra storage space, execution time and computation energy waste. These extras are just signs of non-natural approach. I argue that there is a solid reason to call the classpath-based configuration "natural". Furthermore, the same classpath is also used by java compiler, so the natural meta-approach to class resolution additionally favors the (better) development.
> There are any number of ways to do this which do not
> require using a class name on the command line.
Sounds intriguing. Let me surmise. Since our purpose is to assign a (strategy) class to a main program, we cannot proceed without the class name at all. So, the question is where can we put that name if it can be neither hardcoded, nor classpathed, nor cmd lined? The only one thing remains -- the configuration file. Indeed, it more flexible than java-hardcoded configuration program, since it does not require the compilation. But anyway, you need extra code in your program to parse and accept the configuration, e.g. to extract the name and load/instantiate the class. Why not just to exploit the special tool for the purpose, the system classpath file?
> As such I doubt you are going to find any discussions
> about the way you did it.
What makes you thinking that I'm not interested in the topic I have created? Quite contrary. Since you are making me to think that my idea is somwhat novel, thus, likely previously not covered in the literature, I'm interested to broaden the topic to the startup scripts.
What do you know about scripts? Are they used for assembling components? What is bad in binding java classes by a trivial command script? When it is appropriate to glue the major compiled components by simple compiled configuration program, when it is worth to parse a file or cmd line and when it is enaugh to assemble/configure the major components by scripts?
> Do not you agree that configuring environment pror to multiple
> launches of program is much more convenient than passing
> configuration to the program every time you launch it?
I don't.
jboss doesn't run from a 'java' command. It runs with a OS specific script file. That file sets up a lot of stuff which includes both the class path and the command line.
I wouldn't trade that for any combination that required me to keep separate classpaths or separate command line options.
And changing the class path either means that there is only one java application on the box (one class path) or that the class path MUST be included in a separate environment or as a command line option anyways. So it doesn't matter.
> > Do not you agree that configuring environment pror
> to multiple
> > launches of program is much more convenient than
> passing
> > configuration to the program every time you launch
> it?
>
> I don't.
>
> jboss doesn't run from a 'java' command. It runs
> with a OS specific script file. That file sets up a
> lot of stuff which includes both the class path and
> the command line.
>
OK, I was adressing the standard applications. My solution does not fit the server "applications". I suppose the server applications are plug-ins, all share a single server class path. Obviously, changing classpath for a single plug-in would require to stop the whole application, which is not acceptible in the case of server.
But it is also obvious that servers should allow the applications to manage their (apps') classpath. Aren't they? I've seen the severs use hacks to accomplish this http://forum.java.sun.com/thread.jspa?threadID=300557
> I wouldn't trade that for any combination that
> required me to keep separate classpaths or separate
> command line options.
What do you mean by the "trade"? The script is configuration of your server. You tell that you have only one and will dismiss any proposal of another configuration/strategy. Nevertheless, configurations make sense only when there is more than one and this topic about pros and cons of one particular approach to switch between them.
>
> OK, I was adressing the standard applications. My
> solution does not fit the server "applications". I
> suppose the server applications are plug-ins, all
> share a single server class path. Obviously, changing
> classpath for a single plug-in would require to stop
> the whole application, which is not acceptible in the
> case of server.
That doesn't change anything that I said. I was using jboss as an example of a complex process needed to start up an application (it doesn't matter than the functionality of that application is to act as a server.)
>
> But it is also obvious that servers should allow the
> applications to manage their (apps') classpath.
> Aren't they? I've seen the severs use hacks to
> accomplish this
> http://forum.java.sun.com/thread.jspa?threadID=300557
>
That thread addresses class loading at runtime. That is functionality that an app might or might not need and so the thread is only specific to that. Jboss uses class loaders but that has nothing to do with the set up for running it.
>
>
>
> > I wouldn't trade that for any combination that
> > required me to keep separate classpaths or separate
> > command line options.
>
> What do you mean by the "trade"? The script is
> configuration of your server. You tell that you have
> only one and will dismiss any proposal of another
> configuration/strategy. Nevertheless, configurations
> make sense only when there is more than one and this
> topic about pros and cons of one particular approach
> to switch between them.
The script for jboss is a setup that allows me to run jboss on my computer. The script for tomcat is a setup that allows me to run tomcat on my computer. I can run both at the same time. Both use different class paths and different command line options. In fact each can be run with a different VM as well.
That is possible only because they use a script file. It has nothing to do with how they use the classpath nor what they do with the command line options.
Once one starts using a script file it is irrelevant as to how the class path or command line options are used. If you are using a script file then do it however you want. It doesn't matter.
But if you are not using a script file then a solution that requires modifying the classpath is not a good solution.
If you are using a script file and your are only asking about what one should do in that, then to some extent it probably depends on how you intend to deliver and license the application.
I, too, was taught that using the environment variable was the 'best' way to go. I was taught a lot of "best practices" at university, much of which I've thrown away since. trust the people who code for a living over those who teach coding for a living
> > But it is also obvious that servers should allow
> the
> > applications to manage their (apps') classpath.
> > Aren't they? I've seen the severs use hacks to
> > accomplish this
> >
> http://forum.java.sun.com/thread.jspa?threadID=300557
> >
>
> That thread addresses class loading at runtime. That
> is functionality that an app might or might not need
> and so the thread is only specific to that. Jboss
> uses class loaders but that has nothing to do with
> the set up for running it.
That thread is named "Modify Classpath At Runtime" and it addresses its subject. Сlassloaders are the only objects which physically use classpaths. That is why they are there.
> Once one starts using a script file it is irrelevant
> as to how the class path or command line options are
> used. If you are using a script file then do it
> however you want. It doesn't matter.
Yes, scripts assemble components by initializing environment and launch them with cmd params. You can do the same (glue and execute components) by a wrapper java/other compiled application. So, why do you use script if you are against them?
> But if you are not using a script file then a
> solution that requires modifying the classpath is not
> a good solution.
So, classpaths should not be used with java from outside of scripts. Peahaps, it is good memo for enduser. However, I'm asking about when using calsspathes as glue?
> If you are using a script file and your are only
> asking about what one should do in that, then to some
> extent it probably depends on how you intend to
> deliver and license the application.
Do scripts require a separate license?
> I, too, was taught that using the environment
> variable was the 'best' way to go. I was taught a lot
> of "best practices" at university, much of which I've
> thrown away since. trust the people who code for a
> living over those who teach coding for a living
It is nice to hear from someone that his time in school was a waste of time. Is it all you wanted to deliver or you are suggesing that my teachnical adviser was meaningless too?
> > > But it is also obvious that servers should allow the
> > > applications to manage their (apps') classpath.
> > > Aren't they? I've seen the severs use hacks to
> > > accomplish this
> > >
> >
> http://forum.java.sun.com/thread.jspa?threadID=300557
> > >
> >
> > That thread addresses class loading at runtime. That
> > is functionality that an app might or might not need
> > and so the thread is only specific to that. Jboss
> > uses class loaders but that has nothing to do with
> > the set up for running it.
>
> That thread is named "Modify Classpath At Runtime"
> and it addresses its subject. 裭assloaders are
> the only objects which physically use classpaths.
> That is why they are there.
>
Looking back at why you provided this link you suggested that the solution provided by the link is a 'hack' (reply #7). Again using jboss....
1. Jboss is NOT using class loaders because there is some sort of limitation in the class path.
2. Jboss has a requirement to load functionality at runtime. And to reload it. Class loaders provide that.
Despite the OPs contention in that thread, loading classes dynamically has been discussed many times. Even loading jdbc drivers has been discussed many times. Those discussions are not centered around a limitation of the command line but rather because the authors want to load using a different methodology. Note that one can create a class loader that loads classes across a network or even from a database and neither of those would be solved by any variation on the command line.
>
>
> Once one starts using a script file it is
> irrelevant as to how the class path or command line options
> are
> used. If you are using a script file then do it
> however you want. It doesn't matter.
>
> Yes, scripts assemble components by initializing
> environment and launch them with cmd params. You can
> do the same (glue and execute components) by a
> wrapper java/other compiled application. So, why do
> you use script if you are against them?
>
I didn't say I was against them.
I don't know how to say what I said differently. So again, if one is using a script file then then how one uses the command line options and class path are irrelevant.
>
>
> > But if you are not using a script file then a
> > solution that requires modifying the classpath is not
> > a good solution.
>
> So, classpaths should not be used with java from
> outside of scripts. Peahaps, it is good memo for
> enduser. However, I'm asking about when using
> calsspathes as glue?
>
End user? I do not understand that statement.
The solution you proposed specifically has to do with starting a java application.
And as I said, using the env classpath var for that purpose is not generally a good idea. Actually most of the time it is bad idea, even for a dedicated server.
Why you think you need to use that doesn't change the fact that using it impacts the entire system and not just your application.
>
>
> > If you are using a script file and your are only
> > asking about what one should do in that, then to some
> > extent it probably depends on how you intend to
> > deliver and license the application.
>
> Do scripts require a separate license?
>
You misread what I said. It does not say nor suggest that script files themselves are licensed nor that licensing depends on the script file. What is says is how you use the script file depends on the needs of your business and in particular how you deliver and license the application.
> methodology. Note that one can create a class
> loader that loads classes across a network or even
> from a database and neither of those would be solved
> by any variation on the command line.
Once more, people have discovered a 'hack' to control a classpath at runtime. Classpath is a way to tell the ClassLoader which class should it load/bind into your application.
> I don't know how to say what I said differently. So
> again, if one is using a script file then then how
> one uses the command line options and class path are
> irrelevant. But if you are not using a script file then a
> solution that requires modifying the classpath is
> not a good solution.
Thank you for bringing that explicitly. By script, you mean configuration + launch instructions. It is convetient for user. But during my development, I usually set up path only once per session of java/javac launches. Is it bad?
I other words you approve any use of script for glueing application components including my case. Anyway, you have intrigued me and I would like to hear the alternative ways of configuring an application in addition to the mentioned ones: java hardcoding, cmd line, config file and, finally, config script (script is the only meta java instruction).
> And as I said, using the env classpath var for that
> purpose is not generally a good idea. Actually most
> of the time it is bad idea, even for a dedicated
> server.
In the last paragraph, the type of glue was irrelevant. Since, I've started this thread to hear some critics, please be a little more specific. Do you mean that static binding precludes coexistance of multiple alternatives of the same class in one environment?
> Why you think you need to use that doesn't change the
> fact that using it impacts the entire system and not
> just your application.
As we have mentioned previously, one can easily run two applications with different (classpath) configurations simultaneously on the same machine. Hardly, Sun would rely on classpathes have they system-wide interference.
> Do scripts require a separate license?
>
> You misread what I said. It does not say nor suggest
> that script files themselves are licensed nor that
> licensing depends on the script file. What is says
> is how you use the script file depends on the
> needs of your business and in particular how you
> deliver and license the application.
I just do not understand such general phrases. Despite I can bring many examples of how copyright terrorists prevent population from natural/optimal/best solutions, I do not see why pure java classes vs. java classes + java scripts and configuration files require a different license treatment. The only rational obstacle to using scripts I see is the target system non-uniformity. You can always be shure in existance of standard JVM but which java metatools are allowed is a system-dependent. This is the only reason I see to prefer parsing cmd line or config file over classpath binding. We have already discussed the server applications, which are merely plug-ins and, thus, do not allow easy classpath trick. Applets have a somewhat standard glue -- the javascript, an alternative to the environment scripts.
> > methodology. Note that one can create a class
> > loader that loads classes across a network or even
> > from a database and neither of those would be
> solved
> > by any variation on the command line.
>
> Once more, people have discovered a 'hack' to control
> a classpath at runtime. '
No, this is not a "hack" that was "discoverd." It was designed into the API from the beginning.
I knew that name looked familiar. http://forum.java.sun.com/thread.jspa?threadID=731805
> > methodology. Note that one can create a class
> > loader that loads classes across a network or even
> > from a database and neither of those would be
> solved
> > by any variation on the command line.
>
> Once more, people have discovered a 'hack' to control
> a classpath at runtime. Classpath is a way to tell
> the ClassLoader which class should it load/bind into
> your application.
Again no. A class loader specifically exists to a allow an application to control how classes are loaded. It has nothing to do with being a 'hack'
>
>
>
>
> > I don't know how to say what I said differently. So
> again, if one is using a script file then then how
> one uses the command line options and class path are
> irrelevant. But if you are not using a script file then a
> solution that requires modifying the classpath is
> not a good solution.
>
> Thank you for bringing that explicitly. By script,
> you mean configuration + launch instructions. It is
> convetient for user. But during my development, I
> usually set up path only once per session of
> java/javac launches. Is it bad?
>
How you want to do your developement environment is irrelevant as well. Myself I usually use a script file right from the start and in there sometimes I set the env class path and sometimes I use the command line class path arg. The choice is completely arbritrary.
> I other words you approve any use of script for
> glueing application components including my case.
I wouldn't state it like that. I would state that if you are using a script file to start your app then it doesn't really matter what you want to do with the actually env var and command line arguments. Do it based on a business need, for programming convenience or even because you think it is cool to do it that way. Most of the time it doesn't matter (the only time it does matter is if there is a business need that is being ignored.)
> Anyway, you have intrigued me and I would like to
> hear the alternative ways of configuring an
> application in addition to the mentioned ones: java
> hardcoding, cmd line, config file and, finally,
> config script (script is the only meta java
> instruction).
>
A script file is a way to encapsulate the start up process. It is not itself a solution.
Some that I can think of.
- env var
- command line
- boot class loading
- factories
- persistent store
....- config file
....- database
............Variations in here allow for class paths, class names, classes themselves (even in a config file.), and even factories which could then provide strategies.
>
>
>
> > And as I said, using the env classpath var for that
> > purpose is not generally a good idea. Actually most
> > of the time it is bad idea, even for a dedicated
> > server.
>
> In the last paragraph, the type of glue was
> irrelevant. Since, I've started this thread to
> hear some critics, please be a little more specific.
> Do you mean that static binding precludes coexistance
> of multiple alternatives of the same class in one
> environment?
>
If I must set the class path in my environment to run your application what impact might that have on any other java application in my environment?
Can you be sure that the class path that you are using will not have artifacts from other applications on my computer that will not impact your application?
> > Why you think you need to use that doesn't change the
> > fact that using it impacts the entire system and not
> > just your application.
>
> As we have mentioned previously, one can easily run
> two applications with different (classpath)
> configurations simultaneously on the same machine.
> Hardly, Sun would rely on classpathes have they
> system-wide interference.
>
If you set the env var for the computer then all java applications which run without excluding the env var will use that same class path.
This is most likely to have an impact in the following situatations.
1. Common libraries are used (like xml) but each application uses a different version.
2. Vendors do not name their class strictly and so name conflicts exist.
3. Different applications from the same vendor with changes in the shared code between the applications and versions of the shared code.
>
>
> > Do scripts require a separate license?
> >
> > You misread what I said. It does not say nor suggest
> > that script files themselves are licensed nor that
> > licensing depends on the script file. What is says
> > is how you use the script file depends on the
> > needs of your business and in particular how you
> > deliver and license the application.
>
> I just do not understand such general phrases.
> Despite I can bring many examples of how copyright
> terrorists prevent population from
> natural/optimal/best solutions, I do not see why
> pure java classes vs. java classes + java scripts
> and configuration files require a different license
> treatment.
Again I didn't say that.
I did not say that using a script changes your license.
Again your business needs drive how you create the script.
Hopefully an example will help you understand this.
Example: Your business delivers a standard and a professional version. As a business decision (this is not a technical decision) you can choose to handle delivery in one of the following ways.
1. The standard version has all of the functionality of the professional version but a license key only allows the application to run the standard functionality. To upgrade all a user needs is a new license key.
2. The standard version and the professional version are completely separate. To upgrade a user will need to download a new version of the software.
The above choice could impact how the application starts.
> The only rational obstacle to using
> scripts I see is the target system non-uniformity.
> You can always be shure in existance of standard JVM
> but which java metatools are allowed is a
> system-dependent. This is the only reason I see to
> prefer parsing cmd line or config file over
> classpath binding. We have already discussed the
> server applications, which are merely plug-ins and,
> thus, do not allow easy classpath trick. Applets
> have a somewhat standard glue -- the javascript, an
> alternative to the environment scripts.
Huh?
No idea what you mean by "meta-tools".
I haven't suggested that there is any "obstacle" to using a script file to start an application.
Applets have nothing to do with it. If you are creating applets and intend to require that the class path on the client machine needs to be modified to support the applet then you are missing a significant advantage in using applets in the first place.
And javascript really has nothing to do with it.
Perhaps it would help if I clarified that 'script file' means a batch file in windows or a borne/cshell/korne shell on unix. These days one could use javascript/vbscript as a substitute for a batch file on a windows system (but the conceptual implementation for those languages would still be that of a batch file.)
> No, this is not a "hack" that was "discoverd." It was
> designed into the API from the beginning.
I do not think there is a meaningful difference between hacking and exploiting to point out.
> > Once more, people have discovered a 'hack' to
> control
> > a classpath at runtime. Classpath is a way to tell
> > the ClassLoader which class should it load/bind
> into
> > your application.
>
> Again no. A class loader specifically exists to a
> allow an application to control how classes are
> loaded. It has nothing to do with being a 'hack'
What are you neglecting here? What are bringing here is intended behaviour of ClassLoader. I'm pointing to how people hack the loader to control the classpath at runtime. Whereby, the classpath is a variable of ClassLoader telling it the classes to be loaded.
> How you want to do your developement environment is
> irrelevant as well. Myself I usually use a script
> file right from the start and in there sometimes I
> set the env class path and sometimes I use the
> command line class path arg. The choice is
> completely arbritrary.
Talking that the means of configuring/gluing/launching of compiled components is irrelevant you are missing the topic.
> > I other words you approve any use of script for
> > glueing application components including my case.
>
> I wouldn't state it like that. I would state that if
> you are using a script file to start your app then it
> doesn't really matter what you want to do with the
> actually env var and command line arguments. Do it
> based on a business need, for programming convenience
> or even because you think it is cool to do it that
> way.
For me "cool" is everything that "fits naturally" or "effortlessly". After all, the creative job (the non-routine one like ours) requires some design guidelines to decide which solution is better. And this ideal is the nature. Any complications must be justified.
> Most of the time it doesn't matter (the only
> time it does matter is if there is a business need
> that is being ignored.)
Ok, you have explained what is a business (as opposed to technical/rational) solution. I would also to hear why env vars are bad for business and why what is good? And which solution is better for binding components in a multiedition family of similar products?
> ............Variations in here allow for class paths,
> class names, classes themselves (even in a config
> file.), and even factories which could then provide
> strategies.
And someone must have instruct the factory the classes it must produce. I have explained that classpath eliminates redundant coding and is thus a natural class fatory: it does what is supposed to do (points to target classes) and the conventional ClassLoader loads the classes in a usual way. In addition, no problems with explicit dynamic casting appears.
> If I must set the class path in my environment to run
> your application what impact might that have on any
> other java application in my environment?
> Can you be sure that the class path that you are
> using will not have artifacts from other applications
> on my computer that will not impact your
> application?
> > > Why you think you need to use that doesn't change
> the
> > > fact that using it impacts the entire system and
> not
> > > just your application.
> >
> > As we have mentioned previously, one can easily
> run
> > two applications with different (classpath)
> > configurations simultaneously on the same machine.
> > Hardly, Sun would rely on classpathes have they
> > system-wide interference.
> >
>
> If you set the env var for the computer then all java
> applications which run without excluding the env var
> will use that same class path.
Stop repating the ideas I have never proposed and, furthermore, have pubilcally repudiated in the 2/02/01 replay on georgemc attacks. Listen what he tells: by far and away the best policy is to give your application the exact classpath it needs when you start it. the only room for error there is your own. I cannot agree more. This guideline will prevent you from running more than one application in the same environment accompanied by your artifacts.
> No idea what you mean by "meta-tools".
These are software tools lying above your java code (jre, scripts). Had you understood in the beginning that the new operator and forClass are java means to choose a class to be instantiated while classpath relies behind the java app?
> I haven't suggested that there is any "obstacle" to
> using a script file to start an application.
I did. And the abstractness of the "command script" is the only rational problem, which means that in different enfironments you will have different tools. Hence, using scripts you loose the "run everywhere" advantage.
> Applets have nothing to do with it. If you are
> creating applets and intend to require that the class
> path on the client machine needs to be modified to
> support the applet then you are missing a significant
> advantage in using applets in the first place.
>
> And javascript really has nothing to do with it.
I'm telling that the javascript is an alternative glue to command scripts. It allows instantiation of java objects and establishing references between them. It is supplementary to binding/loading by classpath.
> Perhaps it would help if I clarified that 'script
> file' means a batch file in windows or a
> borne/cshell/korne shell on unix. These days one
> could use javascript/vbscript as a substitute for a
> batch file on a windows system (but the conceptual
> implementation for those languages would still be
> that of a batch file.)
A script (no matter whether browser, other application or OS-supplied) is a high-level language, used for configuring environments, assembling and executing components. Running apps from cmd line, there is a natural means to configure an application (regarding assigning a strategy) by classpath.
> > No, this is not a "hack" that was "discoverd." It
> was
> > designed into the API from the beginning.
>
> I do not think there is a meaningful difference
> between hacking and exploiting to point out.
WTF are you talking about? A feature was provided for a specific purpose, and we use it for that purpose. That's not a hack.
jverda at 2007-7-21 11:57:47 >
I'm f'g talking that exploiting protected code is sometimes called a hack.
> I'm f'g talking that exploiting protected code is> sometimes called a hack.You're saying that using a classloader is "exploiting protected code"?
jverda at 2007-7-21 11:57:47 >
I do not treat blindness. Go troll another forum.
> I do not treat blindness. Go troll another forum.
Ah, so you've taken on a new form of childish irrationality. Previously when someone questioned your or disagreed with you, you called them Java bigots. Now you've switched to calling me a troll rather than explaining anything.
No wonder nobody takes you seriously.
jverda at 2007-7-21 11:57:47 >
>
> > Most of the time it doesn't matter (the only
> > time it does matter is if there is a business need
> > that is being ignored.)
>
> Ok, you have explained what is a business (as opposed
> to technical/rational) solution. I would also to hear
> why env vars are bad for business and why what is
> good? And which solution is better for binding
> components in a multiedition family of similar
> products?
>
It is bad for business because it relies on the state of the enviroment existing as expected rather than defininig (setting up) the environment so that it always exists in a known state.
>
> > ............Variations in here allow for class paths,
> > class names, classes themselves (even in a config
> > file.), and even factories which could then
> provide
> > strategies.
>
> And someone must have instruct the factory the
> classes it must produce. I have explained that
> classpath eliminates redundant coding and is thus a
> natural class fatory: it does what is supposed to do
> (points to target classes) and the conventional
> ClassLoader loads the classes in a usual way. In
> addition, no problems with explicit dynamic casting
> appears.
And I have repeatedly stated that as long as you are wrapping this is a script then it doesn't matter what you do with the class path.
> >
> > If you set the env var for the computer then all java
> > applications which run without excluding the env var
> > will use that same class path.
>
> Stop repating the ideas I have never proposed and,
> furthermore, have pubilcally repudiated in the
> 2/02/01 replay on georgemc attacks. Listen what he
> tells: by far and away the best policy is to give
> your application the exact classpath it needs when
> you start it. the only room for error there is your
> own. I cannot agree more. This guideline will
> prevent you from running more than one application in
> the same environment accompanied by your artifacts.
It seems like you did propose it however.
OP: "set classpath = .;BasicStrategy"
Reply #2: "The class path is quite long anyway,"
So do you intend to start you application using a script file or not?
>
> > No idea what you mean by "meta-tools".
>
> These are software tools lying above your java code
> (jre, scripts). Had you understood in the beginning
> that the new operator and forClass are
> java means to choose a class to be instantiated while
> classpath relies behind the java app?
>
I know how java works.
You said "java metatools" in reply #12. The JRE is not a 'meta' tool. Script files (batch, unix shell scripts, vbscript, javascript, etc) have nothing to do with java. Nor are they meta tools.
Perhaps you didn't mean to prefix that with 'java'.
>
> > I haven't suggested that there is any "obstacle" to
> > using a script file to start an application.
>
> I did. And the abstractness of the "command script"
> is the only rational problem, which means that in
> different enfironments you will have different tools.
> Hence, using scripts you loose the "run everywhere"
> advantage.
You can't use a class path env var that does not vary for every environment. Not only does the syntax differ but the way you set it up varies as well.
>
>
>
> > Applets have nothing to do with it. If you are
> > creating applets and intend to require that the
> class
> > path on the client machine needs to be modified to
> > support the applet then you are missing a
> significant
> > advantage in using applets in the first place.
> >
> > And javascript really has nothing to do with it.
>
> I'm telling that the javascript is an alternative
> glue to command scripts. It allows instantiation of
> java objects and establishing references between
> them. It is supplementary to binding/loading by
> classpath.
>
Java script can instantiate java objects? Please provide an example of that.
>
>
> > Perhaps it would help if I clarified that 'script
> > file' means a batch file in windows or a
> > borne/cshell/korne shell on unix. These days one
> > could use javascript/vbscript as a substitute for
> a
> > batch file on a windows system (but the conceptual
> > implementation for those languages would still be
> > that of a batch file.)
>
> A script (no matter whether browser, other
> application or OS-supplied) is a high-level language,
> used for configuring environments, assembling and
> executing components. Running apps from cmd line,
> there is a natural means to configure an application
> (regarding assigning a strategy) by classpath.
Again it appears to me that you are suggesting that classpath is an alternative to some other start up method.
And again, as mentioned by me and others, that is not a good idea. If you intend to sell to any market that does not dedicate a machine to your application then your solution should budget extra support cost for your solutions that rely solely on the env var.
> It is bad for business because it relies on the state
> of the enviroment existing as expected rather than
> defininig (setting up) the environment so that it
> always exists in a known state.
I have denied the the proposal to rely on global classpath 3 times in this thread. Do you ever read whay I write? I'm in agreement with the georgemc's rule: by far and away the best policy is to give your application the exact classpath it needs when you start it. the only room for error there is your own. Your favorite jboss complies with it as well, so it should be a bad for business.
>And someone must have instruct the factory the
> classes it must produce. I have explained that
> classpath eliminates redundant coding and is thus a
> natural class fatory: it does what is supposed to
> do
> (points to target classes) and the conventional
> ClassLoader loads the classes in a usual way. In
> addition, no problems with explicit dynamic casting
> appears.
>
> And I have repeatedly stated that as long as you are
> wrapping this is a script then it doesn't matter what
> you do with the class path.
If it does not matter which design pattern to employ in which case, if they all are equally good for all cases, then we should close not only this topic but the whole forum. I still think that using environment tools are sometimes more advantegous over java coding.
> > > If you set the env var for the computer then all
> java
> > > applications which run without excluding the env
> var
> > > will use that same class path.
> >
> > Stop repating the ideas I have never proposed and,
> > furthermore, have pubilcally repudiated in the
> > 2/02/01 replay on georgemc attacks. Listen what he
> > tells: by far and away the best policy is to
> give
> > your application the exact classpath it needs when
> > you start it. the only room for error there is
> your
> > own. I cannot agree more. This guideline will
> > prevent you from running more than one application
> in
> > the same environment accompanied by your
> artifacts.
>
> It seems like you did propose it however.
>
> OP: "set classpath = .;BasicStrategy"
> Reply #2: "The class path is quite long anyway,"
>
> So do you intend to start you application using a
> script file or not?
What is a problem to put the command into a file? Should I write:==== Cmd file start ====cut here ====
"set classpath = .;BasicStrategy"
==== Cmd file end =====cut here ====
But you do not usually require this for java files. I am just giving you a novel idea to naturally implement a pattern of loading a replaceable class. I assume the details like packaging the cp set command into a script and executing it in preparation to app start as obvious.
> > > No idea what you mean by "meta-tools".
> >
> > These are software tools lying above your java
> code
> > (jre, scripts). Had you understood in the
> beginning
> > that the new operator and forClass
> are
> > java means to choose a class to be instantiated
> while
> > classpath relies behind the java app?
> >
>
> I know how java works.
>
> You said "java metatools" in reply #12. The JRE is
> not a 'meta' tool. Script files (batch, unix shell
> scripts, vbscript, javascript, etc) have nothing to
> do with java. Nor are they meta tools.
>
> Perhaps you didn't mean to prefix that with 'java'.
Here, you have wondered what do I mean by the 'meta'. The java environment can be influenced both from within your java program as well as by meta tools. One can reach the desired functionality by writing complex java components and glueing them by scripts (external tools). Set classpath is just on one of the meta commands which can give miraculous caps.
> > I haven't suggested that there is any "obstacle"
> to
> > using a script file to start an application.
>
> I did. And the abstractness of the "command script"
> is the only rational problem, which means that in
> different enfironments you will have different
> tools.
> Hence, using scripts you loose the "run everywhere"
> advantage.
>
> You can't use a class path env var that does not vary
> for every environment. Not only does the syntax
> differ but the way you set it up varies as well.
What is the "env var that does not vary for every environment"? Why jbos can be run by a script but my apps cannot?
> > > Applets have nothing to do with it. If you are
> > > creating applets and intend to require that the
> > class
> > > path on the client machine needs to be modified
> to
> > > support the applet then you are missing a
> > significant
> > > advantage in using applets in the first place.
> > >
> > > And javascript really has nothing to do with it.
> >
> > I'm telling that the javascript is an alternative
> > glue to command scripts. It allows instantiation
> of
> > java objects and establishing references between
> > them. It is supplementary to binding/loading by
> > classpath.
> >
>
> Java script can instantiate java objects? Please
> provide an example of that.
Have you heard of Netscape's LiveConnect?
http://www.phpfreaks.com/javascript_manual/page/lc.htm#1043780
> > Perhaps it would help if I clarified that 'script
> > file' means a batch file in windows or a
> > borne/cshell/korne shell on unix. These days one
> > could use javascript/vbscript as a substitute for
> a
> > batch file on a windows system (but the
> conceptual
> > implementation for those languages would still be
> > that of a batch file.)
>
> A script (no matter whether browser, other
> application or OS-supplied) is a high-level
> language,
> used for configuring environments, assembling and
> executing components. Running apps from cmd line,
> there is a natural means to configure an
> application
> (regarding assigning a strategy) by classpath.
>
> Again it appears to me that you are suggesting that
> classpath is an alternative to some other start up
> method.
>
> And again, as mentioned by me and others, that is not
> a good idea. If you intend to sell to any market
> that does not dedicate a machine to your application
> then your solution should budget extra support cost
> for your solutions that rely solely on the env var.
What do you mean "to rely solely on the env var"? Why when I use the classpath for the purpose -- to refer class path -- you label it a fragile relying solely on the env var?
> > I do not treat blindness. Go troll another forum.
>
> Ah, so you've taken on a new form of childish
> irrationality. Previously when someone questioned
> your or disagreed with you, you called them Java
> bigots. Now you've switched to calling me a troll
> rather than explaining anything.
>
> No wonder nobody takes you seriously.
I have responded on that. The person who bytes me because he cannot understand why the ClasspathHack class was presented on the parallel topic is blind and I cannot cure it.
The organ of vision is the brain. And the bigots are the blind believers. And I remember they claimed that "superconstructor first" is good thing but they will not tell me why. So refer the complain of unexplaining anything to youself.
> The organ of vision is the brain. And the bigots are
> the blind believers. And I remember they claimed
> that "superconstructor first" is good thing but they
> will not tell me why.
You were told why, in great detail. You simply ignored or did not understand the explanations. You, on the other hand, were not willing or able to provide any support at all for your proposal other than irrelevant analogies. I haven't read your ramblings in great detail here, but it seems to be just more of the same.
jverda at 2007-7-21 11:57:47 >
good grief you waffle on, don't you? I wouldn't like to comment on your technical advisors meaning, but for the record, I don't rate you too highly. the use of the global CLASSPATH environment variable is almost universally ignored by java professionals, and your refusal to accept this highlights the depth of your inexperience
the JDK provides us with a very nifty mechanism for loading classes of our choosing, at runtime, and without depending on the CLASSPATH environment variable for it. hardly a hack, is it? unless, of course, by "hack" you mean "I don't understand how it works". which you clearly don't. Java is a portable runtime, extending to platforms that will not even have a concept of "environment variables", so how you think this very platform-specific mechanism - that is not guaranteed to be present - is the de facto way to specify a classpath is beyond me
> the JDK provides us with a very nifty mechanism for
> loading classes of our choosing, at runtime, and
> without depending on the CLASSPATH environment
> variable for it.
In fact, quite the other way around. CLASSPATH depends on the classloader mechanism. CLASSPATH (and -cp and -classpath) is simply split apart and fed as elements to a ClassLoader. It's one particular, often convenient, way of making use of the classloader mechanism through simple runtime configuration.
> hardly a hack, is it? unless, of
> course, by "hack" you mean "I don't understand how it
> works".
BINGO!
jverda at 2007-7-21 11:57:47 >
ah, good old URLClassLoader. god bless you, and all who subclass you :-)
> > The organ of vision is the brain. And the bigots
> are
> > the blind believers. And I remember they claimed
> > that "superconstructor first" is good thing but
> they
> > will not tell me why.
>
> You were told why, in great detail. You simply
> ignored or did not understand the explanations. You,
> on the other hand, were not willing or able to
> provide any support at all for your proposal other
> than irrelevant analogies. I haven't read your
> ramblings in great detail here, but it seems to be
> just more of the same.
As about which analogies are relevant, I guess you do not accept any anologies at all. I cannot help if you fail to understand that superconstruction can be preceded by auxiliary building and blindly beleive that member fields cannot be calculated/initialized in parallel.
> good grief you waffle on, don't you? I wouldn't like
> to comment on your technical advisors meaning, but
> for the record, I don't rate you too highly. the use
> of the global CLASSPATH environment variable is
> almost universally ignored by java professionals, and
> your refusal to accept this highlights the depth of
> your inexperience
Peahaps, your profs ignore the 'path' variable in the first place but I agree with academists telling that launching apps from user data directory should be prefered to bin directory and classpath var is a java way to get away of it.
> the JDK provides us with a very nifty mechanism for
> loading classes of our choosing, at runtime, and
> without depending on the CLASSPATH environment
> variable for it. hardly a hack, is it? unless, of
> course, by "hack" you mean "I don't understand how it
> works".
Which mechanics do I not understand?
> As about which analogies are relevant, I guess you do
> not accept any anologies at all.
Wrong.
I accept analogies that are applicable and sensible. Your's were not.
> I cannot help if you
> fail to understand that superconstruction can be
> preceded by auxiliary building
And I cannot help you if you fail to understand that I never claimed otherwise. As was pointed out in that thread, it could have been done that way, but it would have led to many more errors for little or no gain.
> Peahaps, your profs ignore the 'path' variable in the
> first place but I agree with academists telling that
> launching apps from user data directory should be
> prefered to bin directory and classpath var is a java
> way to get away of it.
The above makes no sense. What do you mean "launching apps from user data directory"? What do you mean "classpath var is a java way to get away of it"? Your English is not precise enough to express your point. Perhaps you could try posting examples of code, command lines, scripts, whatever.
jverda at 2007-7-21 11:57:52 >
> And I cannot help you if you fail to understand that
> I never claimed otherwise. As was pointed out in that
> thread, it could have been done that way, but
> it would have led to many more errors for little or
> no gain.
You claim you can make an auxiliary construction while keeping the requirement to build the superconstruction first? What about constructing the super and extended parts of the object simultaneously?
> > Peahaps, your profs ignore the 'path' variable in
> the
> > first place but I agree with academists telling
> that
> > launching apps from user data directory should be
> > prefered to bin directory and classpath var is a
> java
> > way to get away of it.
>
> The above makes no sense. What do you mean "launching
> apps from user data directory"? What do you mean
> "classpath var is a java way to get away of it"? Your
> English is not precise enough to express your point.
> Perhaps you could try posting examples of code,
> command lines, scripts, whatever.
I have explained earlier. The data directory is a current directrory. The directory becomes current for application if you start it in that directory. Usually, apps process user files, so the current directory must be the data directory. Once classpath is set up, you are free to run your app from any location. Do not know why should I clarify the "menanigless and unprofessional things" :(
>> Usually, apps process user files, so the current directory must be the data directory
really? not got much enterprise experience, then? google 'database systems' for some insight into why the above quote might just be a teeny bit flawed
>> Once classpath is set up, you are free to run your app from any location
I've rarely come across that requirement, and in the few instances I have, a script to start the app with the correct classpath has always sufficed
to be honest, valjok, it's patently obvious that you are a little out of your depth here, and that your 'arguments' are based on what you've read in a book rather than any of your own actual experience. give up
