[patch] update ecj to ecj-3.8.2/4.2.2

[patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore since
2008, having no support for java7.  It looks like this ecj is already used
within the Fedora disto, however only locally patched (at least I couldn't find
any mail sent to java-patches).

Find attached the changes required to build a new ecj.jar from the R3_8_2 git
tag.  The built files can be found at
http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
fine, building libjava with the new ecj.jar doesn't show any regressions, and
the testsuite doesn't show any regressions.  However the filenames for some
generated class and header files have changed for inner classes:

$ svn status|grep UIDefaults|sort -k1
!       classpath/lib/javax/swing/UIDefaults$1.class
!       classpath/lib/javax/swing/UIDefaults$2.class
!       classpath/lib/javax/swing/UIDefaults$3.class
!       classpath/lib/javax/swing/UIDefaults$4.class
?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
!       javax/swing/UIDefaults$1.h
!       javax/swing/UIDefaults$2.h
!       javax/swing/UIDefaults$3.h
!       javax/swing/UIDefaults$4.h
?       javax/swing/UIDefaults$ProxyLazyValue$1.h
?       javax/swing/UIDefaults$ProxyLazyValue$2.h
?       javax/swing/UIDefaults$ProxyLazyValue$3.h
?       javax/swing/UIDefaults$ProxyLazyValue$4.h
M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
M       classpath/lib/javax/swing/UIDefaults.class
M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
M
classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class

See the attached svn-status.gz file for a complete diff (replace ! with D, ?
with A).

 - I'd like to ask Tom (or somebody else) to look at the patches
   for the rhug/java repository.

 - Ask to rebuild the .class and .h files using this new ecj.jar on the trunk,
   after the ecj.jar is uploaded.

There are issues building OpenJDK and IcedTea with this new compiler.  Please
see the IcedTea ML for a follow-up posting.

  Matthias

[-- Attachment #2: eclipse-gcj.diff --]
[-- Type: text/plain, Size: 3906 bytes --]

2013-04-13  Matthias Klose  <doko@ubuntu.com>

	* Makefile (TAG): Set to R3_8_2 (cvsroot, login): Remove,
	(checkout): Download from git repository.
	(compile): Compile for 1.5, catch errors copying resource files,
	don't include the META-INF file.
	* org/eclipse/jdt/internal/compiler/batch/GCCMain.java: Adopt to
	new API.
	
Index: Makefile
===================================================================
RCS file: /cvs/rhug/eclipse-gcj/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile	28 Sep 2009 17:38:31 -0000	1.10
+++ Makefile	13 Apr 2013 16:03:28 -0000
@@ -1,4 +1,4 @@
-TAG = R3_5_1
+TAG = R3_8_2
 
 cvsroot = :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
 
@@ -11,13 +11,27 @@
 	$(MAKE) compile
 	$(MAKE) ecj.jar ecj-source.tar.bz2
 
-login:
-	cvs -d $(cvsroot) login
-
 checkout:
-	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
+#	git clone -b R3_8_maintenance git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
+#	wget http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
+	tar xf $(TAG).tar.gz
+	rm -rf org.eclipse.jdt.core
+	mkdir org.eclipse.jdt.core
+	cp $(TAG)/org.eclipse.jdt.core/scripts/about.html \
+	  org.eclipse.jdt.core/.
+	cp $(TAG)/org.eclipse.jdt.core/scripts/build.xml \
+	  org.eclipse.jdt.core/.
+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
+	  | tar -x -f - -C org.eclipse.jdt.core/
+	find org.eclipse.jdt.core -name CheckDebugAttributes.java | xargs -r rm -f
+	find org.eclipse.jdt.core -name BuildJarIndex.java | xargs -r rm -f
+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
+	  | tar -x -f - -C org.eclipse.jdt.core/
+	mkdir -p org.eclipse.jdt.core/META-INF/services
+	printf 'org.eclipse.jdt.internal.compiler.tool.EclipseCompiler #Eclipse compiler' \
+	  > org.eclipse.jdt.core/META-INF/services/javax.tools.JavaCompiler
 
-SOURCES = org org.eclipse.jdt.core/batch org.eclipse.jdt.core/compiler
+SOURCES = org org.eclipse.jdt.core
 
 OUTPUT = bin
 
@@ -31,17 +45,19 @@
 compile:
 	@mkdir -p $(OUTPUT)
 	find $(SOURCES) -name '*.java' > List
-	ecj -d $(OUTPUT) -1.4 -nowarn -g @List
+	ecj -d $(OUTPUT) -1.5 -nowarn -g @List
+	set -e; \
 	here=`pwd`; for dir in $(SOURCES); do \
-	  (cd $$dir; find . -name '*.properties' -o -name '*.rsc' | \
+	  (cd $$dir; find . -name '*.properties' -o -name '*.props' -o -name '*.rsc' | \
 	   while read x; do \
 	     echo "cp $$x $$here/$(OUTPUT)/$$x"; \
+	     mkdir -p $$(dirname $$here/$(OUTPUT)/$$x); \
 	     cp $$x $$here/$(OUTPUT)/$$x; \
 	   done); \
 	done
 	cat gcc.properties >> $(OUTPUT)/org/eclipse/jdt/internal/compiler/batch/messages.properties
 	mkdir -p $(OUTPUT)/META-INF
-	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
+#	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
 
 # Once per GCC release you should upload an appropriate jar.
 # Don't change these once the release is out.
Index: org/eclipse/jdt/internal/compiler/batch/GCCMain.java
===================================================================
RCS file: /cvs/rhug/eclipse-gcj/org/eclipse/jdt/internal/compiler/batch/GCCMain.java,v
retrieving revision 1.8
diff -u -r1.8 GCCMain.java
--- org/eclipse/jdt/internal/compiler/batch/GCCMain.java	11 Sep 2009 10:59:21 -0000	1.8
+++ org/eclipse/jdt/internal/compiler/batch/GCCMain.java	13 Apr 2013 16:03:29 -0000
@@ -29,6 +29,7 @@
 import org.eclipse.jdt.internal.compiler.env.AccessRule;
 import org.eclipse.jdt.internal.compiler.env.AccessRuleSet;
 import org.eclipse.jdt.internal.compiler.impl.CompilerOptions;
+import org.eclipse.jdt.internal.compiler.problem.ProblemSeverities;
 import org.eclipse.jdt.internal.compiler.util.Messages;
 import org.eclipse.jdt.internal.compiler.util.SuffixConstants;
 
@@ -463,7 +464,7 @@
 		}
 
 		if (inhibitAllWarnings)
-			disableWarnings();
+			disableAll(ProblemSeverities.Warning);
 		if (treatWarningsAsErrors)
 			turnWarningsToErrors();
 

[-- Attachment #3: svn-status.gz --]
[-- Type: application/gzip, Size: 23037 bytes --]

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Andrew Hughes]

----- Original Message -----
> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
> since
> 2008, having no support for java7.  It looks like this ecj is already used
> within the Fedora disto, however only locally patched (at least I couldn't
> find
> any mail sent to java-patches).
> 
> Find attached the changes required to build a new ecj.jar from the R3_8_2 git
> tag.  The built files can be found at
> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
> fine, building libjava with the new ecj.jar doesn't show any regressions, and
> the testsuite doesn't show any regressions.  However the filenames for some
> generated class and header files have changed for inner classes:
> 
> $ svn status|grep UIDefaults|sort -k1
> !       classpath/lib/javax/swing/UIDefaults$1.class
> !       classpath/lib/javax/swing/UIDefaults$2.class
> !       classpath/lib/javax/swing/UIDefaults$3.class
> !       classpath/lib/javax/swing/UIDefaults$4.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
> !       javax/swing/UIDefaults$1.h
> !       javax/swing/UIDefaults$2.h
> !       javax/swing/UIDefaults$3.h
> !       javax/swing/UIDefaults$4.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
> M       classpath/lib/javax/swing/UIDefaults.class
> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
> M
> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
> 
> See the attached svn-status.gz file for a complete diff (replace ! with D, ?
> with A).
> 
>  - I'd like to ask Tom (or somebody else) to look at the patches
>    for the rhug/java repository.
> 
>  - Ask to rebuild the .class and .h files using this new ecj.jar on the
>  trunk,
>    after the ecj.jar is uploaded.
> 
> There are issues building OpenJDK and IcedTea with this new compiler.  Please
> see the IcedTea ML for a follow-up posting.
> 
>   Matthias
> 

Is this ecj buildable with gcj?  My experience of 3.8 is that it isn't buildable
without the javax.lang.model code that is now in GNU Classpath, but hasn't yet been
merged to gcj (it's not yet ready for that).
-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

Am 15.04.2013 15:28, schrieb Andrew Hughes:
> ----- Original Message -----
>> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
>> since
>> 2008, having no support for java7.  It looks like this ecj is already used
>> within the Fedora disto, however only locally patched (at least I couldn't
>> find
>> any mail sent to java-patches).
>>
>> Find attached the changes required to build a new ecj.jar from the R3_8_2 git
>> tag.  The built files can be found at
>> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
>> fine, building libjava with the new ecj.jar doesn't show any regressions, and
>> the testsuite doesn't show any regressions.  However the filenames for some
>> generated class and header files have changed for inner classes:
>>
>> $ svn status|grep UIDefaults|sort -k1
>> !       classpath/lib/javax/swing/UIDefaults$1.class
>> !       classpath/lib/javax/swing/UIDefaults$2.class
>> !       classpath/lib/javax/swing/UIDefaults$3.class
>> !       classpath/lib/javax/swing/UIDefaults$4.class
>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
>> !       javax/swing/UIDefaults$1.h
>> !       javax/swing/UIDefaults$2.h
>> !       javax/swing/UIDefaults$3.h
>> !       javax/swing/UIDefaults$4.h
>> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
>> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
>> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
>> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
>> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
>> M       classpath/lib/javax/swing/UIDefaults.class
>> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
>> M
>> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
>>
>> See the attached svn-status.gz file for a complete diff (replace ! with D, ?
>> with A).
>>
>>  - I'd like to ask Tom (or somebody else) to look at the patches
>>    for the rhug/java repository.
>>
>>  - Ask to rebuild the .class and .h files using this new ecj.jar on the
>>  trunk,
>>    after the ecj.jar is uploaded.
>>
>> There are issues building OpenJDK and IcedTea with this new compiler.  Please
>> see the IcedTea ML for a follow-up posting.
>>
>>   Matthias
>>
> 
> Is this ecj buildable with gcj?  My experience of 3.8 is that it isn't buildable
> without the javax.lang.model code that is now in GNU Classpath, but hasn't yet been
> merged to gcj (it's not yet ready for that).

I used

  gcj-4.8 -C -g -I/usr/share/ant/lib/ant.jar @files

and that seems to work well enough to build libjava.

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Andrew Hughes]

----- Original Message -----
> Am 15.04.2013 15:28, schrieb Andrew Hughes:
> > ----- Original Message -----
> >> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
> >> since
> >> 2008, having no support for java7.  It looks like this ecj is already used
> >> within the Fedora disto, however only locally patched (at least I couldn't
> >> find
> >> any mail sent to java-patches).
> >>
> >> Find attached the changes required to build a new ecj.jar from the R3_8_2
> >> git
> >> tag.  The built files can be found at
> >> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C
> >> looks
> >> fine, building libjava with the new ecj.jar doesn't show any regressions,
> >> and
> >> the testsuite doesn't show any regressions.  However the filenames for
> >> some
> >> generated class and header files have changed for inner classes:
> >>
> >> $ svn status|grep UIDefaults|sort -k1
> >> !       classpath/lib/javax/swing/UIDefaults$1.class
> >> !       classpath/lib/javax/swing/UIDefaults$2.class
> >> !       classpath/lib/javax/swing/UIDefaults$3.class
> >> !       classpath/lib/javax/swing/UIDefaults$4.class
> >> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
> >> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
> >> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
> >> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
> >> !       javax/swing/UIDefaults$1.h
> >> !       javax/swing/UIDefaults$2.h
> >> !       javax/swing/UIDefaults$3.h
> >> !       javax/swing/UIDefaults$4.h
> >> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
> >> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
> >> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
> >> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
> >> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
> >> M       classpath/lib/javax/swing/UIDefaults.class
> >> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
> >> M
> >> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
> >>
> >> See the attached svn-status.gz file for a complete diff (replace ! with D,
> >> ?
> >> with A).
> >>
> >>  - I'd like to ask Tom (or somebody else) to look at the patches
> >>    for the rhug/java repository.
> >>
> >>  - Ask to rebuild the .class and .h files using this new ecj.jar on the
> >>  trunk,
> >>    after the ecj.jar is uploaded.
> >>
> >> There are issues building OpenJDK and IcedTea with this new compiler.
> >> Please
> >> see the IcedTea ML for a follow-up posting.
> >>
> >>   Matthias
> >>
> > 
> > Is this ecj buildable with gcj?  My experience of 3.8 is that it isn't
> > buildable
> > without the javax.lang.model code that is now in GNU Classpath, but hasn't
> > yet been
> > merged to gcj (it's not yet ready for that).
> 
> I used
> 
>   gcj-4.8 -C -g -I/usr/share/ant/lib/ant.jar @files
> 
> and that seems to work well enough to build libjava.
> 
> 

>>> Compiling source in /mnt/builder/portage.build/portage/dev-java/eclipse-ecj-4.2.1/work ...
 * bootstrapping ecj with /usr/lib/gcj-jdk-4.8.0/bin/javac ...

1. ERROR in org/eclipse/jdt/internal/compiler/apt/dispatch/RoundDispatcher.java (at line 21)
	import javax.annotation.processing.RoundEnvironment;
	       ^^^^^^^^^^^^^^^^
The import javax.annotation cannot be resolved
----------
2. ERROR in org/eclipse/jdt/internal/compiler/apt/dispatch/RoundDispatcher.java (at line 22)
	import javax.lang.model.element.Element;
	       ^^^^^^^^^^
The import javax.lang cannot be resolved
----------
3. ERROR in org/eclipse/jdt/internal/compiler/apt/dispatch/RoundDispatcher.java (at line 23)
	import javax.lang.model.element.TypeElement;
	       ^^^^^^^^^^
The import javax.lang cannot be resolved

and so on...

78 problems (78 errors) * ERROR: dev-java/eclipse-ecj-4.2.1 failed (compile phase):

Are you using a complete ecj or deleting some classes?
-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

Am 15.04.2013 16:02, schrieb Andrew Hughes:
> Are you using a complete ecj or deleting some classes?

I did use what I did send in the patch, and what should be same as is in the
current version of ecj.jar as distributed on gcc.gnu.org.

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Andrew Hughes]

----- Original Message -----
> Am 15.04.2013 16:02, schrieb Andrew Hughes:
> > Are you using a complete ecj or deleting some classes?
> 
> I did use what I did send in the patch, and what should be same as is in the
> current version of ecj.jar as distributed on gcc.gnu.org.
> 
> 

It's not clear from that patch what exactly is being compiled.  I do see some
rm calls so I suspect bits of ecj are being deleted.

I'd rather we wait until the javax.lang.model work is merged and a more complete
ecj can be used.
-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Jon VanAlten]

----- Original Message -----
> From: "Matthias Klose" <doko@ubuntu.com>
> To: "GCJ-patches" <java-patches@gcc.gnu.org>
> Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, classpath@gnu.org, "Tom Tromey" <tromey@redhat.com>
> Sent: Monday, April 15, 2013 6:21:45 AM
> Subject: [patch] update ecj to ecj-3.8.2/4.2.2
> 
> It looks like this ecj is already used
> within the Fedora disto, however only locally patched (at least I couldn't
> find
> any mail sent to java-patches).
> 

My bad.  I honestly didn't have any idea what the upstream process would be. My
history in the free java world starts after openjdk/icedtea, so all the gcj
fluff isn't really known well to me, and I don't really know where to look for
information (pointers appreciated!  :D  ).  So I sort of let it slip through
the cracks.

I did bring it up on an earlier thread[1], and it seems like by accident it
also went to java-patches.  Now I know for next time, if and when there is a
next time.

cheers,
jon

[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-March/022168.html

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Andrew Hughes]

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Matthias Klose" <doko@ubuntu.com>
> > To: "GCJ-patches" <java-patches@gcc.gnu.org>
> > Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, classpath@gnu.org, "Tom
> > Tromey" <tromey@redhat.com>
> > Sent: Monday, April 15, 2013 6:21:45 AM
> > Subject: [patch] update ecj to ecj-3.8.2/4.2.2
> > 
> > It looks like this ecj is already used
> > within the Fedora disto, however only locally patched (at least I couldn't
> > find
> > any mail sent to java-patches).
> > 
> 
> My bad.  I honestly didn't have any idea what the upstream process would be.
> My
> history in the free java world starts after openjdk/icedtea, so all the gcj
> fluff isn't really known well to me, and I don't really know where to look
> for
> information (pointers appreciated!  :D  ).  So I sort of let it slip through
> the cracks.
> 
> I did bring it up on an earlier thread[1], and it seems like by accident it
> also went to java-patches.  Now I know for next time, if and when there is a
> next time.
> 

Don't feel bad, Jon.  It's not your fault.  I was around for "the gcj fluff"
(perhaps wording it better would be a good idea though) and I still have no
idea how this is updated, despite asking on this list at least once.

And to be honest, I still don't.

> cheers,
> jon
> 
> [1]
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-March/022168.html
> 

-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Jon VanAlten]

----- Original Message -----
> From: "Andrew Hughes" <gnu.andrew@redhat.com>
> To: "Jon VanAlten" <jon.vanalten@redhat.com>
> Cc: "Matthias Klose" <doko@ubuntu.com>, "GCJ-patches" <java-patches@gcc.gnu.org>, classpath@gnu.org, "Tom Tromey"
> <tromey@redhat.com>
> Sent: Monday, April 15, 2013 5:34:49 PM
> Subject: Re: [patch] update ecj to ecj-3.8.2/4.2.2
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Matthias Klose" <doko@ubuntu.com>
> > > To: "GCJ-patches" <java-patches@gcc.gnu.org>
> > > Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, classpath@gnu.org, "Tom
> > > Tromey" <tromey@redhat.com>
> > > Sent: Monday, April 15, 2013 6:21:45 AM
> > > Subject: [patch] update ecj to ecj-3.8.2/4.2.2
> > > 
> > > It looks like this ecj is already used
> > > within the Fedora disto, however only locally patched (at least I
> > > couldn't
> > > find
> > > any mail sent to java-patches).
> > > 
> > 
> > My bad.  I honestly didn't have any idea what the upstream process would
> > be.
> > My
> > history in the free java world starts after openjdk/icedtea, so all the gcj
> > fluff isn't really known well to me, and I don't really know where to look
> > for
> > information (pointers appreciated!  :D  ).  So I sort of let it slip
> > through
> > the cracks.
> > 
> > I did bring it up on an earlier thread[1], and it seems like by accident it
> > also went to java-patches.  Now I know for next time, if and when there is
> > a
> > next time.
> > 
> 
> Don't feel bad, Jon.  It's not your fault.  I was around for "the gcj fluff"
> (perhaps wording it better would be a good idea though) and I still have no
> idea how this is updated, despite asking on this list at least once.
> 
> And to be honest, I still don't.
> 

Hah, ok then hopefully those that *do* know their way around can offer up a
pointer to some documentation (possibly preceded by creating and publishing
said documentation) :)

Just to make sure, I don't mean "fluff" in a derogatory sense at all!
Rather, I thank the forebearers of the free java community for doing all
that great work.  It's just that now, since there is very little active work
on those bits (as I understand it because there is very little need for
active work), I haven't had the opportunity to learn the ins and outs, and
so it all seems like a big black box to me, such that I fall back on
speaking of it in generic terms like "fluff" by which I mean just "stuff",
not at all "inconsequential".

cheers,
jon

ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

ping

Am 15.04.2013 12:21, schrieb Matthias Klose:
> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore since
> 2008, having no support for java7.  It looks like this ecj is already used
> within the Fedora disto, however only locally patched (at least I couldn't find
> any mail sent to java-patches).
> 
> Find attached the changes required to build a new ecj.jar from the R3_8_2 git
> tag.  The built files can be found at
> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
> fine, building libjava with the new ecj.jar doesn't show any regressions, and
> the testsuite doesn't show any regressions.  However the filenames for some
> generated class and header files have changed for inner classes:
> 
> $ svn status|grep UIDefaults|sort -k1
> !       classpath/lib/javax/swing/UIDefaults$1.class
> !       classpath/lib/javax/swing/UIDefaults$2.class
> !       classpath/lib/javax/swing/UIDefaults$3.class
> !       classpath/lib/javax/swing/UIDefaults$4.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
> !       javax/swing/UIDefaults$1.h
> !       javax/swing/UIDefaults$2.h
> !       javax/swing/UIDefaults$3.h
> !       javax/swing/UIDefaults$4.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
> M       classpath/lib/javax/swing/UIDefaults.class
> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
> M
> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
> 
> See the attached svn-status.gz file for a complete diff (replace ! with D, ?
> with A).
> 
>  - I'd like to ask Tom (or somebody else) to look at the patches
>    for the rhug/java repository.
> 
>  - Ask to rebuild the .class and .h files using this new ecj.jar on the trunk,
>    after the ecj.jar is uploaded.
> 
> There are issues building OpenJDK and IcedTea with this new compiler.  Please
> see the IcedTea ML for a follow-up posting.
> 
>   Matthias
> 

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Jon VanAlten]

----- Original Message -----
> From: "Matthias Klose" <doko@ubuntu.com>
> To: "GCJ-patches" <java-patches@gcc.gnu.org>
> Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, "Tom Tromey" <tromey@redhat.com>, "Andrew Haley" <aph@redhat.com>
> Sent: Thursday, June 20, 2013 6:39:22 AM
> Subject: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
> 
> ping
> 
> Am 15.04.2013 12:21, schrieb Matthias Klose:
> > The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
> > since
> > 2008, having no support for java7.  It looks like this ecj is already used
> > within the Fedora disto, however only locally patched (at least I couldn't
> > find
> > any mail sent to java-patches).
> > 
> > Find attached the changes required to build a new ecj.jar from the R3_8_2
> > git
> > tag.  The built files can be found at
> > http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
> > fine, building libjava with the new ecj.jar doesn't show any regressions,
> > and
> > the testsuite doesn't show any regressions.  However the filenames for some
> > generated class and header files have changed for inner classes:
> > 
> > $ svn status|grep UIDefaults|sort -k1
> > !       classpath/lib/javax/swing/UIDefaults$1.class
> > !       classpath/lib/javax/swing/UIDefaults$2.class
> > !       classpath/lib/javax/swing/UIDefaults$3.class
> > !       classpath/lib/javax/swing/UIDefaults$4.class
> > ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
> > ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
> > ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
> > ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
> > !       javax/swing/UIDefaults$1.h
> > !       javax/swing/UIDefaults$2.h
> > !       javax/swing/UIDefaults$3.h
> > !       javax/swing/UIDefaults$4.h
> > ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
> > ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
> > ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
> > ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
> > M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
> > M       classpath/lib/javax/swing/UIDefaults.class
> > M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
> > M
> > classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
> > 
> > See the attached svn-status.gz file for a complete diff (replace ! with D,
> > ?
> > with A).
> > 
> >  - I'd like to ask Tom (or somebody else) to look at the patches
> >    for the rhug/java repository.
> > 
> >  - Ask to rebuild the .class and .h files using this new ecj.jar on the
> >  trunk,
> >    after the ecj.jar is uploaded.
> > 
> > There are issues building OpenJDK and IcedTea with this new compiler.
> > Please
> > see the IcedTea ML for a follow-up posting.
> > 
> >   Matthias
> > 

Hi Matthias,

I didn't realize this was still waiting for input.
/me puts on Fedora packager hat...
We don't even use the Makefile here (we copy GCCMain and properties
into ecj source tree and use their ant build), but I have a couple
comments about that change anyways.

 checkout:
-	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
+#	git clone -b R3_8_maintenance git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
+#	wget http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
+	tar xf $(TAG).tar.gz

So "checkout" target no longer does a checkout... seems a bit off. Is
the commented git clone line left over from doing some of this before
the official tag existed? Might want to drop that, and consider
renaming the target to reflect its new behaviour.

+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
+	  | tar -x -f - -C org.eclipse.jdt.core/

Am I missing something or is this equivalent and simpler:

+	mv $(TAG)/org.eclipse.jdt.core/compiler/org org.eclipse.jdt.core/

+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
+	  | tar -x -f - -C org.eclipse.jdt.core/

Ditto.

-	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
+#	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF

Any reason not to just delete this line if it's no longer needed?

As for the GCCMain portion of the change, yes it looks both necessary
and correct. We do same in Fedora package (once again sorry it didn't
get posted upstream due to my ignorance), and it would be nice to drop
the patch once this is in a release.

cheers,
jon

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

On 06/26/13 21:23, Jon VanAlten wrote:
> 
> 
> ----- Original Message -----
>> From: "Matthias Klose" <doko@ubuntu.com>
>> To: "GCJ-patches" <java-patches@gcc.gnu.org>
>> Cc: "Jon VanAlten" <jon.vanalten@redhat.com>, "Tom Tromey" <tromey@redhat.com>, "Andrew Haley" <aph@redhat.com>
>> Sent: Thursday, June 20, 2013 6:39:22 AM
>> Subject: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
>>
>> ping
>>
>> Am 15.04.2013 12:21, schrieb Matthias Klose:
>>> The ecj.jar provided on ftp://gcc.gnu.org/pub/java wasn't updated anymore
>>> since
>>> 2008, having no support for java7.  It looks like this ecj is already used
>>> within the Fedora disto, however only locally patched (at least I couldn't
>>> find
>>> any mail sent to java-patches).
>>>
>>> Find attached the changes required to build a new ecj.jar from the R3_8_2
>>> git
>>> tag.  The built files can be found at
>>> http://people.debian.org/~doko/tmp/eclipse-gcj/. The resulting gcj -C looks
>>> fine, building libjava with the new ecj.jar doesn't show any regressions,
>>> and
>>> the testsuite doesn't show any regressions.  However the filenames for some
>>> generated class and header files have changed for inner classes:
>>>
>>> $ svn status|grep UIDefaults|sort -k1
>>> !       classpath/lib/javax/swing/UIDefaults$1.class
>>> !       classpath/lib/javax/swing/UIDefaults$2.class
>>> !       classpath/lib/javax/swing/UIDefaults$3.class
>>> !       classpath/lib/javax/swing/UIDefaults$4.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$1.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$2.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$3.class
>>> ?       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue$4.class
>>> !       javax/swing/UIDefaults$1.h
>>> !       javax/swing/UIDefaults$2.h
>>> !       javax/swing/UIDefaults$3.h
>>> !       javax/swing/UIDefaults$4.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$1.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$2.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$3.h
>>> ?       javax/swing/UIDefaults$ProxyLazyValue$4.h
>>> M       classpath/lib/javax/swing/plaf/basic/SharedUIDefaults.class
>>> M       classpath/lib/javax/swing/UIDefaults.class
>>> M       classpath/lib/javax/swing/UIDefaults$ProxyLazyValue.class
>>> M
>>> classpath/lib/javax/swing/UIManager$MultiplexUIDefaults$MultiplexEnumeration.class
>>>
>>> See the attached svn-status.gz file for a complete diff (replace ! with D,
>>> ?
>>> with A).
>>>
>>>  - I'd like to ask Tom (or somebody else) to look at the patches
>>>    for the rhug/java repository.
>>>
>>>  - Ask to rebuild the .class and .h files using this new ecj.jar on the
>>>  trunk,
>>>    after the ecj.jar is uploaded.
>>>
>>> There are issues building OpenJDK and IcedTea with this new compiler.
>>> Please
>>> see the IcedTea ML for a follow-up posting.
>>>
>>>   Matthias
>>>
> 
> Hi Matthias,
> 
> I didn't realize this was still waiting for input.
> /me puts on Fedora packager hat...
> We don't even use the Makefile here (we copy GCCMain and properties
> into ecj source tree and use their ant build), but I have a couple
> comments about that change anyways.
> 
>  checkout:
> -	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
> +#	git clone -b R3_8_maintenance git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
> +#	wget http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
> +	tar xf $(TAG).tar.gz
> 
> So "checkout" target no longer does a checkout... seems a bit off. Is
> the commented git clone line left over from doing some of this before
> the official tag existed? Might want to drop that, and consider
> renaming the target to reflect its new behaviour.

