I was looking at this test for another reason and thought, it might be a
good idea to make it a little bit more compact and re-indent it.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
SOURCE_INPUTS, TARGET_INPUTS, COMPLIANCE_INPUTS are now populated in a
'for' loop in a static initialiser block. I.e., adding support for a new
Java version is now as simple as incrementing field JAVA_VERSION_MAX. In
case ECJ raises the minimum supporter compiler source/target version,
field JAVA_VERSION_MIN needs to be incremented. But that should happen
less frequently.
This was done to make the 'AspectJ_JDK_Update' tasks as easy and as
little error-prone as possible.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove most MINOR_*, MINOR_* BCEL class file versions
in favour of Constants.ClassFileVersion.of(int, int). The few ones
retained are used from production code, the vast majority of removed
ones only from test code.
This gets rid of yet another 'AspectJ_JDK_Update' tag. One less place to
check and update with each newly supported Java version. :-)
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
LangUtil: remove methods like 'is11VMOrGreater', 'is1dot5VMOrGreater'
Replace them by a uniform method 'isVMGreaterOrEqual(double)', also
overloaded for int.
This gets rid of one 'AspectJ_JDK_Update' tag. One less place to check
and update with each newly supported Java version. :-)
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The hint is meant to help AspectJ developers identify the places where
there are to-dos for releases supporting new Java versions. This is work
in progress, new tags can be added wherever necessary in the future. But
for now, the most important places should be covered:
- AJC version string
- Test infrastructure (test suites, classes and XML files)
- BCEL class file version MAJOR_*, MINOR_* constants
- AjcTask constants for compiler source, target, release
- LangUtil::is*VMOrGreater methods
- ASM and JDT Core dependency versions
- CI workflow file
- Release notes
The to-do to check the tagged places is also mentioned in RELEASE.md.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Remove obsolete section "Deploying the AspectJ installer to
aspectj.dev", because we are publishing releases on GitHub, attaching
installers to them.
- Add section "Publish documentation on website".
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
One less warning in IntelliJ due to the entirely optional groupId for
that plugin, but IntelliJ still complains.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Use Antrun plugin to eliminate javadoc version number in HTML
This is the one issue that cannot be solved regarding reproducible
builds by setting javadoc options, because that header comment is
hard-coded into the JDK with no option to avoid it. I just created an
OpenJDK issue (internal review ID 9076583, not published yet) for it,
but that does not help us today.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Maven Javadoc: Add options for reproducible build artifacts
and smaller diffs when committing changes to the website,avoiding
timestamps, changing current copyright years, artifact versions.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add decade 2020-2029 to copyright years in Checklics
FWIW, I just wanted to know if the tests in module 'build' would still
pass. They did not find copyrights for more recent years, so I added
them here.
But I am still unsure, if we need these tests at all. Obviously, they
were not running during CI builds, i.e. they seem to be non-essential.
But chances are, they were forgotten to be added to the suite.
BTW, running the tests in module 'build' with '-Drun.build.tests=true'
is failing, too, because some old JDK classes looked up there no longer
exist in more recent JDKs.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Avoid "Last updated [timestamp]" footer on each docs page
Set Asciidoctor option 'nofooter' to avoid the annoying timestamps. It
makes updating the website difficult, because always there are "changes"
in each file. Diffing real changes in generated files for the website
before committing becomes difficult. Furthermore, the user does not have
any immediate benefit for most documents, as they change infrequently or
never (e.g. old release notes).
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add missing release notes for 1.8.12, 1.8.13, 1.8.14
I found those in HTML only on the Eclipse web server, but not in the Git
repository. So, I manually converted them to ADOC.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Mapping file for Git committers, mapping e-mail addresses to names for
'git shortlog -sne'. See https://git-scm.com/docs/gitmailmap.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Globally replace "http:" by "https:" in non-XML files
Maybe, the XML files and Maven wrapper files will follow. First, let us
find out if this breaks the build, maybe some tests are asserting on
"http:". But there, the replacement would also have taken place, so
probably it just works.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace links to https://www.eclipse.org/aspectj/doc/next
This part of the website is outdated and will be deleted. Instead, link
to ADOCs right in the GitHub repository.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Classes and methods named '_' are no longer allowed in ECJ, obviously
also not for old target versions like 1.5. This probably is due to
the added support for unnamed patterns and classes in the latest
upstream JDT Core merge. Therefore, we simply rename '_' to '__'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
AjCompilerOptions: Increment irritant levels to GROUP4
Needs eclipse-aspectj/eclipse.jdt.core#ed6050bb.
See also eclipse-jdt/eclipse.jdt.core#2006.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Store only weaved class names in the generatedClasses map
The generatedClasses map contained both keys of woven classes that had
generated classes associated with them, and the keys of the generated
classes themselves. It seems like this map is never consulted for the
generated class key - the generated class is generated from within the
context of woven class loading / retransformation, and thus no transform
event is generated for it by the JVM. Because of that, we do not need to
guard against re-weaving it. Other uses of generatedClasses map are for
full/empty tests, where the woven class key is sufficient. This change
simplifies deletion of a class because we do not have to look for its
associated generated classes.
Relates to #279.
WeavingAdaptor.couldWeave() tested two things: whether this specific
class (by its name) should be excluded from weaving, and whether the
class has generated classes associated with it (in which case we avoid
weaving to avoid re-creating those generated classes). However, if the
class has generated classes associated, couldWeave() is not called at
all because of the new wovenWithGeneratedClass() test, so we have
only the name test which is now called directly.
Relates to #279.
Use previous weaving result if classes were generated during weaving
A parallel-capable class loader might load the same class multiple times
in multiple threads, see
https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html.
In this scenario, the JVM instrumentation mechanism invokes the AspectJ
weaver twice on the same class. In simple weaving scenarios, this would
just cause weaving logic to run multiple times and produce the same
result for each thread, but if the weaver is generating new classes,
it is undesirable to generate those classes multiple times.
To avoid this, the generatedClasses map in WeavingAdaptor keeps track of
classes for which inner classes were generated and avoids re-weaving
them. However, before this change, if a class was found in the generated
map, the weaver would return the un-woven bytes, which would cause
AspectJ not to work for some of the threads.
This change returns the woven bytes instead of re-running weaving.
Fixes #279.
Change value of woven class in generatedClasses map
Store the woven class and not a generated (inner) class as value of the
woven class name. This has no effect in this commit, because the value
is not consulted at all, but will be used later on.
Relates to #279.
Test "same class woven concurrently in parallel-capable classloader"
reproduces #279. Originally taken and modified from:
https://gitlab.com/urisimchoni/aspectj-parallel-issue
Co-authored-by: Uri Simchoni <urisimchoni@gmail.com>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Weaver returns null instead of original bytes for unwoven classes
This change makes sense independently of #277, but also enables using
- cp "my.jar;aspectjweaver.jar"
-XX:+AllowArchivingWithJavaAgent
-javaagent:aspectjweaver.jar
while creating a CDS archive. Afterward, the application can be run in
its woven state from the CDS archive even without '-javaagent', because
the byte code was archived in its woven state ("poor man's AJC"). See
https://github.com/eclipse-aspectj/aspectj/issues/277#issuecomment-1931142753
for details.
Fixes #277.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
coactions/setup-xvfb no longer seems to be necessary, because XVFB is
now pre-installed on Linux.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
On my workstation, more recent JDKs generate partly German javadocs.
Background: Avoid non-English javadoc generation. Due to
https://bugs.openjdk.org/browse/JDK-8222793 reoccurring at least in JDKs
19-21 and also being broken in some older JDKs, we cannot rely on just
setting the locale parameter, but also need the 'user.language' and
'user.country' parameters in 'additionalJOptions' as a workaround.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch
Uri Simchoni