Nabble - OpenJDK General discussion

Re: Howto implement configure/makefile checking for JNI headers?

2009-11-02T01:32:05Z

Clemens Eisserer wrote:

> I would like to add a Java binding to an existing project written in
> C, however I am totally unexperienced with make/configure.
> Any hints, or even better snippits, how I could search for JNI headers
> during configure, allow the variable to be configureable with a saned
> efault value?

It's hard to tell from this what you're trying to do.

Andrew.

Re: Howto implement configure/makefile checking for JNI headers?

2009-10-31T12:06:33Z

Hi Remi,

The JNI code is already written, and I plan to avoid adding additional
dependencies as I hope that stuff will become a part of IcedTea some
day.

The big question is how do I get it built in a way, RedHat won't
refuse creating packages from it ;)

- Clemens

Re: Howto implement configure/makefile checking for JNI headers?

2009-10-31T11:50:21Z

Le 31/10/2009 18:45, Clemens Eisserer a écrit :

> Hi,
>
> I would like to add a Java binding to an existing project written in
> C, however I am totally unexperienced with make/configure.
> Any hints, or even better snippits, how I could search for JNI headers
> during configure, allow the variable to be configureable with a saned
> efault value?
>
> Thank you in advance, Clemens
>

Hi Clemens,
The best is to use tools that already do some kind of glue
like jna.dev.java.net.

cheers,
Rémi

Howto implement configure/makefile checking for JNI headers?

2009-10-31T10:45:45Z

Hi,

I would like to add a Java binding to an existing project written in
C, however I am totally unexperienced with make/configure.
Any hints, or even better snippits, how I could search for JNI headers
during configure, allow the variable to be configureable with a saned
efault value?

Thank you in advance, Clemens

Re: Attach Api and agent unloading

2009-10-15T01:08:03Z

Ishaaq Chandy wrote:
> Hi all,
> Not sure if this is the right forum to ask this, if you know of a more
> appropriate one please direct me there.
>
This mailing lists is the general discussion list. The "Monitoring,
Management, Debugging, and Profiling APIs" forum [1] is a useful place
for questions on this (and related) APIs. If this is a JVM TI agent then
the agent library will not be unloaded until the VM exits (in a
multi-threaded environment it's usually not feasible to unload a shared
library mid-flight). If this is a j.l.instrument agent then the agent's
JAR is added to the system class path (details are in the j.l.instrument
package description).

-Alan.

[1] http://forums.sun.com/forum.jspa?forumID=539

Attach Api and agent unloading

2009-10-14T18:26:44Z

Hi all,
Not sure if this is the right forum to ask this, if you know of a more appropriate one please direct me there.

I am using the awesome Attach API http://java.sun.com/javase/6/docs/jdk/api/attach/spec/index.html to attach an java-based agent to a running app. All working perfectly, great API!

Now, I want to know if there is a way to "unattach" the agent. i.e., does the agent run in a child classloader that can be unloaded on demand thus freeing up any resources the agent was using?

What I'm trying to get to is an attaching tool that can be run on demand to attach to a production app - do whatever it needs to do and then clean up after itself - i.e. stop any new threads it started, close all resources, unload any new classes it may have loaded up, free up memory it was using etc, so that the production app can continue running at normal operation mode, almost as if we never attached to it in the first place. Obviously, there can be caveats here - if the attached code is written in such a way that makes it impossible for the classloader to release the classes for GC then all bets are off.

Looking at the API, it looks like this is not possible, but I just thought I'd ask on the offchance I am missing something here.

Thanks,
Ishaaq

Re: OpenJDK server status

2009-10-13T14:14:41Z

2009/10/13 Mark Reinhold <mr@...>:
> The hosting team has moved the OpenJDK servers to an alternate storage
> system. At this point all our domains are back up and working normally.
>
> As always, please report any problems to ops@....
>
> - Mark
>

Except when the lists stop that email working... ;)
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

OpenJDK and IcedTea source backups

2009-10-12T03:42:20Z

Hi,

Since it seems the servers are still not back to 100% health (lets hope
at least mail is back up to get this message through) it might be good
to point out that at least the master mercurial source code forests have
some read-only public backups:
http://gnu.wildebeest.org/diary/2009/10/12/icedtea-and-openjdk-backups/

It would be good to make the various public info on the servers (db,
bugs, mail, hg, cr and the main webpages at least) publicly rsyncable so
we can setup read-only mirrors for everything in the future just in
case.

Cheers,

Mark

Re: JDK 7 build 73 is available at the openjdk.java.net website

2009-10-02T17:41:44Z

Hi,

I tried building jdk7-b73 on Ubuntu dapper,
and had it fail with

