The Revenge of the Geeks

A

Arved Sandstrom

some of us never go anywhere near business apps though...


for example, I am mostly at-present a game developer, with side areas in
audio/video processing (writing codecs, ...), and am also into things
like compilers and scripting VM technology.

these are generally areas where C and C++ have a much stronger hold.
[ SNIP ]

"Business" apps is however the core strength of Java, that and all the
tooling that goes along with it. I couldn't care less if Java is found
on *any* consumer computer, because that's not particularly important.

It comes back to this: you pick a language because of what it's suited
for, or after languages have been around for a while, what other people
already have used it for.

For "enterprise" type work the languages used are variable. For example,
if you're dealing with IBM WebSphere MQ, depending on your task, you
might be using a .NET language, Java, C or C++. But nevertheless a great
deal of applications from the big iron companies are Java SE and EE.

AHS
 
B

BGB

some of us never go anywhere near business apps though...


for example, I am mostly at-present a game developer, with side areas in
audio/video processing (writing codecs, ...), and am also into things
like compilers and scripting VM technology.

these are generally areas where C and C++ have a much stronger hold.
[ SNIP ]

"Business" apps is however the core strength of Java, that and all the
tooling that goes along with it. I couldn't care less if Java is found
on *any* consumer computer, because that's not particularly important.

It comes back to this: you pick a language because of what it's suited
for, or after languages have been around for a while, what other people
already have used it for.

For "enterprise" type work the languages used are variable. For example,
if you're dealing with IBM WebSphere MQ, depending on your task, you
might be using a .NET language, Java, C or C++. But nevertheless a great
deal of applications from the big iron companies are Java SE and EE.

well, yes, but this creates a split:
people writing business apps have reason to use it, since it does fairly
well at this particular domain;
people doing other stuff have less reason to use it (since, they are not
writing business apps, and it doesn't have as many strong points outside
this area).


it is worth noting though that the original topic applied mostly to
end-users using Java on Windows systems, and presumably what sorts of
apps this implies (most likely end-user applications, running on desktop
PCs).

very likely, this largely amounts to things like OpenOffice and
Minecraft and similar...

but, Java doesn't otherwise make a strong presence in this space.


granted, yes, I may be biased some in that I don't really write all that
much Java code (admittedly, I have written a lot more C and C# code, and
ironically, more C# thus far than C++). actually, there is more code in
my scripting-language than in C++ as well at present it seems (so, the
language-use ranking based on line-counts of my project is like: C, C#,
BS, C++, Java).

all sort of glued together into a single Mloc-sized project...
C is dominiant, and also sort of the "common hub" language, as pretty
much everything can talk to C, but not as often to each other.


or such...
 
R

Roedy Green

"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.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
 
E

Ezekiel

cipher said:
Additionally, at least one major software outfit, Libre Office, has
announced their intentions to scrap Java in favor of another solution.
As it is, only the DB portion of LO relies on Java...

Say what??? How did you come up with that ridiculous conclusion?

https://wiki.documentfoundation.org/Development/Java

<quote>
What pieces of LibreOffice are written in Java?
(The list of java code in LibreOffice is constantly changing. This list was
last updated in May 2012)

Java Source Files

a.. accessibility/
a.. bridge/
b.. workben(ch)/
b.. android/
c.. apache-commons/ ("Java libraries; used for logging and http/https
access in Extensions")
d.. bean/
e.. bridges/
f.. chart2/qa/TestCaseOldAPI.java (nothing else under chart2)
g.. cli_ure/qa/climaker/ClimakerTestCase.java
h.. codemaker/test/javamaker/
i.. comphelper/qa/complex/
j.. connectivity/
a.. com/sun/star/sdbcx/comp/
b.. qa/
a.. complex/connectivity/
b.. connectivity/tools/
k.. cppuhelper/qa/propertysetmixin/JavaSupplier.java
l.. dbaccess/qa/
m.. desktop/test/deployment/
n.. embeddedobj/qa/
o.. embeddedobj/test/
p.. extensions/qa/
q.. extensions/test/
r.. filter/
s.. forms/qa/
t.. framework/qa/complex/
u.. javaunohelper/{test/}com/sun/star/
v.. jurt/{test/}com/sun/star/
w.. jurt/workbench/com/sun/star/comp/urlresolver/UrlResolver_Test.java
x.. jvmaccess/workbench/java/TestComponent.java
y.. jvmfwk/plugins/sunmajor/pluginlib/JREProperties.java
z.. l10ntools/source/filter/
aa.. linguistic/qa/complex/linguistic/HangulHanjaConversion.java
ab.. linguistic/qa/complex/linguistic/TestDocument.java
ac.. nlpsolver/src/com/sun/star/comp/Calc/NLPSolver/
ad.. nlpsolver/ThirdParty/EvolutionarySolver/src/net/adaptivebox/
ae.. odk/examples/DevelopersGuide/
af.. odk/examples/java/
ag.. odk/source/com/sun/star/lib/loader/
ah.. package/qa/ofopxmlstorages/
ai.. package/qa/storages/
aj.. qadevOOo/ (LOTS of java files in multiple subdirs)
ak.. reportbuilder/java/com/sun/star/report/
al.. reportdesign/qa/complex/reportdesign/
am.. ridljar/ (many files)
an.. sc/qa/complex/
ao.. scripting/examples/java/
ap.. scripting/java/
aq.. scripting/workben/
ar.. sfx2/qa/
as.. smoketest/com/sun/star/comp/smoketest/TestExtension.java
at.. sot/qa/complex/olesimplestorage/
au.. starmath/qa/unoapi/Test.java
av.. stoc/test/javavm/
aw.. svl/qa/complex/
ax.. swext/mediawiki/src/com/sun/star/wiki/
ay.. sw/qa/complex/
az.. testtools/
ba.. toolkit/qa/
bb.. toolkit/test/accessibility/
bc.. ucb/qa/complex/
bd.. ucb/test/com/sun/star/comp/ucb/GlobalTransfer_Test.java
be.. unotest/source/java/org/openoffice/test/
bf.. unotools/qa/complex/tempfile/
bg.. unoxml/qa/complex/unoxml/
bh.. ure/source/uretest/
bi.. vcl/qa/complex/
bj.. wizards/com/sun/star/wizards/
bk.. writerfilter/qa/complex/ooxml/ (2 files)
bl.. xmerge/source/ (MANY files in many subdirs)
bm.. xmerge/workben/XmlDiff.java
bn.. xmlsecurity/test_docs/tools/httpserv/src/httpserv/Main.java
bo.. xmlsecurity/tools/uno/
JAR Files (Compressed Archives included in-tree):

a.. qadevOOo/testdocs/qadevlibs/JobExecutor.jar
b.. qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
c.. src/8294d6c42e3553229af9934c5c0ed997-stax-api-1.0-2-sources.jar
d.. xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
</quote>

--
Any country with laws is, by definition, not "free"

Homer, the frothing idiot.
23 Jan 2013
Message-ID: <[email protected]>
 
E

Ezekiel

cipher said:
I'll dig it up, but I read it.

here's one:

<http://www.lockergnome.com/uncategorized/2010/11/12/libre-office-using-
java-to-a-lesser-extent/>

That's a fairly old link (2010) from some anonymous person (theoracle). The
very specific list of modules using Java is from the Libre Office itself and
is from 2012. I'm inclined to take their word on it.
I have no Java and LO works fine but for the DB. The DB needs
Are you actually using it?

Yes I do have it installed on a couple of my Linux machines (work and home)
and use it occasionally. I also have Java installed and since I need and
use Java for other things I don't have any plans to remove Java.
 
A

Arne Vajhøj

That's a fairly old link (2010) from some anonymous person (theoracle). The
very specific list of modules using Java is from the Libre Office itself and
is from 2012. I'm inclined to take their word on it.


Yes I do have it installed on a couple of my Linux machines (work and home)
and use it occasionally. I also have Java installed and since I need and
use Java for other things I don't have any plans to remove Java.

It is well known that OO/LO can be used without Java.

You can't use the database and a few other things, but the
rest is working.

Why someone would bother I don't understand (it is just a few
hundred MB of disk space).

But it is certainly doable.

Arne
 
A

Arne Vajhøj

I appreciate your not jumping on my error, 66% not 61% is what I should
have posted...

I did but I am just a bit subtle.
When Homeland Security/CERT start posting recommendations and
instructions for removing Java you know your product is in trouble.

Not really.

The Java economy is something like 0.1% applets, 0.9% desktop apps
and 99% server side apps.

So if Java on desktop dropped to 0% in 10 minutes, then almost
nobody in the Java world would even notice it.

Arne
 
A

Arne Vajhøj

Additionally, at least one major software outfit, Libre Office, has
announced their intentions to scrap Java in favor of another solution.
As it is, only the DB portion of LO relies on Java...

I did not see that announcement.

DB is the big Java part, but there are also some other minor
pieces in Java.

Java in OO/LO has always been controversial.

But I suspect that they may find it difficult to get rid of.

They need to find a new DB engine and integrate with that.

They need to replace all the Java code. It may not be the biggest
parts, but some years ago (around OOo 3.1 time) I counted almost 3500
Java sources files in the source.

And they have the DB conversion issue. Can they live with not being able
to open old databases or do they include HSQLDB and Java the next 5
years to be able to convert old databases.

Arne
 
A

Arne Vajhøj

some of us never go anywhere near business apps though...

Yes. But then Java may not be the obvious choice.
for example, I am mostly at-present a game developer, with side areas in
audio/video processing (writing codecs, ...), and am also into things
like compilers and scripting VM technology.

these are generally areas where C and C++ have a much stronger hold.

Yes.

Java is probably almost non-existing on the graphical side.

I believe some multi-player games use Java server side.
in general, yes, it is ok.

its main selling points IMO are its reasonably fast compile times and
ease of quickly throwing together GUIs in WinForms, ...

WinForms was supplemented with a slight taste of replaced with
WPF 7 years ago.
AFAIK, Java EE costs money though, and I somehow suspect probably most
end-users have Java SE installed.

No - Java EE does not necessarily cost money. JBoss, Tomcat etc. can be
used for free.

Java EE is server side. Client side will typical be browser, but can in
theory also be a Java SE desktop app or a .NET/native desktop app.
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.

:)

