Byte buddy says that it works with java 9, there is even code for it: ByteBuddyAgent.install(ForJigsawVm.INSTANCE)
I use simple ByteBuddyAgent.install() that should check all possibilities (including java 9/jigsaw), but it fails.
I'm doing something wrong? Or it doesn't support java 9 yet?
The support for Java 9 is still experimental but the recent versions of Byte Buddy support attachment on recent ea builds of Java 9:
Instrumentation instrumentation = ByteBuddyAgent.install();
Make sure that you are:
Running a recent version of Byte Buddy.
Running a recent version of Java 9.
Do however note that Byte Buddy cannot yet process Java 9 class files due to ASM not supporting it. If you require it, use the byte-buddy-dep package and explicitly add a dependency to ASM in version 6.0_ALPHA. Doing so, allows you to use Byte Buddy on Java 9 with close to no limitations (I am still evening out some edges).
Related
Alrighty, so I'm working on an older application that was built using Enterprise Library 5 and am updating it to use the latest version (6.0.1304). However, I'm running into an issue in a few of the data access pieces that are trying to use EnterpriseLibraryContainer like so:
EnterpriseLibraryContainer.GetInstance(Of Database)(ConfigurationManager.ConnectionStrings("SomeDatabaseWeUse").Name)
My question is, what is an example of replacing this older code?
I did see this
The bootstrapping code for all of the blocks has changed in version 6 of Enterprise Library. The blocks no longer use Unity to manage the initialization and configuration, and each block now includes its own bootstrapping code. Any calls to the EnterpriseLibraryContainer.Current.GetInstance method to resolve a type from one of the Enterprise Library blocks should be replaced with the block specific bootstrap code.>
Buuuuut I couldn't find any examples particular to GetInstance so maybe I completely understand what it means to replace it with block specific code :x
Solution I ended up using:
Dim factory As DatabaseProviderFactory = New DatabaseFactory
db = factory.Create(ConfigurationManager.ConnectionStrings("SomeDatabaseWeUse").Name)
After using the sample code want to generate the HTML for the plot plot.makeFile() throws the below exception even passed a custom path still there are errors in generating the HTML file using
implementation("kscience.plotlykt:plotlykt-core:0.2.0")
Exception in thread "main" java.lang.NoSuchMethodError: java.nio.file.Path.of(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;
at kscience.plotly.PlotlyHeadersKt$systemPlotlyHeader$1.invoke(plotlyHeaders.kt:39)
at kscience.plotly.PlotlyHeadersKt$systemPlotlyHeader$1.invoke(plotlyHeaders.kt)
at kscience.plotly.HtmlKt.toHTML(html.kt:34)
at kscience.plotly.FileExportKt.makeFile(fileExport.kt:53)
at kscience.plotly.FileExportKt.makeFile$default(fileExport.kt:49)
at UndefinedKt.main(Undefined.kt:30)
at UndefinedKt.main(Undefined.kt)
The method used here is introduced in Java 11: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#of(java.lang.String,java.lang.String...)
You need to use JDK 11 or newer to run it. If I remember properly, newer versions won't even work with something below JDK 11. So just use newer JDK. If for some reason you are not able to do so, please open an issue here: https://github.com/mipt-npm/plotly.kt/issues. We can roll back to 1.8 bytecode.
Since upgrading from Domino 9 to 11 some LS-Agents crash the server on calls to C API functions.
We're running Domino 11.0.1 64 bit on AIX 7.2
First we thought about a change in handle sizes and switching from 32 bit to 64 bit fixed some calls. But other calls needed a switch from 32 bit to 16 bit to work. Strange! (In fact the declared size should make no difference, as long as its big enough for the actual value, because all arguments are passed as 64 bit on 64 bit machines - at least in this case)
I've tested the calls from Java using JNA - everything works as expected with 32 bit handles. So C API seems to be OK, but LS C callout seems broken.
Does anyone else notice this behaviour? Or is it just us?
Just in case anyone else runs into this issue:
SPR #ASHEBSVQ72 (not online visible by now)
It's a regression bug with C callouts from LS on AIX. Has been there since Domino 10. Strange thing nobody but us ran into this problem.
No easy workaround known. Wait for a fix or use JNA in Java for callouts.
I've been filling myself up with notes trying to successfully create my first program on Windows 7 with NASM, but with a few self imposed stipulations (until I'm ready to move forward). In creating this first program, however, I have a ton of questions.
.
The stipulations for now are that:
I'm running Window 7 SP1 - 64-bit
I do not wish to use DOSBox so Interrupts 0x21-24 are likely not applicable
I do not wish to rely on C so this is all NASM
I would really like to avoid downloading Visual Studio or associated WDK tools if I can (this depends on whether or not I NEED to interact with the Windows API and relates to Question 2 below)
I've downloaded and installed MinGW
I'm writing my code in Notepad++ and saving as *.asm
I am linking using "ld" for now, but from what I've read, most seem to recommend "GoLink" (and Alink hasn't been updated in years?). I'll probably migrate to GoLink after I've assured myself that "ld" may be too limiting
I want to know if printing is possible without the use of the Windows API or C because of the code below?
.
The only code example that has worked for me in some capacity can be found here.
nasm is not executing file in Windows 8
.
;FILE: main.asm
[section] .text
global _main
_main:
mov eax, 6
ret ; returns eax (exits)
Linked:
c:\Users\James\Desktop>nasm -fwin32 main.asm
c:\Users\James\Desktop>ld -e _main main.obj -o main.exe
c:\Users\James\Desktop>main.exe
c:\Users\James\Desktop>echo %errorlevel%
6
.
My questions (a ton):
The fact that in the code above "ret" by itself gives output, although it just returns whatever is in EAX, is there a way to use it (or another directive outside of the Windows API) to return the contents of a variable (hopefully a string variable)? I tried to use ret with DOS calls, but as noted above, that definitely doesn't work because I'm on a 64-bit system.
In case I absolutely must use the Windows API, is the only way to interact with it by using the WDK tools? Is there some other way because that last time I downloaded Visual Studio and associated WDK tools it took up a ton of memory and massively slowed down my computer. Is there another way to make programs give output or print to the screen either by using internal commands or some other method to use API calls? One thread I admittedly skimmed (amidst 40 more tabs I have open) mentions "Russinovich's Windows Internals" but not a direct answer. At current every time I use code with the extern commands "ld" tells me that the references to commands like WinMain/WinMain#16 are undefined. In the same vein is there a table I can consult containing accurate calls to the API (i.e. _ExitProcess#4 vs. ExitProcess). I found this link to what think may be the NT API but I'm not sure it applies given my stipulations, but in reality, I'm just kind of confused:
http://j00ru.vexillium.org/ntapi/
In bits of code I've encountered I've seen directives for [Bit 16], [Bit 32], and [Bit 64]. [Bit 16] is likely ignorable, but I'm confused by the [Bit 32] and [Bit 64] for the following reasons which may not even be related: Via the code above I'm using the command, "nasm -fwin32 main.asm", then I'm linking it successfully and going on to receive output. For some reason - though I have not read the full "ld" documentation yet - when I use the command "nasm -fwin64 main.asm" and link it in the same way I receive an error saying "main.obj: File not recognized: File format not recognized". I don't understand why differentiating between 32 and 64 while I'm on a native 64-bit machine causes an error although this probably is just unique to ld.
.
In the meantime I'll be reading this question and will post an update it if helps: Executable isn't compatible with 64 bits processor
I can't answer some parts in great detail, so I expect somebody either putting up better answer, or feel free to edit this one.
you are linking against default clib, so your _main is called after Clib is initialized, the ret with value in eax is like return 6; in C++. Then Clib correctly destructs everything and calls windows exit process with exit code 6. You can return only int from _main, and I'm not even sure if full int is propagated to exit process call, or only 8 bit value is used. So you can return single char in ASCII encoding, if you treat that number as char.
You must call Windows API, if you want to display something in console/window, or write something into file, ie. do any output (and of course also for input). There's no peripheral available to win32/64 executable directly, like in DOS CGA/EGA/VGA text modes accessible trough int 10h or video ram at B800:0000. Any try to access some I/O peripheral directly should result into access violation. Only Win API should be legal for user-level application code.
How much of WDK you need I have no idea, haven't developed anything for windows for years. I think it's even possible to create executable without WDK, which would provide correct externs and dependencies on kernel32.dll and similar, but the amount of effort is way beyond simply using proper parts of WDK or clib from MinGW.
I think your linker is set to default to 32b executable, you have to figure out what kind of object format is produced by nasm for -fwin64 and how link that one with ld.
Why the difference. The 64b OS can run 32b binaries. But you can't mix 32/64 in single executable so easily (if at all). So you are either producing 32b or 64b binary, and you have to adjust everything to it (asm instructions used, directives and options, and WinAPI calls).
I am using Checkstyle Plug-in 5.7.0 in eclipse with Java 8. I am getting Got an exception - expecting EOF, found 'throw' in my interface default method. Can you please help me how to fix my checkstyle. Following is the method
default void validate(final String fieldName) {
if (StringUtils.isEmpty(fieldValue)) {
throw new RuntimeException(""); //check style error here
}
}
Even if I remove the method body, i get the same error on the ending brace. It seems that checkstyle is not supporting a method with body in interface.
That is not your fault - Checkstyle does not support Java 8 syntax yet. (This is true for version 5.7, which is the most current version at the time of this writing.)
However, the Checkstyle team and especially the contributors are working hard on it, and Java 8 support is announced to be released before October 15, 2014 (according to the October 4 comment by Roman Ivanov, one of the Checkstyle committers).
So, think the best strategy is to wait for a few more days. :-)