BUILD FAILED
.../jaxp/build-defs.xml:66: Could not create task or type of type:
replaceregexp.

Ant could not find the task or a class this task relies upon.

----

This problem does not happen on Ubuntu hardy.

It appears to be fixed by installing the "ant-optional"
debian package, in addition to "ant".
But this is not obvious - it might be worth adding
sanity checks and/or documentation.

Martin

On Fri, Oct 2, 2009 at 15:24, Michael Wilkerson
<Michael.Wilkerson@...> wrote:

> The OpenJDK source is available at:
> http://hg.openjdk.java.net/jdk7/jdk7
> http://hg.openjdk.java.net/jdk7/jdk7/rev/3ac6dcf78232
>
> The OpenJDK source binary plugs for the promoted JDK 7 build 73 are
> available under the openjdk http://openjdk.java.net website under Source
> Code (direct link to bundles: http://download.java.net/openjdk/jdk7)
>
> Summary of changes:
> http://download.java.net/jdk7/changes/jdk7-b73.html
>
>
> -Michael
>

JDK 7 build 73 is available at the openjdk.java.net website

2009-10-02T15:24:59Z

The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/3ac6dcf78232

The OpenJDK source binary plugs for the promoted JDK 7 build 73 are
available under the openjdk http://openjdk.java.net website under Source
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b73.html

-Michael

Re: OpenJDK server migration status

2009-09-30T02:36:22Z

2009/9/30 Mark Reinhold <mr@...>:

>> From: Mark Reinhold <mr@...>
>> Date: Tue, 29 Sep 2009 14:06:40 -0700
>
>> The migration is complete except for the bugs server, which is still
>> being worked on. The cr, hg, and mail servers are now open for updates
>> and incoming e-mail.
>
> bugs.openjdk.java.net is back online. (Thanks Brad!)
>
> We now return you to your regularly scheduled hacking.
>
> - Mark
>

Yay!

Thanks Mark, Tim and Brad for all your hard work on this.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: OpenJDK server migration status

2009-09-29T14:10:44Z

I assume updating to some Oracle product? :)

geir

On Sep 29, 2009, at 5:06 PM, Mark Reinhold wrote:

> The migration is complete except for the bugs server, which is still
> being worked on. The cr, hg, and mail servers are now open for
> updates
> and incoming e-mail.
>
> When pushing changesets to hg.openjdk.java.net or code-review
> materials
> to cr.openjdk.java.net you will likely see a frightening "DNS SPOOFING
> DETECTED" / "REMOTE HOST IDENTIFICATION HAS CHANGED" message pointing
> to specific lines of your ~/.ssh/known_hosts file. You can eliminate
> the message by removing those lines from the file.
>
> FYI the fingerprint of the new RSA host key for both the hg and cr
> servers is 37:e0:73:cc:23:fc:2e:29:e7:40:fd:9d:35:69:bc:e3.
>
> Please report any problems to ops@....
>
> Thanks to Tim Bell and Brad Wetmore for helping with this migration,
> on very short notice!
>
> - Mark

Re: OpenJDK server migration TONIGHT (Monday 2009/9/28)

2009-09-28T19:32:49Z

Mark Reinhold wrote:
> The OpenJDK servers will move to a new datacenter tonight. No updates
> to any openjdk.java.net host will be accepted after 8pm PDT tonight,
> though all will continue to be available in read-only mode. The cr,
> hg, and mail servers should be ready to accept updates by noon PDT on
> Tuesday, if not earlier; the bugs server may be offline for a day or
> two longer.

http://bugs.openjdk.java.net will not be ready by tomorrow. Bugzilla
has not been happy with the switch to a new OS/MySQL version.

I will let you know when bugs.openjdk.java.net has completed its migration.

Brad

JDK 7 build 72 is available at the openjdk.java.net website

2009-09-17T21:09:33Z

The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/0d7e03b426df

The OpenJDK source binary plugs for the promoted JDK 7 build 72 are
available under the openjdk http://openjdk.java.net website under Source
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b72.html

-Xiomara

JDK 7 build 71 is available at the openjdk.java.net website

2009-09-03T17:56:42Z

The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/4c36e9853dda

The OpenJDK source binary plugs for the promoted JDK 7 build 71 are
available under the openjdk http://openjdk.java.net website under Source
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b71.html

-Xiomara

Compiling from Repository tip

2009-08-31T02:09:52Z

Hey,

I have checked out 2 of the forests and would like to compile them into a
running OpenJDK.

I assume I have to get the bundle and then just copy the directories "corba
hotspot jaxp jaxws jdk langtools" from the repo over to the bundle?

Will this be enough? Won't it possibly create incompatibilities, such as
when something in the forest changed that requires a change in another, like
a new API added which the bundle doesn't have yet?

What is the best way to do this?

--
Quintin Beukes

Should FileTime be serializable?

2009-08-27T06:44:56Z

That is java.nio.file.attribute.FileTime. According to the b70
documentation it isn't.

Regards,
Mark Thornton

Re: Opensource plugin&webstart - when?

2009-08-26T14:09:09Z

2009/8/26 Mark Wielaard <mark@...>:
> BTW. For those that haven't seen it yet, Deepak has a blog which
> highlights all the stuff going on around the IcedTea[NP] Plugin, with
> roadmaps, technical designs and just plain cool screenshots showing the
> various features: http://dbhole.wordpress.com/
>
>

And already has more features (beyond being the only Free plugin)!

http://dbhole.wordpress.com/2009/08/26/icedtea-java-plugin-with-chromium-and-firefox-3-6a1
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Opensource plugin&webstart - when?

2009-08-26T13:19:30Z

BTW. For those that haven't seen it yet, Deepak has a blog which
highlights all the stuff going on around the IcedTea[NP] Plugin, with
roadmaps, technical designs and just plain cool screenshots showing the
various features: http://dbhole.wordpress.com/

Re: Opensource plugin&webstart - when?

2009-08-26T11:41:50Z

2009/8/26 Mark Wielaard <mark@...>:
> If history is our guide then improving the GNU implementations till they
> are at least as good, or threaten to surpass the proprietary
> implementations will trigger proprietary companies into opening op and
> working with the community more.
>

Exactly. There's nothing to be gained by moaning at Sun.

> Cheers,
>
> Mark
>
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Opensource plugin&webstart - when?

2009-08-26T10:49:12Z

Hi Clemens,

On Wed, 2009-08-26 at 12:40 -0400, Clemens Eisserer wrote:
> I just can't understand the reason of holding those two components
> back

It isn't clear what is going on. After saying Sun was committed to
releasing the code as Free Software, at conferences, blogs and on the
mailinglists, nothing happened for 6 months. The only communication
since has been "circumstances changed". Nobody knows which circumstances
those are or what changed however. So, for all we know they are still
committed, just delayed. Lets just hope the delay isn't going to be
multiple years. Or that someone from Sun explains what is really going
on now after the commitment and what the expected timeline is.

> So it seems to old catch-up game continues again, with
> half-"compatible" implementations arround, hurting java's reputation
> and user experience.

I think that isn't doing the free alternative justice, compatibility is
of a huge concern. Please do report any bugs you might find. From my own
experience any bugs are taken seriously and patched quickly. All
GNU/Linux distros now ship the IcedTea plugin, so at least across free
platforms things should be pretty compatible.

If history is our guide then improving the GNU implementations till they
are at least as good, or threaten to surpass the proprietary
implementations will trigger proprietary companies into opening op and
working with the community more.

Cheers,

Mark

Re: Opensource plugin&webstart - when?

2009-08-26T09:40:20Z

I just can't understand the reason of holding those two components
back nore can I imagine any way how to make money out of it.

So it seems to old catch-up game continues again, with
half-"compatible" implementations arround, hurting java's reputation
and user experience.

- Clemens

2009/8/21 Andrew John Hughes <gnu_andrew@...>:

> 2009/8/21 Clemens Eisserer <linuxhippy@...>:
>> Hello,
>>
>> Back in February I talked to Mark Reinhold at Fosdem about
>> open-sourcing the next generation java plugin as well as Webstart -
>> and was told to expect a release pretty soon.
>> However until now nothing has happend.
>>
>> I have a few Webstart / deployment toolkit fixes here myself, but
>> won't contribute this as long as it remains proprietary code.
>>
>> Whats the status of all this?
>>
>> Thanks, Clemens
>>
>
> Assuming you're referring to the proprietary Sun plugin, the last word
> on it was:
>
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-June/000604.html
>
> squirrelled away on the jdk6-dev list rather than discuss.
>
> There is a Free implementation of the plugin and javaws in IcedTea
> which is being rapidly developed in the open. Given the continued
> lack of commitment from Sun on releasing their plugin as part of
> OpenJDK, I think our efforts are best served by concentrating
> development on the IcedTea plugin rather than banging our collective
> heads against a brick wall. At present, it seems more likely that
> this plugin will be upstreamed into OpenJDK (most of the copyright is
> held by Red Hat developers who have an SCA with Sun) rather than the
> Sun plugin suddenly appearing.
>
> I would, of course, be very happy to be proved wrong on this.
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>

Creation of the Hotspot Express Project is APPROVED

2009-08-21T21:10:37Z

Sorry about the long notice on this.

Per the interim governance guidelines for Projects [1] I'm pleased to
announce the creation of the Hotspot Express Project [2] following the Hotspot Compiler
Group's decision to sponsor it.

The initial project of Hotspot Express is HSX 14 [3].

As this project is primarily intended for consumption by the OpenJDK 6 folks, discussion
regarding this project is to be held on jdk6-dev@... mailing list, rather
than creating a new dedicated list.

The vote was 16 for, none against.

[1] http://openjdk.java.net/projects
[2] http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html
[3] http://hg.openjdk.java.net/hsx/hsx14

--
Erik Trimble
Sun Microsystems, Inc.
Java System Support
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

Re: Opensource plugin&webstart - when?

2009-08-21T09:34:14Z

2009/8/21 Andrew John Hughes <gnu_andrew@...>:

I should mention that, given you've looked at the Sun proprietary
code, it would be dangerous to contribute code to the IcedTea plugin.

Bug reports and testing is of course still welcome.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Opensource plugin&webstart - when?

2009-08-21T08:48:10Z

2009/8/21 Clemens Eisserer <linuxhippy@...>:

> Hello,
>
> Back in February I talked to Mark Reinhold at Fosdem about
> open-sourcing the next generation java plugin as well as Webstart -
> and was told to expect a release pretty soon.
> However until now nothing has happend.
>
> I have a few Webstart / deployment toolkit fixes here myself, but
> won't contribute this as long as it remains proprietary code.
>
> Whats the status of all this?
>
> Thanks, Clemens
>

Assuming you're referring to the proprietary Sun plugin, the last word
on it was:

http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-June/000604.html

squirrelled away on the jdk6-dev list rather than discuss.

There is a Free implementation of the plugin and javaws in IcedTea
which is being rapidly developed in the open. Given the continued
lack of commitment from Sun on releasing their plugin as part of
OpenJDK, I think our efforts are best served by concentrating
development on the IcedTea plugin rather than banging our collective
heads against a brick wall. At present, it seems more likely that
this plugin will be upstreamed into OpenJDK (most of the copyright is
held by Red Hat developers who have an SCA with Sun) rather than the
Sun plugin suddenly appearing.

I would, of course, be very happy to be proved wrong on this.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Opensource plugin&webstart - when?

2009-08-21T07:55:44Z

Hello,

Back in February I talked to Mark Reinhold at Fosdem about
open-sourcing the next generation java plugin as well as Webstart -
and was told to expect a release pretty soon.
However until now nothing has happend.

I have a few Webstart / deployment toolkit fixes here myself, but
won't contribute this as long as it remains proprietary code.

Whats the status of all this?

Thanks, Clemens

JDK 7 build 70 is available at the openjdk.java.net website

2009-08-20T19:24:06Z

The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/175cb3fe6159

The OpenJDK source binary plugs for the promoted JDK 7 build 70 are
available under the openjdk http://openjdk.java.net website under Source
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b70.html

-Xiomara

Re: Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-17T12:16:02Z

2009/8/17 Mark Wielaard <mark@...>:

> Hi Andrew,
>
> On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
>> 2009/8/12 Mark Wielaard <mark@...>:
>> It's been possible to bootstrap OpenJDK with the GNU toolchain since
>> June 2007 (with a few workarounds) and that setup has certainly been
>> capable of compiling 1.6 source files. Given, AFAIK, the only changes
>> between 1.5 and 1.6 were verifier changes, I don't see why it would be
>> a problem. Without being able to do this, there wouldn't be an
>> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
>> distributions.
>
> Precisely. Which brings us to...
>
>> > Although IcedTea can indeed also try to bootstrap things with 1.5
>> > capable tools (most of this is now disabled in IcedTea7 I see)
>>
>> What has been disabled? I still run every new IcedTea7 build with
>> gcj. Nothing has changed AFAIK.
>
> IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
> -source/target 1.5 options. Mostly at the same points that now also have
> such settings in openjdk7. So those have been removed to not conflict.
> But they are now explicitly 1.6, no longer 1.5.
>
> This isn't a problem with newer/patches gcj/gij, since those do accept
> class major version 51 (even though it don't use the stack maps), but
> older gcj/gij doesn't accept such major class versions. (As you point
> out above, there is no real advantage using 1.6 over 1.5 in the VM. As
> long as the class library supports the needed 1.6 classes - as gnu
> classpath does.)
>
>> The problem is there is not one but three 'JDKs' in the mix here.
>> It's even more complicated if you consider each of them can be a mix
>> of different VMs and compilers. Things would be easier to debug if
>> Ant wasn't being used.
>
> Yes, ant makes things just that much more interesting... :}
>
> I have slowly gone through the build to try to have the "tool
> classes" (that need to be run during the build) and the "final rt
> classes" (that don't need to be run during the build) have explicitly
> compiled with the -source/target specifically set. Not fully there yet.
>
> The biggest problem is the jdk build. There are a couple of tools that
> are run during the build but that depend on com.sun.* classes that are
> (also) compiled as part of the runtime rt classes.
>
> This currently only work by accident. There are two slightly different
> ways this can happen:
> a) because you are using a bootstrap vm that already has those com.sun.*
> classes on the bootclasspath (the wrong old version is used then, not
> the just compiled one, but the one in the bootstrap vm core class
> libraries).
> b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
> mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
> the rt classes) when running the java build generation tools (this will
> work until one of the accidentally included new rt classes will actually
> start using invokedynamic, it already fails with gcj/gij that don't
> accept such newer 1.7/41 classes - such as the gcj/gij on Debian
> stable.).
>
> Cheers,
>
> Mark
>
>