Arne
 
A

Arne Vajhøj

On 1/23/2013 7:17 PM, Arne Vajhøj wrote:
I don't think Java should worry about C++. For business apps, then
C++ is not really an option. And business apps is what Java is good
at.

some of us never go anywhere near business apps though...

for example, I am mostly at-present a game developer, with side areas in
audio/video processing (writing codecs, ...), and am also into things
like compilers and scripting VM technology.

these are generally areas where C and C++ have a much stronger hold.
[ SNIP ]

"Business" apps is however the core strength of Java, that and all the
tooling that goes along with it. I couldn't care less if Java is found
on *any* consumer computer, because that's not particularly important.

It comes back to this: you pick a language because of what it's suited
for, or after languages have been around for a while, what other people
already have used it for.

For "enterprise" type work the languages used are variable. For example,
if you're dealing with IBM WebSphere MQ, depending on your task, you
might be using a .NET language, Java, C or C++. But nevertheless a great
deal of applications from the big iron companies are Java SE and EE.

well, yes, but this creates a split:
people writing business apps have reason to use it, since it does fairly
well at this particular domain;
people doing other stuff have less reason to use it (since, they are not
writing business apps, and it doesn't have as many strong points outside
this area).

Java is not the language for all purposes.
it is worth noting though that the original topic applied mostly to
end-users using Java on Windows systems, and presumably what sorts of
apps this implies (most likely end-user applications, running on desktop
PCs).

True.

But it it is still relevant because it explains where and why the focus
of Java are.

Arne
 
L

Lew

BGB said:
....
[Arved]

Facts not in evidence.
some of us never go anywhere near business apps though...

And therefore don't use Java, if they don't choose. Doesn't say anything
against Java as a platform.
... [Arved]
90% of developer productivity is achieved by adept and informed use of
what other people have written: libraries.
potentially, but if a person can choose freely, all the major language
options have libraries. not necessarily all the same libraries, but
libraries none-the-less [sic] ...

