Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > The Revenge of the Geeks

Reply
Thread Tools

The Revenge of the Geeks

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 10:10 PM, BGB wrote:
> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>> On 1/24/2013 5:10 PM, BGB wrote:
>>> On 1/24/2013 10:06 AM, Arne Vajh°j wrote:
>>>> On 1/23/2013 11:47 PM, BGB wrote:
>>>>> but, in any case, with the other languages there are a wide range of
>>>>> libraries available, many under fairly open licenses (like MIT or
>>>>> BSD),
>>>>> and there is a lot more GPL stuff available,
>>>>
>>>> In the EE space you would need to look at CORBA or DCOM.
>>>>
>>>> You would prefer Java EE believe me.
>>>>
>>>>
>>>>
>>>
>>> errm, so you can't just copy all the files over to ones' servers? and/or
>>> recompile the code for ones' servers?...

>>
>> The coding model in Java EE is definitely more modern than that
>> of CORBA and DCOM.
>>

>
> I didn't mean like CORBA or DCOM, but probably directly copying over
> program binaries (DLLs or SOs and precompiled binaries and similar), and
> probably using traditional compilation and linking.


You lost me.

How to get the same type of services as Java EE provides is related
to copying binaries how?

>>> as for data sharing (between lots of networked servers), I am less sure,
>>> I would think maybe something like NFS or SAMBA, but then thinking of
>>> it, NFS or Samba might not scale well if the number of servers becomes
>>> sufficiently large (like, people would probably want to locally cache
>>> files, rather than always doing IO over the network, ...).

>>
>> Persistent data in the the Java EE world is most often in database.
>>

>
> well, I meant for code and other resources.
>
> or, to you mean putting code in the database as well?...
>
> (like, put the JAR in a data-blob and fetch it out via a SELECT or
> something?...).


No.

But as I said I am lost.

Arne

 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 10:10 PM, BGB wrote:
> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>> On 1/24/2013 5:10 PM, BGB wrote:
>>> otherwise, not entirely sure why developing for these would be all that
>>> much different than dealing with a normal PC or Linux box.

>>
>> It is not the type of box that makes a difference.
>>
>> You can run a Java EE app server on your laptop.
>>
>> You laptop does just not have the IO system and the 24x7
>> reliability to run in most production contexts.
>>
>> The difference in development is the services provided by the
>> server that the application can utilize if the application follows
>> the rules.
>>

>
> I have a web-server I am running on an old laptop, it uses Windows XP,
> Apache, and also has PHP, MySQL, and MediaWiki...


If you decided that you preferred Java over PHP, then
you would replace PHP with a Java EE web container (Tomcat
would be obvious) and write your web app using Java EE
technologies like servlet, JSP and JSF.

Arne


 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      01-25-2013
BGB wrote:
> I didn't mean like CORBA or DCOM, but probably directly copying over
> program binaries (DLLs or SOs and precompiled binaries and similar), and
> probably using traditional compilation and linking.


What does any of that have to do with Java EE, BGB?

> Arne Vajh°j wrote:
>> Persistent data in the the Java EE world is most often in database.

>
> well, I meant for code and other resources.


WTF?

That has nothing to do with Java EE or Java SE. Source code is kept in textfiles,
ideally managed through version control, regardless of which you're using.

Or are you talking about the binaries? The binaries are just Java classes.

> or, to you mean putting code in the database as well?...
> (like, put the JAR in a data-blob and fetch it out via a SELECT or
> something?...).


Huh?

BGB, your posts show no evidence of any comprehension of what Java EE is ordoes,
none for knowledge of what Java EE-compliant products are out there, or thefact that
Java EE is just Java with some additional specifications that vendors implement.

I suggest you study up on those matters before pontificating about the subject.

--
Lew
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 9:15 PM, Arne Vajh°j wrote:
> On 1/24/2013 10:10 PM, BGB wrote:
>> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>>> On 1/24/2013 5:10 PM, BGB wrote:
>>>> On 1/24/2013 10:06 AM, Arne Vajh°j wrote:
>>>>> On 1/23/2013 11:47 PM, BGB wrote:
>>>>>> but, in any case, with the other languages there are a wide range of
>>>>>> libraries available, many under fairly open licenses (like MIT or
>>>>>> BSD),
>>>>>> and there is a lot more GPL stuff available,
>>>>>
>>>>> In the EE space you would need to look at CORBA or DCOM.
>>>>>
>>>>> You would prefer Java EE believe me.
>>>>>
>>>>>
>>>>>
>>>>
>>>> errm, so you can't just copy all the files over to ones' servers?
>>>> and/or
>>>> recompile the code for ones' servers?...
>>>
>>> The coding model in Java EE is definitely more modern than that
>>> of CORBA and DCOM.
>>>