After some experimentation:

* OpenJDK7 (from the IcedTea forest) builds fine on its own (i.e.
without IcedTea) using IcedTea6. So we haven't picked the bug Martin
and I had on OpenJDK6.
* javac.in has always passed -1.5 to ecj as it defaults to 1.4.
Leaving this in causes langtools to fail in build-bootstrap-javac:

[javac] Compliance level '1.5' is incompatible with source level
'1.6'. A compliance level '1.6' or better is required

* changing this to 1.6 causes a later failure in build.classes.javac

[javac] Compliance level '1.6' is incompatible with source level
'1.7'. A compliance level '1.7' or better is required

* getting rid of it altogether allows langtools to build and breaks
corba which isn't setting source/target:

/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javac
-J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -encoding ascii -d
/mnt/builder/icedtea7/openjdk-ecj/build/linux-amd64/corba/btclasses \
-sourcepath ../../tools/src
../../tools/src/build/tools/stripproperties/StripProperties.java

This only works on IcedTea because it defaults to a higher
source/target version.

* using 1.7 in javac.in works for me, but clearly not for mjw.

So I think we need to remove the option and specify it explicitly when
needed. Which means some more OpenJDK fixes are required.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-17T11:12:37Z

Hi Andrew,

On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
> 2009/8/12 Mark Wielaard <mark@...>:
> It's been possible to bootstrap OpenJDK with the GNU toolchain since
> June 2007 (with a few workarounds) and that setup has certainly been
> capable of compiling 1.6 source files. Given, AFAIK, the only changes
> between 1.5 and 1.6 were verifier changes, I don't see why it would be
> a problem. Without being able to do this, there wouldn't be an
> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
> distributions.

Precisely. Which brings us to...

> > Although IcedTea can indeed also try to bootstrap things with 1.5
> > capable tools (most of this is now disabled in IcedTea7 I see)
>
> What has been disabled? I still run every new IcedTea7 build with
> gcj. Nothing has changed AFAIK.

IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
-source/target 1.5 options. Mostly at the same points that now also have
such settings in openjdk7. So those have been removed to not conflict.
But they are now explicitly 1.6, no longer 1.5.

This isn't a problem with newer/patches gcj/gij, since those do accept
class major version 51 (even though it don't use the stack maps), but
older gcj/gij doesn't accept such major class versions. (As you point
out above, there is no real advantage using 1.6 over 1.5 in the VM. As
long as the class library supports the needed 1.6 classes - as gnu
classpath does.)

> The problem is there is not one but three 'JDKs' in the mix here.
> It's even more complicated if you consider each of them can be a mix
> of different VMs and compilers. Things would be easier to debug if
> Ant wasn't being used.

Yes, ant makes things just that much more interesting... :}

I have slowly gone through the build to try to have the "tool
classes" (that need to be run during the build) and the "final rt
classes" (that don't need to be run during the build) have explicitly
compiled with the -source/target specifically set. Not fully there yet.

The biggest problem is the jdk build. There are a couple of tools that
are run during the build but that depend on com.sun.* classes that are
(also) compiled as part of the runtime rt classes.

This currently only work by accident. There are two slightly different
ways this can happen:
a) because you are using a bootstrap vm that already has those com.sun.*
classes on the bootclasspath (the wrong old version is used then, not
the just compiled one, but the one in the bootstrap vm core class
libraries).
b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
the rt classes) when running the java build generation tools (this will
work until one of the accidentally included new rt classes will actually
start using invokedynamic, it already fails with gcj/gij that don't
accept such newer 1.7/41 classes - such as the gcj/gij on Debian
stable.).

