| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> I have sinned :) I actually started a discussion on /. regarding the combination of "Java and Debian" and find it funny to see how some people simply don't understand that in some cases it can be beneficial to keep multiple versions around 8)
<1> Tsk tsk
<1> What have you done!?
<0> Resonator: I actually posted a response about how the gnu tools aren't that great and how you can easily install the Sun JDK using 'dpkg' (Debian package manager) and a simply 'control' file :)
<1> This is true.
<0> Resonator: so people pointed out "make-jpkg" which "debianizes" the JDK tarball to which I responded that its not feasible because you can't keep multiple versions around 8)
<0> Resonator: its peanuts, but I actually keep 1.5-6 around for my customer projects while I use 1.5-8 for my own hacking 8)
<2> could i get some quick comments on this? http://xjc.weirdbyte.com/
<0> DrunkCow: why expect us to goto websites while we prefer IRC? How about giving us some more context first?
<2> :) its the java-cgi thing
<0> I don't believe in java-cgi crapola.
<0> </comment>
<2> please motivate
<0> DrunkCow: I have done so in the past already.
<3> "demonstration"
<3> what's the use of that, besides "looky, it works"?
<3> and what does cgi have to do with it? you can dynamically invoke methods in a servlet just as well.
<3> ah, that's the point, to avoid a specific java container, ok.
<0> Clackwell: from what I understand from discussions in the past he actually runs java programs through Apache as if it were a cgi program.
<3> well
<3> DrunkCow: if you start a new JVM instance that way you might be in trouble, as they tend to be kind of heavyweight.
<2> servlets arent instaced by a new JVM each time?
<3> DrunkCow: the point of servlets is that they and the jvm are not instanciated for each request, yes.
<2> ok
<3> that was the initial motivation for creating them, because cgi was too limiting performance-wise.
<2> ok
<2> Even tho, this is a faster way to hook your applications to apache than with tomcat.
<3> you could have a cgi that contacts a running jvm...but then you would have to create a communication interface. what would that be? how about http? your cgi would relay the request to the jvm via http then. and the jvm? that would probably run a...servlet container in turn. :)
<3> DrunkCow: define "faster" and "applications".
<3> nobody will write applications for xjc.
<3> it is lunacy.
<2> Clackwell: because of perfomance-wise?
<3> DrunkCow: xjc can handle more requests per second than tomcat, orion and others?
<0> DrunkCow: if you don't like the idea of an application server, why not get a webserver which can do both? Like the SunONE webserver.
<3> prove that, i guess.
<2> Clackwell: why shoulnd't. Apache can handle more requests than Tomcat
<0> DrunkCow: errrrr
<2> Tomcat is weaker than Apache.
<0> and this is where I stop discussing since there's no point.
<3> DrunkCow: let me ask again: does xjc instantiate a new jvm for each request?
<2> Clackwell: yes
<1> Wow.
<2> Clackwell: but has the init of new jvm have an affect on number of connections? or the handing of requests?
<3> DrunkCow: again: servlets and other mechanisms have been invented because the cgi approach is ****ed up performance-wise for anything the goes beyond a few hits per second (i am exaggerating, but still)
<3> DrunkCow: creating processes is relatively expensive.
<1> DrunkCow: JVM's also take up a pretty good chunk of memory too. Concurrent hits to the application would be a m***ive waste of memory.
<1> s/ too//
<2> Resonator: yes, it takes hardware requirements.
<3> and cpu cycles (for creating the process, loading the jvm, loading all the cl***es, over and over again).
<1> DrunkCow: but it's not like invoking something like a Perl interpreter
<2> So, servlets and jsp arent cgi? CGI does have its advantages aswell.
<3> DrunkCow: believe me, nobody with a clue will use xjc, unless you turn it into a "fastcgi" or something more or less like servlets, which avoids the constant creation of new processes.
<1> DrunkCow: the JVM overall is a VERY heavy application - much more heavy than Perl, for example.
<2> Clackwell: the only way to do that is to have a running server-app all the time tho.
<2> Clackwell: then it wont be CGI.
<3> (how heavy depends on the actual cl***es being used. the jvm may be quick to load, but if you access swing cl***es...)
<3> DrunkCow: exactly.
<1> Clackwell: well, yeah, but comparatively speaking :)
<3> DrunkCow: and if people need to install java on their box anyway...why not go that extra mile. and why stick to something proprietary like xjc?
<3> really, i think this is doomed.
<0> you're not alone on that idea 8)
<3> and you are lucky people aren't laughing at you, and that they talk to you at all.
<0> Clackwell: we're past that stage 8)
<3> ;)
<2> lucky? :) this is the internet, im suprised :P
<2> c*
<2> Besides, its fun to talk about new ideas and discuss them.
<3> that's not new, that's old. the IT world has p***ed that cgi performance discussion about 6, 8 years ago.
<2> I dont really want an application that is on all the time. Seems like its too fussy. PHP doesnt have it, but yet again thats written in c and doesnt have a jvm
<3> the jvm is written in c too <shrug>
<3> surely the hardware has changed since then.
<2> sooo...?
<0> actually... php also uses some sort of jvm.
<2> so why is this "idea" bad compared to php
<1> I dunno that it's as much a VM as an interpreter though.
<3> DrunkCow: you said php is written in c, as if that meant anything. and so i pointed out that the jvm is written in c too, so it means the same thing (if anything).
<0> Resonator: hmm... good point.
<1> DrunkCow: because Java requires a virtual machine to run. PHP/Perl are interpreted languages. And in most cases, they're interpreted once, and then there is what is basically a natively-compiled version available to the server. From what I understand, that's how PHP works.
<3> DrunkCow: size matters. and who says that php used via cgi is such a good idea anyway?
<1> That's also how Perl works if you're using something like mod_perl, compile once, and every execution after that is really fast.
<3> erh..
<1> I mean that it caches the interpreted version of the script, it's not literally a native binary
<3> mod_perl sounds more like an in-process module in the web server (apache). so the main point of that is that it does not create a process for each request.
<3> same goes for the/a php module.
<1> I thought the latest versions would cache compiled scripts?
<3> if it can keep a preparsed/compiled version of the scripts/pages around, even better.
<3> but the main point is to avoid the mad spawning of processes, i am sure.
<1> If not, I stand corrected... Anyway, the point is, Java needs that VM. When you run PHP, you run a module in Apache that interprets the scripts, it's on all the time after you load Apache.
<1> If you're using Java, why not have a JVM sitting around ready to run Java apps whenever they are requested?
<2> so the weak thing of this is the creation of jvm would take a lot of unwanted resources
<1> DrunkCow: yeah, essentially.
<3> DrunkCow: creating processes is expensive. any processes.
<3> and the heavier the programs running in them, the worse. and the sun jvm is on the heavier side of life.
<2> what about if you use j2me? ;)
<3> php's and perl's executable/intepreters might be more lightweight, for sure.
<3> then you still have the process overhead.
<3> you are trying to dodge the wrong problem.
<2> true, but the execute time would increase
<2> decrease
<2> its impossible to do that, unless you create somesort of a server
<2> how does modules work? if its only one process. apache starts, for example, php.exe and keeps it running?
<3> DrunkCow: the cgi could act as a relay to the server. if invoked, it could check if the server is running, and if not, start it, then communicate with it. the server could shutdown after an idle time.
<3> DrunkCow: also you could load the sun jvm into the apache process as a module.
<1> Didn't that Apache JServ thing do that?
<3> how that is different to having a separate process escapes me though.
<3> Resonator: <shrug>
<1> Oh well, work day is over for me, see you folks later.
<2> how is what different from having a seperate process?
<3> DrunkCow: loading the sun jvm into the apache process by way of a module.
<2> even if i start jvm, i have to create some kind of interface to actually run my code.
<3> you are loading it INTO the apache process....so you have the jvm resource overhead, no way to avoid that.
<3> DrunkCow: sure. right now that interface consists of cgi and some java cl***.
<2> thats way over my head. startin jme without an "application" and then telling it to execute what byte-code is more than i can
<3> DrunkCow: the sun jvm can be used as a DLL/shared library by c/c++ and other languages/programs.
<3> they can load it and tell it to execute stuff.
<3> java.exe actually does that.
<2> java.exe starts the jvm then tells it what to load
<3> exactly. and since the jvm is a dll...
<4> is there a standard way to include external xml into xml?
<3> so you could write your own .exe to load the jvm, and tell it what to do.
<2> Clackwell: yea, i think thats how todays .exe java applications work today
<5> never mind, i think i found it
<2> anyway, this ****s. I wanted to create websites in pure Java enviroment without any fuss. XJC works tho, but.. mm
<6> Hm.. I'm having a most bizzare .. well I can't say it's an "error"...
<6> Does this initialization make any sense? : int storeInfo[] = { this.blaqla, this.srcCol, this.minX, this.minX, this.minX, this.minX };
<6> Will it do what I think it shoud do? Just create a new int[ 6 ] and fill it up with the mentioned values?
<2> Clackwell: is this really doomed? no way i can optimize it?
<5> yes
<6> Because it doesn't do that... it creates an int[] of lenght 6 with only the first two values being copied...
<6> Although nothing is acessing the this.minX, maxX, and so on.. they're all nonzero values, but in the new int[] fields, there are zeroes
<6> Is this some common glitch or is there a devil in my computer
<5> strange, what if you replace the init elements with constants 2..6
<6> I will try that, good idea
<6> int storeInfo[] = { this.blaqla, this.srcCol, 2,3,4,5 }; results in....
<6> 4 : 16711680 : 2 : 3 : 4 : 5
<6> it's ok
<6> It seems that somehow, when the field is being initialized, it picks up wrong values from the min max fields
<6> Although, listen to this
<6> Just one line above the initialization I did a
<6> System.out.println( this.blaqla + " : " + this.srcCol + " : " + this.minX + " : " + this.maxX+ " : " + this.minY+ " : " + this.maxY );
<6> and all the values are in place! i mean wtf?
<5> if you provide a compilable example I'd check it out
<6> rgr
<6> What was that paste site, please?
<5> pastebin.com
<3> DrunkCow: you should ask yourself what problem you are trying to solve. you are not just fixing the "needs java servlet container" requirement, but you also make this into "this is not servlets, this is my own proprietary thing", which is a pretty strong turnoff. people like standards.
<3> see you later
<6> Ok, this is my code : http://pastebin.com/775261
Return to
#java
or
Go to some related
logs:
radjijit
#AllNiteCafe
#c++
#teens
#chatzone
#linuxhelp
#MissKitten
#teens
castup linux
#linux
|
|