Jigsaw unfriendly + source/class file mismatch
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- java
- Domain
- build-system
Research direction
Start by comparing the contents of swinglibrary-2.2.2.jar with the 2.2.2 source zip, then inspect the dependency javalib-core-2.0.3.jar. Check the unnamed-package classes, OptionalArgsForTableCellClicking.class, and the referenced ArrayUtil class. Done means the source, binary, and dependency artifacts are consistent, or the remaining discrepancies are documented with a clear resolution.
Written by the indexing model from the issue text.
Description
I list here some issues I've encountered trying to resolve classloading problems with swinglibrary-2.2.2.jar under Java 11...
While I'm not strictly trying to make this load as a java module, I am getting classloader errors that I'm having difficulty pinning down, thus I'm taking a close look at how all the bits fit together, and either I'm confused, or the parts I'm working with have issues.
Things I'm seeing:
-
Contains classes in the unnamed package, specifically: SwingLibrary.class and TestSwingLibrary.class
Jigsaw requires all java classes live in proper packages. -
The jar for swinglibrary-2.2.2 (from https://repo1.maven.org/maven2/org/robotframework/swinglibrary/2.2.2/swinglibrary-2.2.2.jar ) contains org/robotframework/swing/keyword/table/OptionalArgsForTableCellClicking.class This class file is not in the corresponding source zip (from https://codeload.github.com/robotframework/SwingLibrary/zip/refs/tags/2.2.2)
-
The above class file from the jar refers references org.robotframework.javalib.util.ArrayUtil which should live in the dependency javalib-core-2.0.3.jar. This dependency has the package org.robotframework.javalib.util, however ArrayUtil is absent from it.
I don't know if there's more discrepancies between source code and output. If however the source calls itself 2.2.2 and the binary calls itself 2.2.2, I'd expect them to represent the same thing.
Usually, I can use programmatic crowbars and sledgehammers to make arbitrary jars play nice with java modules/jigsaw, but what I'm encountering here are a mix of issues interfering with that goal, of a sort that I'd really rather not touch.
- Dominant language
- Java
- Stars
- 117
- Forks
- 69
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MarketSquare/SwingLibrary
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
MarketSquare/SwingLibrary#169 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
MarketSquare/SwingLibrary#171 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 50/100
MarketSquare/SwingLibrary#166 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
MarketSquare/SwingLibrary#161 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
MarketSquare/SwingLibrary#155 · 1 comment ·
All issues in MarketSquare/SwingLibrary
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
opensearch-project/k-NN#3597 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100