Cheers,

Mark

Re: Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-17T09:20:08Z

2009/8/12 Mark Wielaard <mark@...>:

> [sorry if this becomes a duplicate, I sent the original from an
> unsubscribed address to the list, hopefully resending from the address
> actually subscribed to the list now.]
>
> Hi Jon,
>
> On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
>> The boot JDK must support Java 6 or better. From the message in the
>> previous line about annotation processing, it would seem you're not using a
>> version of javac capable of compiling -source 6 files.
>

It's been possible to bootstrap OpenJDK with the GNU toolchain since
June 2007 (with a few workarounds) and that setup has certainly been
capable of compiling 1.6 source files. Given, AFAIK, the only changes
between 1.5 and 1.6 were verifier changes, I don't see why it would be
a problem. Without being able to do this, there wouldn't be an
IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
distributions.

> Although IcedTea can indeed also try to bootstrap things with 1.5
> capable tools (most of this is now disabled in IcedTea7 I see)

What has been disabled? I still run every new IcedTea7 build with
gcj. Nothing has changed AFAIK.

I don't

> think that was the issue in this case. It might be related though.
>
> IcedTea goes out of its way to try to make openjdk "bootstrappable"
> through the existing GNU java toolchains. So maybe some of the effort of
> tuning the -target and -source for the new 1.7 source/target have been
> biting each other. This might be more visible with IcedTea because the
> existing GNU java toolchain isn't monolithic like the openjdk one, so
> the core libraries, runtime vm and/or the compiler might have different
> source/target defaults and coverage.
>

The javac.in script did have to be changed to pass -1.7 instead of 1.5
to build with this latest version (this applies to ecj only). After
that, it worked AFAIR. You could try reverting this and see if it
helps. It's also worth checking what is being used by Ant and what is
being used by bootstrap/ecj.
The problem is there is not one but three 'JDKs' in the mix here.
It's even more complicated if you consider each of them can be a mix
of different VMs and compilers. Things would be easier to debug if
Ant wasn't being used.

> The CompilePropertiesTask that the original error was about had a class
> major version of 51, which indicates it was generated through -target
> 1.7 (or at least some compiler defaulting to 1.7). But since that class
> is used in the bootstrap cycle I think it should explicitly target 1.6.
>
> So I think this part in langtools/make/build.xml needs an explicit
> source="${boot.javac.source}" and target="${boot.javac.target}":
>
> <javac fork="true"
> executable="${boot.java.home}/bin/javac"
> srcdir="${make.tools.dir}/CompileProperties"
> destdir="${build.toolclasses.dir}/"
> classpath="${ant.home}/lib/ant.jar"/>
>
> The same thing happens later in the build with some other classes that
> are compiled and then run using the bootstrap tools.
>
> The corba stripproperties classes. The BOOT_JAVAC_CMD in
> corba/make/common/BuildToolJar.gmk doesn't define a source or target,
> they should probably be defined in as BOOT_CLASS_VERSION in
> corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
> since these classes will be run during the build on the bootstrap
> runtime vm.
>
> Similarly for the hotspot gamma classes. They are compiled with
> COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
> could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
> should probably also include an explicit target/source setting.
> Similarly for the jvmtiGen classes that are run using the bootstrap
> runtime vm.
>
> Especially the jdk build is a bit tricky since some things like the
> generatebreakiteratordata and javazic tools that are run during the
> build to generate classes and/or new source/property files combine
> classes that will go into the new rt.jar, and so have been compiled with
> -target 1.7, with tools build classes (like sun.text or
> sun.util.calendar classes) which have been compiled with -target 1.6,
> and that should be run by the bootstrap jdk (which is only capable of
> understanding 1.6 classes). This can be solved by making a copy of those
> classes and putting them in to tool package so the whole tool is 1.6
> runnable, but this is slightly ugly because that means you build stuff
> twice (once for -target 1.6 to run the tool and once for -target 1.7 to
> put into rt.jar).
>
> I'll try to go through a whole build (currently stuck on the bootstrap
> rmic not liking to generate Stub classes for some of the new-target 1.7
> classes) and suggest some real patches. That is after I made sure it
> isn't caused by some of the IcedTea "cleanup" patches that already try
> to do the same thing. And if any of the above sounds terribly wrong,
> please do yell and shout, so I take another step back.
>
> Thanks,
>
> Mark
>
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

JDK 7 build 69 is available at the openjdk.java.net website

2009-08-13T19:46:50Z

The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/82e6c820c51a

The OpenJDK source binary plugs for the promoted JDK 7 build 69 are
available under the openjdk http://openjdk.java.net website under Source
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b69.html