All automobiles have engines. Why would anyone ever buy a Ferrari?

Java is notable for the extent and quality of the libraries bundled with the platform.

And as Arne points out, the quality of the EE libraries are what make it such a solid
spec.
AFAIK, Java EE costs money though, and I somehow suspect probably most

Wha...?

JBoss, OpenEJB, Glassfish, Geronimo, ...
end-users have Java SE installed.

Wha...?

Do most end users have C++ installed?
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),

Are these enterprise libraries suitable for the use cases that make Java dominate?
and there is a lot more GPL stuff available, although GPL has some of

Apache, BSD, etc., etc., etc.

Including those free Java EE systems that go farther than you know.
its own issues (can't really use GPL'ed code in developing proprietary
software, ...).

Which is why other licenses exist.
 
A

Arved Sandstrom

I am a bit skeptical about that as a general approach.

If the situation were that Java programs were almost always correct
but that what took time was writing all the boilerplate code, then
switching to Scala would be an obvious choice.

But I don't see that. I see a large portion of Java developers not
mastering Java and switching them to Scala would be one big
fucking disaster.

As a general approach I'd have to agree. OTOH for the unknown percentage
of Java programmers who are actually competent, which is the group I had
in mind, there are tasks that are best done in another JVM language. The
interop for Clojure<=>Java and Scala<=>Java is pretty good.

For the incompetent group they shouldn't be programming at all.
 
A

Arne Vajhøj

As a general approach I'd have to agree. OTOH for the unknown percentage
of Java programmers who are actually competent, which is the group I had
in mind, there are tasks that are best done in another JVM language. The
interop for Clojure<=>Java and Scala<=>Java is pretty good.

For the incompetent group they shouldn't be programming at all.

I agree.

But that means nothing.

Because they still do.

Arne
 
B

BGB

Yes. But then Java may not be the obvious choice.


Yes.

Java is probably almost non-existing on the graphical side.

I believe some multi-player games use Java server side.

Minecraft has both the client and server end written in Java.


don't know much about others games.

most of the other game engines I am aware of are typically written in C
or C++, usually with either a common scripting language (such as Python
or Lua), or a specialized scripting language (such as UnrealScript,
descendants of QuakeC, ...).

in most I am familiar with, servers are typically run by individuals,
usually either a "listen server", where the player runs the server and
also plays the game at the same time, and other players may join their
world, or a "dedicated server", typically where the server runs in its
own process, which may or may not be on the same computer the player is
using to play the game.

I am less familiar with MMOs though, but from what I can gather it is
more often that they will do something like the dedicated server case,
just typically run each area on its own server (often each on a
different physical computer as well). when a player hits an area between
server-managed regions, they will typically just jump from one server to
another.


my project more fits into the category of a game-engine mostly in C with
a scripting language, and is mostly aiming for the listen-server and
player-run dedicated-server use case (which may be coupled with the use
of an HTTP server for pulling other game contents).