>>
>> I didn't mean like CORBA or DCOM, but probably directly copying over
>> program binaries (DLLs or SOs and precompiled binaries and similar), and
>> probably using traditional compilation and linking.

>
> You lost me.
>
> How to get the same type of services as Java EE provides is related
> to copying binaries how?
>


I may be missing something here...


because... it involves linking against and using libraries, correct?...


like "both languages have libraries, but maybe not the same libraries".

as in, for Java, you can copy around and use a JAR.
or in C or C++, you link against the DLL or SO, or use a static-library
(which then becomes a permanent part of the binary), ...

like, for Java there is LWOGL, and for C there is "opengl32.dll".
or, one person uses AWT or Swing, and another uses GDI+ or WinForms.


if you have some program and need to run it on a web-server, it can be
copied over into its "cgi-bin/" directory or similar, or set it to run
at start-up as a deamon (or a as a service on Windows, or launch it via
"start-up applications" or similar).


if end users run a program, they typically download it off the internet,
maybe as a ZIP, or maybe as a self-extracting "setup.exe" or similar.

any libraries would be contained inside, and copied over into the
relevant directories. any data files are typically copied along as well,
and the installer might put everything in its place.


and, if a person needs new libraries for a project they are developing,
they will go and download them off the internet, maybe recompile it from
source, ...


I actually have little idea how DCOM or CORBA fits into this, as they
are network protocols (like for doing RPC), but you don't generally need
a network protocol for using a library, just the library itself (IOW:
its compiled binary).

like, you might need something like these for accessing a web-service or
similar I guess. (like, Google does something like this, for its search
APIs and Google Earth and similar I think).


but, little idea what if-anything web-services have to do with using
libraries though.

admittedly, I don't personally have much experience dealing with RPC or
web-services though (and mostly use HTTP for file-delivery, well, and
for providing a website).



but, for most client/server apps I am familiar with are more like:
server runs somewhere (opening a listen port, for example, port 80 for
HTTP, ...);
user downloads and runs client;
client opens socket to connect to server (such as TCP or UDP);
then they share whatever data is relevant over the socket, using the
relevant protocol (often application-specific).

say, the protocol does structured message delivery, either using globs
of XML (like Jabber/XMPP or similar), or maybe some specialized binary
message format, and sometimes with a "multiplexer" to avoid clogging up
TCP sockets with large messages (by breaking large messages into smaller
pieces), ...

then each end sees the messages, and handles them as appropriate (or
reassembles the pieces, and handles complete messages when they arrive), ...


>>>> as for data sharing (between lots of networked servers), I am less
>>>> sure,
>>>> I would think maybe something like NFS or SAMBA, but then thinking of
>>>> it, NFS or Samba might not scale well if the number of servers becomes
>>>> sufficiently large (like, people would probably want to locally cache
>>>> files, rather than always doing IO over the network, ...).
>>>
>>> Persistent data in the the Java EE world is most often in database.
>>>

>>
>> well, I meant for code and other resources.
>>
>> or, to you mean putting code in the database as well?...
>>
>> (like, put the JAR in a data-blob and fetch it out via a SELECT or
>> something?...).

>
> No.
>
> But as I said I am lost.
>


I am confused as well...


the whole Java SE vs Java EE thing has taken a turn into the confusing...


the former makes sense, because that is what a person gets when they go
download and install the JDK or the JRE.

but the latter?... dunno. it sounds like something a bit different (not
just an alternate version of the JDK or JRE).


> Arne
>


 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 9:17 PM, Arne Vajh°j wrote:
> On 1/24/2013 10:10 PM, BGB wrote:
>> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>>> On 1/24/2013 5:10 PM, BGB wrote:
>>>> otherwise, not entirely sure why developing for these would be all that
>>>> much different than dealing with a normal PC or Linux box.
>>>
>>> It is not the type of box that makes a difference.
>>>
>>> You can run a Java EE app server on your laptop.
>>>
>>> You laptop does just not have the IO system and the 24x7
>>> reliability to run in most production contexts.
>>>
>>> The difference in development is the services provided by the
>>> server that the application can utilize if the application follows
>>> the rules.
>>>

