You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/02/23 23:00:44 UTC
[Fwd: TALK:Wednesday 3-1-06 Evolution of the Java (tm) Programming
Language an]
for those in the cambridge, MA area.
--
Stefano.
Re: Harmony and the future of Java
Posted by Dalibor Topic <ro...@kaffe.org>.
Damian Hamill <damian <at> herculeez.com> writes:
> Can we have a distribution of Harmony that complies with Java
> certification and add whatever is required to build an on-demand version
> so as a developer/distributor I can choose what technologies I adopt for
> the distribution and execution of my Applets ?
No. It needs to quack, walk and swim like Java in all configurations to be
certified.
Sun would sue Apache to hell and back if we did that, and as a negative bonus,
we wouldn't get certified. Subsetting is prohibited for licensees, so Apache can
not ship a subset.
But the code being free software, you, personally, can ship a subset of Apache
Harmony code, unless you've got a contract with Sun that prevents you from doing
that. BCL, JRL, SCSL, or whatever else they have to prevent you from shipping
subsets. If in doubt, ask your lawyer.
cheers,
dalibor topic
Re: Harmony and the future of Java
Posted by Damian Hamill <da...@herculeez.com>.
Dalibor Topic wrote:
> Damian Hamill <damian <at> herculeez.com> writes:
>
>
>> If most/all of the classes were like this then the class library zip
>> file would be very small. The same goes for the other programs and
>> dlls, if they are not part of the JVM core and needed by every
>> applet/application that runs then make them stubs that download the
>> real thing when they are used the first time.
>>
>
> That's an interesting idea, but unfortunately, it can't be done in an
> implementation that wants to be certified as Java compatible, like Harmony,
> since the VM + class library that you ship needs to be certified as compatible,
> not the VM + class library + something you download on demand from some server
> if you have a network connection around. The fundamental problem with the idea
> is that you end up effectively subsetting J2SE, and the current rules do not
> allow for that, a J2SE implementation always needs to behave as one, even
> without a network connection. :)
>
>
I think this scenario only applies when there is a network connection,
we are talking about Applets in web pages after all.
I understand that from the Harmony project point of view the goal is to
be certified as Java compatible. From a USER point of view I am less
concerned about Java certification, all I care about is getting my
Applets to run in the users browser before they hit the back button and
when they are running to be able to do useful things.
Can we have a distribution of Harmony that complies with Java
certification and add whatever is required to build an on-demand version
so as a developer/distributor I can choose what technologies I adopt for
the distribution and execution of my Applets ?
This argument goes way beyond the JVM and classlib, it also applies to
all the useful stuff we use from jakarta commons etc. That all adds to
the overall download. My Applet is ~200kb but once I add JDOM (148kb),
commons-httpclient (284kb) and commons-logging etc I am up to ~700kb,
when I add audio there is another 316kb and charts add another 1.3MB and
I bet I am using only a small percentage of the classes in these
distributions. Then there is the JMF which looks useful but isn't part
of the standard JRE so I can't use it. I am just not going to ask users
to download and install another Java installation so I can play a video
- I think I'll use Flash instead.
If the classes our programs/applets use are downloaded on-demand and
cached locally things will be a lot easier and quicker next time
around. If my Java Applet needs the user to jump through a load of
hoops in order to run but my competitors ActiveX control runs out of the
box the choice for the user is easy and I will be faced with the choice
of sinking with Java or swimming with ActiveX.
So from my user perspective I need the barriers of entry to be removed
so I can continue to use Java and continue to benefit from the wide
variety of open source Java software that I can use in my projects.
From my perspective those barriers are;
1) seamless and efficient download and execution
2) a security regime based on user interaction or trust metrics
uhmmmm... can I start hacking :-)
regards
damian
Re: Harmony and the future of Java
Posted by Dalibor Topic <ro...@kaffe.org>.
Damian Hamill <damian <at> herculeez.com> writes:
>
> I joined the list a few days ago and I got here as a result of reading the
> "Java: Dead Like COBOL, Not Like Elvis?" thread on TheServerside
> http://www.theserverside.com/news/thread.tss?thread_id=39066.
>
> In a couple of posts by Dalibor Topic (a developer on GNU Classpath
> and Kaffe OpenVM) he asserted that Java developers will move on to
> .NET and he used this phrase "just like how applets were replaced by
> Flash". He also said
>
> "For example, you can write neat GUI applications for Windows today
> using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though,
> GUI application developers on Windows will be facing an interesting
> choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE
> 1.6) for a Java application. As we've seen with applets vs flash,
> there is a very simple answer: the ubiquitous one wins. See Netscape
> vs IE, which was decided the moment Microsoft bundled the browser with
> the OS."
Thanks for the praise, and giving my arguments on that forum your consideration.
FWIW, I am also one the folks who helped getting Apache Harmony going, so I am
trying in a lot of ways to help fix the problems I see with Java, in different
venues.
> If most/all of the classes were like this then the class library zip
> file would be very small. The same goes for the other programs and
> dlls, if they are not part of the JVM core and needed by every
> applet/application that runs then make them stubs that download the
> real thing when they are used the first time.
That's an interesting idea, but unfortunately, it can't be done in an
implementation that wants to be certified as Java compatible, like Harmony,
since the VM + class library that you ship needs to be certified as compatible,
not the VM + class library + something you download on demand from some server
if you have a network connection around. The fundamental problem with the idea
is that you end up effectively subsetting J2SE, and the current rules do not
allow for that, a J2SE implementation always needs to behave as one, even
without a network connection. :)
> So I found my way to Harmony in the hope that I can help and this is
> the area I would like to get involved in.
Welcome on board, and have fun.
dalibor topic
Re: Harmony and the future of Java
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr <geir <at> pobox.com> writes:
>
>
> Damian Hamill wrote:
>
> >
> > I started to wonder if I should switch to c# .NET. I would rather
> > stick with Java but the 16MB JRE download is a killer.
>
> One of our goals is Java everywhere. Literally.
We've actually had that goal reached for years. Every distribution out there has
shipped Kaffe & other GNU Classpath based free runtimes for several years. But
most Java developers didn't and don't have a need to use them or can't help to
improve them.
We've got to become *a lot* better that the proprietary runtime solutions, for
the distribution issue to matter in our favour even on platforms where free
runtimes are ubiquitous.
Distribution on Windows is not an issue open source Java implementations can
possibly solve, since they can't make it attractive for Microsoft to bundle an
open source J2SE implementation. Other than as a migration path to .NET, there
is no money to be made for Microsoft in that.
> This is a concern of a lot of people, especially when you see J2SE 6
> throwing everything and the kitchen sink into the JRE. So having core
> modules and optional modules that can be downloaded on demand would be
> very cool.
Yes. But since that's going to be possible only post java 7, unless someone
comes up with a great way of doing it within the next year or two, so I don't
think that will actually matter by the time it arrives. JSR 277 looks dead (or
silently dormant) from the outside.
We'd still have to ship the huge brick of all the core classes releases as part
of the core since 1.6, or we wouldn't be compatible. That sort of kills the
utility of class library modularization for J2SE, but leaves opportunities in
the embedded arena.
> However, the reason why you don't need this w/ MSFT is because it's all
> there already. We need to achieve the same thing with java - ubiquity.
> I'm pretty sure that MSFT won't be shipping it, but suppose we could
> get it bundled w/ Firefox? :)
Here are a few numbers.
The global PC market last year was ~220 million units. Spreadfirefix.com
bloggers currently estimate their market share at ~10%, so that means around 20
million of those new PCs end up having firefox on them in one way or another and
actually being used. 90% don't.
On the other hand, 90% of PCs ship with Windows, and the assorted plumbing and
kitchen sink. Starting from late this year when Vista starts shipping, that
means 90% of the next year's ~250 million PCs will ship with a bundled .NET 2.0
runtime. Let's assume for the sake of making the numbers in the argument look
nicer, that Microsoft loses market share, etc, and it's just 200 million PCs
with Whidbey.
That still leaves us with 10 times the number of PCs that could run .NET apps
vs. the number of PCs that could run Java applications even if a free runtime
was bundled with firefox, be it Kaffe, Harmony, or whatever, in a few years down
the road, when its done. Since there isn't and most likely won't be one bundled
for a while [1], the actual numbers will be a lot worse.
cheers,
dalibor topic
[1] Not until gcjwebplugin is finished, at least. And GNU Classpath's AWT &
Swing works like a charm on win32. And until we know that GNU Classpath plus the
VM to bundle has no security issues, and can assure the Mozilla project of that.
Lots of work for hungry volunteers, etc.
Re: Harmony and the future of Java
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Damian Hamill wrote:
>
> I started to wonder if I should switch to c# .NET. I would rather
> stick with Java but the 16MB JRE download is a killer.
One of our goals is Java everywhere. Literally.
Unless Java
> Applets are as easy for the user as other technologies then they will
> be second choice for developers. I believe there is a solution but it
> means changing the way classes are loaded, but it may take the JVM
> out of spec, I don't know.
>
> The problem is that before you start to run your applet you have to
> download and install everything that makes up the JRE including
> classes, programs and dlls that your applet will never use. A better
> solution would be to download and install the core JVM and the classes
> your applet uses only. Everything else should be downloaded on
> demand e.g.
>
>
> package javax.sql.rowset;
>
> public abstract class BaseRowSet implements Serializable, Cloneable {
>
> public static String classSourceURL =
> "http://www.mydistribution-server.com/cgi-bin/classServer.cgi";
>
> // nothing else defined in this stub class. }
>
> The class loader finds a class with only the classSourceURL field and
> uses the URL in the field to download the real class passing the fully
> qualified class name as an argument. The class server can return a
> zip file with the named class and all the classes it depends on.
Yep.
This is a concern of a lot of people, especially when you see J2SE 6
throwing everything and the kitchen sink into the JRE. So having core
modules and optional modules that can be downloaded on demand would be
very cool.
However, the reason why you don't need this w/ MSFT is because it's all
there already. We need to achieve the same thing with java - ubiquity.
I'm pretty sure that MSFT won't be shipping it, but suppose we could
get it bundled w/ Firefox? :)
geir
Re: Harmony and the future of Java
Posted by Tim Ellison <t....@gmail.com>.
Damian Hamill wrote:
> Stefano Mazzocchi wrote:
>> Damian Hamill wrote:
>>>
>>> The problem is that before you start to run your applet you have to
>>> download and install everything that makes up the JRE including
>>> classes, programs and dlls that your applet will never use. A better
>>> solution would be to download and install the core JVM and the classes
>>> your applet uses only. Everything else should be downloaded on
>>> demand e.g.
>>>
>>>
>>> package javax.sql.rowset;
>>>
>>> public abstract class BaseRowSet implements Serializable, Cloneable {
>>>
>>> public static String classSourceURL =
>>> "http://www.mydistribution-server.com/cgi-bin/classServer.cgi";
>>>
>>> // nothing else defined in this stub class. }
>>>
>>> The class loader finds a class with only the classSourceURL field and
>>> uses the URL in the field to download the real class passing the fully
>>> qualified class name as an argument. The class server can return a
>>> zip file with the named class and all the classes it depends on.
>>>
>>> If most/all of the classes were like this then the class library zip
>>> file would be very small. The same goes for the other programs and
>>> dlls, if they are not part of the JVM core and needed by every
>>> applet/application that runs then make them stubs that download the
>>> real thing when they are used the first time.
>>>
>>
>> And who's going to pay for that bandwidth?
> Although that is a problem it is a different problem and the answer may
> arise in due course (benefactors please step forward).
>
> When this JRE is ready for prime time how will it be distributed ?
>
> At the moment when I embed an Applet in a web page I specify
> http://java.sun.com/path... as the codebase. At some time in the future
> will I be able to change that to use the Harmony JRE and if so what will
> I change it to ?
>
> This proposal isn't limited to the JRE, it can work for userland classes
> as well so I would pay for the on-demand delivery of any classes that I
> create in my projects.
>
> As an Applet developer my goal is to embed my Applet in web pages and
> have them run with the minimum of fuss for the end user, otherwise I may
> be forced to switch to alternative technologies. If the innovation is
> done here in Harmony then it may be picked up by the other JRE vendors.
We are making modest steps in that direction within the Harmony classlib
code base by having modules with well-defined dependencies between them,
so, while the granularity may not be at the individual type level, you
can see how a given module can be loaded 'on demand' and drag in just
the pre-requisities for its implementation rather than all JSE.
If you see opportunities for reducing the module coupling further (i.e.
by reimplementing something that removes an import dependency on another
module) without undue cost to speed/complexity/size etc. then please
send it along. This is an area I'm very interested in.
> BTW the other thing that needs fixing is security. Java security was
> designed to stop malicious software writers from corrupting a users
> machine, the rest of us pay the price for this.
...and have benefited from this.
> Right now it means I
> can't do certain useful things in Applets unless the user modifies their
> security policy file. Asking them to edit c:/Program
> Files/Java/jre-{version}/lib/security.policy with notepad is not a
> serious option. So to do certain useful things like connect to other
> hosts I am forced to use JNLP. I would like to be able to ask the user
> for permission (via the security manager) to do things like connect to
> other hosts, disk access to a sandbox local directory etc.
Applets have a well-defined security model we wouldn't want to break,
but I understand what you are saying. Perhaps some other delivery
mechanism that can ask for broader permissions from the JRE either
through user interaction, or presenting a trusted signature, etc.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Harmony and the future of Java
Posted by Damian Hamill <da...@herculeez.com>.
Stefano Mazzocchi wrote:
> Damian Hamill wrote:
>>
>> The problem is that before you start to run your applet you have to
>> download and install everything that makes up the JRE including
>> classes, programs and dlls that your applet will never use. A better
>> solution would be to download and install the core JVM and the classes
>> your applet uses only. Everything else should be downloaded on
>> demand e.g.
>>
>>
>> package javax.sql.rowset;
>>
>> public abstract class BaseRowSet implements Serializable, Cloneable {
>>
>> public static String classSourceURL =
>> "http://www.mydistribution-server.com/cgi-bin/classServer.cgi";
>>
>> // nothing else defined in this stub class. }
>>
>> The class loader finds a class with only the classSourceURL field and
>> uses the URL in the field to download the real class passing the fully
>> qualified class name as an argument. The class server can return a
>> zip file with the named class and all the classes it depends on.
>>
>> If most/all of the classes were like this then the class library zip
>> file would be very small. The same goes for the other programs and
>> dlls, if they are not part of the JVM core and needed by every
>> applet/application that runs then make them stubs that download the
>> real thing when they are used the first time.
>>
>
> And who's going to pay for that bandwidth?
Although that is a problem it is a different problem and the answer may
arise in due course (benefactors please step forward).
When this JRE is ready for prime time how will it be distributed ?
At the moment when I embed an Applet in a web page I specify
http://java.sun.com/path... as the codebase. At some time in the future
will I be able to change that to use the Harmony JRE and if so what will
I change it to ?
This proposal isn't limited to the JRE, it can work for userland classes
as well so I would pay for the on-demand delivery of any classes that I
create in my projects.
As an Applet developer my goal is to embed my Applet in web pages and
have them run with the minimum of fuss for the end user, otherwise I may
be forced to switch to alternative technologies. If the innovation is
done here in Harmony then it may be picked up by the other JRE vendors.
BTW the other thing that needs fixing is security. Java security was
designed to stop malicious software writers from corrupting a users
machine, the rest of us pay the price for this. Right now it means I
can't do certain useful things in Applets unless the user modifies their
security policy file. Asking them to edit c:/Program
Files/Java/jre-{version}/lib/security.policy with notepad is not a
serious option. So to do certain useful things like connect to other
hosts I am forced to use JNLP. I would like to be able to ask the user
for permission (via the security manager) to do things like connect to
other hosts, disk access to a sandbox local directory etc.
regards
damian
Re: Harmony and the future of Java
Posted by Stefano Mazzocchi <st...@apache.org>.
Damian Hamill wrote:
> Stefano Mazzocchi wrote:
>>
>> I agree with you (and Ben) about the fact that monoculture brings
>> stagnation, but I don't think this is a good place for talking about
>> "java innovations".
>>
>> <hat type="project mentor">
>> This project is about implement a JVM as specified by the JCP, of
>> which the ASF is part of.
>>
>> Changing and influencing that JVM spec is out of scope it if brings
>> incompatibilities that will preclude passing the certification stage.
>> </hat>
>>
>> This said, it is not impossible for Harmony to be instrumental in
>> showing that additions to the JVM might be beneficial for the outside
>> world and therefore submit them for review to the JCP.
>>
>> There is *nothing* that prevents us from implementing harmony-specific
>> features, if this doesn't stop us from passing the TCK.
>>
> This is my cue;
>
> I joined the list a few days ago and I got here as a result of reading the
> "Java: Dead Like COBOL, Not Like Elvis?" thread on TheServerside
> http://www.theserverside.com/news/thread.tss?thread_id=39066.
>
> In a couple of posts by Dalibor Topic (a developer on GNU Classpath
> and Kaffe OpenVM) he asserted that Java developers will move on to
> .NET and he used this phrase "just like how applets were replaced by
> Flash". He also said
> "For example, you can write neat GUI applications for Windows today
> using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though,
> GUI application developers on Windows will be facing an interesting
> choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE
> 1.6) for a Java application. As we've seen with applets vs flash,
> there is a very simple answer: the ubiquitous one wins. See Netscape
> vs IE, which was decided the moment Microsoft bundled the browser with
> the OS."
>
> I started to wonder if I should switch to c# .NET. I would rather
> stick with Java but the 16MB JRE download is a killer. Unless Java
> Applets are as easy for the user as other technologies then they will
> be second choice for developers. I believe there is a solution but it
> means changing the way classes are loaded, but it may take the JVM
> out of spec, I don't know.
>
> The problem is that before you start to run your applet you have to
> download and install everything that makes up the JRE including
> classes, programs and dlls that your applet will never use. A better
> solution would be to download and install the core JVM and the classes
> your applet uses only. Everything else should be downloaded on
> demand e.g.
>
>
> package javax.sql.rowset;
>
> public abstract class BaseRowSet implements Serializable, Cloneable {
>
> public static String classSourceURL =
> "http://www.mydistribution-server.com/cgi-bin/classServer.cgi";
>
> // nothing else defined in this stub class. }
>
> The class loader finds a class with only the classSourceURL field and
> uses the URL in the field to download the real class passing the fully
> qualified class name as an argument. The class server can return a
> zip file with the named class and all the classes it depends on.
>
> If most/all of the classes were like this then the class library zip
> file would be very small. The same goes for the other programs and
> dlls, if they are not part of the JVM core and needed by every
> applet/application that runs then make them stubs that download the
> real thing when they are used the first time.
>
> So I found my way to Harmony in the hope that I can help and this is
> the area I would like to get involved in.
>
> BTW My 2 cents on the local (HTTP/FTP/SMTP) server issue is to
> implement the servers as Java classes, the protocols are simple and a
> lot of that code exists in apacheland anyway.
And who's going to pay for that bandwidth?
--
Stefano.
Re: Harmony and the future of Java
Posted by Damian Hamill <da...@herculeez.com>.
Stefano Mazzocchi wrote:
>
> I agree with you (and Ben) about the fact that monoculture brings
> stagnation, but I don't think this is a good place for talking about
> "java innovations".
>
> <hat type="project mentor">
> This project is about implement a JVM as specified by the JCP, of
> which the ASF is part of.
>
> Changing and influencing that JVM spec is out of scope it if brings
> incompatibilities that will preclude passing the certification stage.
> </hat>
>
> This said, it is not impossible for Harmony to be instrumental in
> showing that additions to the JVM might be beneficial for the outside
> world and therefore submit them for review to the JCP.
>
> There is *nothing* that prevents us from implementing harmony-specific
> features, if this doesn't stop us from passing the TCK.
>
This is my cue;
I joined the list a few days ago and I got here as a result of reading the
"Java: Dead Like COBOL, Not Like Elvis?" thread on TheServerside
http://www.theserverside.com/news/thread.tss?thread_id=39066.
In a couple of posts by Dalibor Topic (a developer on GNU Classpath
and Kaffe OpenVM) he asserted that Java developers will move on to
.NET and he used this phrase "just like how applets were replaced by
Flash". He also said
"For example, you can write neat GUI applications for Windows today
using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though,
GUI application developers on Windows will be facing an interesting
choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE
1.6) for a Java application. As we've seen with applets vs flash,
there is a very simple answer: the ubiquitous one wins. See Netscape
vs IE, which was decided the moment Microsoft bundled the browser with
the OS."
I started to wonder if I should switch to c# .NET. I would rather
stick with Java but the 16MB JRE download is a killer. Unless Java
Applets are as easy for the user as other technologies then they will
be second choice for developers. I believe there is a solution but it
means changing the way classes are loaded, but it may take the JVM
out of spec, I don't know.
The problem is that before you start to run your applet you have to
download and install everything that makes up the JRE including
classes, programs and dlls that your applet will never use. A better
solution would be to download and install the core JVM and the classes
your applet uses only. Everything else should be downloaded on
demand e.g.
package javax.sql.rowset;
public abstract class BaseRowSet implements Serializable, Cloneable {
public static String classSourceURL =
"http://www.mydistribution-server.com/cgi-bin/classServer.cgi";
// nothing else defined in this stub class.
}
The class loader finds a class with only the classSourceURL field and
uses the URL in the field to download the real class passing the fully
qualified class name as an argument. The class server can return a
zip file with the named class and all the classes it depends on.
If most/all of the classes were like this then the class library zip
file would be very small. The same goes for the other programs and
dlls, if they are not part of the JVM core and needed by every
applet/application that runs then make them stubs that download the
real thing when they are used the first time.
So I found my way to Harmony in the hope that I can help and this is
the area I would like to get involved in.
BTW My 2 cents on the local (HTTP/FTP/SMTP) server issue is to
implement the servers as Java classes, the protocols are simple and a
lot of that code exists in apacheland anyway.
regards
damian
Re: Harmony and the future of Java
Posted by Tim Ellison <t....@gmail.com>.
Stefano Mazzocchi wrote:
> Santiago Gala wrote:
>> El jue, 23-02-2006 a las 20:44 -0500, Stefano Mazzocchi escribió:
>>
>> (...)
>>> A good friend of mine used to have "cat juggler" as his title and I
>>> was thinking about using "software plumber" as mine at one point.
>>
>> Fair enough, I used to have "problem solver" or "I solve your problems
>> for a fee" as mine.
>>
>>>
>>> I tend to prefer somebody who admits to be a religiously attached to
>>> something than those who pretend to be objective about it and deep
>>> inside they are not.
>>>
>>> Not sure this is the case, but that's how I read it.
>>>
>>
>> OK, I just got surprised. I'm giving a talk on "Software and Artistic
>> Expression" in two weeks, so I kind of understand code as speech. From
>> there to code as scripture there is just some sliding slope.
>>
>> I can grok evangelist as a metaphor, but being a Theologian would in
>> my view mean that src.zip is some sort of holy scripture, thing that
>> I'm far from believing. Oh, and heresy outside of the JCP church. :-P
>>
>> What is more, such a title helps building on the tradition of java as
>> a "mono(theistic)culture", together with the .NET. one
>>
>> Just yesterday I got squeak/smalltalk communities criticized (and I
>> agree) for being too closed in themselves, and it rang bells about
>> java being sort of the same. Having been part of both communities, I
>> can't but sympathise with Ben Hyde's "Small Gods" post:
>> http://enthusiasm.cozy.org/archives/2003/06/small-gods
>>
>> Getting closer to topic, I wonder if someone can post here a
>> subjective summary of the ideas on support for dynamic languages in
>> future java. I'm concerned about the stagnation of jython (barely
>> commits since 2.2a1) and I would also like to know how far is support
>> for dynamic languages going to be.
>>
>> In particular, things like smalltalk's primitive "anObject become:
>> anotherObject", which will turn all references to an object to
>> references to a different one seem difficult to mix with the static
>> typing nature of java, and I would like to know more about the
>> approach they are going to take for such kind of problems.
>
> I agree with you (and Ben) about the fact that monoculture brings
> stagnation, but I don't think this is a good place for talking about
> "java innovations".
>
> <hat type="project mentor">
> This project is about implement a JVM as specified by the JCP, of which
> the ASF is part of.
>
> Changing and influencing that JVM spec is out of scope it if brings
> incompatibilities that will preclude passing the certification stage.
> </hat>
>
> This said, it is not impossible for Harmony to be instrumental in
> showing that additions to the JVM might be beneficial for the outside
> world and therefore submit them for review to the JCP.
>
> There is *nothing* that prevents us from implementing harmony-specific
> features, if this doesn't stop us from passing the TCK.
>
Yes, well put.
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Harmony and the future of Java
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr <geir <at> pobox.com> writes:
> >> Getting closer to topic, I wonder if someone can post here a
> >> subjective summary of the ideas on support for dynamic languages in
> >> future java. I'm concerned about the stagnation of jython (barely
> >> commits since 2.2a1) and I would also like to know how far is support
> >> for dynamic languages going to be.
>
> It's my understanding that Sun et al has figured out there's a problem.
> The dam was broken w/ the Groovy JSR, and if there isn't now, there
> will be a JSR at some point focused on support for dynamic languages on
> the JVM.
>
> Groovy made some important people (like Graham Hamilton) either realize
> or admit that "Java" as we know it is fundamentally about the JVM and
> classlibraries, and how you produce your bytecode is secondary. (i.e.
> if you write in Java, great! if Groovy, great!)
I think the situation depends on what one wants to do. If one wants to have a
Java-like language, that's got some properties of dynamic languages, then yes,
one can sort of do that on the JVM today, and it may not be too hard to make the
life of implementors of such languages a little easier in the future, without
breaking the type system, security, yadda, yadda of the JVM.
If one wants to have a language that is not Java-like, and hasn't been designed
with the idea of having it compile to the JVM, then one won't get such a
language implemented efficiently on top of a JVM, as can be seen by the long,
long list of implementations of languages for the JVM that are not as successful
as the implementations that don't run on the JVM.
The JVM design is very hard to extend without breaking years of existing code,
and/or making migration really ugly, or introducing nasty problems in the type
system, i.e. throwing security overboard. See JNI, which was shoehorned later
into the JVM to replace NMI. It's not exactly beautyful. See JSR 14's necessity
to go with erasure over reification, and so on.
We're stuck with the JVM, and contrary to some people, I don't think that's an
advantage, no matter how great some people may belive that some proprietary JVM
implementations are.
I do think that Java has a future ahead, though, and that free software
implementations like Kaffe, Harmony and other have a (hopefuly large) role to
play in it. I don't think they, or JRuby, Groovy, or whatever, can save Java
from losing the niches where it's not a great solution for the problems, to
other platforms, languages, etc. But they can help solve the yucky problem of
integration of Java code into other systems, which is not going to be solved by
companies with a strong monetary interest in keeping the developers stuck on a
platform they have complete control over.
As for developers, I find it hard to believe that the same pragmatic Java
developers who rejected the idea of them being voluntarily trapped on a
proprietary platform last year when RMS published his Java Trap article, will
have ethical problems pragmatically switching over to the next best proprietary
Java-like platform, once Whidbey is dominant, and leaving Java behind them on
their CVs.
cheers,
dalibor topic
Re: Harmony and the future of Java
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Santiago Gala wrote:
[SNIP]
>>
>> Getting closer to topic, I wonder if someone can post here a
>> subjective summary of the ideas on support for dynamic languages in
>> future java. I'm concerned about the stagnation of jython (barely
>> commits since 2.2a1) and I would also like to know how far is support
>> for dynamic languages going to be.
It's my understanding that Sun et al has figured out there's a problem.
The dam was broken w/ the Groovy JSR, and if there isn't now, there
will be a JSR at some point focused on support for dynamic languages on
the JVM.
Groovy made some important people (like Graham Hamilton) either realize
or admit that "Java" as we know it is fundamentally about the JVM and
classlibraries, and how you produce your bytecode is secondary. (i.e.
if you write in Java, great! if Groovy, great!)
>>
>> In particular, things like smalltalk's primitive "anObject become:
>> anotherObject", which will turn all references to an object to
>> references to a different one seem difficult to mix with the static
>> typing nature of java, and I would like to know more about the
>> approach they are going to take for such kind of problems.
>
> I agree with you (and Ben) about the fact that monoculture brings
> stagnation, but I don't think this is a good place for talking about
> "java innovations".
>
> <hat type="project mentor">
> This project is about implement a JVM as specified by the JCP, of which
> the ASF is part of.
>
> Changing and influencing that JVM spec is out of scope it if brings
> incompatibilities that will preclude passing the certification stage.
> </hat>
>
> This said, it is not impossible for Harmony to be instrumental in
> showing that additions to the JVM might be beneficial for the outside
> world and therefore submit them for review to the JCP.
>
> There is *nothing* that prevents us from implementing harmony-specific
> features, if this doesn't stop us from passing the TCK.
>
Right - I think that there are all sorts of things I'd like to see in
Harmony, like good management, being able to checkpoint a JVM, serialize
the goop, move it to another machine, and let it continue... I'd also
love to experiment with how a VM can assist with the problem of object
persistence, disconnected object graphs, etc.
But this is done with the compatibility meme in mind, becuase w/o
compatibility, we have a mess.
geir
Harmony and the future of Java
Posted by Stefano Mazzocchi <st...@apache.org>.
Santiago Gala wrote:
> El jue, 23-02-2006 a las 20:44 -0500, Stefano Mazzocchi escribió:
>
> (...)
>> A good friend of mine used to have "cat juggler" as his title and I was
>> thinking about using "software plumber" as mine at one point.
>
> Fair enough, I used to have "problem solver" or "I solve your problems
> for a fee" as mine.
>
>>
>> I tend to prefer somebody who admits to be a religiously attached to
>> something than those who pretend to be objective about it and deep
>> inside they are not.
>>
>> Not sure this is the case, but that's how I read it.
>>
>
> OK, I just got surprised. I'm giving a talk on "Software and Artistic
> Expression" in two weeks, so I kind of understand code as speech. From
> there to code as scripture there is just some sliding slope.
>
> I can grok evangelist as a metaphor, but being a Theologian would in my
> view mean that src.zip is some sort of holy scripture, thing that I'm
> far from believing. Oh, and heresy outside of the JCP church. :-P
>
> What is more, such a title helps building on the tradition of java as a
> "mono(theistic)culture", together with the .NET. one
>
> Just yesterday I got squeak/smalltalk communities criticized (and I
> agree) for being too closed in themselves, and it rang bells about java
> being sort of the same. Having been part of both communities, I can't
> but sympathise with Ben Hyde's "Small Gods" post:
> http://enthusiasm.cozy.org/archives/2003/06/small-gods
>
> Getting closer to topic, I wonder if someone can post here a subjective
> summary of the ideas on support for dynamic languages in future java.
> I'm concerned about the stagnation of jython (barely commits since
> 2.2a1) and I would also like to know how far is support for dynamic
> languages going to be.
>
> In particular, things like smalltalk's primitive "anObject become:
> anotherObject", which will turn all references to an object to
> references to a different one seem difficult to mix with the static
> typing nature of java, and I would like to know more about the approach
> they are going to take for such kind of problems.
I agree with you (and Ben) about the fact that monoculture brings
stagnation, but I don't think this is a good place for talking about
"java innovations".
<hat type="project mentor">
This project is about implement a JVM as specified by the JCP, of which
the ASF is part of.
Changing and influencing that JVM spec is out of scope it if brings
incompatibilities that will preclude passing the certification stage.
</hat>
This said, it is not impossible for Harmony to be instrumental in
showing that additions to the JVM might be beneficial for the outside
world and therefore submit them for review to the JCP.
There is *nothing* that prevents us from implementing harmony-specific
features, if this doesn't stop us from passing the TCK.
--
Stefano.
Re: [Fwd: TALK:Wednesday 3-1-06 Evolution of the Java (tm)
Programming Language an]
Posted by Santiago Gala <sg...@apache.org>.
El jue, 23-02-2006 a las 20:44 -0500, Stefano Mazzocchi escribió:
(...)
> A good friend of mine used to have "cat juggler" as his title and I was
> thinking about using "software plumber" as mine at one point.
Fair enough, I used to have "problem solver" or "I solve your problems
for a fee" as mine.
>
> I tend to prefer somebody who admits to be a religiously attached to
> something than those who pretend to be objective about it and deep
> inside they are not.
>
> Not sure this is the case, but that's how I read it.
>
OK, I just got surprised. I'm giving a talk on "Software and Artistic
Expression" in two weeks, so I kind of understand code as speech. From
there to code as scripture there is just some sliding slope.
I can grok evangelist as a metaphor, but being a Theologian would in my
view mean that src.zip is some sort of holy scripture, thing that I'm
far from believing. Oh, and heresy outside of the JCP church. :-P
What is more, such a title helps building on the tradition of java as a
"mono(theistic)culture", together with the .NET. one
Just yesterday I got squeak/smalltalk communities criticized (and I
agree) for being too closed in themselves, and it rang bells about java
being sort of the same. Having been part of both communities, I can't
but sympathise with Ben Hyde's "Small Gods" post:
http://enthusiasm.cozy.org/archives/2003/06/small-gods
Getting closer to topic, I wonder if someone can post here a subjective
summary of the ideas on support for dynamic languages in future java.
I'm concerned about the stagnation of jython (barely commits since
2.2a1) and I would also like to know how far is support for dynamic
languages going to be.
In particular, things like smalltalk's primitive "anObject become:
anotherObject", which will turn all references to an object to
references to a different one seem difficult to mix with the static
typing nature of java, and I would like to know more about the approach
they are going to take for such kind of problems.
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [Fwd: TALK:Wednesday 3-1-06 Evolution of the Java (tm) Programming
Language an]
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerry Steele wrote:
> you can ask that question. Cause i agree what the *($%^ is going on.
> Seriously. I hope it is with regard to the philosophical enquiry into
> the persuasive nature of technological advancement.
>
> Not how the bible is the handbook for the persuasive appropriation of
> the waterfall method upon engineers cause, you know, he liked to walk
> on water and ultimately he fell to his death cause of this fallacy.
>
> Or most logically, a programmer who happens to think he is a
> theologian. But whats more, append it to his credentials. Now that is
> silly.
>
> Hopefully, the first two are closer to reality.
A good friend of mine used to have "cat juggler" as his title and I was
thinking about using "software plumber" as mine at one point.
I tend to prefer somebody who admits to be a religiously attached to
something than those who pretend to be objective about it and deep
inside they are not.
Not sure this is the case, but that's how I read it.
--
Stefano.
Re: [Fwd: TALK:Wednesday 3-1-06 Evolution of the Java (tm) Programming Language an]
Posted by Gerry Steele <ge...@gmail.com>.
you can ask that question. Cause i agree what the *($%^ is going on.
Seriously. I hope it is with regard to the philosophical enquiry into
the persuasive nature of technological advancement.
Not how the bible is the handbook for the persuasive appropriation of
the waterfall method upon engineers cause, you know, he liked to walk
on water and ultimately he fell to his death cause of this fallacy.
Or most logically, a programmer who happens to think he is a
theologian. But whats more, append it to his credentials. Now that is
silly.
Hopefully, the first two are closer to reality.
Gerry.
On 2/23/06, Santiago Gala <sg...@apache.org> wrote:
> El jue, 23-02-2006 a las 17:00 -0500, someone wrote:
> ...
> > Brief Bio: Gilad Bracha is a Computational Theologist and
> > Distinguished Engineer at Sun Microsystems. He
> ...
> From Webster's via dictd:
>
> theologist
> n : someone who is learned in theology or who speculates about
> theology (especially Christian theology) syn: theologian,
> theologizer, theologiser
>
> May I ask, as a non-native English speaker, what the h*** is a
> "Computational Theologist" ?
>
> Thanks in advance
> Santiago
>
> --
> VP and Chair, Apache Portals (http://portals.apache.org)
> Apache Software Foundation
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
>
> iD8DBQBD/kIwZAeG2a2/nhoRAkldAKCMxzj6bi9eSNbmPMBiwzPfikv5wQCeOqIP
> 2d0Zzes2zDEk0qm0fT+DW/M=
> =20vQ
> -----END PGP SIGNATURE-----
>
>
>
--
Gerry Steele
http://gerry-steele.blogspot.com/
Re: [Fwd: TALK:Wednesday 3-1-06 Evolution of the Java (tm)
Programming Language an]
Posted by Santiago Gala <sg...@apache.org>.
El jue, 23-02-2006 a las 17:00 -0500, someone wrote:
...
> Brief Bio: Gilad Bracha is a Computational Theologist and
> Distinguished Engineer at Sun Microsystems. He
...
From Webster's via dictd:
theologist
n : someone who is learned in theology or who speculates about
theology (especially Christian theology) syn: theologian,
theologizer, theologiser
May I ask, as a non-native English speaker, what the h*** is a
"Computational Theologist" ?
Thanks in advance
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation