I have written a piece of code where I'm checking the size of an ArrayList like:
[1,2,3].size
All works well on Groovy Console and with Grails embedded Tomcat server. But once I deployed this code to Websphere Application Server, I receivec an exception stating
Exception evaluating property 'size' for java.util.ArrayList, Reason: groovy.lang.MissingPropertyException: No such property: size for class: java.lang.Integer.
After a while of debugging, testing and plenty of WTFs, I realized that there were parenthesis missing from the method call. The property notation should not work as there's no method getSize() for Collection (it's plain size()) and this all makes sense.
What's puzzling me, is why does someCollection.size work on Groovy Console and Grails?
Grails and Groovy Console version is 2.3.6
ArrayList in (at least) the Sun JDK 1.7u67 and in OpenJDK 1.6 holds a private int size, which is accessible to groovy. If your other environment uses another JDK, this var might not exist and groovy would fallback to the interpretation of [1,2,3]*.getSize(), which then fails.
Related
I am attempting to upgrade from Wicket 9.0.0 to Wicket 9.3.0. When I change the version in a quick-start application, everything is fine.
The problem occurs in my real application, where we were originally using Jakarta Enterprise Beans 8.0.0. At runtime, when a database access was attempted, we got an exception with the following message:
Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]
Trying to use Jakarta EE 9.1 instead
I changed my pom.xml as follows:
<jakartaee>9.1.0</jakartaee>
<wicket.version>9.3.0</wicket.version>
I downloaded the jar for Jakarta EE 9.1, changed "javax" to "jakarta" throughout my application, rebuilt it and tried to run again.
The result was still not perfect, but significantly better than before: a plain old null pointer exception instead of any weird errors about cglib.
Here's the section of code that now causes the trouble:
#EJB(name = "AdminNotesFacade")
private AdminNotesFacade adminNotesFacade;
public AdminNotesFacade getAdminNotesFacade() {
return adminNotesFacade; //ACTUALLY RETURNS NULL
}
So now the big question is: what do I need to do/change to make the #EJB work instead of returning null?
Checking the Payara log, I get this error:
java.lang.RuntimeException: Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for D:\Dev\icase2\target\icase2.
If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected
at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:189)
Adding further details, 2022-05-06
I wonder if we were going off on the wrong track when we thought that we could fix this by upgrading our jakartaee version. From Wicket 9.0 to 9.3 is only a change of minor version and you wouldn't expect to have to make such fundamental changes to get a minor upgrade working.
I've tried using Wicket 9.9.1 instead, in case this problem has been fixed in more recent versions, but it's exactly the same.
Anyway, I have created a very small "quick-start" application, based on Wicket's own templates, to reproduce the problem. I have stuck with the original "javax" version, and added just one EJB - a JavaMail bean. I think it's probably interesting to know that it's not a specifically database-related issue. We just can't seem to load any EJBs at all.
In the Wicket 9.0.0 version, a simple form is displayed on the home page, allowing the user to enter their email address. When they submit the form, a test message is sent to that address. It works fine.
Then if I change the Wicket version to 9.3.0 but make no other changes at all, it doesn't even get to the stage of displaying the home page, it immediately crashes with the message "Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]"
For what it's worth, here's the code that triggers the error.
public class HomePage extends WebPage {
#EJB(name = "EmailerFacade")
private EmailerFacade emailerFacade;
private static final long serialVersionUID = 1L;
private String sendTo = "";
public HomePage(final PageParameters parameters) {
super(parameters);
add(new Label("version", getApplication()
.getFrameworkSettings().getVersion()));
FeedbackPanel feedback = new FeedbackPanel("feedback");
add(feedback);
final Form emailForm = new Form("emailForm") {
#Override
protected void onSubmit() {
emailerFacade.sendMessage(sendTo, "Test message from quick-start",
"Version is " + getApplication().getFrameworkSettings()
.getVersion());
info("Tried to send message to " + sendTo);
}
};
add(emailForm);
final TextField<String> emailAddress = new TextField<>("emailAddress",
new PropertyModel<>(this, "sendTo"));
emailAddress.setLabel(Model.of("Email address"));
emailAddress.setRequired(true);
emailForm.add(emailAddress);
}
}
Wicket 9.x is based on javax.servlet APIs. To deploy it on jakarta.servlet supporting web container you will need to migrate the bytecode with a tool like https://github.com/apache/tomcat-jakartaee-migration.
I am not sure whether Payara does something smart at runtime to support both javax.** and jakarta.** classes.
Tomcat 10.x supports migration of the classes at application start time by deploying your app in the special $CATALINA_HOME/webapps-javaee folder.
This answer was actually provided by Sven Meier. He commented:
Use the new system property to switch to ByteBuddy in Wicket 9.x:
-Dwicket.ioc.useByteBuddy=true
To expand a bit on this, I found I needed to do three things:
Set the system property "wicket.ioc.useByteBuddy" to true as specified by Sven
Add a dependency on byte buddy
Upgrade to a higher version than I was initially attempting to do: 9.3.0 was not good enough. I see in a comment above by Sven, he says that the migration to byte buddy was actually done in 9.5. So in fact I upgraded to the latest version, which is currently 9.9.1.
Here is the dependency on byte buddy that I added:
<dependency>
<groupId>net.bytebuddy</groupId>
<artifactId>byte-buddy</artifactId>
<version>1.12.10</version>
</dependency>
My spring web application is using servlet api 2.5 along with spring framework 4. Its deployed in tomcat 9. Its working fine. I am not sure why tomcat is not complaining about it as it needs servlet api 4 as per documentation. Is it backward compatible or spring is doing some magic? Just for clarity We are using interfaces from servlet api 2.5 in our code which should not compile with servlet api 4. It is compiling because we are compiling with 2.5 but we are expecting it to fail at runtime in tomcat. Thanks
Are you using methods/classes that no longer exist in servlet spec 4? There isn't magic - it's downward compatible. If you tried to run, for example, AsyncEvent code in Tomcat 5.5 (servlet spec 2.4) then yes, you'd have a problem. But running old code on a new server - without using things that have totally changed or disappeared - is rarely a problem.
EDIT
You said that the "old" code has:
Map parameterMap = request.getParameterMap();
This is still valid if not best practice. With newer compilers you may get a warning from the compiler that you are not using generics but it is still valid. And since the Javadocs from that time say:
Returns: an immutable java.util.Map containing parameter names as keys and parameter values as map values. The keys in the parameter map are of type String. The values in the parameter map are of type String array.
So your old code must be casting the keys as a String and the values as a String[] - just like the newer code that would be:
Map<String, String[]> parameterMap = request.getParameterMap();
Both versions will compile in recent versions of the compiler though, again, you may get warnings with the code that doesn't take advantage of generics.
The key is the use of generics - the <String, String[]> part. It's clearer code when using generics and the compiler can help with issues. With the non-generics version you could have tried to cast the key in the map to any object. It would compile but at runtime you'd likely get a ClassCastException.
From the perspective of Tomcat it's still returning the same thing.
Is that clearer?
I'm trying to migrate a program from java 8 to java 9.
In my program I found the following code.
//Run JavaFX Application Thread/Toolkit
PlatformImpl.startup(() -> {
});
It tries to start the JavaFX Toolkit
Unfortunately, the PlatformImpl.startup is no longer supported in java 9.
Which substitute is there for it?
How can I start the JavaFX Toolkit?
Thank you
The startup() method is one of the methods that was promoted from the non-public class PlatformImpl to the public API Platform class in the Java 9 release. It is now fully documented in the API documentation.
Thus the equivalent call in Java 9 is
Platform.startup(() -> { });
Note that the use cases for this method are fairly rare, and the API docs go to some lengths to emphasize this:
In general it is not necessary to explicitly call this method, since it is invoked as a consequence of how most JavaFX applications are built.
...
As noted, it is normally the case that the JavaFX Application Thread is started automatically. It is important that this method only be called when the JavaFX runtime has not yet been initialized. Situations where the JavaFX runtime is started automatically include:
For standard JavaFX applications that extend Application, and use either the Java launcher or one of the launch methods in the Application class to launch the application, the FX runtime is initialized automatically by the launcher before the Application class is loaded.
For Swing applications that use JFXPanel to display FX content, the FX runtime is initialized when the first JFXPanel instance is constructed.
For SWT application that use FXCanvas to display FX content, the FX runtime is initialized when the first FXCanvas instance is constructed.
When an application does not follow any of these common approaches, then it becomes the responsibility of the developer to manually start the JavaFX runtime by calling this startup method.
Calling this method when the JavaFX runtime is already running will result in an IllegalStateException being thrown - it is only valid to request that the JavaFX runtime be started once.
So, while you are in the process of making the changes you need to update your application to be Java 9 compatible, you might want to carefully consider if you need to call startup() at all; maybe there is a more standard and robust approach to starting your JavaFX application anyway.
ISSUE: StackFrame.GetMethod() returns a property name prepended with unknown characters (myProperty returned as __XY_myProperty).
Recently we have added a property to an existing class. This class is used in ASP.NET. Every property in this class calls a custom securitycheck function that uses stacktrace to get the method name of the callee to perform actions based on that name.
The issue is, StackFrame returns this newly added property name (myProperty) prepended with unknown characters (__XY_myProperty) during the runtime. This happens only on a production machine. We couldn't reproduce in any other machines that have similar settings.
Here is a sample of code:
// comments
public returntype myProperty
{
get
{
security.checkSecurity();
return returntype();
}
set
{
security.checkSecurity();
if (value == null)
{
Row["abc"] = anothervale;
}
else
{
Row["xyz"] = value;
}
}
}
// comment
StackFrame.GetMethod() call in security.checkSecurity() returns myProperty method name as: __XY_myProperty
(StackFrame.GetMethod() call not shown in the above example.)
What we tried is:
Cleared ASP.NET Caches
Compared .NET patches
Restarted the server
None of these resolved the issue.
Server Info:
Windows 2003
Runs on VMWare (Does JIT optimizes differently on VMWare?)
IIS 6
NET 3.5
ASP.NET project built in release mode
DLLs compiled in debug mode to make stacktrace behave properly
The answer is:
A profiler that installed on the machine was altering the MSIL code for code instrumentation.
Code instrumentation is the process of being able to modify the code as it is being given to the .NET runtime for execution. When the CLR loads a class and executes its method, the method's IL code is compiled to native instructions during the just-in-time (JIT) compilation process. The Profiling API provided as part of the CLR allows you to intercept this process. Before a method gets JIT-compiled, you can modify its IL code.
Solution: Uninstalled the profiler and everything works fine. It proved StackTrace is not dependable.
I know a bit about JDK and JRE source and binary compatibility (e.g. this and this), but not sure about the following situation:
Consider I have an application which is compiled using JDK5 and runs on JRE6. It uses some libraries (jars) which are also compiled using JDK5.
Now I want to compile my application using JDK6. What new problems could arise in runtime in such a case (particularly, in compatibility with the "old" jars)? Should I fully retest the application (touch every library) or can rely on promised JDK/JRE compatibility?
Normally no problems should arise if you set the compiler option of JDK6 to use 1.5 source compatibility. However sometimes this is not always true.
I remember once when compiling 1.4 code with 1.5 compiler (using 1.4 compatibility). The jars where ok (1.4 binary level) but the application crashed due to a funny conversion.
We used a BigDecimal number passing an integer as argument to the constructor. The 1.4 version had only a constructor from double but the 1.5 version had both, the int and the double constructors. So when compiling with 1.4 compiler made the automatic conversion from int to double, but with the 1.5 compiler it checked that the int constructor existed and did not realize that conversion. Then when using the perfect binary compatible code on 1.4 JRE the program crashed with a NoSuchMethodException.
I have to admit that it was a strange case, but it is one of those cases where logic does not work. So my advice is if you plan to compile for older versions of JRE try to use the target version JDK whenever possible.
Untill and unless you have not changed your code and added new Java 6 features, there should be no issues.
With regards to other jars there should be no issues at all.
JDK always maintains backward compatibility.
Compatibility mostly works. I would not expect any issue for you to arise aside from various warnings for e.g. not using generics. Maybe some barely used APIs were deprecated, but I assume they were left in place, just marked as deprecated.
Just try it, if it compiles you should be fine.
A key design aspect of Java - unfortunately - is full backwards compatibility.
There are very few exceptions where backwards compatibility was not preserved; most prominently Eclipse suffered when the sorting algorithm was changed from a stable to a non-stable sort algorithm (the order of objects that sort identically was no longer preserved); but that was never part of the Java specification, but a bug in Eclipse.
It's unfortunate, because there were a few poor choices that now cannot be changed. Iterator should not have had a remove() function in the API, Vector should not have been synchronized (solved by having ArrayList now), StringBuffer should not have been synchronized, hence StringBuilder. String should probably have been an interface, not a class, to allow for e.g. 8-bit strings, 32-bit strings - CharSequence is the better string interface, but too many methods do not accept CharSequence and require returning a String. Observable should be an interface too: you cannot make a subclass observable with this API. To name a few. But because of backwards compatibility, these cannot be fixed anymore until maybe JDK modularization (at which point some can at least disappear into an donotuse module ...).
Of course you should already have thousands of unit tests to help you test with the new JDK... :-)