Speak from technical standpoint of view, whether it is possible to access an internal class inside a third-party jar?
i have try out the '-Xfriend-paths', but it seems it does not support anything like
kotlinc -Xfriend-paths=xxxx.jar ...
Can any one point me some directions
It's impossible to access internal members (which is a good thing). See this discussion for more details.
You may have run into this Kotlin bug: https://youtrack.jetbrains.com/issue/KT-29933
Try again using an absolute path, or making sure that your Kotlin version is at least 1.3.70.
Related
I have been searching the official docs and existing questions and could not find any information on this - in Elm, how it would be possible to see the members/methods/variables that belong to or are exposed by a package in Elm, (such as the dir method in python), without having to dive into the source code each time?
What I want to do is get a simple list of what methods are exposed by an imported package. (So for a package like List, it should output reverse , all, any, map, etc.) I have attempted tab completion in elm repl and the elm extension available in VS code editor, and elm repl does not offer any methods such as help, doc, ?, dir, man, etc., so I have no idea where to even start. I'm wondering how everyone else does this other than pulling up the source code for each and every package they use.
I apologize for the newbie question and if I misread or have been missing anything, but I couldn't even find anything in the https://elmprogramming.com tutorial. Thanks in advance.
Nothing like this exists in Elm to do reflection over modules, unfortunately (as of 0.19.1, at least).
However, if you aren't looking to actually do this kind of thing at runtime, but rather as a convenient way of finding out for development, the elm packaging system enforces the requirement that all public functions are documented, so if you visit the package page, every public function and type will be documented there (obviously it can't enforce the content of the documentation, but at the very least it will be listed).
I'm trying to update a software system to JDK-11 using modules, and everything was going just fine right up until I slammed head-on into the aforementioned issue.
I have a legacy signed JAR that I need to incorporate for interaction with legacy systems. There's no way to update the JAR and no way to get a new version. The JAR must be signed in order to be usable (the whole "trusted code" deal and whatnot). The problem is that the JAR contains classes in the unnamed (root) package. Yeah. Stupid. Bad practice. Blablabla. It's still there, and I still need to use it.
I've not found any documentation or answers anywhere that would remotely suggest that what I need is possible. In fact, the opposite is true: everyone is adamant that in the "new"(ish) module system, no class may reside in the unnamed package.
Needless to say I'm unable to both modify the contents of the JAR, or get at the sources to render a new one - that's without even considering the issue of the signature...
That said: I refuse to believe the folks at Oracle would leave such a glaring oversight with regards to legacy code. As we all know, a lot of the time we have no choice but to use it for legitimate reasons, and we can't do anything to fix/update/refactor/etc... I would have hoped there was a mechanism added to the module system to support this, albeit for extreme cases only, etc...etc...
Disclaimer: I do fully understand why this isn't meant to be supported. What I'm having a hard time with is the lack of a workaround...
Thanks!
I've already tried:
creating a facade module that transitively adds the offending module (obviously no dice, same problem)
unpacking-and-repacking the module while temporarily disabling signature validation in a test env (fails because the class is apparently referenced within many other, properly-organized classes)
finding an updated module (no luck here, either)
beheading a chicken and roasting it over a pentagram while invoking the aid of ancient pagan gods (tasty, but didn't fix it)
curling up in a ball under my desk and weeping until execution succeeds (that's where I'm typing this from)...
We are migrating our application from Eclipse Indigo to Photon and I need help find a solution or alternate for a particular class which is present in Indigo but not in Photon.
The class we are trying to figure out is org.eclipse.ui.internal.navigator.AdaptabilityUtility.
Since it is an Internal class it is not available. But we had no luck finding an alternate.
Only one function of the class is used :
IAdaptable openable = (IAdaptable) AdaptabilityUtility.getAdapter(
selection.getFirstElement(), IResource.class);
If someone knows an alternative method which can be used here, it will be a great help.
Eclipse internals were completely rewritten for Eclipse 4 so in general there may not be exact alternatives for internal classes which were never part of the official API.
However for AdaptabilityUtility it looks like the current org.eclipse.core.runtime.Adapters class should work:
IResource resource = Adapters.adapt(selection.getFirstElement(), IResource.class);
Adapters.adapt uses generics so casts are not needed. Adapters is not internal so it is an official API.
For some reasons, I'd like to play around with an alternative implementation for the jupiter-engine.
Now, for some reason I have the impression that at least IntelliJ automatically adds the default jupiter-engine to the test execution class path even though if I only added the jupiter-api (in gradle).
I'd expect that, if I don't add an engine manually to the class path, I just should NOT have an engine.
Is this true? Is this by-design? Or am I plain wrong?
I didn't find any explanation in the reference, but when I type impl in IntelliJ IDEA, I get an error:
It seems that it's treated as a reserved word, but what's it for?
I tried putting many kinds of stuffs after impl but I get the error every time.
Update: It's renamed to expect after Kotlin 1.2.
It's for future multiplatform project support, and it's the pair of the header keyword which #hotkey explained in their comment here. It appeared in one of Andrey Breslav's presentations which you can find here, this specific topic starts at the 14:25 mark.
To sum it up briefly, the basic idea he presents is that you could have a common module shared between your platforms, in which there are some functions that are declared but not implemented, and are marked with the header keyword. Then, for the different platforms (JVM, JS, etc) you could have separate modules that implement these functions in platform specific ways - these actual implementations are where the impl keyword would be used.
He says that this whole system is just an internal prototype for now, so this presentation is probably all the public info we have about it. I'd also be interested in more details about this mechanism though :)
Update: as of the Kotlin 1.2 Beta, these keywords have been now replaced with expect and actual.