-Xiomara

Re: Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-12T18:56:00Z

On Aug 12, 2009, at 5:03 PM, Jonathan Gibbons wrote:

>
> On Aug 12, 2009, at 3:35 PM, Mark Wielaard wrote:
>
>> Hi Jon,
>>
[snip]

>>
>> So I think this part in langtools/make/build.xml needs an explicit
>> source="${boot.javac.source}" and target="${boot.javac.target}":
>>
>> <javac fork="true"
>> executable="${boot.java.home}/bin/javac"
>> srcdir="${make.tools.dir}/CompileProperties"
>> destdir="${build.toolclasses.dir}/"
>> classpath="${ant.home}/lib/ant.jar"/>
>>
>> The same thing happens later in the build with some other classes
>> that
>> are compiled and then run using the bootstrap tools.
>
>
> While it would not be wrong to specify boot.javac.source and
> boot.java.target
> it should not be necessary if it is compiled and run with equivalent
> versions of
> javac and java from the same ${boot.java.home}.
>

I take that back. I agree that source and target values should be
specified here,
since the class is compiled with boot.java but executed by Ant. I
have some
other minor fixes for build.xml underway, and will include this fix as
well.

> [snip]

-- Jon

Re: Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-12T17:03:59Z

On Aug 12, 2009, at 3:35 PM, Mark Wielaard wrote:

> Hi Jon,
>
> On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
>> The boot JDK must support Java 6 or better. From the message in the
>> previous line about annotation processing, it would seem you're not
>> using a
>> version of javac capable of compiling -source 6 files.
>
> Although IcedTea can indeed also try to bootstrap things with 1.5
> capable tools (most of this is now disabled in IcedTea7 I see) I don't
> think that was the issue in this case. It might be related though.
>
> IcedTea goes out of its way to try to make openjdk "bootstrappable"
> through the existing GNU java toolchains. So maybe some of the
> effort of
> tuning the -target and -source for the new 1.7 source/target have been
> biting each other. This might be more visible with IcedTea because the
> existing GNU java toolchain isn't monolithic like the openjdk one, so
> the core libraries, runtime vm and/or the compiler might have
> different
> source/target defaults and coverage.
>
> The CompilePropertiesTask that the original error was about had a
> class
> major version of 51, which indicates it was generated through -target
> 1.7 (or at least some compiler defaulting to 1.7). But since that
> class
> is used in the bootstrap cycle I think it should explicitly target
> 1.6.
>
> So I think this part in langtools/make/build.xml needs an explicit
> source="${boot.javac.source}" and target="${boot.javac.target}":
>
> <javac fork="true"
> executable="${boot.java.home}/bin/javac"
> srcdir="${make.tools.dir}/CompileProperties"
> destdir="${build.toolclasses.dir}/"
> classpath="${ant.home}/lib/ant.jar"/>
>
> The same thing happens later in the build with some other classes that
> are compiled and then run using the bootstrap tools.

While it would not be wrong to specify boot.javac.source and
boot.java.target
it should not be necessary if it is compiled and run with equivalent
versions of
javac and java from the same ${boot.java.home}.

>
>
> The corba stripproperties classes. The BOOT_JAVAC_CMD in
> corba/make/common/BuildToolJar.gmk doesn't define a source or target,
> they should probably be defined in as BOOT_CLASS_VERSION in
> corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
> since these classes will be run during the build on the bootstrap
> runtime vm.
>
> Similarly for the hotspot gamma classes. They are compiled with
> COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
> could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
> should probably also include an explicit target/source setting.
> Similarly for the jvmtiGen classes that are run using the bootstrap
> runtime vm.
>
> Especially the jdk build is a bit tricky since some things like the
> generatebreakiteratordata and javazic tools that are run during the
> build to generate classes and/or new source/property files combine
> classes that will go into the new rt.jar, and so have been compiled
> with
> -target 1.7, with tools build classes (like sun.text or
> sun.util.calendar classes) which have been compiled with -target 1.6,
> and that should be run by the bootstrap jdk (which is only capable of
> understanding 1.6 classes). This can be solved by making a copy of
> those
> classes and putting them in to tool package so the whole tool is 1.6
> runnable, but this is slightly ugly because that means you build stuff
> twice (once for -target 1.6 to run the tool and once for -target 1.7
> to
> put into rt.jar).
>
> I'll try to go through a whole build (currently stuck on the bootstrap
> rmic not liking to generate Stub classes for some of the new-target
> 1.7
> classes) and suggest some real patches. That is after I made sure it
> isn't caused by some of the IcedTea "cleanup" patches that already try
> to do the same thing. And if any of the above sounds terribly wrong,
> please do yell and shout, so I take another step back.
>
> Thanks,
>
> Mark
>