I ended up trying to use Java for scripting at one point (since
Minecraft made it look like maybe this made sense), and ended up using
my own custom mini-JVM (using a JavaME like subset, mostly due to JNI
frustration), but soon enough realized that it didn't really make a
particularly great scripting language (didn't really fit in well with
the use case, and I couldn't readily "eval()" it).

(I also evaluated using .NET and/or Mono and C# for scripting, but this
also looked like a big mess).


so, effort mostly shifted back to my custom script language, which is
more closely derived from JavaScript and ActionScript (with a lot more
elements from C, Java, C#, ... glued on). (like, hell, I will glue on
what parts I care about).

it seems to work moderately well for game-scripting tasks, without the
same level of funkiness as Lua or Python (I more prefer an at least
vaguely C/Java/C# style syntax, even if the language still has its share
of funkiness, and the controversy over whether to the use JS/AS or
Java/C# style declaration syntax, ...).

theoretically, I guess it would be a more direct competitor with Lua or
similar though.


security is a potential worry case (yet to be adequately addressed IMO),
mostly to hopefully be able to prevent malicious content to be spread
to/from servers and/or exploit client computers.

these would be sort of like macro-viruses in MS Word or similar...


WinForms was supplemented with a slight taste of replaced with
WPF 7 years ago.

well, yes, but a person can choose whether they want to use WinForms or
WPF (at least in my version of Visual Studio, it gives both options in
the "New Project" box, along with "Console Application", ...).

No - Java EE does not necessarily cost money. JBoss, Tomcat etc. can be
used for free.

Java EE is server side. Client side will typical be browser, but can in
theory also be a Java SE desktop app or a .NET/native desktop app.

ok.

I had thought Java EE had been like some sort of bigger money-costing
version of Java SE (with more libraries and stuff).

granted, I had never really looked much into it.

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?...


granted, dunno much about business systems, but I was under the
understanding that most were some combination of:

rack mounts running Linux, typically with x86 CPUs, and with Gigabit
Ethernet or 10GbE or similar linking them all together.

one or more server computers in a desktop-like form factor, sometimes
with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM
installed, and sometimes also in a LAN. AFAIK, Linux is also popular
here. (though I guess Windows XP, Windows Vista, and Windows Server,
also make an appearance).

something more strange, like IBM mainframes or similar, where everyone
uses them via funky multi colored textual interfaces inside of a
terminal emulator, ... pretty much everything I have read about them
sounds strange.



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, ...).

I guess alternatively, an option could be a sort of centralized
batch-push or batch-pull, where a daemon or similar is used to update
all the servers, or something... (say, on a schedule, they pull from a
Git or Hg repository or something...).

but, in any case, people have probably figured out all this stuff already.


otherwise, not entirely sure why developing for these would be all that
much different than dealing with a normal PC or Linux box.
 
A

Arne Vajhøj

I ended up trying to use Java for scripting at one point (since
Minecraft made it look like maybe this made sense), and ended up using
my own custom mini-JVM (using a JavaME like subset, mostly due to JNI
frustration), but soon enough realized that it didn't really make a
particularly great scripting language (didn't really fit in well with
the use case, and I couldn't readily "eval()" it).

(I also evaluated using .NET and/or Mono and C# for scripting, but this
also looked like a big mess).

so, effort mostly shifted back to my custom script language, which is
more closely derived from JavaScript and ActionScript (with a lot more
elements from C, Java, C#, ... glued on). (like, hell, I will glue on
what parts I care about).

it seems to work moderately well for game-scripting tasks, without the
same level of funkiness as Lua or Python (I more prefer an at least
vaguely C/Java/C# style syntax, even if the language still has its share
of funkiness, and the controversy over whether to the use JS/AS or
Java/C# style declaration syntax, ...).

theoretically, I guess it would be a more direct competitor with Lua or
similar though.

If one need a scripting language, then a scripting language is
often the best choice.

:)

If you absolutely want to use Java, then use BeanShell.

Arne
 
A

Arne Vajhøj

ok.

I had thought Java EE had been like some sort of bigger money-costing
version of Java SE (with more libraries and stuff).

granted, I had never really looked much into it.

Java EE is:
- specs (PDF files) about how applications are interacting
with servers and what servers do
- server implementations, some pure commercial (WebSphere,
WebLogic), some commercial and open source (JBoss), some pure
open source (Tomcat, Jetty, Glassfish)

The functionality is server centric.

Arne
 
A

Arne Vajhøj

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.
granted, dunno much about business systems, but I was under the
understanding that most were some combination of:

rack mounts running Linux, typically with x86 CPUs, and with Gigabit
Ethernet or 10GbE or similar linking them all together.

one or more server computers in a desktop-like form factor, sometimes
with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM
installed, and sometimes also in a LAN. AFAIK, Linux is also popular
here. (though I guess Windows XP, Windows Vista, and Windows Server,
also make an appearance).

something more strange, like IBM mainframes or similar, where everyone
uses them via funky multi colored textual interfaces inside of a
terminal emulator, ... pretty much everything I have read about them
sounds strange.

Java EE run on servers for production usage.

But all types of OS and hardware.

Linux is the most popular OS, but Windows, various Unix and
mainframe are still seen.
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.
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.

Arne
 
A

Arved Sandstrom

On 01/24/2013 06:10 PM, BGB wrote:
[ SNIP ]
errm, so you can't just copy all the files over to ones' servers? and/or
recompile the code for ones' servers?...

granted, dunno much about business systems, but I was under the
understanding that most were some combination of:

rack mounts running Linux, typically with x86 CPUs, and with Gigabit
Ethernet or 10GbE or similar linking them all together.

one or more server computers in a desktop-like form factor, sometimes
with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM
installed, and sometimes also in a LAN. AFAIK, Linux is also popular
here. (though I guess Windows XP, Windows Vista, and Windows Server,
also make an appearance).

something more strange, like IBM mainframes or similar, where everyone
uses them via funky multi colored textual interfaces inside of a
terminal emulator, ... pretty much everything I have read about them
sounds strange.

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, ...).

I guess alternatively, an option could be a sort of centralized
batch-push or batch-pull, where a daemon or similar is used to update
all the servers, or something... (say, on a schedule, they pull from a
Git or Hg repository or something...).

but, in any case, people have probably figured out all this stuff already.

otherwise, not entirely sure why developing for these would be all that
much different than dealing with a normal PC or Linux box.
"Server" - sometimes the actual computer/OS (real or virtual) running
the "serving" application(s), sometimes the "serving" applications,
sometimes the combination, sometimes a cluster of one or more of the
above etc - is a role, not a technical specification. A "server"
performs a function for client applications, that's basically all there
is to it.

What particular hardware/OS/application software configurations are the
right ones depends entirely on performance requirements, reliability and
necessary quality of service etc. These days you can have pretty
sizeable user bases served off a consumer tower or laptop, granted best
running a "server"-variant OS, and this is often acceptable. A
consumer-level computer these days blows away servers of not so long
ago, so the kinds of things you mention above aren't what define
"server" - it's the function, not the form.

As to the technical, these days we're moving away from direct access to
physical servers and storage, it's all VMs and private/public clouds. If
you're administering VMs you'll certainly be aware where your physical
CPUs/cores are, and what real devices have your storage, but everything
gets pooled and divvied up from there.

AHS
 
B

BGB

If one need a scripting language, then a scripting language is
often the best choice.

yeah, it can also be specialized to application needs, like, say, a
scripting language for a game having built-in vector math support and
similar (vectors are a part of the numeric tower).

:)