sure, I can rename that.  any suggestion?  The purpose is to make it clear where
the source do come from.

> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
> +	  | tar -x -f - -C org.eclipse.jdt.core/
> 
> Am I missing something or is this equivalent and simpler:
> 
> +	mv $(TAG)/org.eclipse.jdt.core/compiler/org org.eclipse.jdt.core/
> 
> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
> +	  | tar -x -f - -C org.eclipse.jdt.core/
> 
> Ditto.

yes, not having to run the checkout / pull from the web again.

> 
> -	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
> +#	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
> 
> Any reason not to just delete this line if it's no longer needed?

sure, can be dropped, the file is generated by jar anyway.

> As for the GCCMain portion of the change, yes it looks both necessary
> and correct. We do same in Fedora package (once again sorry it didn't
> get posted upstream due to my ignorance), and it would be nice to drop
> the patch once this is in a release.

yes, having this upstream would be appreciated.

So besides the style how to do fetch the sources, this looks ok?

Is there another newer released ecj version which should be used instead?

  Matthias

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Jon VanAlten]

----- Original Message -----
> From: "Matthias Klose" <doko@ubuntu.com>
> To: "Jon VanAlten" <jon.vanalten@redhat.com>
> Cc: "GCJ-patches" <java-patches@gcc.gnu.org>, "Tom Tromey" <tromey@redhat.com>, "Andrew Haley" <aph@redhat.com>
> Sent: Tuesday, July 2, 2013 3:36:14 AM
> Subject: Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
> 
> On 06/26/13 21:23, Jon VanAlten wrote:
> > 
> >  checkout:
> > -	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
> > +#	git clone -b R3_8_maintenance
> > git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
> > +#	wget
> > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
> > +	tar xf $(TAG).tar.gz
> > 
> > So "checkout" target no longer does a checkout... seems a bit off. Is
> > the commented git clone line left over from doing some of this before
> > the official tag existed? Might want to drop that, and consider
> > renaming the target to reflect its new behaviour.
> 
> sure, I can rename that.  any suggestion?  The purpose is to make it clear
> where
> the source do come from.