Bootstrapping (Was: Non-ASCII characters and OpenJDK)

2009-08-12T15:38:38Z

[sorry if this becomes a duplicate, I sent the original from an
unsubscribed address to the list, hopefully resending from the address
actually subscribed to the list now.]

Hi Jon,

On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
> The boot JDK must support Java 6 or better. From the message in the
> previous line about annotation processing, it would seem you're not using a
> version of javac capable of compiling -source 6 files.

Although IcedTea can indeed also try to bootstrap things with 1.5
capable tools (most of this is now disabled in IcedTea7 I see) I don't
think that was the issue in this case. It might be related though.

IcedTea goes out of its way to try to make openjdk "bootstrappable"
through the existing GNU java toolchains. So maybe some of the effort of
tuning the -target and -source for the new 1.7 source/target have been
biting each other. This might be more visible with IcedTea because the
existing GNU java toolchain isn't monolithic like the openjdk one, so
the core libraries, runtime vm and/or the compiler might have different
source/target defaults and coverage.

The CompilePropertiesTask that the original error was about had a class
major version of 51, which indicates it was generated through -target
1.7 (or at least some compiler defaulting to 1.7). But since that class
is used in the bootstrap cycle I think it should explicitly target 1.6.

So I think this part in langtools/make/build.xml needs an explicit
source="${boot.javac.source}" and target="${boot.javac.target}":

<javac fork="true"
executable="${boot.java.home}/bin/javac"
srcdir="${make.tools.dir}/CompileProperties"
destdir="${build.toolclasses.dir}/"
classpath="${ant.home}/lib/ant.jar"/>

The same thing happens later in the build with some other classes that
are compiled and then run using the bootstrap tools.

The corba stripproperties classes. The BOOT_JAVAC_CMD in
corba/make/common/BuildToolJar.gmk doesn't define a source or target,
they should probably be defined in as BOOT_CLASS_VERSION in
corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
since these classes will be run during the build on the bootstrap
runtime vm.

Similarly for the hotspot gamma classes. They are compiled with
COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
should probably also include an explicit target/source setting.
Similarly for the jvmtiGen classes that are run using the bootstrap
runtime vm.

Especially the jdk build is a bit tricky since some things like the
generatebreakiteratordata and javazic tools that are run during the
build to generate classes and/or new source/property files combine
classes that will go into the new rt.jar, and so have been compiled with
-target 1.7, with tools build classes (like sun.text or
sun.util.calendar classes) which have been compiled with -target 1.6,
and that should be run by the bootstrap jdk (which is only capable of
understanding 1.6 classes). This can be solved by making a copy of those
classes and putting them in to tool package so the whole tool is 1.6
runnable, but this is slightly ugly because that means you build stuff
twice (once for -target 1.6 to run the tool and once for -target 1.7 to
put into rt.jar).

I'll try to go through a whole build (currently stuck on the bootstrap
rmic not liking to generate Stub classes for some of the new-target 1.7
classes) and suggest some real patches. That is after I made sure it
isn't caused by some of the IcedTea "cleanup" patches that already try
to do the same thing. And if any of the above sounds terribly wrong,
please do yell and shout, so I take another step back.

Thanks,

Mark

Re: Non-ASCII characters and OpenJDK

2009-08-10T15:46:44Z

2009/8/10 Mark Wielaard <mark@...>:

> Hi,
>
> On Fri, 2009-08-07 at 14:13 -0700, Joe Darcy wrote:
>> The fix for 6827026 "Change javac source and target default to 7" added
>> explicit -source options throughout the JDK build so keep the same build
>> semantics of -source 1.5. As documented in the javac man page and as I
>> wrote up recently,
>
> This, and the bump to b68, also seems to have broken the IcedTea7
> bootstrap:
> http://icedtea.classpath.org/pipermail/testresults/2009-August/000109.html
> Note the "java.lang.ClassFormatError: CompilePropertiesTask
> (unrecognized class file version)". I assume that is because some
> -target output is used for a .class file too early in the bootstrap and
> either the compiler or runtime used doesn't support it yet.
>
> Cheers,
>
> Mark
>
>

I'll take a look when I'm back at work next week.

It goes without saying that it (eventually) worked for me or I
wouldn't have committed the change. Unfortunately, ant is about as
useful as a chocolate teapot when it comes to debugging such errors,
but I'd suggest taking a look at which JDK is running ant. I've had
all manner of JDKs end up running it before, including kaffe once
which caused some rather bizarre results!
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8