If you absolutely want to use Java, then use BeanShell.

well, as-is my script-language works well enough.


and, my main codebase is pretty solidly stuck with being C as well.
(could do more C++, but this would make a mess of some things, as
at-present most of my tools can't parse or process C++ code, as well as
making code using C++ features as part of its external API unusable from
script code, ...).


luckily, with the new JIT, the language shouldn't be as slow as it was
before either (I was measuring it as around 3x slower than C for things
like array sorting), which is an improvement over the 60x slower than C
with the plain-C interpreter.

the JIT is still a bit naive at present though, and doesn't cover
much/most of the ISA, in which case operations fall back to "call
threaded code" (but, this is still faster than the plain interpreter).

admittedly, this JIT is x86 only at the moment.


as-is, some elements of the VM architecture did take some ideas from the
JVM though, like for example, many opcodes are either type-specific or
may be type-qualified via prefixes, ...

the use of prefixes was more a result of migrating a dynamically-typed
VM to being largely statically typed, as the prefixes resulted in less
ISA expansion (and also it being easier to figure this stuff out in the
front-end compiler than in the back-end). though, I did end up with a
pile of type-specialized arithmetic operations.

like "ADD_XI" or "PF_HINT_XI ADD", which serve a similar role to "IADD"
in the JVM, ...


or such...
 
B

BGB

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.


or if you mean like network communication?...

Java EE run on servers for production usage.

But all types of OS and hardware.

Linux is the most popular OS, but Windows, various Unix and
mainframe are still seen.

fair enough.

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?...).

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...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top