If my reading of this is correct, this make target now does some moving
about of things that are already checked out into the local filesystem.
My suggestion would be to call it "prepare-sources" or just "prepare".

> 
> > +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
> > +	  | tar -x -f - -C org.eclipse.jdt.core/
> > 
> > Am I missing something or is this equivalent and simpler:
> > 
> > +	mv $(TAG)/org.eclipse.jdt.core/compiler/org org.eclipse.jdt.core/
> > 
> > +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
> > +	  | tar -x -f - -C org.eclipse.jdt.core/
> > 
> > Ditto.
> 
> yes, not having to run the checkout / pull from the web again.
> 

Right, so doing it as "cp -ar" instead of a "mv" would accomplish same?

> > As for the GCCMain portion of the change, yes it looks both necessary
> > and correct. We do same in Fedora package (once again sorry it didn't
> > get posted upstream due to my ignorance), and it would be nice to drop
> > the patch once this is in a release.
> 
> yes, having this upstream would be appreciated.
> 
> So besides the style how to do fetch the sources, this looks ok?
> 

Yep.

> Is there another newer released ecj version which should be used instead?
> 

Let's check the authoritative source[1] for that.  It does seem as though
they've done their 4.3 release, the sources for just ecj can be found
under JDT Core Batch Compiler at [2].  News[3] does mention a few compiler
improvements, but I might suggest to first push update to 3.8 and then
update to latest in separate commit (so anyone else who consumes this can
choose the version they prefer).