>>
>> I have a web-server I am running on an old laptop, it uses Windows XP,
>> Apache, and also has PHP, MySQL, and MediaWiki...

>
> If you decided that you preferred Java over PHP, then
> you would replace PHP with a Java EE web container (Tomcat
> would be obvious) and write your web app using Java EE
> technologies like servlet, JSP and JSF.
>


I use PHP mostly for sake of running MediaWiki, which is probably the
biggest/most complicated thing on the site.


my own CGI binaries have typically been written in C and compiled into
EXE's before being copied over to the server.

though, PHP does have the advantage that a person doesn't have to
recompile it after editing (though, there is the possibility that a web
request could come in with the PHP code in an inconsistent state, say
because someone was in the middle of editing the code directly on the
server or something...).


I had idly considered the possibility of using my own scripting language
here, but haven't seen much point.

like, C works well enough, and PHP works even if it does look a little
funky.


I had considered the remote possibility of a kind of "pay and register"
thing, which would probably work something like:
person clicks button, and does paypal thing;
it uses a target URL set to the user registration form;
after doing this, it probably gives them their user-key (basically, as a
glob of ciphered data), and records this into a file.

haven't done so yet, and am currently operating under a "donate if you
want to" system, but hardly anyone is making donations, so probably no
one would care enough to bother paying and registering either (they
would just be like "hay whatever" and not bother, or just warez it or
figure out a way to circumvent making a payment or similar via using
hacked URLs or something...).

so, I haven't done so yet...


granted, yes, either way I am not exactly making money here (rarely does
anyone donate anything, and in the off chance they do, it has been like
$0.05 and similar...).

making actually more money on YouTube, as theoretically at least, I have
$0.75 on this, from ads on videos, but meh, whatever sometimes...


 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 9:42 PM, Lew wrote:
> BGB wrote:
>> I didn't mean like CORBA or DCOM, but probably directly copying over
>> program binaries (DLLs or SOs and precompiled binaries and similar), and
>> probably using traditional compilation and linking.

>
> What does any of that have to do with Java EE, BGB?
>
>> Arne Vajh°j wrote:
>>> Persistent data in the the Java EE world is most often in database.

>>
>> well, I meant for code and other resources.

>
> WTF?
>
> That has nothing to do with Java EE or Java SE. Source code is kept in text files,
> ideally managed through version control, regardless of which you're using.
>
> Or are you talking about the binaries? The binaries are just Java classes.
>
>> or, to you mean putting code in the database as well?...
>> (like, put the JAR in a data-blob and fetch it out via a SELECT or
>> something?...).

>
> Huh?
>
> BGB, your posts show no evidence of any comprehension of what Java EE is or does,
> none for knowledge of what Java EE-compliant products are out there, or the fact that
> Java EE is just Java with some additional specifications that vendors implement.
>
> I suggest you study up on those matters before pontificating about the subject.
>


I was not claiming here to have any idea what Java EE was, this much
should have been obvious enough...

just responding to what people have been writing, but it is confusing,
and the Wikipedia article doesn't really make it obvious either.



granted, I will not claim to have much familiarity with businesses or
enterprise systems either (not a business person, not really worked on
anything like this either, ...).

or, IOW: this is all in an area I have never gone into, much beyond what
was covered in college classes, when trying to study for a CompSci major
(and then getting screwed over by stupid math classes and moving...).


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-25-2013
BGB wrote:
> I may be missing something here...
> because... it involves linking against and using libraries, correct?...


Not in the case of Java EE explicitly. You use libraries to write your Java code, sure,
just like in Java SE, but there's no link step.

But once you've written a Java EE app, you don't do anything resembling linking. You
upload the app to the application server, which deploys it for you.

> like "both languages have libraries, but maybe not the same libraries".


You overemphasize the similarities and ignore the differences.

> as in, for Java, you can copy around and use a JAR.


You can, but that's only the tip of the iceberg.

> or in C or C++, you link against the DLL or SO, or use a static-library
> (which then becomes a permanent part of the binary), ...


Whatever. This does not shed light on the use or value (or problems) of Java EE.

> like, for Java there is LWOGL, and for C there is "opengl32.dll".


Nothing to do with this discussion.

> or, one person uses AWT or Swing, and another uses GDI+ or WinForms.


