#SQLite database gets malformed on compile
pulsar scroll
is the idea you shade the database
pulsar axle
Correct, it should provide a working local DB if it cannot connect to the remote one
I however am apparently stupid and for whatever reason it breaks when compiling lmao
pulsar scroll
is the database file in the jar, but just corrupted?
or is it like 0KB sorta thing
pulsar axle
Correct, the remote and the one in "resources" work but the one that's put in the jar while the right size is considered malformed.
I assume something in the build process
oh wait
hold tf up, it's got an extra 20 KB tf
340 kb is the original 360 is the modified one
pulsar scroll
i mean, seems like a maven issue then. I guess it could be incorrectly interpreting the data
proven marsh
pulsar axle
I do use <filtering>true</filtering> actually
Literally just used for current_version=${project.version} but tbh I need to see if that's even used lmao
pulsar scroll
love the arrow xD
proven marsh
you could try to separate it
pulsar axle
lmao it's not
pulsar scroll
pulsar axle
I assume I had a reason for it, but I don't remember what lol
Okay yea, it was because of the filtering thing @proven marsh
proven marsh
Nice!
pulsar axle
*probably something stupid*
I was right lol
Or not, realized that I was still connected to the network lmao @proven marsh
pulsar axle
Seems like a fair bit gets changed
pulsar axle
Well, how would I find that out?
Nothing encoding wise gets changed on compile afaik
proven marsh
lemme google that >->
pulsar axle
okay so
pulsar axle
<compilerArgs>
<arg>-XDignore.symbol.file</arg>
</compilerArgs>
<fork>true</fork>
Something to do with that lmao
proven marsh
yea probably
pulsar axle
I commented that out, it works. Dunno why, but it does lol
pulsar axle
I have found the answer myself.
When javac is compiling code it doesn't link against rt.jar by default. Instead it uses special symbol file lib/ct.sym with class stubs.
Surprisingly this file contains many but not all of internal sun classes. In my case one of those more-internal-than-usual classes was sun.awt.event.IgnorePaintEvent.
And the answer to my question is: javac -XDignore.symbol.file
That's what javac uses for compiling rt.jar.
Is there a way to disable restrictions of javac 1.6.0_22 that prevent me from using JRE internal classes like sun.awt.event.* ?
I'm not looking for:
an explanation why it is forbidden.
suggestion to use different classes
suggestion to use reflection
suggestion to use ecj/eclipse
I just want to know if it is possible or not, and if it is then how.
proven marsh
oh ok
pulsar axle
So it's used to allow using internal classes, which I assume I did or was planning on doing at some point
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
<configuration>
<source>17</source>
<target>17</target>
<compilerArgs>
<arg>-XDignore.symbol.file</arg>
</compilerArgs>
<fork>true</fork>
<showDeprecation>true</showDeprecation>
</configuration>
</plugin>
Was this part
proven marsh
so it works now?
pulsar axle
as for <fork>
true means it will create (fork) a new JVM to run the compiler. This is a bit slower but the isolation is better.
Especially you can specify a different JVM than the one Maven is started with, and you can also specify command line parameters (for increasing Heapsize or Metaspace) only in this case. In your case it causes problems as it seem to use the wrong JVM, you could specify the full path with <executable> or a toolchain configuration.
This is one method to use a modern Maven which does not run with Java 1.6, but still use a clean compile environment for older source/target versions.
false means it is startign the compiler directly in the JVM you have run maven with, this makes the build less repeatable.
and yea