cheers,
jon

[1] http://download.eclipse.org/eclipse/downloads/
[2] http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/
[3] http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/news/eclipse-news-part2.html

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

Am 02.07.2013 21:04, schrieb Jon VanAlten:
> 
> 
> ----- Original Message -----
>> From: "Matthias Klose" <doko@ubuntu.com>
>> To: "Jon VanAlten" <jon.vanalten@redhat.com>
>> Cc: "GCJ-patches" <java-patches@gcc.gnu.org>, "Tom Tromey" <tromey@redhat.com>, "Andrew Haley" <aph@redhat.com>
>> Sent: Tuesday, July 2, 2013 3:36:14 AM
>> Subject: Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2
>>
>> On 06/26/13 21:23, Jon VanAlten wrote:
>>>
>>>  checkout:
>>> -	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
>>> +#	git clone -b R3_8_maintenance
>>> git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
>>> +#	wget
>>> http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
>>> +	tar xf $(TAG).tar.gz
>>>
>>> So "checkout" target no longer does a checkout... seems a bit off. Is
>>> the commented git clone line left over from doing some of this before
>>> the official tag existed? Might want to drop that, and consider
>>> renaming the target to reflect its new behaviour.
>>
>> sure, I can rename that.  any suggestion?  The purpose is to make it clear
>> where
>> the source do come from.
> 
> If my reading of this is correct, this make target now does some moving
> about of things that are already checked out into the local filesystem.
> My suggestion would be to call it "prepare-sources" or just "prepare".
> 
>>
>>> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
>>> +	  | tar -x -f - -C org.eclipse.jdt.core/
>>>
>>> Am I missing something or is this equivalent and simpler:
>>>
>>> +	mv $(TAG)/org.eclipse.jdt.core/compiler/org org.eclipse.jdt.core/
>>>
>>> +	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
>>> +	  | tar -x -f - -C org.eclipse.jdt.core/
>>>
>>> Ditto.
>>
>> yes, not having to run the checkout / pull from the web again.
>>
> 
> Right, so doing it as "cp -ar" instead of a "mv" would accomplish same?
> 
>>> As for the GCCMain portion of the change, yes it looks both necessary
>>> and correct. We do same in Fedora package (once again sorry it didn't
>>> get posted upstream due to my ignorance), and it would be nice to drop
>>> the patch once this is in a release.
>>
>> yes, having this upstream would be appreciated.
>>
>> So besides the style how to do fetch the sources, this looks ok?
>>
> 
> Yep.
> 
>> Is there another newer released ecj version which should be used instead?
>>
> 
> Let's check the authoritative source[1] for that.  It does seem as though
> they've done their 4.3 release, the sources for just ecj can be found
> under JDT Core Batch Compiler at [2].  News[3] does mention a few compiler
> improvements, but I might suggest to first push update to 3.8 and then
> update to latest in separate commit (so anyone else who consumes this can
> choose the version they prefer).
> 
> cheers,
> jon
> 
> [1] http://download.eclipse.org/eclipse/downloads/
> [2] http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/
> [3] http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/news/eclipse-news-part2.html
> 

now updated to build from the 4.3.1 release (ecj itself identified as 3.9.0).
Renamed the download target into prepare, and removed the comment.

Test built libjava with --enable-maintainer-mode. No regressions.

Ok to checkin?

  Matthias