Things are always cognate, but that doesn't make them the same.

All analogies share the characteristic that they break down if carried too far.

> if you have some program and need to run it on a web-server, it can be
> copied over into its "cgi-bin/" directory or similar, or set it to run
> at start-up as a deamon (or a as a service on Windows, or launch it via
> "start-up applications" or similar).


That's very different from how you administer a Java EE server.

Really, it's annoying that you don't research this first. Bye.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-25-2013
BGB wrote:
> Lew wrote:
>> BGB, your posts show no evidence of any comprehension of what Java EE is or does,
>> none for knowledge of what Java EE-compliant products are out there, or the fact that
>> Java EE is just Java with some additional specifications that vendors implement.

>
>> I suggest you study up on those matters before pontificating about the subject.

>
> I was not claiming here to have any idea what Java EE was, this much
> should have been obvious enough...


No, it was not obvious that you were disclaiming knowledge, though it was obvious that
you lacked it.

Most of the stuff you've been saying about Java EE is very far off the mark. You should read
about it.

> just responding to what people have been writing, but it is confusing,
> and the Wikipedia article doesn't really make it obvious either.


I have not heard of anyone being able to program Java from reading a Wikipedia article
about it.

> granted, I will not claim to have much familiarity with businesses or
> enterprise systems either (not a business person, not really worked on
> anything like this either, ...).


That has nothing to do with being able to evaluate the technical aspects of the
specification.

> or, IOW: this is all in an area I have never gone into, much beyond what
> was covered in college classes, when trying to study for a CompSci major
> (and then getting screwed over by stupid math classes and moving...).


Exactly. It is an area you have never gone into. I am suggesting that you remedy that.

College is irrelevant. "Stupid math classes" are irrelevant. None of that stopped you from
talking about Java EE without understanding. You can gain understanding with a modicum
of research. You need not blame your history, or your college professor, or past
grievances, nor be held back by them. You can determine your own future by doing the
freaking research and learning something of what you're passing judgment about.

--
Lew
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      01-25-2013
On 1/24/2013 6:30 AM, Roedy Green wrote:
> On Tue, 22 Jan 2013 06:41:45 -0800 (PST), Ramon F Herrera
> <(E-Mail Removed)> wrote, quoted or indirectly quoted someone who
> said :
>
>> "A close look at how Oracle installs deceptive software with Java
>> updates"

>
> WinZip is one of the worst. You really have to keep your wits about
> you these days to avoiding installing junk. It is quite undignified of
> a product like Java to stoop that low. I hate it when companies buy
> out smaller companies. The products always deteriorate or disappear
> entirely.
>
> I would like to start pressuring everyone to put the name of the
> product and version on any download button.
>


(satire)

but then how would the download sites make money, if they can't make
every banner be a giant green "Download" button, with the actual
download for the program being a little plain-text link somewhere near
the bottom of the page somewhere?...


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-26-2013
On 1/24/2013 11:31 PM, BGB wrote:
> On 1/24/2013 9:15 PM, Arne Vajh°j wrote:
>> On 1/24/2013 10:10 PM, BGB wrote:
>>> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>>>> On 1/24/2013 5:10 PM, BGB wrote:
>>>>> On 1/24/2013 10:06 AM, Arne Vajh°j wrote:
>>>>>> On 1/23/2013 11:47 PM, BGB wrote:
>>>>>>> but, in any case, with the other languages there are a wide range of
>>>>>>> libraries available, many under fairly open licenses (like MIT or
>>>>>>> BSD),
>>>>>>> and there is a lot more GPL stuff available,
>>>>>>
>>>>>> In the EE space you would need to look at CORBA or DCOM.
>>>>>>
>>>>>> You would prefer Java EE believe me.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> errm, so you can't just copy all the files over to ones' servers?
>>>>> and/or
>>>>> recompile the code for ones' servers?...
>>>>
>>>> The coding model in Java EE is definitely more modern than that
>>>> of CORBA and DCOM.
>>>>
>>>
>>> I didn't mean like CORBA or DCOM, but probably directly copying over
>>> program binaries (DLLs or SOs and precompiled binaries and similar), and
>>> probably using traditional compilation and linking.

>>
>> You lost me.
>>
>> How to get the same type of services as Java EE provides is related
>> to copying binaries how?

>
> I may be missing something here...
>
> because... it involves linking against and using libraries, correct?...
>
> like "both languages have libraries, but maybe not the same libraries".
>
> as in, for Java, you can copy around and use a JAR.
> or in C or C++, you link against the DLL or SO, or use a static-library
> (which then becomes a permanent part of the binary), ...
>
> like, for Java there is LWOGL, and for C there is "opengl32.dll".
> or, one person uses AWT or Swing, and another uses GDI+ or WinForms.
>
> if you have some program and need to run it on a web-server, it can be
> copied over into its "cgi-bin/" directory or similar, or set it to run
> at start-up as a deamon (or a as a service on Windows, or launch it via
> "start-up applications" or similar).
>
> if end users run a program, they typically download it off the internet,
> maybe as a ZIP, or maybe as a self-extracting "setup.exe" or similar.
>
> any libraries would be contained inside, and copied over into the
> relevant directories. any data files are typically copied along as well,
> and the installer might put everything in its place.
>
> and, if a person needs new libraries for a project they are developing,
> they will go and download them off the internet, maybe recompile it from
> source, ...


You copy jar files in Java EE just like you do in Java SE.

The difference is in what the libraries do. Not how they are
distributed.

> I actually have little idea how DCOM or CORBA fits into this, as they
> are network protocols (like for doing RPC),


They are not.

CORBA is a component model that uses IIOP as network protocol.

DCOM is a component model that uses ncacn_tcp as network protocol.

> but, for most client/server apps I am familiar with are more like:
> server runs somewhere (opening a listen port, for example, port 80 for
> HTTP, ...);
> user downloads and runs client;
> client opens socket to connect to server (such as TCP or UDP);
> then they share whatever data is relevant over the socket, using the
> relevant protocol (often application-specific).
>
> say, the protocol does structured message delivery, either using globs
> of XML (like Jabber/XMPP or similar), or maybe some specialized binary
> message format, and sometimes with a "multiplexer" to avoid clogging up
> TCP sockets with large messages (by breaking large messages into smaller
> pieces), ...
>
> then each end sees the messages, and handles them as appropriate (or
> reassembles the pieces, and handles complete messages when they arrive),
> ...


Let me give you a very simple example.

You want to allow browsers to connect to your code and be
told what the time is.

You could write that in Java SE. You listen on port 80, accept
a connection, start a thread that parse the request and outout
the response.

With Java EE you could write now.jsp:

<%=new Date()%>

and Java EE would handle sockets, threads, reading and writing for
you.

The JSP get compiled to Java that get compiled to byte code that
get JIT compiled.

>>>>> as for data sharing (between lots of networked servers), I am less
>>>>> sure,
>>>>> I would think maybe something like NFS or SAMBA, but then thinking of
>>>>> it, NFS or Samba might not scale well if the number of servers becomes
>>>>> sufficiently large (like, people would probably want to locally cache
>>>>> files, rather than always doing IO over the network, ...).
>>>>
>>>> Persistent data in the the Java EE world is most often in database.
>>>>
>>>
>>> well, I meant for code and other resources.
>>>
>>> or, to you mean putting code in the database as well?...
>>>
>>> (like, put the JAR in a data-blob and fetch it out via a SELECT or
>>> something?...).

>>
>> No.
>>
>> But as I said I am lost.
>>

>
> I am confused as well...
>
> the whole Java SE vs Java EE thing has taken a turn into the confusing...
>
> the former makes sense, because that is what a person gets when they go
> download and install the JDK or the JRE.
>
> but the latter?... dunno. it sounds like something a bit different (not
> just an alternate version of the JDK or JRE).


Correct.

Let us say that the Java SE model is:
- you write some classes and build them with JDK
- you start the JVM with a main method in one of your classes
- your main code calls some code

The Java EE model is:
- you start the JVM with the Java EE app server
- you write some classes and build them with JDK
- you deploy your classes (no main method) to the server
- the server calls your code

In Java SE terms you can consider the Java EE server to be the
program and your Java EE application to be a plugin to the
server.

Arne


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Revenge JAFO Computer Support 8 05-17-2005 11:54 PM
New computer and Yuri's revenge George Computer Support 4 07-31-2004 07:57 AM
Jaws: The Revenge, Release Differences? Aphelion DVD Video 6 07-07-2004 01:01 PM
Getting Revenge slumpy Computer Support 5 04-27-2004 11:42 AM
New Revenge Of The Pink Panther - Music missing? PW DVD Video 4 04-10-2004 08:45 AM



Advertisments