[-- Attachment #2: eclipse-gcj.diff --]
[-- Type: text/plain, Size: 4033 bytes --]

2013-12-10  Matthias Klose  <doko@ubuntu.com>

	* Makefile (TAG): Set to R4_3_1. (cvsroot, login): Remove,
	(checkout): Rename to prepare.
	(prepare): Download from git repository.
	(compile): Compile for 1.5, catch errors copying resource files,
	don't include the META-INF file.
	* org/eclipse/jdt/internal/compiler/batch/GCCMain.java: Adopt to
	new API.
	
 
Index: Makefile
===================================================================
RCS file: /cvs/rhug/eclipse-gcj/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile	28 Sep 2009 17:38:31 -0000	1.10
+++ Makefile	10 Dec 2013 15:47:35 -0000
@@ -1,4 +1,4 @@
-TAG = R3_5_1
+TAG = R4_3_1
 
 cvsroot = :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
 
@@ -11,13 +11,26 @@
 	$(MAKE) compile
 	$(MAKE) ecj.jar ecj-source.tar.bz2
 
-login:
-	cvs -d $(cvsroot) login
+prepare:
+	wget http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/snapshot/$(TAG).tar.gz
+	tar xf $(TAG).tar.gz
+	rm -rf org.eclipse.jdt.core
+	mkdir org.eclipse.jdt.core
+	cp $(TAG)/org.eclipse.jdt.core/scripts/about.html \
+	  org.eclipse.jdt.core/.
+	cp $(TAG)/org.eclipse.jdt.core/scripts/build.xml \
+	  org.eclipse.jdt.core/.
+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/compiler org \
+	  | tar -x -f - -C org.eclipse.jdt.core/
+	find org.eclipse.jdt.core -name CheckDebugAttributes.java | xargs -r rm -f
+	find org.eclipse.jdt.core -name BuildJarIndex.java | xargs -r rm -f
+	tar -c -f - -C $(TAG)/org.eclipse.jdt.core/batch org \
+	  | tar -x -f - -C org.eclipse.jdt.core/
+	mkdir -p org.eclipse.jdt.core/META-INF/services
+	printf 'org.eclipse.jdt.internal.compiler.tool.EclipseCompiler #Eclipse compiler' \
+	  > org.eclipse.jdt.core/META-INF/services/javax.tools.JavaCompiler
 
-checkout:
-	cvs -d $(cvsroot) co -r$(TAG) org.eclipse.jdt.core
-
-SOURCES = org org.eclipse.jdt.core/batch org.eclipse.jdt.core/compiler
+SOURCES = org org.eclipse.jdt.core
 
 OUTPUT = bin
 
@@ -31,17 +44,18 @@
 compile:
 	@mkdir -p $(OUTPUT)
 	find $(SOURCES) -name '*.java' > List
-	ecj -d $(OUTPUT) -1.4 -nowarn -g @List
+	ecj -d $(OUTPUT) -1.5 -nowarn -g @List
+	set -e; \
 	here=`pwd`; for dir in $(SOURCES); do \
-	  (cd $$dir; find . -name '*.properties' -o -name '*.rsc' | \
+	  (cd $$dir; find . -name '*.properties' -o -name '*.props' -o -name '*.rsc' | \
 	   while read x; do \
 	     echo "cp $$x $$here/$(OUTPUT)/$$x"; \
+	     mkdir -p $$(dirname $$here/$(OUTPUT)/$$x); \
 	     cp $$x $$here/$(OUTPUT)/$$x; \
 	   done); \
 	done
 	cat gcc.properties >> $(OUTPUT)/org/eclipse/jdt/internal/compiler/batch/messages.properties
 	mkdir -p $(OUTPUT)/META-INF
-	cp org.eclipse.jdt.core/META-INF/MANIFEST.MF $(OUTPUT)/META-INF
 
 # Once per GCC release you should upload an appropriate jar.
 # Don't change these once the release is out.
@@ -51,4 +65,4 @@
 	scp ecj.jar $(destination)/ecj-$(RELEASE).jar
 	scp ecj-source.tar.bz2 $(destination)/ecj-$(RELEASE)-source.tar.bz2
 
-.PHONY: all login checkout ecj.jar compile upload
+.PHONY: all login prepare ecj.jar compile upload
Index: org/eclipse/jdt/internal/compiler/batch/GCCMain.java
===================================================================
RCS file: /cvs/rhug/eclipse-gcj/org/eclipse/jdt/internal/compiler/batch/GCCMain.java,v
retrieving revision 1.8
diff -u -r1.8 GCCMain.java
--- org/eclipse/jdt/internal/compiler/batch/GCCMain.java	11 Sep 2009 10:59:21 -0000	1.8
+++ org/eclipse/jdt/internal/compiler/batch/GCCMain.java	10 Dec 2013 15:47:35 -0000
@@ -29,6 +29,7 @@
 import org.eclipse.jdt.internal.compiler.env.AccessRule;
 import org.eclipse.jdt.internal.compiler.env.AccessRuleSet;
 import org.eclipse.jdt.internal.compiler.impl.CompilerOptions;
+import org.eclipse.jdt.internal.compiler.problem.ProblemSeverities;
 import org.eclipse.jdt.internal.compiler.util.Messages;
 import org.eclipse.jdt.internal.compiler.util.SuffixConstants;
 
@@ -463,7 +464,7 @@
 		}
 
 		if (inhibitAllWarnings)
-			disableWarnings();
+			disableAll(ProblemSeverities.Warning);
 		if (treatWarningsAsErrors)
 			turnWarningsToErrors();
 

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Andrew Haley]

On 12/10/2013 03:51 PM, Matthias Klose wrote:
> Ok to checkin?

OK, and thanks.

Andrew.

Re: ping: Re: [patch] update ecj to ecj-3.8.2/4.2.2

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Am 10.12.2013 17:05, schrieb Andrew Haley:
> On 12/10/2013 03:51 PM, Matthias Klose wrote:
>> Ok to checkin?
> 
> OK, and thanks.

please find attached the two files built.  These have to be uploaded to
ftp://gcc.gnu.org:/pub/java.  I don't have permissions to do that.

With the makefile in this project:  make upload RELEASE=4.9

  Matthias


[-- Attachment #2: ecj.jar --]
[-- Type: application/x-java-archive, Size: 1619429 bytes --]

[-- Attachment #3: ecj-source.tar.bz2 --]
[-- Type: application/x-bzip, Size: 787868 bytes --]